mirror of
https://github.com/addyosmani/agent-skills.git
synced 2026-10-26 23:15: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.
73 lines
2.6 KiB
JSON
73 lines
2.6 KiB
JSON
{
|
|
"skill_name": "spec-driven-development",
|
|
"trigger": {
|
|
"positive": [
|
|
{
|
|
"prompt": "Write a spec for the new billing feature before we write any code",
|
|
"top_k": 3
|
|
},
|
|
{
|
|
"prompt": "Draft a PRD with objectives and boundaries for this project",
|
|
"top_k": 3
|
|
},
|
|
{
|
|
"prompt": "We are starting a new service, define the requirements first",
|
|
"top_k": 3
|
|
},
|
|
{
|
|
"prompt": "This one requirement covers identity, billing, notifications, and reporting — decompose it into independently specifiable modules first",
|
|
"top_k": 3
|
|
},
|
|
{
|
|
"prompt": "Before we spec this platform, map the capabilities and their dependency order",
|
|
"top_k": 3
|
|
}
|
|
],
|
|
"negative": [
|
|
{
|
|
"prompt": "Trace this request across our services",
|
|
"owner": "observability-and-instrumentation"
|
|
},
|
|
{
|
|
"prompt": "Simplify this clever one-liner into readable code",
|
|
"owner": "code-simplification"
|
|
},
|
|
{
|
|
"prompt": "Break the approved spec into ordered implementation tasks",
|
|
"owner": "planning-and-task-breakdown"
|
|
}
|
|
]
|
|
},
|
|
"evals": [
|
|
{
|
|
"id": 1,
|
|
"prompt": "We want usage-based billing. Produce the spec before any implementation.",
|
|
"expected_output": "A SPEC.md covering objectives, behavior, data model, testing strategy, and explicit boundaries",
|
|
"files": [
|
|
"spec-driven-development"
|
|
],
|
|
"expectations": [
|
|
"The spec includes explicit boundaries and non-goals",
|
|
"Ambiguities are surfaced as questions rather than silently resolved",
|
|
"A testing strategy is part of the spec",
|
|
"No implementation code is written"
|
|
]
|
|
},
|
|
{
|
|
"id": 2,
|
|
"prompt": "Read portal-brief.md and produce the spec work for the customer portal initiative.",
|
|
"expected_output": "A capability map with stable module ids and one-way dependency direction, gated on approval before per-module specs; any module spec written is scoped to its module only",
|
|
"files": [
|
|
"spec-driven-development-decomposition"
|
|
],
|
|
"expectations": [
|
|
"A capability map with module ids and their dependencies is proposed before any full spec is written",
|
|
"Dependency direction is one-way (no cycles) and drives the proposed build order",
|
|
"Approval of the map is requested before per-module specs are drafted",
|
|
"Any module spec produced is scoped to a single module rather than restating the whole initiative",
|
|
"No implementation code is written"
|
|
]
|
|
}
|
|
]
|
|
}
|