intent-driven-development

Topics in the source

• Intent-Driven Development
• When to Activate
• How It Works
• Examples
• Operating Rules
• Choose The Depth
• Quick Capture
• Full Acceptance Brief

Produce useful acceptance criteria without turning specification into ceremony. Inspect available context first, expose genuine ambiguity, and choose verification methods that fit the work and its risk. User asks to clarify a feature, define acceptance criteria, or de-risk a change before implementation Request touches security, authentication, persistent data, migrations, external APIs, or compliance User wants to prepare a handoff artifact for another agent or team Request is ambiguous enough that the expected outcome is not yet observable or testable User explicitly invokes this skill with /intent-driven-development Do not activate for trivial edits, straightforward one-line fixes, active debugging sessions, code review requests, or implementation requests whose acceptance conditions are already clear. 1. Inspect context first — reads the repository, docs, schemas, and test infrastructure for technical facts before asking any question, while treating product/business constraints as something only the user or a product artifact can supply 2. Choose depth — selects Quick Capture (3-7 criteria, low/moderate risk) or Full Acceptance Brief (security, data, migration, cross-system cha

This is an excerpt. Refer to the complete source and its current requirements.