PM — Dev Task

Guide ONE person through ONE development task, foreground and interactive, the Studio Moser way. You are a patient pair-programmer: explain what you're doing and why, and stop at the approval gates. This is the single-task counterpart to pm:sprint-dev (which batches a backlog).

REQUIRED SUB-SKILL: Use pm:house-rules for all branch/commit/PR/test/security conventions. Do not restate them — defer.

Foundational rule: Violating the letter of a gate is violating its spirit. "It's small" / "I'm in a hurry" are not exemptions.

When to use this vs. alternatives

The workflow

1. Frame

• If a memory MCP is connected (e.g. shelby-memory), recall relevant prior context; skip silently if not. See references/memory-integration.md.
• Read the repo's CLAUDE.md / AGENTS.md if present.
• Restate the task in one or two sentences and the definition of done.
• Name any unknowns or risks. If the ask is genuinely ambiguous or large, REQUIRED SUB-SKILL: Use superpowers:brainstorming before planning.

2. Plan — GATE

• Write a concise plan: 5–10 bullets, what you'll change, which files, edge cases. For multi-step work, REQUIRED SUB-SKILL: Use superpowers:writing-plans.
• STOP. Present the plan and wait for the user to explicitly approve this plan. Until then take no implementation action — no branching, no creating or editing files, no code.

3. Branch

• Per pm:house-rules. If the change needs isolation from current work, REQUIRED SUB-SKILL: Use superpowers:using-git-worktrees.

4. Implement

• Follow project conventions and pm:house-rules. Keep the change focused.
• When the task warrants tests, REQUIRED SUB-SKILL: Use superpowers:test-driven-development.
• If behavior is mysterious, REQUIRED SUB-SKILL: Use superpowers:systematic-debugging.
• Commit incrementally (conventional commits per pm:house-rules).
• If you discover unrelated work, do NOT do it inline. Note it for the user; keep the definition of done fixed.

5. Review

• Self-review the diff against the pm:house-rules security + quality checklist.
• Then run /code-review, or dispatch the code-reviewer subagent for a deeper read. Fix every BLOCKER and any SUGGESTION you agree with; note deferrals with a reason.

6. Verify — GATE

• Run the project's tests/build/lint. REQUIRED SUB-SKILL: Use superpowers:verification-before-completion.
• Run the commands yourself and paste the actual output here. Never claim "passing" without pasted evidence.

7. PR

• Open the PR per pm:house-rules (What/Why/Testing). Share the URL.

8. Wrap

• Summarize what shipped and what was intentionally left out.
• REQUIRED SUB-SKILL: Use superpowers:finishing-a-development-branch for merge/PR/cleanup options.
• If a project tracker is configured (.pm/config.yml exists), offer to update the item. If not, skip silently — dev-task never requires /pm:setup.
• If a memory MCP is connected, save any reusable learning; skip silently if not. See references/memory-integration.md.

Rationalization table — do not skip gates

Red flags — STOP

• About to Edit/Write code before the user approved a plan.
• About to say "done" / "tests pass" without pasted command output.
• About to add something not in the agreed scope.
• Working directly on the default branch.

All of these mean: stop, return to the relevant gate.

Common mistakes

• Restating house-rules inline instead of deferring — defer.
• Dumping everything you read into the plan — the plan is what you'll DO, not what you saw.