mirror of
https://github.com/addyosmani/agent-skills.git
synced 2026-10-26 15:05:04 +00:00
ayobamiseun
cbf37af0ae
Implements the v1 scope agreed in #431: when one requirement bundles several independently testable capabilities, spec-driven-development now runs a bounded front-step before Specify — detect multi-capability scope, propose a capability map (stable module ids, one-way dependency direction, build order), gate it on human approval, then recurse the gated workflow per module in dependency order. Kept deliberately small per the maintainer's scoping: - detection + module map + stable identity only; no per-module artifact tree — module specs reuse the root-level SPEC-<id>.md naming so the layout follows the delta-spec direction in #383 rather than leading it - the simple path is preserved: single-capability requests skip Phase 0 entirely, and the section says so first - non-goals held: no PM framework, no forced hierarchy on small features Also: - description gains the decomposition vocabulary so realistic asks route here (both new positive triggers rank #1) - /spec command wrappers (.claude, commands/, .gemini) gain one matching step, kept in parity - eval case: +2 positive triggers, +1 owner-negative guarding the planning-and-task-breakdown boundary, +1 execution eval backed by a new multi-capability fixture (portal-brief.md) Verification: validate-skills 24/24, validate-commands 8/8, run-evals 127 checks 0 errors 0 warnings, rank-1 86% (67/78) over floor 80, behavioral dry-run resolves both spec evals.
17 lines
911 B
TOML
17 lines
911 B
TOML
description = "Start spec-driven development — write a structured specification before writing code"
|
|
|
|
prompt = """
|
|
Invoke the spec-driven-development skill.
|
|
|
|
Begin by understanding what the user wants to build. Ask clarifying questions about:
|
|
1. The objective and target users
|
|
2. Core features and acceptance criteria
|
|
3. Tech stack preferences and constraints
|
|
4. Known boundaries (what to always do, ask first about, and never do)
|
|
|
|
Then generate a structured spec covering all six core areas: objective, commands, project structure, code style, testing strategy, and boundaries.
|
|
|
|
If the request bundles several independently testable capabilities, first propose a capability map (module ids, dependency direction, build order) per the skill's Phase 0 and get it approved, then spec each module in dependency order.
|
|
|
|
Save the spec as SPEC.md in the project root and confirm with the user before proceeding.
|
|
""" |