New: 97,000+ skills indexed from GitHub repos with 100+ stars · every skill safety-checkedBrowse top skillsTop skills
Esc to closeBrowse all skills
Submit a skillBrowse skills
Submit a skillBrowse skills

Agent skill

Spec

by codewithmukesh in codewithmukesh/dotnet-claude-kit

Turn a vague feature or product idea into an agreed, persisted specification through relentless structured questioning.

MITAuto-check passedProduct & Project Management

Install Spec

skills CLI
$ npx skills add codewithmukesh/dotnet-claude-kit --skill spec -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install codewithmukesh/dotnet-claude-kit spec --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/codewithmukesh/dotnet-claude-kit.git skills-src && mkdir -p .claude/skills && cp -r skills-src/skills/spec .claude/skills/spec && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
spec
GitHub stars
751
Token cost
~2k tokens
SKILL.md length
753 words
Files
1
Skills in repo
47
Repo updated
First seen
Licence
MIT

At a glance

Turn a vague feature or product idea into an agreed, persisted specification through relentless structured questioning.

  • Works in 6 steps: Capture and Restate → Questioning Rounds → Draft the Spec File → …
  • Acceptance criteria
  • SKILL.md covers What, When, How and Example, plus 1 more section
  • Instructions only: no scripts, shell commands, URLs or credentials in SKILL.md

What it does

Spec is an agent skill from codewithmukesh/dotnet-claude-kit. Turn a vague feature or product idea into an agreed, persisted specification through relentless structured questioning. Never assumes — every gap, ambiguity, or "probably" becomes a question to the developer, and the spec cannot be approved while open questions remain. Produces docs/specs/<NNN-<slug.md with acceptance criteria that /plan, /scaffold, and /tdd consume. Use when: "spec", "write a spec", "spec this out", "requirements", "PRD", "acceptance criteria", "define the feature", "user stories", "what should…

Its SKILL.md is about 2k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

It sits in Product & Project Management, covering User stories, PRD writing and Test-driven development. The repository describes itself as: Make Claude Code a .NET 10 Expert. The licence is MIT.

When your agent uses it

  • Acceptance criteria
  • Define the feature
  • What should we build
  • Before planning any feature too big to describe in one sentence

Example prompts

  • “probably”
  • “write a spec”
  • “spec this out”
  • “/spec”

Workflow steps

6 steps, taken from the step headings in SKILL.md.

  1. Capture and Restate
  2. Questioning Rounds
  3. Draft the Spec File
  4. Review Loop
  5. The Agreement Gate
  6. Handoff

What it can do on your machine

Read from SKILL.md and the folder at commit 2330089. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    No scripts in the folder and no shell commands in SKILL.md (its code samples are markdown).

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Spec loads about 2k tokens when it runs. Until then it costs about 151 tokens; SKILL.md has 753 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~151
When it runs · the whole SKILL.md, loaded when a task matches
~2k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from codewithmukesh/dotnet-claude-kit at commit 2330089, republished under its MIT licence (© codewithmukesh). 753 words, ~1,992 tokens.

Download SKILL.mdSave it as .claude/skills/spec/SKILL.md (or your agent's skills folder).
name
spec
description
Turn a vague feature or product idea into an agreed, persisted specification through relentless structured questioning. Never assumes — every gap, ambiguity, or "probably" becomes a question to the developer, and the spec cannot be approved while open questions remain. Produces docs/specs/<NNN>-<slug>.md with acceptance criteria that /plan, /scaffold, and /tdd consume. Use when: "spec", "write a spec", "spec this out", "requirements", "PRD", "acceptance criteria", "define the feature", "user stories", "what should we build", or before planning any feature too big to describe in one sentence.

/spec — Relentless Specification Workflow

What

Converts an idea into a written, versioned specification that both the developer and Claude explicitly agree on — before any planning or code. The contract:

  • Never assume. Every gap in the idea becomes a question. If Claude catches itself thinking "probably", "presumably", or "the usual way" — that thought is a question to ask, not a decision to make.
  • Relentless, but structured. Questions come in focused rounds (3–5 at a time) across nine dimensions — not one overwhelming dump, and not a single polite round that stops early.
  • Agreement is explicit. Specs have a status lifecycle: Draft → In Review → Approved. Implementation never starts from a Draft. Approval requires the developer to read the final document and say so.
  • Specs are files, not chat. Output persists to docs/specs/<NNN>-<slug>.md and survives the session. Plans, tests, and commits reference it.

When

  • Any feature too big to describe completely in one sentence
  • New product or module ideas ("I want to add team workspaces")
  • Before /plan for non-trivial features — plan consumes the approved spec
  • When requirements feel fuzzy mid-implementation: stop, /spec, re-plan
  • Trigger phrases: "spec", "requirements", "PRD", "define the feature", "acceptance criteria"

Skip for: bug fixes, refactors, single-endpoint CRUD where the entity is obvious.

How

Step 1: Capture and Restate

Take the raw idea and restate it in one paragraph: what Claude understood, in its own words. End with: "Is this the idea? What did I get wrong?" Do not begin questioning until the developer confirms the restatement — questioning the wrong idea wastes everyone's time.

Step 2: Questioning Rounds

Work through the nine dimensions in order. Each round: pick the 3–5 most load-bearing unanswered questions (answers that reshape later questions come first). Where the harness supports selectable options, present choices with trade-offs — and a recommendation — but the developer chooses; a recommendation is never silently applied.

#DimensionWhat to pin down
1Problem & usersWho hurts today, how they work around it, what success looks like
2ScopeWhat is IN this iteration, what is explicitly OUT, where the MVP line sits
3Domain & dataEntities, relationships, lifecycle (create→archive→delete?), retention
4API contractResources, endpoints, request/response shapes, pagination, versioning
5AuthorizationWho can do what, role/claim model, tenant boundaries
6Edge cases & failure modesConcurrency, duplicates, idempotency, partial failure, limits
7Non-functionalsExpected volume, latency budget, growth assumptions
8IntegrationsExternal services, published events, webhooks, side effects
9Acceptance criteriaTestable Given/When/Then for every behavior in scope

Rules of relentless questioning:

  • Record every answer in the draft spec immediately — answers are requirements, not conversation.
  • Challenge contradictions on the spot: "In round 1 you said X; this answer implies not-X. Which wins?"
  • "I don't know" is a legal answer → moves to Deferred Decisions with an explicit fallback the developer chooses now ("default to soft-delete until decided"). Silent deferral is forbidden.
  • A dimension is done when a follow-up round generates zero new questions for it.
  • The questioning phase is done when ALL nine dimensions are done. Do not stop because the conversation feels long — stopping early is how assumptions sneak in.
Show full SKILL.md (248 more words)Show less
Step 3: Draft the Spec File

Determine the next number from existing files in docs/specs/ (create the directory if missing). Write docs/specs/<NNN>-<slug>.md:

markdown
# Spec NNN: <Title>

**Status:** Draft
**Date:** <today>

## Problem            <!-- who hurts, why now -->
## Scope              <!-- ### In / ### Out — both explicit -->
## Domain Model       <!-- entities, relationships, lifecycle -->
## API Contract       <!-- endpoints table: verb, route, request, response, errors -->
## Authorization      <!-- who can do what -->
## Edge Cases & Failure Modes
## Non-Functional Requirements
## Integrations
## Acceptance Criteria  <!-- Given/When/Then, numbered AC-1, AC-2, ... -->
## Deferred Decisions   <!-- decision, chosen fallback, revisit trigger -->
## Open Questions       <!-- MUST be empty before approval -->
Step 4: Review Loop

Set status to In Review. Present the complete spec and ask: "Read this end-to-end. What is wrong, missing, or over-engineered?" Fold corrections in and re-present. Repeat until the developer has no further changes. New answers may spawn new questions — that is the process working, not a failure to converge.

Step 5: The Agreement Gate

Approval is a deliberate act, never inferred from silence or "looks good" in passing. Ask explicitly: "Do you approve this spec? After approval, code follows the spec — changes go through the spec first." On approval, set **Status:** Approved (<date>).

  • Open Questions must be empty. If any remain, the spec cannot be approved — resolve or defer each one explicitly.
  • If implementation later reveals a wrong assumption: stop, set status back to In Review, fix the spec with the developer, then resume. Code never silently diverges from an approved spec.
Step 6: Handoff
  • /plan reads the approved spec and maps acceptance criteria to implementation steps
  • /tdd turns acceptance criteria into the first failing tests (AC-n → test name)
  • Commits for the feature reference the spec: feat: team workspaces (spec 004)

Example

User: /spec users should be able to invite teammates

Claude: Here's what I understood: an existing user can invite another person
  to join their... workspace? account? That's already my first gap.
  Is this the idea? What did I get wrong?

User: yes, invite to their organization

Claude: Round 1 — Scope & Users:
  1. Can invitees be people without an existing account, or only registered users?
  2. Who can invite — any member, or only admins/owners?
  3. Is there a limit on pending invites (per org, per plan)?
  4. Out of scope check: bulk invites and SSO-provisioned members — both OUT for now?

User: 1: both. 2: admins only. 3: no limit. 4: correct, both out.

Claude: Round 2 — Edge cases (your "both" in Q1 raises these):
  1. Inviting an email that already has a pending invite — error, or resend?
  2. Invite expiry — 7 days, 30 days, never?
  3. Invitee already belongs to another org — multi-org membership or rejection?
  ...

[…rounds continue until all nine dimensions are exhausted…]

Claude: Spec written to docs/specs/004-team-invitations.md (In Review).
  Read it end-to-end. What is wrong, missing, or over-engineered?

User: looks right. approved.

Claude: Status: Approved (2026-06-12). Next: /plan to map AC-1..AC-9
  to implementation steps.
  • /plan — Consumes the approved spec; never plan a spec-worthy feature without one
  • /tdd — Acceptance criteria become the first failing tests
  • /scaffold — Generates the slices the plan calls for
  • architecture-advisor — Load during Step 2 if the feature forces architectural decisions

© codewithmukesh, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in skills/spec of codewithmukesh/dotnet-claude-kit.

Open the folder on GitHubat commit 2330089

Compare with similar skills

Spec next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Spec compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Spec this skillcodewithmukesh/dotnet-claude-kit751—~2kAutomated safety check: PassMIT
Prd V07 Implementation Loopmattgierhart/PRD-driven-context-engineering179—~5.1kAutomated safety check: NotesMIT
Prd V07 Test Planningmattgierhart/PRD-driven-context-engineering179—~3.5kAutomated safety check: NotesMIT
Ralph Tui Create Beadssubsy/ralph-tui2.5k1 repos~2.6kAutomated safety check: PassMIT
Ralph Tui Create Beads Rustsubsy/ralph-tui2.5k1 repos~2.8kAutomated safety check: PassMIT
Ralph Tui Create JSONsubsy/ralph-tui2.5k1 repos~2.6kAutomated safety check: PassMIT

Similar skills

  • Prd V07 Implementation Loop

    mattgierhart/PRD-driven-context-engineering

    Execute implementation within EPICs following test-first development, continuous SoT updates, and code traceability during PRD v0.7 Build Execution.

    179 GitHub stars~5.1k tokensUpdated 1 mo ago
    Product & Project ManagementAuto-check: notes

  • Prd V07 Test Planning

    mattgierhart/PRD-driven-context-engineering

    Define test cases BEFORE implementation, ensuring every API, business rule, and user journey has verifiable acceptance criteria during PRD v0.7 Build Execution.

    179 GitHub stars~3.5k tokensUpdated 1 mo ago
    Testing & QAAuto-check: notes

  • Ralph Tui Create Beads

    subsy/ralph-tui

    Convert PRDs to beads for ralph-tui execution. An agent skill from subsy/ralph-tui.

    2.5k GitHub starsUsed in 1 repo~2.6k tokens
    Product & Project ManagementAuto-check passed

  • Ralph Tui Create Beads Rust

    subsy/ralph-tui

    Convert PRDs to beads for ralph-tui execution using beads-rust (br CLI).

    2.5k GitHub starsUsed in 1 repo~2.8k tokens
    Product & Project ManagementAuto-check passed

  • Ralph Tui Create JSON

    subsy/ralph-tui

    Convert PRDs to prd.json format for ralph-tui execution. An agent skill from subsy/ralph-tui.

    2.5k GitHub starsUsed in 1 repo~2.6k tokens
    Product & Project ManagementAuto-check passed

  • To Prd

    ywwynm/EverythingDone

    Turn the current conversation context into a PRD and publish it to the project issue tracker.

    144 GitHub starsUsed in 11 repos~777 tokens
    Product & Project ManagementAuto-check passed

More from codewithmukesh/dotnet-claude-kit

All 47 skills in this repo

  • API Versioning

    codewithmukesh/dotnet-claude-kit

    API versioning strategies for ASP.NET Core. An agent skill from codewithmukesh/dotnet-claude-kit.

    751 GitHub starsUsed in 1 repo~1.2k tokens
    Auto-check passed

  • Scaffold

    codewithmukesh/dotnet-claude-kit

    Architecture-aware feature scaffolding for .NET 10 projects.

    751 GitHub stars~1.7k tokensUpdated 2 mo ago
    Auto-check passed

  • Architecture Advisor

    codewithmukesh/dotnet-claude-kit

    Architecture selection advisor for .NET applications. An agent skill from codewithmukesh/dotnet-claude-kit.

    751 GitHub starsUsed in 1 repo~2.9k tokens
    Auto-check passed

  • Aspire

    codewithmukesh/dotnet-claude-kit

    .NET Aspire for cloud-native orchestration. An agent skill from codewithmukesh/dotnet-claude-kit.

    751 GitHub starsUsed in 1 repo~1.5k tokens
    Auto-check passed

  • Authentication

    codewithmukesh/dotnet-claude-kit

    Authentication and authorization for ASP.NET Core. An agent skill from codewithmukesh/dotnet-claude-kit.

    751 GitHub starsUsed in 1 repo~1.9k tokens
    Auto-check passed

  • Caching

    codewithmukesh/dotnet-claude-kit

    Caching strategies for .NET 10 applications. An agent skill from codewithmukesh/dotnet-claude-kit.

    751 GitHub starsUsed in 1 repo~1.4k tokens
    Auto-check passed

Categories

Questions about Spec

What does Spec do?

Turn a vague feature or product idea into an agreed, persisted specification through relentless structured questioning. Spec is an agent skill from codewithmukesh/dotnet-claude-kit. Turn a vague feature or product idea into an agreed, persisted specification through relentless structured questioning.

When should I use Spec?

Spec fits situations like: acceptance criteria; define the feature; what should we build; before planning any feature too big to describe in one sentence.

How do I install Spec in Claude Code?

Run `npx skills add codewithmukesh/dotnet-claude-kit --skill spec -a claude-code`. Or copy the skill folder (skills/spec in codewithmukesh/dotnet-claude-kit) into .claude/skills/spec in your project. Claude Code loads it when a task matches its description.

How do I install Spec in Codex?

Run `npx skills add codewithmukesh/dotnet-claude-kit --skill spec -a codex`. Or copy the skill folder (skills/spec in codewithmukesh/dotnet-claude-kit) into .agents/skills/spec in your project. Codex loads it when a task matches its description.

Can I use Spec in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add codewithmukesh/dotnet-claude-kit --skill spec -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/spec, .gemini/skills/spec, .github/skills/spec and .opencode/skills/spec in your project.

What does Spec need to run?

SKILL.md names no scripts, command-line tools or credentials: Spec is instructions for the agent only.

Does Spec access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Spec safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Spec use?

Spec is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Spec use?

About 2k tokens (SKILL.md is roughly 8k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Spec?

Skills that share tags, products or a category with Spec: Prd V07 Implementation Loop (mattgierhart/PRD-driven-context-engineering, 179 stars), Prd V07 Test Planning (mattgierhart/PRD-driven-context-engineering, 179 stars), Ralph Tui Create Beads (subsy/ralph-tui, 2.5k stars) and Ralph Tui Create Beads Rust (subsy/ralph-tui, 2.5k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Spec?

codewithmukesh (a GitHub organization) maintains it in codewithmukesh/dotnet-claude-kit, which has 751 GitHub stars. The repository holds 47 skills in this directory. The repository was last updated on August 7, 2026.

Source: codewithmukesh/dotnet-claude-kit on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.