agentleFS
lifekit-hqlifekit-hq/devclaw/.claude/skills/speckit-tinyspec-classify/SKILL.md

speckit-tinyspec-classify

Skill1 starsChanged 24 days agoMITView on GitHub

Classify task complexity and recommend tinyspec or full SDD workflow

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
  1. Very specific:

    Verify a spec-kit project exists by checking for .specify/ directory

    line 24
  2. Distinctive:

    Verify the user has described the task (if not, ask what they want to build)

    line 25

≈ “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

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

$ARGUMENTS

You MUST consider the user input before proceeding (if not empty). The user describes what they want to build or fix.

Prerequisites

  1. Verify a spec-kit project exists by checking for .specify/ directory
  2. Verify the user has described the task (if not, ask what they want to build)

Outline

  1. Analyze the task: Evaluate the task description against complexity signals:

    Small task signals (→ tinyspec):

    SignalExample
    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):

    SignalExample
    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)
  2. 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
  3. Classify and recommend:

    ComplexityFilesTasksRiskRecommendation
    Small1-51-8Low/speckit.tinyspec
    Medium5-158-20MediumFull SDD (/speckit.specify)
    Large15+20+HighFull SDD with clarify (/speckit.clarify → /speckit.specify)
  4. 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

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.