speckit-tinyspec-classify
Skill1 starsChanged 24 days agoMITView on GitHub
Classify task complexity and recommend tinyspec or full SDD workflow
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-implementSkill
- speckit-tinyspec-tinyspecSkill
- speckit-verify-tasks-runSkill
- speckit-verify-tasksSkill
The file
We split this skill into the rules it gives an agent
2 rules. About 0 are common, 1 is distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈1
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
- Very specific: line 24
Verify a spec-kit project exists by checking for .specify/ directory
- Distinctive: line 25
Verify the user has described the task (if not, ask what they want to build)
≈ “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
Classify Task Complexity
Analyze a task description to determine whether it should use the lightweight tinyspec workflow or the full SDD workflow (specify → plan → tasks → implement). Acts as an intelligent router that saves time on small tasks and ensures proper process for complex ones.
User Input
$ARGUMENTSYou MUST consider the user input before proceeding (if not empty). The user describes what they want to build or fix.
Prerequisites
- Verify a spec-kit project exists by checking for
.specify/directory - Verify the user has described the task (if not, ask what they want to build)
Outline
Analyze the task: Evaluate the task description against complexity signals:
Small task signals (→ tinyspec):
Signal Example Single UI component change "Add a logout button" Bug fix with known location "Fix date format in invoices" Config or environment change "Add new env variable for API key" Simple validation addition "Add email validation to signup" Copy/text update "Update error messages" Single endpoint addition "Add GET /health endpoint" Styling change "Make the sidebar responsive" Large task signals (→ full SDD):
Signal Example Multiple modules affected "Add user authentication system" New database tables/schema "Add a comments feature with threading" Architectural change "Migrate from REST to GraphQL" New service or integration "Add Stripe payment processing" Cross-cutting concern "Add audit logging to all endpoints" Multiple user stories "Build the admin dashboard" Unknown scope "Improve performance" (needs investigation first) - Estimate scope: Quick estimation based on available information:
- Files affected: How many files will likely change
- Task count: How many distinct implementation steps
- Risk level: How likely is this to break existing functionality
- Dependencies: Does this require coordination across modules
Classify and recommend:
Complexity Files Tasks Risk Recommendation Small 1-5 1-8 Low /speckit.tinyspecMedium 5-15 8-20 Medium Full SDD ( /speckit.specify)Large 15+ 20+ High Full SDD with clarify ( /speckit.clarify→/speckit.specify)Output recommendation:
# Task Classification | Factor | Assessment | |--------|-----------| | **Task** | {task description} | | **Complexity** | 🟢 Small / 🟡 Medium / 🔴 Large | | **Estimated files** | ~{N} files | | **Estimated tasks** | ~{N} tasks | | **Risk** | Low / Medium / High | ## Recommendation → Use **`/speckit.tinyspec`** — this is a small, well-scoped change. OR → Use **`/speckit.specify`** — this task has enough complexity to benefit from the full SDD workflow.
Rules
- Read-only — this command never modifies any files
- Default to tinyspec — when in doubt between small and medium, recommend tinyspec (users can always upgrade)
- Explain the reasoning — always tell the user why you classified the task as small/medium/large
- No blocking — this is a recommendation, not a gate. Users can choose either workflow regardless
- Context-aware — consider the project's codebase size and architecture when estimating scope
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.

