agentleFS
Sign inStart free
iyakiiyaki/specralph/.agents/skills/spec-creator/SKILL.md

spec-creator

Skill7 starsChanged 11 days agoMITView on GitHub

Create, update, or review engineering-grade technical specifications for a codebase, following spec-driven development (SDD) conventions. Use whenever the user asks for a spec, requirements or design doc, feature specification, API contract, data model, or wants a feature planned on paper before implementation — including phrases like "write a spec for X", "draft the spec first", "update the specs", or any spec-first workflow (e.g. with Ralph). Produces implementation-ready, testable specs using the bundled SPEC_TEMPLATE.md.

3 other projects use a version of this.

Adopted by

Most recently taken up by

  • Other versions3 projects use a version of this.

    Word for word · 0

    None found.

    Edited · 0

    None found.

    Wrote their own version · 3

    1. felipeArnold/filament-ai-skills★ 9same name
    2. jornalistainclusivo/jinc-skills★ 1same name
    3. Lausbub198/claude-skills★ 0same name

    How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.

  • In this repository5 other files it gives its agents.

The file

Show its rules and text

We split this skill into the rules it gives an agent

19 rules. About 0 are common, 18 are distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈18

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Prefer concrete examples over vague descriptions.

    line 17
  2. Distinctive:

    Use consistent naming and types across the document.

    line 18
  3. Distinctive:

    Avoid assumptions; write them down.

    line 20
  4. Distinctive:

    Keep implementation details out of the spec: no algorithms, file/package layouts, or internal design choices.

    line 23
  5. Distinctive:

    Never reference source code: no file paths, no function, class, or module names, no code snippets from the codebase.

    line 24
  6. Distinctive:

    Follow this structure exactly, but customize content to the project.

    line 31
  7. Distinctive:

    Use precise, plain english language.

    line 35
  8. Distinctive:

    Prefer tables for enums, options, or matrices.

    line 36
  9. Distinctive:

    Write what and why, never how: justify decisions and constraints.

    line 38
  10. Distinctive:

    Never reference source code artifacts: no file paths, no function, class, or module names, no code snippets.

    line 39
  11. Distinctive:

    Keep naming consistent across entities, APIs, and SDKs.

    line 41
  12. Distinctive:

    If a behavior depends on policy, state it explicitly.

    line 42
  13. Distinctive:

    If a data model is shared across domains, treat one spec as the source of truth and reference it rather than re-defining it.

    line 43
  14. Distinctive:

    All core entities and relationships are defined.

    line 50
  15. Distinctive:

    Every endpoint has auth and payloads.

    line 51
  16. Distinctive:

    All critical workflows are described step-by-step.

    line 52
  17. Distinctive:

    Every requirement reads as intended, observable behavior (what and why).

    line 55
  18. Distinctive:

    No implementation details and no source-code references remain.

    line 56
  19. Very specific:

    When the new spec is complete, update specs/README.md to include it in the list of available specs.

    line 60

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Spec Authoring

Purpose

Produce detailed, engineering-grade specifications similar in depth and structure to a full platform spec. The output must be explicit, testable, and implementation-ready without needing back-and-forth clarification. Specs state intended behavior — what the system must do and why — and leave how to implementation.

Core Principles

  1. State intent clearly and early.
  2. Define scope and non-scope to avoid ambiguity.
  3. Make every requirement verifiable.
  4. Prefer concrete examples over vague descriptions.
  5. Use consistent naming and types across the document.
  6. Include failure modes and edge cases.
  7. Avoid assumptions; write them down.
  8. Define canonical data models in a single spec and reference them elsewhere to prevent duplication.
  9. Describe intended, observable behavior: what the system must do, not how it does it.
  10. Keep implementation details out of the spec: no algorithms, file/package layouts, or internal design choices.
  11. Never reference source code: no file paths, no function, class, or module names, no code snippets from the codebase.
  12. Give the why: justify decisions and constraints so implementers understand the intent behind them.

Required Structure

See the SPEC_TEMPLATE.md for a template with detailed section descriptions and writing guidelines.

Follow this structure exactly, but customize content to the project.

Writing Rules

  • Use precise, plain english language.
  • Prefer tables for enums, options, or matrices.
  • Describe requirements as intended behavior: given X, the system must Y — including error and edge cases.
  • Write what and why, never how: justify decisions and constraints; leave algorithms, file/package organization, and library choices to implementation.
  • Never reference source code artifacts: no file paths, no function, class, or module names, no code snippets.
  • Include code blocks only to illustrate examples (inputs, outputs, commands, data formats); never source code.
  • Keep naming consistent across entities, APIs, and SDKs.
  • If a behavior depends on policy, state it explicitly.
  • If a data model is shared across domains, treat one spec as the source of truth and reference it rather than re-defining it.

Output Quality Checklist

Before finalizing, confirm:

  • Scope is explicit and non-goals are listed.
  • All core entities and relationships are defined.
  • Every endpoint has auth and payloads.
  • All critical workflows are described step-by-step.
  • Security and permissions are not implicit.
  • At least one example is given for each major section.
  • Every requirement reads as intended, observable behavior (what and why).
  • No implementation details and no source-code references remain.

Related docs

When the new spec is complete, update specs/README.md to include it in the list of available specs.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free