agentleFS
cnoe-iocnoe-io/ai-platform-engineering/.claude/skills/speckit.implement/SKILL.md

speckit.implement

Skill438 starsChanged 53 days agoApache-2.0View on GitHub

You MUST consider the user input before proceeding (if not empty). Check for extension hooks (before implementation): - Check if .specify/extensions.yml exists in the project root. - If it exists, read it and look for entries under the hooks.before_implement key - If the YAML cannot be parsed or is invalid, skip hook checking silently and continue normally - Filter to only hooks where enabled: true - For each remaining hook, do not attempt to interpret or evaluate hook condition expressions:…

  • Reads credentials

3 other projects use a version of this, 1 of them edited.

Adopted by

Most recently taken up by

The file

Show its rules and text

We split this skill into the rules it gives an agent

35 rules. About 0 are common, 26 are distinctive, and 9 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈26

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 9

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Check if .specify/extensions.yml exists in the project root.

    line 24
  2. Very specific:

    If it exists, read it and look for entries under the hooks.before_implement key

    line 25
  3. Distinctive:

    If the YAML cannot be parsed or is invalid, skip hook checking silently and continue normally

    line 26
  4. Very specific:

    If the hook has no condition field, or it is null/empty, treat the hook as executable

    line 29
  5. Very specific:

    If the hook defines a non-empty condition, skip the hook and leave condition evaluation to the HookExecutor implementation

    line 30
  6. Very specific:

    If no hooks are registered or .specify/extensions.yml does not exist, skip silently

    line 53
  7. Very specific:

    Run {SCRIPT} from repo root and parse FEATURE_DIR and AVAILABLE_DOCS list.

    line 57
  8. Distinctive:

    Create a status table:

    line 65
  9. Distinctive:

    PASS: All checklists have 0 incomplete items

    line 76
  10. Distinctive:

    Wait for user response before continuing

    line 82
  11. Distinctive:

    If user says "no" or "wait" or "stop", halt execution

    line 83
  12. Distinctive:

    If user says "yes" or "proceed" or "continue", proceed to step 3

    line 84
  13. Distinctive:

    REQUIRED: Read tasks.md for the complete task list and execution plan

    line 91
  14. Distinctive:

    REQUIRED: Read plan.md for tech stack, architecture, and file structure

    line 92
  15. Distinctive:

    IF EXISTS: Read data-model.md for entities and relationships

    line 93
  16. Distinctive:

    IF EXISTS: Read contracts/ for API specifications and test requirements

    line 94
  17. Distinctive:

    IF EXISTS: Read research.md for technical decisions and constraints

    line 95
  18. Distinctive:

    IF EXISTS: Read quickstart.md for integration scenarios

    line 96
  19. Distinctive:

    REQUIRED: Create/verify ignore files based on actual project setup:

    line 99
  20. Distinctive:

    Check if the following command succeeds to determine if the repository is a git repo (create/verify .gitignore if so):

    line 102
  21. Distinctive:

    Check if Dockerfile* exists or Docker in plan.md → create/verify .dockerignore

    line 108
  22. Distinctive:

    Check if .eslintrc* exists → create/verify .eslintignore

    line 109
  23. Very specific:

    Check if eslint.config.* exists → ensure the config's ignores entries cover required patterns

    line 110
  24. Distinctive:

    Check if .prettierrc* exists → create/verify .prettierignore

    line 111
  25. Very specific:

    Check if .npmrc or package.json exists → create/verify .npmignore (if publishing)

    line 112
  26. Distinctive:

    Check if terraform files (*.tf) exist → create/verify .terraformignore

    line 113
  27. Distinctive:

    Check if .helmignore needed (helm charts present) → create/verify .helmignore

    line 114
  28. Distinctive:

    If ignore file already exists: Verify it contains essential patterns, append missing critical patterns only

    line 116
  29. Distinctive:

    If ignore file missing: Create with full pattern set for detected technology

    line 117
  30. Distinctive:

    Respect dependencies: Run sequential tasks in order, parallel tasks [P] can run together

    line 150
  31. Distinctive:

    Validation checkpoints: Verify each phase completion before proceeding

    line 153
  32. Distinctive:

    Tests before code: If you need to write tests for contracts, entities, and integration scenarios

    line 157
  33. Distinctive:

    Verify all required tasks are completed

    line 171
  34. Distinctive:

    Check that implemented features match the original specification

    line 172
  35. Very specific:

    Check for extension hooks: After completion validation, check if .specify/extensions.yml exists in the project root.

    line 179

≈ “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
<!-- Execute tasks to produce source code and tests --><!-- AUTO-GENERATED — DO NOT EDIT --><!-- Source: .specify/templates/commands/implement.md --><!-- Regenerate: make generate-agent-files -->

description: Execute tasks to produce source code and tests scripts: sh: scripts/bash/check-prerequisites.sh --json --require-tasks --include-tasks ps: scripts/powershell/check-prerequisites.ps1 -Json -RequireTasks -IncludeTasks

User Input

$ARGUMENTS

You MUST consider the user input before proceeding (if not empty).

Pre-Execution Checks

Check for extension hooks (before implementation):

  • Check if .specify/extensions.yml exists in the project root.
  • If it exists, read it and look for entries under the hooks.before_implement key
  • If the YAML cannot be parsed or is invalid, skip hook checking silently and continue normally
  • Filter to only hooks where enabled: true
  • For each remaining hook, do not attempt to interpret or evaluate hook condition expressions:
    • If the hook has no condition field, or it is null/empty, treat the hook as executable
    • If the hook defines a non-empty condition, skip the hook and leave condition evaluation to the HookExecutor implementation
  • For each executable hook, output the following based on its optional flag:
    • Optional hook (optional: true):
      ## Extension Hooks
      
      **Optional Pre-Hook**: {extension}
      Command: `/{command}`
      Description: {description}
      
      Prompt: {prompt}
      To execute: `/{command}`
    • Mandatory hook (optional: false):
      ## Extension Hooks
      
      **Automatic Pre-Hook**: {extension}
      Executing: `/{command}`
      EXECUTE_COMMAND: {command}
      
      Wait for the result of the hook command before proceeding to the Outline.
  • If no hooks are registered or .specify/extensions.yml does not exist, skip silently

Outline

  1. Run {SCRIPT} from repo root and parse FEATURE_DIR and AVAILABLE_DOCS list. All paths must be absolute. For single quotes in args like "I'm Groot", use escape syntax: e.g 'I'''m Groot' (or double-quote if possible: "I'm Groot").
  2. Check checklists status (if FEATURE_DIR/checklists/ exists):
    • Scan all checklist files in the checklists/ directory
    • For each checklist, count:
      • Total items: All lines matching - [ ] or - [X] or - [x]
      • Completed items: Lines matching - [X] or - [x]
      • Incomplete items: Lines matching - [ ]
    • Create a status table:

      | Checklist | Total | Completed | Incomplete | Status |
      |-----------|-------|-----------|------------|--------|
      | ux.md     | 12    | 12        | 0          | ✓ PASS |
      | test.md   | 8     | 5         | 3          | ✗ FAIL |
      | security.md | 6   | 6         | 0          | ✓ PASS |
    • Calculate overall status:
      • PASS: All checklists have 0 incomplete items
      • FAIL: One or more checklists have incomplete items
    • If any checklist is incomplete:
      • Display the table with incomplete item counts
      • STOP and ask: "Some checklists are incomplete. Do you want to proceed with implementation anyway? (yes/no)"
      • Wait for user response before continuing
      • If user says "no" or "wait" or "stop", halt execution
      • If user says "yes" or "proceed" or "continue", proceed to step 3
    • If all checklists are complete:
      • Display the table showing all checklists passed
      • Automatically proceed to step 3
  3. Load and analyze the implementation context:
    • REQUIRED: Read tasks.md for the complete task list and execution plan
    • REQUIRED: Read plan.md for tech stack, architecture, and file structure
    • IF EXISTS: Read data-model.md for entities and relationships
    • IF EXISTS: Read contracts/ for API specifications and test requirements
    • IF EXISTS: Read research.md for technical decisions and constraints
    • IF EXISTS: Read quickstart.md for integration scenarios
  4. Project Setup Verification:

    • REQUIRED: Create/verify ignore files based on actual project setup:

    Detection & Creation Logic:

    • Check if the following command succeeds to determine if the repository is a git repo (create/verify .gitignore if so):

      git rev-parse --git-dir 2>/dev/null
    • Check if Dockerfile* exists or Docker in plan.md → create/verify .dockerignore
    • Check if .eslintrc* exists → create/verify .eslintignore
    • Check if eslint.config.* exists → ensure the config's ignores entries cover required patterns
    • Check if .prettierrc* exists → create/verify .prettierignore
    • Check if .npmrc or package.json exists → create/verify .npmignore (if publishing)
    • Check if terraform files (*.tf) exist → create/verify .terraformignore
    • Check if .helmignore needed (helm charts present) → create/verify .helmignore

    If ignore file already exists: Verify it contains essential patterns, append missing critical patterns only If ignore file missing: Create with full pattern set for detected technology

    Common Patterns by Technology (from plan.md tech stack):

    • Node.js/JavaScript/TypeScript: node_modules/, dist/, build/, *.log, .env*
    • Python: __pycache__/, *.pyc, .venv/, venv/, dist/, *.egg-info/
    • Java: target/, *.class, *.jar, .gradle/, build/
    • C#/.NET: bin/, obj/, *.user, *.suo, packages/
    • Go: *.exe, *.test, vendor/, *.out
    • Ruby: .bundle/, log/, tmp/, *.gem, vendor/bundle/
    • PHP: vendor/, *.log, *.cache, *.env
    • Rust: target/, debug/, release/, *.rs.bk, *.rlib, *.prof*, .idea/, *.log, .env*
    • Kotlin: build/, out/, .gradle/, .idea/, *.class, *.jar, *.iml, *.log, .env*
    • C++: build/, bin/, obj/, out/, *.o, *.so, *.a, *.exe, *.dll, .idea/, *.log, .env*
    • C: build/, bin/, obj/, out/, *.o, *.a, *.so, *.exe, *.dll, autom4te.cache/, config.status, config.log, .idea/, *.log, .env*
    • Swift: .build/, DerivedData/, *.swiftpm/, Packages/
    • R: .Rproj.user/, .Rhistory, .RData, .Ruserdata, *.Rproj, packrat/, renv/
    • Universal: .DS_Store, Thumbs.db, *.tmp, *.swp, .vscode/, .idea/

    Tool-Specific Patterns:

    • Docker: node_modules/, .git/, Dockerfile*, .dockerignore, *.log*, .env*, coverage/
    • ESLint: node_modules/, dist/, build/, coverage/, *.min.js
    • Prettier: node_modules/, dist/, build/, coverage/, package-lock.json, yarn.lock, pnpm-lock.yaml
    • Terraform: .terraform/, *.tfstate*, *.tfvars, .terraform.lock.hcl
    • Kubernetes/k8s: *.secret.yaml, secrets/, .kube/, kubeconfig*, *.key, *.crt
  5. Parse tasks.md structure and extract:
    • Task phases: Setup, Tests, Core, Integration, Polish
    • Task dependencies: Sequential vs parallel execution rules
    • Task details: ID, description, file paths, parallel markers [P]
    • Execution flow: Order and dependency requirements
  6. Execute implementation following the task plan:
    • Phase-by-phase execution: Complete each phase before moving to the next
    • Respect dependencies: Run sequential tasks in order, parallel tasks [P] can run together
    • Follow TDD approach: Execute test tasks before their corresponding implementation tasks
    • File-based coordination: Tasks affecting the same files must run sequentially
    • Validation checkpoints: Verify each phase completion before proceeding
  7. Implementation execution rules:
    • Setup first: Initialize project structure, dependencies, configuration
    • Tests before code: If you need to write tests for contracts, entities, and integration scenarios
    • Core development: Implement models, services, CLI commands, endpoints
    • Integration work: Database connections, middleware, logging, external services
    • Polish and validation: Unit tests, performance optimization, documentation
  8. Progress tracking and error handling:
    • Report progress after each completed task
    • Halt execution if any non-parallel task fails
    • For parallel tasks [P], continue with successful tasks, report failed ones
    • Provide clear error messages with context for debugging
    • Suggest next steps if implementation cannot proceed
    • IMPORTANT For completed tasks, make sure to mark the task off as [X] in the tasks file.
  9. Completion validation:
    • Verify all required tasks are completed
    • Check that implemented features match the original specification
    • Validate that tests pass and coverage meets requirements
    • Confirm the implementation follows the technical plan
    • Report final status with summary of completed work

Note: This command assumes a complete task breakdown exists in tasks.md. If tasks are incomplete or missing, suggest running /speckit.tasks first to regenerate the task list.

  1. Check for extension hooks: After completion validation, check if .specify/extensions.yml exists in the project root.
    • If it exists, read it and look for entries under the hooks.after_implement key
    • If the YAML cannot be parsed or is invalid, skip hook checking silently and continue normally
    • Filter to only hooks where enabled: true
    • For each remaining hook, do not attempt to interpret or evaluate hook condition expressions:
      • If the hook has no condition field, or it is null/empty, treat the hook as executable
      • If the hook defines a non-empty condition, skip the hook and leave condition evaluation to the HookExecutor implementation
    • For each executable hook, output the following based on its optional flag:
      • Optional hook (optional: true):
        ## Extension Hooks
        
        **Optional Hook**: {extension}
        Command: `/{command}`
        Description: {description}
        
        Prompt: {prompt}
        To execute: `/{command}`
      • Mandatory hook (optional: false):
        ## Extension Hooks
        
        **Automatic Hook**: {extension}
        Executing: `/{command}`
        EXECUTE_COMMAND: {command}
    • If no hooks are registered or .specify/extensions.yml does not exist, skip silently

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.