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.
1.0 KiB
1.0 KiB
Customer portal — product brief
Leadership wants a self-serve customer portal shipped as one initiative. The request, as handed down:
- Customers sign in with email/password or company SSO and manage their account and team members.
- Customers pick a plan, enter payment details, and receive monthly invoices; plan changes prorate.
- Customers get email notifications for invoices, payment failures, and team invitations; enterprise customers can register webhooks for the same events.
- Admins see a usage dashboard: seats, API calls, and spend per month.
Constraints gathered so far:
- Billing must know who the customer is, so it depends on account data.
- Notifications fire on billing and account events.
- The dashboard reads from billing and notification delivery records.
- The four areas have different reviewers: platform owns accounts, finance owns billing, and growth owns notifications and the dashboard.
- Each area should be shippable and verifiable on its own; finance wants to sign off on billing without waiting for the dashboard.