rubenglez Product Plan
Step 1: Read the project
Before asking anything, gather all available context:
Ideation output — read .harness/product/idea.md if it exists:
- Extract: concept, problem, market landscape, competitor list, viability verdict
- These questions are already answered — do not re-ask them in the interview
Existing product docs — read .harness/product/ for prior decisions to update rather than re-litigate
Codebase — if code already exists:
- Read README.md for stated goals and audience
- Scan the feature surface: routes, screens, commands, or API endpoints
- Check the roadmap or issue tracker if present (
gh issue list) - Note what's implemented, what's stubbed, and what's conspicuously absent
Starting mid-flow on an existing project: if code exists but .harness/ is absent, treat this as step 2 — /ideate was skipped. Read the codebase and README to reconstruct what idea.md would have said, then proceed.
Synthesize into a one-paragraph internal picture. Do not share this — use it to skip already-answered questions and form sharper hypotheses.
Step 2: Interview
Interview the user relentlessly — one question at a time. For every question, state a concrete recommendation or hypothesis first. Never ask a bare question. Lead with your position — "My read is X. Do you agree?" — so the user reacts to a specific claim.
Be a realist, not a cheerleader. Surface the truth, not validation: name failure modes, push back on optimistic answers, make vague audiences concrete, call out weak moats.
Work through these dimensions in order; skip any already answered. See REFERENCE.md for detailed questions per dimension:
- The idea
- Target audience
- Market and competition (skip if idea.md covers it)
- Value and differentiation
- Validation
- Features
- UX and design
Step 3: Report
After the interview, produce a report with these sections:
- Audience — who it's for, who the early adopter is, why they care
- Value Proposition — for whom, the key benefit, the core differentiator, why users switch (synthesize from dimensions 4 and 5)
- Market Positioning — category, differentiation, competitive gap
- Competitive Analysis — top 3–5 competitors, strengths, weaknesses
- Direction Assessment — go / conditional go / no-go with 2–3 reasons
- Prioritized Feature Backlog — must-have / should-have / nice-to-have
- UX and Design Direction — core workflow, interaction model, design register
- Key Risks — 2–3 assumptions most likely to be wrong and how to test them
Step 4: Write docs
Doctier bootstrap (once per repo)
.harness/ is tracked in git as age-encrypted blobs via doctier. If .doctier.yml exists at the repo root, skip this — the repo is already set up. If .harness/ already exists but is gitignored (a pre-doctier project), follow the adoption recipe in the migrate-docs skill's REFERENCE.md instead. Otherwise, run the bootstrap in ../_shared/doctier-bootstrap.md.
Spawn the doc writer
Spawn a subagent to write all product docs. Pass the full report as context — it cannot read the conversation.
Runtime note: if your runtime can't spawn a subagent (e.g. Codex), write the docs yourself in this session — see ../_shared/runtime-parallelism.md.
Rules: all files go under .harness/product/; update existing rather than overwrite; omit sections with no source; never link to .harness/ from public docs.
The subagent writes: product.md, roadmap.md, competitors.md, ux.md (if UI discussed), and CONTEXT.md (domain glossary). See REFERENCE.md for templates.
After the subagent finishes, confirm every file written. Refresh the doc index and commit — worktrees and future sessions only see committed .harness/ content:
doctier agents --write
git add .harness AGENTS.md && git commit -m "docs: product plan"
Recommend: "Run /dev-plan to define the architecture and generate feature specs."