メニュー
Use to convert the backlog into a runnable sprint with parallel ticket assignment and dependency tracking. Used primarily by the tech-manager. Triggers on "plan the sprint", "what does the pod do next", or as part of /app-build.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Use before writing any code, spec, or store asset on a Mobify Studio app — loads the relevant House Knowledge Base pack(s) so output matches the studio's established conventions instead of generic defaults. Every IC and exec agent invokes this first.
Use when pointing the team at an EXISTING, already-built app instead of a blank project — detects the stack, reverse-engineers the as-built architecture, and classifies remediation work as safe-to-auto-fix vs risky-needs-approval. Triggered by /app-onboard, /app-audit, and by /app-run when it detects a non-empty app directory.
Use to actually launch multiple developer agents in parallel via the subagent tool (Task/Agent), given a sprint plan and board. Triggers from /app-build or when the tech-manager says "spawn the pod". Encapsulates the rules for safe concurrent agent execution.
Use to produce the technical architecture doc and engineering principles for a mobile app. Used primarily by the CTO agent. Triggers on "design the architecture", "pick the stack", or as part of /app-plan.
Use to construct a complete Product Requirements Document for a mobile app from a vision file. Used primarily by the CPO agent. Triggers on requests to "write the PRD", "spec out the product", or as part of /app-plan.
Use at the very start of a new app project to convert a one-line idea or rough brief into a structured requirements document the CEO/CPO/CTO agents can act on. Triggers when the user says "build an app", "I have an idea for an app", or kicks off /app-init with a fuzzy prompt.
| name | sprint-planner |
| description | Use to convert the backlog into a runnable sprint with parallel ticket assignment and dependency tracking. Used primarily by the tech-manager. Triggers on "plan the sprint", "what does the pod do next", or as part of /app-build. |
Convert docs/11-backlog.md + docs/22-impl-spec-*.md into docs/30-sprint-plan.md and docs/31-board.md.
Read the backlog and impl specs. Note ticket dependencies — if APP-002 needs APP-001's auth module, that's a dependency.
Sprint goal — one sentence at the top of docs/30-sprint-plan.md.
Capacity — default 3 developer agents (iOS, Android, optional Backend), 1 code-reviewer, 1 qa-engineer, 1 ux-designer. Tune to project scope.
Assign for parallelism — group tickets so each developer has independent work to start with. Stack dependent work behind it.
Track A (ios-developer) : APP-001 → APP-004 → APP-007
Track B (android-dev) : APP-002 → APP-005 → APP-008
Track C (backend-dev) : APP-003 → APP-006
Continuous: code-reviewer, qa-engineer, ux-designer (early)
Board — docs/31-board.md. Columns must match the ticket shape in agents/tech-manager.md:
APP-NNN | F-NNN | Title | Owner | Status | Depends on | Estimate | Spec | Acceptance | Notes
F-NNN is the PRD feature ID this implements (so reviewers and QA can trace acceptance back to the PRD).Spec is a short anchor like prd#F-001 + arch§3 so devs don't need to grep.Acceptance is the Given/When/Then copied from the PRD (or a one-line summary plus pointer if long).Notes carries the review-cycle counter (cycles=0, cycles=1, cycles=2 → blocked) and any BUG-NNN-fix linkage.Status starts todo. Update through in_progress → review → qa → done (or blocked).
Definition of done — list it at the top of the board so everyone uses the same one:
SPRINT 1 KICKED OFF
Parallel launch:
- ios-developer ← APP-001, APP-004
- android-developer ← APP-002, APP-005
- backend-developer ← APP-003 (or skip if out of scope)
- ux-designer ← finalize flows for sprint 1 features
- qa-engineer ← write test plan for sprint 1
Reviewer queue: code-reviewer
Daily report: docs/daily/<date>.md