shape-concept

name	shape-concept
description	Create or revise coherent canonical docs/concept/ documents through short proposal, drafting, research, and refinement rounds without creating implementation plans or modifying mechanical protocol files. Use after accepted concept intake, or when an operationally planned project must deliberately change accepted product intent before re-planning.

Shape Concept

Turn accepted intake into a coherent product concept that another agent can later operationalise. Preserve product thinking; do not cross into implementation.

Enter the stage

1. Read AGENTS.md, inventory .agents/, then read docs/intake/concept-intake.md and every existing file in docs/concept/.
2. For initial shaping, require intake status Ready for concept shaping and either no concept index or concept status Shaping when resuming; also accept concept status Ready for operational planning with an explicit user request or /plan-implementation handoff identifying an unresolved concept issue. If the intake is evidently saturated but still marked In progress, recommend closing it with /concept-intake; do not silently bypass the stage boundary. For re-shaping, require concept status Operationally planned or Ready for operational re-planning plus an explicit user request or a handoff from /plan-implementation or /sync-protocol identifying the product-intent change, or concept status Re-shaping when resuming an approved re-shaping round. Treat intake as historical input when reopening accepted concept documents.
3. Treat placeholder concept files as scaffolding, not accepted requirements.
4. Identify the smallest document set that keeps distinct concerns findable. Do not force a fixed taxonomy or create one file per minor topic.

Propose before writing

Return no more than 150 words containing:

• Proposed documents: file names with one-line ownership boundaries.
• Tension: the single most important contradiction or coverage gap, if any.
• Decision: one approval or clarification needed before drafting.

Do not write canonical concept documents until the user approves the proposed shape. Approval applies only to concept drafting, never implementation.

Draft and refine

After approval:

1. Replace placeholder files when appropriate and create or update a compact docs/concept/README.md index with Status: Shaping for initial shaping or Status: Re-shaping for re-shaping.
2. Synthesize the intake by meaning. Do not copy its structure, repeat the same decision across files, or preserve a conversational transcript.
3. Separate settled intent, evidence-backed findings, assumptions, explicit exclusions, and open questions.
4. Cite factual claims using links or local file references. Mark unsupported product judgements as hypotheses or decisions.
5. Conduct research only when the user requests it or approves a named research question. Fold conclusions into the relevant concept document; do not leave a detached research dump.
6. Use short rounds with at most one tension and one next decision. Keep ordinary responses under 150 words unless detailed research was requested.

Boundaries

• Write only within docs/concept/ and, for stage status, the intake document.
• Do not modify AGENTS.md, DESIGN.md, ROADMAP.md, BUILD_STATE.md, source code, or infrastructure.
• Do not invoke /sync-protocol.
• Do not choose frameworks, schemas, APIs, or deployment topology unless they are themselves part of the product concept being deliberately evaluated.
• Do not turn open product questions into implementation-agent discretion.
• Preserve unresolved but non-blocking matters explicitly instead of extending the conversation indefinitely.

Detect concept readiness

Recommend completion when:

• the problem, audience, desired outcome, and primary journeys are coherent;
• scope boundaries, non-negotiables, and important exclusions are explicit;
• material domain behaviours and product rules are described;
• factual dependencies that affect viability are researched or clearly gated;
• contradictions are resolved; and
• remaining unknowns can be decided during operational planning without changing the product's identity or value proposition.

When ready, ask for one decision: accept the concept for initial operational planning or re-planning, as applicable, or name the specific area that still needs shaping. On acceptance:

1. Reconcile duplicates and stale open questions.
2. Set docs/concept/README.md to Status: Ready for operational planning after initial shaping or Status: Ready for operational re-planning after re-shaping.
3. Set the intake status to Concept shaped after initial shaping; preserve it during re-shaping without deleting the intake.
4. Return a one-screen handoff summary, tell the user to start a fresh session with /plan-implementation, and stop. Do not begin planning.