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

speckit-tinyspec-implement

Skill1 starsChanged 24 days agoMITView on GitHub

Implement a small change directly from its tinyspec file

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

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

    line 24
  2. Distinctive:

    Verify git is available and the project is a git repository

    line 25
  3. Very specific:

    If user specifies a name, look for specs/tiny/{name}.md

    line 27
  4. Very specific:

    If no input, look for the most recently created tinyspec in specs/tiny/

    line 28
  5. Very specific:

    If no tinyspec files exist, suggest running /speckit.tinyspec first

    line 29
  6. Distinctive:

    Test patterns and conventions

    line 43
  7. Distinctive:

    Follow existing code patterns and conventions from context files

    line 48
  8. Distinctive:

    Run verification: After all tasks are complete:

    line 51
  9. Distinctive:

    Check that all "Done When" criteria are met

    line 52
  10. Distinctive:

    Verify tests pass (if test tasks were included)

    line 53
  11. Distinctive:

    Verify no lint errors (if linting is configured)

    line 54
  12. Very specific:

    All task checkboxes should be [x]

    line 58

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

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

$ARGUMENTS

You 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

  1. Verify a spec-kit project exists by checking for .specify/ directory
  2. Verify git is available and the project is a git repository
  3. 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.tinyspec first

Outline

  1. 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
  2. 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
  3. 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
  4. 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)
  5. Update tinyspec: Mark the tinyspec as complete:
    • Change **Status**: draft to **Status**: done
    • All task checkboxes should be [x]
    • All "Done When" checkboxes should be [x]
  6. 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

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.