메뉴
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.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | prd-builder |
| description | 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. |
Build docs/10-prd.md and docs/11-backlog.md from docs/00-vision.md and docs/01-intake.md.
Product summary — 2-3 sentences.
Personas — 1-3, each with: name, goal, frustration, context-of-use.
User journeys — 3-7 prose paragraphs. Each paragraph: entry → steps → exit → success state.
Feature table —
| ID | Name | Description | Priority | Acceptance criteria |
|---|
Use F-001, F-002, ... Priority is P0/P1/P2.
User stories — for each P0 feature, 1–5 stories: As a [persona], I want to [action] so that [outcome] plus Given/When/Then acceptance.
Out of scope — explicit list.
Open questions — what needs CEO or user input.
docs/11-backlog.md — every backlog item carries both the implementation ticket ID and the PRD feature ID so the chain is traceable end-to-end:
# Backlog
## Sprint 1 — MVP foundation
- APP-001 [F-001] <feature> — XS/S/M/L/XL
- APP-002 [F-002] <feature> — ...
## Sprint 2 — MVP completion
- ...
## v1.1+
- ...
The [F-NNN] is mandatory. The sprint-planner skill carries it through to the board's F-NNN column, and code-reviewer + qa-engineer use it to fetch the matching acceptance criteria from docs/10-prd.md without guessing.
If you can't trace a feature back, delete it.
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 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.
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.