* feat: add intent-driven-development skill
Converts ambiguous feature or engineering requests into scoped,
verifiable acceptance criteria before implementation starts.
- Chooses between Quick Capture (low/moderate risk) and Full
Acceptance Brief (security, data, migration, cross-system changes)
- Reads repo context before asking questions; only asks what cannot
be inferred
- Non-blocking by default: records criteria and proceeds unless a
real risk requires confirmation
- Rule 9: when an AC fails mid-implementation due to architectural
constraints, marks it [revised], updates scope/verification method,
and re-presents only changed criteria rather than silently dropping
- Output template includes Revision Log for traceability across
multiple implementation cycles
* fix: add canonical When to Activate, How It Works, and Examples sections
Required for auto-activation mechanism detection per CONTRIBUTING.md
and existing skill conventions. Sections inserted after the intro
and before Operating Rules.
* fix: strengthen intent-driven-development skill per review
Address skill-quality review feedback on the intent-driven-development PR:
- Business/product constraints: add Operating Rule 2 forbidding inference
of business rules, compliance/SLAs, pricing, retention, prioritization,
and target users from code; surface the technical-vs-business split in
How It Works, Discover Context, and a dedicated 'supplied, not inferred'
section in the brief template.
- Eval-style pass/fail: add a Pass/Fail Examples section (failing vs
passing AC, plus a misplaced business-rule context entry) and a 5-point
Pass/Fail Rubric users can apply to the output.
- Renumber Operating Rules 1-10 accordingly; markdownlint clean.
Andrea Cavallo