review-spec
Skill31 starsChanged 6 months agoMITView on GitHub
Reviews proposal, specification, design, and task artifacts for internal consistency, testability, traceability, and cross-artifact alignment. Use when asked to review a spec, review artifacts, check design documents, check a change for consistency, or verify artifact quality before implementation.
We split this skill into the rules it gives an agent
3 rules. 0 are common, 3 are distinctive, and 0 are very specific to this project.
0
Common
Most of the 17 edited versions we read keep these.
3
Distinctive
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 11
Read all relevant markdown artifacts and infer their roles from path and content.
- Distinctive: line 24
Every finding must cite the exact path and section.
- Distinctive: line 27
Do not critique product intent or architecture, search for missing behavior or failure-mode decisions, review implementation code, invent …
“Common” is measured: kept by at least 6 in 10 of the 17 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Review Spec
Review the supplied planning artifacts for internal coherence, structural testability, traceability, and cross-artifact consistency. Accept product and design choices as written; consequential gaps, alternatives, and weak decisions belong to an approach review.
Read all relevant markdown artifacts and infer their roles from path and content. Missing artifact types are not findings.
Check applicable concerns:
- contradictions, scope drift, dropped commitments, or terminology drift across artifacts;
- behavioral requirements without a concrete testable scenario, scenarios that do not express their requirement, or unresolved placeholders;
- tasks that are not self-contained, lack exact source citations, alter source acceptance criteria, over-prescribe implementation, retain placeholders, or separate ordinary infrastructure, tests, or docs from the behavior they support; and
- contradictions or unresolved references within an artifact.
Every finding must cite the exact path and section. Recommend the smallest consistency-preserving fix when more than one is possible.
Do not critique product intent or architecture, search for missing behavior or failure-mode decisions, review implementation code, invent missing artifacts, or rewrite the artifacts.
## Findings
### [high|medium|low] <title>
- Artifact: <path and section>
- Issue: <consistency, testability, traceability, or coherence defect>
- Fix: <smallest safe correction>
## Assessment
<Artifact readiness, or "No findings.">Other versions18 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 18
- warpdotdev/oz-for-oss★ 313same name
- sd0xdev/sd0x-dev-flow★ 192same name
- sd0xdev/sd0x-harness★ 192same name
- tranhieutt/software_development_department★ 71same name
- holgerleichsenring/specification-first-agentic-development★ 37same name
- alo-exp/silver-bullet★ 7same name
- sergeyklay/.agents★ 6same name
- dekoza/oh-my-slop★ 4same name
- NitinJ/specforge★ 4same name
- sponge-b0b/Polaris★ 4same name
8 more not listed
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.
Used alongsideProjects with it also use create-spec.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
srobinsonSkillcreate-spec
Create a task specification (SPEC.md) through interactive requirements elicitation. Use when helping users define what they want to build before autonomous execution begins.
Also in 3 projects that use this
In this repository30 other files it gives its agents.
- AGENTS.mdAGENTS.md
- docs/AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- releaseSkill
- releaseSkill
- ask-questionsSkill
- call-agentSkill
- designSkill
- finalize-prSkill
- fix-prSkill
- handoffSkill
- implement-changeSkill
- initSkill
- orchestrate-changeSkill
- plan-tasksSkill
- prepare-acceptanceSkill
- proposal-reviewSkill
- proposeSkill
- push-prSkill
- review-approachSkill
- review-assumptionsSkill
- review-tasksSkill
- session-reportSkill
- simple-planSkill
- specSkill
- task-complianceSkill
- test-flowsSkill
- test-planSkill
- verify-behaviorSkill
- wait-ciSkill
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
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.

