product-capability

$27

• docs/examples/product-capability-template.md

The goal is not to create another planning stack. The goal is to make hidden capability constraints durable and reusable.

Non-Negotiable Rules

• Do not invent product truth. Mark unresolved questions explicitly.

• Separate user-visible promises from implementation details.

• Call out what is fixed policy, what is architecture preference, and what is still open.

• If the request conflicts with existing repo constraints, say so clearly instead of smoothing it over.

• Prefer one reusable capability artifact over scattered ad hoc notes.

Inputs

Read only what is needed:

• Product intent

• issue, discussion, PRD, roadmap note, founder message

• Current architecture

• relevant repo docs, contracts, schemas, routes, existing workflows

• Existing capability context

• PRODUCT.md, design docs, RFCs, migration notes, operating-model docs

• Delivery constraints

• auth, billing, compliance, rollout, backwards compatibility, performance, review policy

Core Workflow

1. Restate the capability

Compress the ask into one precise statement:

• who the user or operator is

• what new capability exists after this ships

• what outcome changes because of it

If this statement is weak, the implementation will drift.

2. Resolve capability constraints

Extract the constraints that must hold before implementation:

• business rules

• scope boundaries

• invariants

• trust boundaries

• data ownership

• lifecycle transitions

• rollout / migration requirements

• failure and recovery expectations

These are the things that often live only in senior-engineer memory.

3. Define the implementation-facing contract

Produce an SRS-style capability plan with:

• capability summary

• explicit non-goals

• actors and surfaces

• required states and transitions

• interfaces / inputs / outputs

• data model implications

• security / billing / policy constraints

• observability and operator requirements

• open questions blocking implementation

4. Translate into execution

End with the exact handoff:

• ready for direct implementation

• needs architecture review first

• needs product clarification first

If useful, point to the next ECC-native lane:

• project-flow-ops

• workspace-surface-audit

• api-connector-builder

• dashboard-builder

• tdd-workflow

• verification-loop

Output Format

Return the result in this order:

CAPABILITY

- one-paragraph restatement

CONSTRAINTS

- fixed rules, invariants, and boundaries

IMPLEMENTATION CONTRACT

- actors

- surfaces

- states and transitions

- interface/data implications

NON-GOALS

- what this lane explicitly does not own

OPEN QUESTIONS

- blockers or product decisions still required

HANDOFF

- what should happen next and which ECC lane should take it

Good Outcomes

• Product intent is now concrete enough to implement without rediscovering hidden constraints mid-PR.

• Engineering review has a durable artifact instead of relying on memory or Slack context.

• The resulting plan is reusable across Claude Code, Codex, Cursor, OpenCode, and ECC 2.0 planning surfaces.