New: 98,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 kdlbs in kdlbs/kandev

Create or update Kandev product requirements and system-design documents before implementation.

AGPL-3.0Auto-check passedAgent Workflows

Install Spec

skills CLI
$ npx skills add kdlbs/kandev --skill spec -a claude-code

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

GitHub CLI
$ gh skill install kdlbs/kandev 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/kdlbs/kandev.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.agents/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
909
Token cost
~2.1k tokens
SKILL.md length
1,089 words
Files
1
Skills in repo
45
Repo updated
First seen
Licence
AGPL-3.0

At a glance

Create or update Kandev product requirements and system-design documents before implementation.

  • Works in 6 steps: Locate the owning system → Confirm intent → Write requirements → …
  • New product behavior
  • SKILL.md covers Artifact routing, Workflow and Design-package behavior
  • Calls python3 and git

What it does

Spec is an agent skill from kdlbs/kandev. Create or update Kandev product requirements and system-design documents before implementation. Use for new product behavior, changed contracts, or explicit specification work. Do not use for implementation plans, work orders, incidents, or behavior-preserving refactors.

Its SKILL.md is about 2.1k 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 Agent Workflows, covering PRD writing, Refactoring and Planning. The repository describes itself as: AI Kanban & Development Environment. Orchestrate multiple agents, review changes, open PRs. Multi-provider, self-hostable, no telemetry. The licence is AGPL-3.0.

When your agent uses it

  • New product behavior
  • Changed contracts
  • Explicit specification work
  • Implementation plans

Example prompts

  • “/spec”

Requirements

  • Python 3

Workflow steps

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

  1. Locate the owning system
  2. Confirm intent
  3. Write requirements
  4. Write system design
  5. Update the system boundary
  6. Validate

What it can do on your machine

Read from SKILL.md and the folder at commit b734113. 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

    Shell commands in SKILL.md call:

    • python3
    • git

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

  • Network

    No URLs in SKILL.md. Its commands use git, which can reach the network depending on how they are called.

    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 2.1k tokens when it runs. Until then it costs about 69 tokens; SKILL.md has 1,089 words of instructions outside code blocks.

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

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 kdlbs/kandev at commit b734113, republished under its AGPL-3.0 licence (© kdlbs). 1,089 words, ~2,113 tokens.

Download SKILL.mdSave it as .claude/skills/spec/SKILL.md (or your agent's skills folder).
name
spec
description
Create or update Kandev product requirements and system-design documents before implementation. Use for new product behavior, changed contracts, or explicit specification work. Do not use for implementation plans, work orders, incidents, or behavior-preserving refactors.

Specification Authoring

Use this skill to create or update durable specifications. Requirements define observable behavior. System designs define the technical path that satisfies requirements.

The canonical rules are in docs/specs/guide/. Read these files before you write an artifact:

  • Always read structure-and-ownership.md.
  • Read requirements.md for requirement work.
  • Read system-design.md for system-design work.
  • Read traceability-and-lifecycle.md for IDs, statuses, references, or migration work.

Use the templates in docs/specs/templates/.

Artifact routing

Route the request before you write:

RequestArtifact
Kandev-wide purpose, actors, principles, measures, or constraintsdocs/specs/product/
Observable behavior for one owning system<system>/requirements/
Technical contracts, models, boundaries, or control flow<system>/system-design/
Durable choice with meaningful alternatives/record and an ADR
Delivery sequence and implementation tasks/plan
Incident or behavior-preserving refactorNo product requirement
Bug/fix, which checks the existing requirement first

Do not create a generic spec.md file.

When routing to docs/specs/product/, read docs/specs/product/README.md before editing. Treat its Product document index as the local index: read every linked product document and any co-located INDEX.md, AGENTS.md, CLAUDE.md, or other instruction file when present. Product files provide cross-system context, not feature requirements; preserve proposed and open-question language instead of promoting it to an active contract without confirmation.

Workflow

1. Locate the owning system

Read docs/specs/README.md and the likely system README.md. If the system has not migrated, run this command to locate the legacy source:

python3 scripts/list-docs.py specs --kind legacy --format paths

Search the catalog, requirements, and designs for the capability name and its main nouns:

python3 scripts/list-docs.py specs --text <capability-term> --format paths

Update an existing capability when it owns the same actor, lifecycle, and contract.

Choose the system that owns the source of truth and durable contract. Do not choose an owner from the code directories that change. Record one sentence in the working notes that states why the selected system owns the capability.

User visibility does not make a capability UI-owned. Keep provider state, task state, permissions, persistence, and recovery with their owning systems. Put desktop, mobile, accessibility, and visible failure outcomes in that owner's requirement. Create a UI requirement only for an independent and reusable presentation contract.

The same system owns the requirement and its design. Other systems link to that source. They do not copy it or claim its requirement IDs in design frontmatter.

If no system owns the behavior, define the new system boundary before you write requirements. A new system needs a README.md based on the system template.

2. Confirm intent

Run the /interview-me assumption check, reusing answers from earlier phases. Resolve material choices before writing the affected contract. Preserve settled terminology and decision rationale in the owning artifacts through that skill. Do not hide an unresolved choice in a draft.

3. Write requirements

Create or update:

text
docs/specs/<system>/requirements/<capability>.md

Each requirement document must contain:

  • Valid frontmatter.
  • One or more stable REQ-* IDs.
  • At least one AC-* acceptance criterion for each requirement.
  • Observable behavior and explicit exclusions.

Use user stories only when they clarify a natural actor and outcome. Do not put files, functions, database queries, or implementation sequences in a requirement.

Keep one cohesive vertical outcome together. Do not create separate backend and UI requirements for the same feature. Split only when actors, lifecycles, or contracts are independent.

4. Write system design

Create or update this file when the change needs a technical design:

text
docs/specs/<system>/system-design/<capability>.md

The design must list the applicable REQ-* IDs in frontmatter. It can use an explicit empty list for internal infrastructure with no independent product requirement.

Describe stable components, models, contracts, flow, failure behavior, persistence, security, and observability when they apply. Link to global ADRs. Do not copy requirement or ADR text.

Cover all runtime boundaries that implement the owned outcome. A provider-owned design can include backend services, storage, projections, frontend components, responsive behavior, and tests. Do not create a parallel UI design for those same requirements.

Show full SKILL.md (461 more words)Show less
5. Update the system boundary

Update the system README.md only when the system boundary, migration record, or related-system links change. State the system boundary and link adjacent systems when ownership can be confused. Do not add a requirement or system-design list.

Before and after adding required links, run wc -c <system>/README.md. Near the 12 KiB system-index limit, keep every required link but use concise labels or other non-semantic compression; never add a size exception. Rerun the specification linter after the index update. Also search the README for count or list summaries, update them when the authoritative pair count changes, and verify that each stated count matches the indexed requirement/design pairs.

During migration, name the new source as authoritative. Replace the old source with a link or archive it. Do not leave two editable sources of truth.

If a migration branch merges or rebases a moving base, re-inventory the migration root after the update. Review files newly added by the base, migrate them or explicitly record them as unmigrated additions before marking the migration complete, then rerun the full specification lint.

6. Validate

Review the artifacts before you run the linter:

  • One system owns each requirement and its design.
  • No adjacent system contains a copied requirement or UI-only duplicate.
  • Requirements contain observable behavior, not storage, control flow, or file details.
  • Every acceptance criterion states a testable behavior. No criterion delegates its meaning to migrated source detail.
  • Selection, restoration, and recovery criteria state candidate eligibility, invalid or ambiguous fallback behavior, and forbidden side effects.
  • Designs map requirement IDs without copying requirement text.
  • Each design identifier that names existing code matches the current source. Use rg to confirm exact symbols before the artifact is complete.
  • New files do not copy the legacy Migrated source detail wrapper.
  • New artifacts appear in the catalog command output for the owning system.
  • Before adding prose to an existing specification, check its current byte count against the applicable limit in structure-and-ownership.md; keep enough headroom for the edit or split the document at a contract boundary.

Run:

bash
python3 scripts/list-docs.py validate
python3 scripts/lint-spec-files.test.py
python3 scripts/lint-spec-files.py --all
git diff --check -- docs/specs docs/decisions

If a file reaches its size limit, split it by capability, lifecycle, or contract boundary. Do not add a size exception for a new document.

An existing legacy_size_exceptions value is a frozen ratchet. When a legacy file grows, reduce or split the content and lower the exception to the resulting exact byte size; never raise the ceiling merely to silence lint.

Design-package behavior

When this skill runs inside /spec-driven-development or /fix, continue to the system design, plan, and work orders. Stop after requirements only when the user explicitly requests a requirements review or a material question blocks safe design.

For a standalone specification request, report the changed paths, requirement IDs, design references, validation results, and open questions. Then return control to the user.

© kdlbs, AGPL-3.0. 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 .agents/skills/spec of kdlbs/kandev.

Open the folder on GitHubat commit b734113

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 skillkdlbs/kandev909—~2.1kAutomated safety check: PassAGPL-3.0
Improvefossasia/eventyay-interpretation1.6k10 repos~3.7kAutomated safety check: WarnMIT
PRP Implementation PlannerWirasm/prp2.3k—~4.1kAutomated safety check: PassMIT
Discoveranombyte93/prd-taskmaster604—~2.4kAutomated safety check: PassMIT
One Three One RuleTommy-yw/RunbookHermes5463 repos~1.3kAutomated safety check: PassMIT
Designsynnaxlabs/synnax128—~4.5kAutomated safety check: PassCustom licence

Similar skills

  • Improve

    fossasia/eventyay-interpretation

    Survey any codebase as a senior advisor and produce prioritized, self-contained implementation plans for OTHER models/agents to execute.

    1.6k GitHub starsUsed in 10 repos~3.7k tokens
    Agent WorkflowsAuto-check: warnings

  • PRP Implementation Planner

    Wirasm/prp

    Turns a PRD, issue or description into an implementation-ready plan grounded in codebase evidence, adding root-cause analysis for bugs and publishing issue plans back to the issue.

    2.3k GitHub stars~4.1k tokensUpdated 6 days ago
    DevelopmentAuto-check passed

  • Discover

    anombyte93/prd-taskmaster

    Phase 1 of the prd-taskmaster pipeline: brainstorm-driven discovery.

    604 GitHub stars~2.4k tokensUpdated 1 mo ago
    Agent WorkflowsAuto-check passed

  • One Three One Rule

    Tommy-yw/RunbookHermes

    Structured decision-making framework for technical proposals and trade-off analysis.

    546 GitHub starsUsed in 3 repos~1.3k tokens
    Agent WorkflowsAuto-check passed

  • Design

    synnaxlabs/synnax

    Process and hard rules for designing and planning complex new features, refactors, and re-architectures.

    128 GitHub stars~4.5k tokensUpdated today
    Agent WorkflowsAuto-check passed

  • Solution Architect

    IBM/ibm-watsonx-orchestrate-adk

    Official

    Expert guidance for creating high-level solution architecture documents from business requirements, use cases, or problem statements.

    178 GitHub stars~8.4k tokensUpdated today
    Agent WorkflowsAuto-check passed

More from kdlbs/kandev

All 45 skills in this repo

  • PR Walkthrough

    kdlbs/kandev

    Generate a single-file HTML walkthrough that explains a PR's purpose, user impact, interface changes, compatibility risks, and implementation.

    909 GitHub stars~6.2k tokensUpdated today
    Auto-check passed

  • Debug

    kdlbs/kandev

    Diagnose Kandev bugs, running-instance issues, UI/browser failures, and runtime behavior.

    909 GitHub stars~2.2k tokensUpdated today
    Auto-check passed

  • Harness Improvement

    kdlbs/kandev

    Improve Kandev's AI harness from session learnings or explicit requests.

    909 GitHub stars~1.3k tokensUpdated today
    Auto-check passed

  • Diagram Design

    kdlbs/kandev

    Create branded architecture, IT current-state, flowchart, sequence, state machine, ER/data model, timeline, swimlane, quadrant, radar/spider, polar chart (polar/radial lollipop), loop/flywheel…

    909 GitHub starsUsed in 1 repo~8k tokens
    Auto-check passed

  • TDD

    kdlbs/kandev

    Implement changes using Test-Driven Development (Red-Green-Refactor).

    909 GitHub stars~4.2k tokensUpdated today
    Auto-check passed

  • Verify

    kdlbs/kandev

    Run a broad local verification audit only when the user explicitly requests it or PR/CI remediation requires it.

    909 GitHub stars~2.7k tokensUpdated today
    Auto-check passed

Categories

Questions about Spec

What does Spec do?

Create or update Kandev product requirements and system-design documents before implementation. Spec is an agent skill from kdlbs/kandev. Create or update Kandev product requirements and system-design documents before implementation.

When should I use Spec?

Spec fits situations like: new product behavior; changed contracts; explicit specification work; implementation plans.

How do I install Spec in Claude Code?

Run `npx skills add kdlbs/kandev --skill spec -a claude-code`. Or copy the skill folder (.agents/skills/spec in kdlbs/kandev) 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 kdlbs/kandev --skill spec -a codex`. Or copy the skill folder (.agents/skills/spec in kdlbs/kandev) 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 kdlbs/kandev --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?

Going by SKILL.md and its folder, Spec needs the command-line tools its instructions call (python3 and git). Our summary lists: Python 3.

Does Spec access the network?

SKILL.md contains no URLs. Its commands use git, which can reach the network depending on how they are called. 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 AGPL-3.0 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 2.1k tokens (SKILL.md is roughly 8.5k 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: Improve (fossasia/eventyay-interpretation, 1.6k stars), PRP Implementation Planner (Wirasm/prp, 2.3k stars), Discover (anombyte93/prd-taskmaster, 604 stars) and One Three One Rule (Tommy-yw/RunbookHermes, 546 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Spec?

kdlbs (a GitHub organization) maintains it in kdlbs/kandev, which has 909 GitHub stars. The repository holds 45 skills in this directory. The repository was last updated on October 8, 2026.

Source: kdlbs/kandev on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.