copilot: Skill for Claude Code

Product Specification

Produce a specification that lets product, engineering, reviewers, and operators understand the same intended product and verify when it is complete.

Before drafting or reviewing, read these repository sources in full:

• Product Specification Standard
• Specification template

Use existing code, workflows, documentation, configuration, and observed failures as evidence. Follow the repository's Graphify rules before broad source exploration. Research external behavior when it is unstable, provider-specific, safety-critical, or central to the decision, and link primary sources.

Working method

1. Establish current behavior and evidence before proposing changes.
2. Separate product requirements, implementation choices, recommended defaults, safety invariants, non-goals, and open decisions.
3. Describe the complete user/operator journey, including pending, successful, partial, blocked, retried, and canceled states.
4. Apply Clean Architecture to the project's real boundaries: identify pure decisions, use cases, semantic ports, adapters, composition, presentation, state ownership, trust boundaries, and executable dependency constraints.
5. Define configuration as a bounded product contract: defaults, values/ranges, invalid combinations, precedence, persistence, migration, and intentionally non-configurable safety rules.
6. Treat issues, PRs, comments, labels, checks, summaries, CLI output, and docs as UI when people rely on them. Show representative content and navigation, not only the data or API behind it.
7. Make complex relationships visual with a small diagram, state table, timeline, or Markdown wireframe. Always provide an adjacent textual equivalent and never rely on color or emoji alone.
8. Define a numeric, risk-derived test budget with distribution by behavior area, coverage expectations, integration/replay/race/security cases, and any required human UX evidence. A count alone is never sufficient.
9. Specify documentation deliverables for users, setup, configuration, operations/recovery, migration, and architecture as applicable.
10. Finish with observable acceptance scenarios, requirement traceability, an implementation sequence, and a Definition of Done containing every quality gate.