speckit-tinyspec-implement
Skill1 starsChanged 24 days agoMITView on GitHub
Implement a small change directly from its tinyspec file
In this repository19 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- docs-auditSkill
- north-starSkill
- root-causeSkill
- speckit-analyzeSkill
- speckit-checklistSkill
- speckit-clarifySkill
- speckit-constitutionSkill
- speckit-convergeSkill
- speckit-implementSkill
- speckit-planSkill
- speckit-specifySkill
- speckit-tasksSkill
- speckit-taskstoissuesSkill
- speckit-tinyspec-classifySkill
- speckit-tinyspec-tinyspecSkill
- speckit-verify-tasks-runSkill
- speckit-verify-tasksSkill
The file
We split this skill into the rules it gives an agent
12 rules. About 0 are common, 7 are distinctive, and 5 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈7
Distinctive · estimate
This author's own choices. Worth a look.
5
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 24
Verify a spec-kit project exists by checking for .specify/ directory
- Distinctive: line 25
Verify git is available and the project is a git repository
- Very specific: line 27
If user specifies a name, look for specs/tiny/{name}.md
- Very specific: line 28
If no input, look for the most recently created tinyspec in specs/tiny/
- Very specific: line 29
If no tinyspec files exist, suggest running /speckit.tinyspec first
- Distinctive: line 43
Test patterns and conventions
- Distinctive: line 48
Follow existing code patterns and conventions from context files
- Distinctive: line 51
Run verification: After all tasks are complete:
- Distinctive: line 52
Check that all "Done When" criteria are met
- Distinctive: line 53
Verify tests pass (if test tasks were included)
- Distinctive: line 54
Verify no lint errors (if linting is configured)
- Very specific: line 58
All task checkboxes should be [x]
≈ “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.
Files
TinySpec Implement
Implement a small change by following the plan and tasks in its tinyspec file. Works like /speckit.implement but optimized for single-file specs — reads one document, executes the tasks, and marks them complete.
User Input
$ARGUMENTSYou MUST consider the user input before proceeding (if not empty). The user may specify which tinyspec to implement (e.g., "logout-button") or a path to the tinyspec file.
Prerequisites
- Verify a spec-kit project exists by checking for
.specify/directory - Verify git is available and the project is a git repository
- Locate the tinyspec file:
- If user specifies a name, look for
specs/tiny/{name}.md - If no input, look for the most recently created tinyspec in
specs/tiny/ - If no tinyspec files exist, suggest running
/speckit.tinyspecfirst
- If user specifies a name, look for
Outline
- Read the tinyspec: Parse the tinyspec file to extract:
- Context files: Files listed in the Context table
- Requirements: The numbered requirements list
- Plan: The ordered implementation steps
- Tasks: The checkbox task list
- Done When: The completion criteria
- Read context files: Load all files listed in the Context table to understand:
- Current code structure and patterns
- Existing imports and dependencies
- Test patterns and conventions
- Execute tasks: Work through the task list in order:
- For each task, follow the corresponding plan step
- Implement the change in the identified file
- Follow existing code patterns and conventions from context files
- Mark each task as
[x]in the tinyspec file after completion
- Run verification: After all tasks are complete:
- Check that all "Done When" criteria are met
- Verify tests pass (if test tasks were included)
- Verify no lint errors (if linting is configured)
- Update tinyspec: Mark the tinyspec as complete:
- Change
**Status**: draftto**Status**: done - All task checkboxes should be
[x] - All "Done When" checkboxes should be
[x]
- Change
Report:
# TinySpec Complete: {Title} | Field | Value | |-------|-------| | **Tasks completed** | {N}/{N} | | **Files modified** | {list} | | **Tests** | ✅ Pass / ❌ Fail | ## Changes Made 1. {What was changed in file 1} 2. {What was changed in file 2} ## Next Steps - Review changes with `git diff` - Commit when satisfied
Rules
- Follow the spec — implement exactly what the tinyspec describes, no more
- One task at a time — complete each task before moving to the next
- Update the tinyspec — mark tasks as done in the file as you complete them
- Respect existing patterns — match the code style of context files
- Stop on ambiguity — if a task is unclear, ask the user rather than guessing
- No scope creep — if implementation reveals the task is larger than expected, stop and suggest upgrading to full SDD
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.

