cspec

Solid

Create a structured specification with testable invariants for a new feature. Researches current best practices before writing invariants. Adapts format to workflow intensity.

Testing & QA 61 stars 2 forks Updated today MIT

Install

View on GitHub

Quality Score: 88/100

Stars 20%
60
Recency 20%
100
Frontmatter 20%
70
Documentation 15%
100
Issue Health 10%
50
License 10%
100
Description 5%
100

Skill Content

# /cspec — Write a Feature Specification > **Shared constraints apply.** Before executing, read `_shared/constraints.md` from the parent of this skill's base directory. All constraints there apply to this skill. You are the spec agent. Your job is to turn a feature idea into a structured specification with testable rules before any code is written. ## Intensity Configuration | | Standard | High | Critical | |---|---|---|---| | Sections | 5 + typed rules | 12 + invariants | 12 + all templates | | Research agent | If needed | Always (security) | Always | | STRIDE | No | Yes | Yes | | Question depth | Socratic | Adversarial | Exhaustive | ## Effective Intensity Determine the effective intensity using the computation in the shared constraints (`_shared/constraints.md`). ## Progress Visibility (MANDATORY) Spec writing takes 5-10 minutes of active work plus conversation time. The user must see progress throughout. **Before starting**, create a task list: 1. Socratic brainstorm 2. Read context (.correctless/ARCHITECTURE.md, antipatterns, drift debt, QA findings) 3. Research phase (if triggered — announce when research subagent completes) 4. Draft spec 5. Load templates and check antipatterns 6. Present to human for review **Between each phase**, print a 1-line status: "Brainstorm complete — refined scope to {summary}. Reading project context..." If a research subagent is spawned, announce: "Spawning research agent for {topic}..." and when it returns: "Research complete — {...

Details

Author
joshft
Repository
joshft/correctless
Created
2 months ago
Last Updated
today
Language
Shell
License
MIT

Similar Skills

Semantically similar based on skill content — not just same category

AI & Automation Listed

spec-writer

Generate structured software specifications for features, bug fixes, and products. Use when the user wants to create a spec, PRD, feature brief, requirements document, or when starting any new implementation that needs a specification first. Invoke via /spec-writer or when the user says "write a spec", "spec this out", "create a spec", "I need a spec for...", or describes a feature they want to build. Produces adaptive-complexity specs with Job Stories, Gherkin acceptance criteria, and three-tier boundaries. Output is a markdown file ready for agent execution or human review.

45 Updated 2 months ago
SamJHudson01
Testing & QA Solid

specify

Create a comprehensive specification from a brief description. Manages specification workflow including directory creation, README tracking, and phase transitions.

285 Updated 3 weeks ago
rsmdt
Testing & QA Listed

spec

Sole mutator of SPEC.md @ repo root — create, amend, ∨ backprop bugs. Triggers when user asks to write spec, start new spec, distill spec from code, add invariants, amend a section, ∨ record a bug. Common phrasings: "write the spec for...", "new spec", "distill spec from code", "spec this idea", "import existing repo", "pull invariants out of code", "this bug keeps biting", "post-mortem on Y".

4 Updated 2 days ago
kborovik
Testing & QA Listed

create-spec

Create a new specification through an adaptive interview process with proactive recommendations and optional research. Use when user says "create spec", "new spec", "generate spec", or wants to start a specification document.

38 Updated 1 months ago
sequenzia
AI & Automation Listed

specdd

Spec-driven development orchestrator that turns vague, top-of-mind feature requests into production-grade specifications before any code is written. ALWAYS use this skill whenever the user describes a feature, change, capability, screen, flow, or new component in plain language — even if they don't explicitly ask for a spec. Triggers on phrases like "build me", "make me", "add a feature", "I want to", "help me create", "implement", "let's build", "I need a", "can you make", "create a screen/page/component", or any new-feature request that lacks complete requirements (missing user stories, acceptance criteria, edge cases, error/empty/loading states, accessibility, or non-functional requirements). Interviews the user to fill gaps, applies UX/UI common sense, produces a structured spec + plan + tasks, then implements against the spec. Use this BEFORE writing any code for non-trivial features. Skip only for true one-liners (rename a variable, fix a typo, answer a research question) or work that is purely investig

1 Updated today
mnyok9939