Cabloy Spec Generation
cabloy/cabloy
A skill your agent uses to create or maintain Cabloy suite specifications under repo-specs, including PRD, SRS, PDP/WBS, acceptance planning, progress, and suite ADRs.
Determines which of PRD, ADR, UI Spec, Design Doc, and Work Plan a change requires, and where each is stored.
Install Documentation Criteria
$ npx skills add shinpr/claude-code-workflows --skill documentation-criteria -a claude-codeProject install by default; add -g for ~/.claude/skills/.
$ gh skill install shinpr/claude-code-workflows documentation-criteria --agent claude-codeProject scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).
$ git clone --depth 1 https://github.com/shinpr/claude-code-workflows.git skills-src && mkdir -p .claude/skills && cp -r skills-src/skills/documentation-criteria .claude/skills/documentation-criteria && rm -rf skills-srcUse ~/.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/
Install the "documentation-criteria" agent skill from https://github.com/shinpr/claude-code-workflows/tree/main/skills/documentation-criteria into .claude/skills/documentation-criteria/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "documentation-criteria", then confirm the skill loads.Claude Code copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$skill-installer install https://github.com/shinpr/claude-code-workflows/tree/main/skills/documentation-criteriaType this inside Codex. $skill-installer <name> installs a curated skill from openai/skills. The installer writes to $CODEX_HOME/skills (default ~/.codex/skills). Restart Codex if the skill does not show up.
$ npx skills add shinpr/claude-code-workflows --skill documentation-criteria -a codexProject install goes to .agents/skills/; add -g for ~/.codex/skills/.
$ gh skill install shinpr/claude-code-workflows documentation-criteria --agent codexProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/shinpr/claude-code-workflows.git skills-src && mkdir -p .agents/skills && cp -r skills-src/skills/documentation-criteria .agents/skills/documentation-criteria && rm -rf skills-srcUse ~/.agents/skills/ instead of .agents/skills for a personal install.
Codex skills documentation · loads skills from .agents/skills/
Install the "documentation-criteria" agent skill from https://github.com/shinpr/claude-code-workflows/tree/main/skills/documentation-criteria into .agents/skills/documentation-criteria/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "documentation-criteria", then confirm the skill loads.Codex copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ npx skills add shinpr/claude-code-workflows --skill documentation-criteria -a cursorProject install goes to .agents/skills/; add -g for ~/.cursor/skills/.
$ gh skill install shinpr/claude-code-workflows documentation-criteria --agent cursorProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/shinpr/claude-code-workflows.git skills-src && mkdir -p .cursor/skills && cp -r skills-src/skills/documentation-criteria .cursor/skills/documentation-criteria && rm -rf skills-srcUse ~/.cursor/skills/ instead of .cursor/skills for a personal install.
Cursor skills documentation · loads skills from .cursor/skills/, .agents/skills/, .claude/skills/, .codex/skills/
Install the "documentation-criteria" agent skill from https://github.com/shinpr/claude-code-workflows/tree/main/skills/documentation-criteria into .cursor/skills/documentation-criteria/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "documentation-criteria", then confirm the skill loads.Cursor copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ gemini skills install https://github.com/shinpr/claude-code-workflows.git --path skills/documentation-criteria--scope user (default) or --scope workspace; --path is the subfolder of the repo that holds the skill; --consent skips the security confirmation prompt.
$ npx skills add shinpr/claude-code-workflows --skill documentation-criteria -a gemini-cliProject install goes to .agents/skills/; add -g for ~/.gemini/skills/.
$ gh skill install shinpr/claude-code-workflows documentation-criteria --agent gemini-cliProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/shinpr/claude-code-workflows.git skills-src && mkdir -p .gemini/skills && cp -r skills-src/skills/documentation-criteria .gemini/skills/documentation-criteria && rm -rf skills-srcUse ~/.gemini/skills/ instead of .gemini/skills for a personal install, then run /skills reload.
Gemini CLI skills documentation · loads skills from .gemini/skills/, .agents/skills/
Install the "documentation-criteria" agent skill from https://github.com/shinpr/claude-code-workflows/tree/main/skills/documentation-criteria into .gemini/skills/documentation-criteria/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "documentation-criteria", then confirm the skill loads.Gemini CLI copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ gh skill install shinpr/claude-code-workflows documentation-criteriaInstalls for Copilot at project scope by default; add --scope user for a personal install. Preview a skill first with gh skill preview. Needs GitHub CLI 2.90.0 or later (public preview).
$ npx skills add shinpr/claude-code-workflows --skill documentation-criteria -a github-copilotProject install goes to .agents/skills/; add -g for ~/.copilot/skills/.
$ git clone --depth 1 https://github.com/shinpr/claude-code-workflows.git skills-src && mkdir -p .github/skills && cp -r skills-src/skills/documentation-criteria .github/skills/documentation-criteria && rm -rf skills-srcUse ~/.copilot/skills/ instead of .github/skills for a personal install. Commit .github/skills so cloud agent and code review can use it.
GitHub Copilot skills documentation · loads skills from .github/skills/, .claude/skills/, .agents/skills/
Install the "documentation-criteria" agent skill from https://github.com/shinpr/claude-code-workflows/tree/main/skills/documentation-criteria into .github/skills/documentation-criteria/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "documentation-criteria", then confirm the skill loads.GitHub Copilot copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ npx skills add shinpr/claude-code-workflows --skill documentation-criteria -a opencodeOpenCode documents no install command of its own. Project install goes to .agents/skills/; add -g for ~/.config/opencode/skills/.
$ gh skill install shinpr/claude-code-workflows documentation-criteria --agent opencodeProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/shinpr/claude-code-workflows.git skills-src && mkdir -p .opencode/skills && cp -r skills-src/skills/documentation-criteria .opencode/skills/documentation-criteria && rm -rf skills-srcUse ~/.config/opencode/skills/ instead of .opencode/skills for a personal install.
OpenCode skills documentation · loads skills from .opencode/skills/, .claude/skills/, .agents/skills/
Install the "documentation-criteria" agent skill from https://github.com/shinpr/claude-code-workflows/tree/main/skills/documentation-criteria into .opencode/skills/documentation-criteria/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "documentation-criteria", then confirm the skill loads.OpenCode copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
Facts
- Skill name
documentation-criteria- GitHub stars
- 694
- Token cost
- ~1.9k tokens
- SKILL.md length
- 904 words
- Files
- 7 (incl. references)
- Skills in repo
- 30
- Repo updated
- First seen
- Licence
- MIT
At a glance
Determines which of PRD, ADR, UI Spec, Design Doc, and Work Plan a change requires, and where each is stored.
- Works in 3 steps: Select the base path from Structural… → Insert an applicable UI Spec immediately… → One or more qualifying ADR decision…
- Deciding documentation scope
- SKILL.md covers What Each Document Fixes, Creation Decision Matrix, Structural Scale and ADR Decision Filters, plus 2 more sections
- Instructions only: no scripts, shell commands, URLs or credentials in SKILL.md
What it does
Documentation Criteria is an agent skill from shinpr/claude-code-workflows. Determines which of PRD, ADR, UI Spec, Design Doc, and Work Plan a change requires, and where each is stored. Use when deciding documentation scope, or when creating or reviewing a technical document.
Its SKILL.md is about 1.9k tokens, which your agent loads only when the skill is triggered. The skill folder holds 7 other files, including reference files (for example `references/adr-template.md`, `references/design-template.md` and `references/plan-template.md`).
It sits in Development, covering Architecture decision records and PRD writing. The repository describes itself as: Development workflows for Claude Code that keep broad exploration focused on the outcome you approved. The licence is MIT.
When your agent uses it
- Deciding documentation scope
- Reviewing a technical document
Example prompts
- “Use the documentation-criteria skill to determine which of PRD, ADR, UI Spec, Design Doc, and Work Plan a change requires, and where each is stored”
- “/documentation-criteria”
Workflow steps
3 steps, taken from the first numbered list in SKILL.md.
- Select the base path from Structural Scale.
- Insert an applicable UI Spec immediately before the Design Doc.
- One or more qualifying ADR decision points insert an ADR batch immediately before the Design Doc. A qualifying decision point sets the…
What it can do on your machine
Read from SKILL.md and the folder at commit a4ecd62. 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.
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
Documentation Criteria loads about 1.9k tokens when it runs, and up to ~12k if it reads all its reference files. Until then it costs about 56 tokens; SKILL.md has 904 words of instructions outside code blocks.
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 shinpr/claude-code-workflows at commit a4ecd62, republished under its MIT licence (© shinpr). 904 words, ~1,927 tokens.
Download SKILL.mdSave it as
.claude/skills/documentation-criteria/SKILL.md (or your agent's skills folder). This skill also uses 6 other files; get the full folder from GitHub.- name
- documentation-criteria
- description
- Determines which of PRD, ADR, UI Spec, Design Doc, and Work Plan a change requires, and where each is stored. Use when deciding documentation scope, or when creating or reviewing a technical document.
Documentation Creation Criteria
This file holds the routing decision: which documents a change requires and where they live. What to write inside one is defined by its template, linked from Storage Locations.
What Each Document Fixes
Each document fixes one class of decision that the repository alone cannot supply. An unfilled section becomes a guess made later by the consumer named below, with no record of what was assumed.
PRD — Fixes the business outcome and the acceptance criteria later work traces to. Its AC IDs are the traceability keys that the Design Doc, UI Spec, and test selection reuse; without them each consumer re-derives requirements from prose and the link between a test and the value it protects is lost. Implementation details belong to the Design Doc, selection rationale to an ADR, phases and task breakdown to the Work Plan.
ADR — Records one durable technical choice and the options it beat, so later work can tell a deliberate decision from an accident. Without it a future change either re-runs the same comparison or silently reverses it.
Acceptedrecords the currently selected means, not an obligation to retain it: when later evidence supports a smaller sufficient choice, update or supersede the decision while the confirmed outcome, desired-future requirements, and non-goals remain true. End-to-end implementation design belongs to the Design Doc, schedule and repository tasks to the Work Plan.UI Spec — Records screen structure, transitions, component/state contracts, and visual acceptance before components exist, so decomposition is decided before implementation instead of per-component during it. Create one when those decisions remain open; reuse an approved UI Spec or go straight to the Design Doc when one evident repository-supported pattern already determines them. Technical implementation and API contracts belong to the Design Doc.
Design Doc — Records the complete implementation design for the confirmed scope: flows, contracts, change impact, and verification strategy. Task execution treats it as the primary technical baseline, so implementation does not silently invent missing How. When repository evidence invalidates technical How while confirmed outcome, desired-future requirements, and non-goals remain true, correct the implementation and the affected technical artifact through their owning workflow without reopening product requirements. Technology selection rationale belongs to an ADR, schedule and assignments to the Work Plan.
Work Plan — Fixes task order, dependencies, executable verification, and the earliest vertical proof point. Without it task order follows file layout rather than dependency, and integration risk moves to the end of the work. Design detail is referenced from the Design Doc rather than restated.
Creation Decision Matrix
| Structural Scale | Base Documents | Creation Order |
|---|---|---|
| Small | None | Direct implementation |
| Medium | Design Doc → Work Plan | Start with Design Doc |
| Large | PRD → Design Doc → Work Plan | Continue after PRD approval |
Build one path in this order:
- Select the base path from Structural Scale.
- Insert an applicable UI Spec immediately before the Design Doc.
- One or more qualifying ADR decision points insert an ADR batch immediately before the Design Doc. A qualifying decision point sets the scale floor to Medium.
Show full SKILL.md (406 more words)Show less
Structural Scale
Classify the decision burden, not repository layout. File count is supporting evidence only.
| Scale | Structural condition |
|---|---|
| Small | One coherent outcome has one evident repository-supported implementation within one responsibility boundary and no unresolved durable choice |
| Medium | One coherent outcome coordinates across a boundary or requires investigation of a potentially durable choice |
| Large | Multiple independently valuable outcomes require separate design decisions |
A qualifying ADR decision point sets the floor at Medium because it creates a durable decision. One coherent outcome remains Medium when it crosses multiple layers; Large requires independently valuable outcomes with separate design decisions.
ADR Decision Filters
Apply the Choice filter, then the Durability filter, to each technical topic inside the confirmed implementation scope. Apply them independently from Structural Scale, and check existing ADRs first.
- Choice requires judgment — current requirements, accepted decisions, and representative repository evidence support at least two credible, materially distinct options whose selection requires comparison.
- Decision is durable — choosing among those options materially changes responsibility, dependency direction, a shared contract, persistence, a technology dependency, reversibility, or lifecycle cost that future work must preserve or understand.
Create one ADR for each topic that passes both filters, and review the complete batch together. Treat choices as one decision point when they must be selected or reconsidered together; separate independently revisitable choices.
Qualifying durable choices include:
- introducing or replacing a technology, library, platform, storage model, or external dependency;
- changing ownership, dependency direction, a trust boundary, or a shared public contract when credible alternatives exist;
- replacing an accepted architecture decision with a different durable choice that passes both filters;
- choosing an irreversible or high-cost-to-reverse data or compatibility strategy.
A local contract, data-flow, state, or component change belongs in the Design Doc when it follows an accepted design, has one evident repository-supported implementation, or remains cheaply reversible. Counts of files, consumers, nesting levels, states, steps, and asynchronous operations are supporting evidence rather than ADR criteria. Only the qualifying decisions above create ADRs; generic technical concerns, operational possibilities, and rejected activities can only support that determination.
Storage Locations
| Document | Path | Naming Convention | Template |
|---|---|---|---|
| PRD | docs/prd/ | [feature-name]-prd.md | prd-template.md |
| ADR | docs/adr/ | ADR-[4-digits]-[title].md | adr-template.md |
| UI Spec | docs/ui-spec/ | [feature-name]-ui-spec.md | ui-spec-template.md |
| UI Spec Assets | docs/ui-spec/assets/{feature-name}/ | Prototype code files | - |
| Design Doc | docs/design/ | [feature-name]-design.md | design-template.md |
| Work Plan | docs/plans/ | YYYYMMDD-{type}-{description}.md | plan-template.md |
| Task File | docs/plans/tasks/ | {plan-name}-task-{number}.md | task-template.md |
*Note: Work plans are excluded by .gitignore
References
Each template defines the content, structural elements, and diagram criteria for its document: prd-template.md, adr-template.md, ui-spec-template.md, design-template.md, plan-template.md, task-template.md
© shinpr, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file
Files
SKILL.md and 6 other files (references) in skills/documentation-criteria of shinpr/claude-code-workflows.
- SKILL.md
- references/adr-template.md
- references/design-template.md
- references/plan-template.md
- references/prd-template.md
- references/task-template.md
- references/ui-spec-template.md
Open the folder on GitHubat commit a4ecd62
Compare with similar skills
Documentation Criteria 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.
| Skill | Stars | Used in | Tokens | Auto-check | Licence | Repo updated |
|---|---|---|---|---|---|---|
| Documentation Criteria this skillshinpr/claude-code-workflows | 694 | — | ~1.9k | Automated safety check: Pass | MIT | |
| Cabloy Spec Generationcabloy/cabloy | 982 | — | ~3.2k | Automated safety check: Notes | MIT | |
| Bmad Architectureaj-geddes/claude-code-bmad-skills | 488 | — | ~1.9k | Automated safety check: Notes | Custom licence | |
| Vibe CodingOfficeDev/microsoft-365-agents-toolkit | 780 | — | ~5.5k | Automated safety check: Pass | Custom licence | |
| Ad ReviewCorridorTech/PoseCap | 224 | — | ~2.4k | Automated safety check: Notes | Apache-2.0 | |
| Squid Planiusztinpaul/squid | 203 | — | ~2.6k | Automated safety check: Pass | Apache-2.0 |
Similar skills
Bmad Architecture
aj-geddes/claude-code-bmad-skills
Solutioning skill (Winston, the Architect). An agent skill from aj-geddes/claude-code-bmad-skills.
Vibe Coding
OfficeDev/microsoft-365-agents-toolkit
End-to-end workflow for agent-driven changes that add or modify behavior in the toolkit packages.
Ad Review
CorridorTech/PoseCap
Two-axis fresh-context code review per WORKFLOW §10. An agent skill from CorridorTech/PoseCap.
Squid Plan
iusztinpaul/squid
Turn a raw feature spec into an approved Tasks Plan — grill the spec, have the Product Architect groom draft tasks (+ optional ADR and glossary additions), then run ONE human gate that decides…
Documentation Criteria
shinpr/ai-coding-project-boilerplate
Determines which PRD, ADR, UI Spec, Design Doc, and Work Plan a change requires and where each is stored.
More from shinpr/claude-code-workflows
All 30 skills in this repoIntegration E2E Testing
shinpr/claude-code-workflows
Integration and E2E test design principles, ROI calculation, test skeleton specification, and review criteria.
AI Development Guide
shinpr/claude-code-workflows
Applies language-agnostic and backend technical decision criteria, anti-pattern detection, debugging, and quality gates.
Frontend AI Guide
shinpr/claude-code-workflows
Applies React/TypeScript-specific technical decision criteria, anti-pattern detection, debugging, and frontend quality gates.
Implementation Approach
shinpr/claude-code-workflows
Implementation strategy selection framework. An agent skill from shinpr/claude-code-workflows.
Recipe Quality Profile
shinpr/claude-code-workflows
Proposes repository-specific quality policy for implementation and review and, after confirmation, creates or updates docs/project-context/quality.yaml.
Subagents Orchestration Guide
shinpr/claude-code-workflows
Guides subagent coordination through implementation workflows.
Related
Categories
Questions about Documentation Criteria
What does Documentation Criteria do?
Determines which of PRD, ADR, UI Spec, Design Doc, and Work Plan a change requires, and where each is stored. Documentation Criteria is an agent skill from shinpr/claude-code-workflows. Determines which of PRD, ADR, UI Spec, Design Doc, and Work Plan a change requires, and where each is stored.
When should I use Documentation Criteria?
Documentation Criteria fits situations like: deciding documentation scope; reviewing a technical document.
How do I install Documentation Criteria in Claude Code?
Run `npx skills add shinpr/claude-code-workflows --skill documentation-criteria -a claude-code`. Or copy the skill folder (skills/documentation-criteria in shinpr/claude-code-workflows) into .claude/skills/documentation-criteria in your project. Claude Code loads it when a task matches its description.
How do I install Documentation Criteria in Codex?
Run `npx skills add shinpr/claude-code-workflows --skill documentation-criteria -a codex`. Or copy the skill folder (skills/documentation-criteria in shinpr/claude-code-workflows) into .agents/skills/documentation-criteria in your project. Codex loads it when a task matches its description.
Can I use Documentation Criteria 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 shinpr/claude-code-workflows --skill documentation-criteria -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/documentation-criteria, .gemini/skills/documentation-criteria, .github/skills/documentation-criteria and .opencode/skills/documentation-criteria in your project.
What does Documentation Criteria need to run?
SKILL.md names no scripts, command-line tools or credentials: Documentation Criteria is instructions for the agent only.
Does Documentation Criteria 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 Documentation Criteria 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 Documentation Criteria use?
Documentation Criteria 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 Documentation Criteria use?
About 1.9k tokens (SKILL.md is roughly 7.7k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full. Its references folder adds about 10k tokens, read only when the agent opens those files.
What are the alternatives to Documentation Criteria?
Skills that share tags, products or a category with Documentation Criteria: Cabloy Spec Generation (cabloy/cabloy, 982 stars), Bmad Architecture (aj-geddes/claude-code-bmad-skills, 488 stars), Vibe Coding (OfficeDev/microsoft-365-agents-toolkit, 780 stars) and Ad Review (CorridorTech/PoseCap, 224 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.
Who maintains Documentation Criteria?
shinpr (a GitHub user) maintains it in shinpr/claude-code-workflows, which has 694 GitHub stars. The repository holds 30 skills in this directory. The repository was last updated on October 1, 2026.
Source: shinpr/claude-code-workflows on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.