Menu

Individual skill

cy-create-spec

Create or update a requested CompozyOS spec and its applicable companion contracts, reusing current decisions and research. Not a prerequisite for ordinary coding tasks.

extensions/spec-cycle/skills/cy-create-spec/SKILL.md

Read pinned source

Source commit 14f57173e5cae483392cce90a06098fd04dcfda0

What was checked

Matches the observed repository HEAD
Yes
Scanner rules are current
Yes
Repository scan complete
No
Skill scan complete
No
Observed behavior
Local scripts
Last checked
Nov 3, 2026

These are observations at the recorded commit, not a guarantee of safety. Review the source before running it.

Install this skill

Choose an agent in your Stack or copy a command below. Commands fetch the pinned commit and copy only this skill directory. Existing destinations are refused. Copying a command does not install anything.

An install command is unavailable: current rules, complete repository and skill scans, an eligible behavior level and a permitted license are required.

Repository context

Repository stars (not skill ratings)
2,856
Repository last updated
Nov 7, 2026
License
MIT

Observed agent integration: No specific integration evidence. Standard SKILL.md installation does not imply verified compatibility.

Files and excerpt

File metadata and permitted, redacted excerpts come from the recorded scan. Source links are pinned to that commit.

Browse files
Read excerpt

# Create Spec

Use for a requested specification, not as a prerequisite to an ordinary fix. Author `_spec.md` with Product and Technical parts and the applicable companion contracts under `.compozy/tasks/<slug>/`.

1. Reuse the user's decisions, existing spec, and current research. Inspect relevant code/contracts for unresolved questions. Market research is needed only for a market/product uncertainty or an explicit request; delegation is optional and bounded.
2. State the motivating problem, observable outcome, scope, and non-goals. Ask focused questions only for decisions the evidence cannot settle, always in the format from `references/grill-protocol.md`; apparent simplicity is not evidence. An approved direction satisfies the product checkpoint; do not repeat an interview or approval already completed. For an open-ended product interview, use the relevant branch of `references/grill-protocol.md`.
3. Write Part I and `_user_stories.md` from `references/spec-template.md` and `references/user-stories-template.md`. Product requirements may name a technology when it is an actual public contract or fixed user constraint; incidental implementation belongs in Part II.
4. Define the changed public surface before its internal implementation: `_dx.md` uses `references/dx-template.md`; UI-bearing work uses `_uiux.md` and `references/uiux-template.md`. For an internal-only spec, a brief no-public-surface entry is sufficient. Preserve named visual references and production owners.
5. Write Part II with the concrete contracts the design changes. Read only relevant ADRs/analysis. Use `references/adr-template.md` for consequential decisions with real alternatives; a routine choice needs no standalone ADR. Document the target project's compatibility policy for changed user state and public surfaces, including lossless migrations, deprecation/removal plans, delete targets, and one owning impact analysis with links from companions. If no policy exists, state the proposed guarantees and unresolved decisions explicitly.
6. Write `_tests.md` using `references/tests-template.md`: distinct invariants, owning suites, inputs/results, and necessary integration journeys. Reuse existing coverage; no quotas per component, error class, or layer.
7. Write `_slices.md`, the delivery order that spec delivery reads:

   ```markdown
   | Slice | Layer    | Depends on | Scope           | Spec refs |