kiss-implement

name	kiss-implement
description	Executes the implementation plan by processing and executing all tasks defined in tasks.md. Use when coding a feature from an existing tasks.md, executing implementation tasks one by one, or when the plan and design are ready and it is time to build.
argument-hint	Optional implementation guidance or task filter
compatibility	Requires kiss project structure with .kiss/ directory
metadata	{"author":"github-kiss","source":"agent-skills/kiss-implement/kiss-implement.md"}
user-invocable	true
disable-model-invocation	false

User Input

$ARGUMENTS

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

Audience and tone (interactive mode)

When KISS_AGENT_MODE=interactive (the default), assume the user has limited technical background and limited domain knowledge — they may know basics but lack deep expertise in software implementation. Run this skill as a guided questionnaire and always show the diff before applying any source edit:

• One task at a time. Walk tasks.md task-by-task; never apply multiple tasks before the user confirms.
• Yes / no first. "Apply this change? (yes / no / explain this line)" is the canonical question for each diff.
• Translate jargon, don't strip it. Use the term but always pair it with a plain-English gloss the first time it appears.
• Choices, not blank fields. When yes/no isn't enough, offer 2-4 lettered options (A/B/C/D) with one-line plain-language descriptions of the trade-off. Always include "Not sure — pick a sensible default".
• Always recommend. State the option you would pick and why in one sentence so the user can reply "yes" / "ok" to accept.
• Show, don't ask. Propose the smallest viable diff per task and ask "yes / change?". Never apply blind.
• not sure / skip on a task pauses the task rather than applying a guess; mark it as (skipped — needs follow-up) in tasks.md and continue with the next.

When KISS_AGENT_MODE=auto (or --auto), skip the conversational gate but still: produce diffs, run tests after each change, halt on the first failing test, and log decisions to the parent agent's decision log.

Pre-Execution Checks

Check for extension hooks (before implementation):

• Check if .kiss/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 out hooks where enabled is explicitly false. Treat hooks without an enabled field as enabled by default.

• 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

• When constructing slash commands from hook command names, replace dots (.) with hyphens (-). For example, kiss.git.commit → /kiss-git-commit.

• 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 .kiss/extensions.yml does not exist, skip silently

Outline

1. Run scripts/bash/check-prerequisites.sh --json --require-tasks --include-tasks 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

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

1. Check for extension hooks: After completion validation, check if .kiss/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 out hooks where enabled is explicitly false. Treat hooks without an enabled field as enabled by default.

   • 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

   • When constructing slash commands from hook command names, replace dots (.) with hyphens (-). For example, kiss.git.commit → /kiss-git-commit.

   • 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 .kiss/extensions.yml does not exist, skip silently

Inputs

• Tasks List ({context.current.tasks}): current.tasks.

  • If set: Read the tasks file.
  • If null: Search {context.paths.tasks} for the most recent tasks.md.
  • If not provided: Error: tasks file is required. Run /kiss-taskify first.

• Implementation Plan ({context.current.plan}): current.plan.

  • If set: Reference the plan for technical context.
  • If null: Search {context.paths.plans} for the most recent plan.md.
  • If not provided: Proceed with implementation; plan is recommended but not required.

Outputs

• Implementation Artifacts (project root): project root.
  • Behavior: Create/modify source files per task definitions. Ask before overwriting files if confirm_before_write is true.
  • Overwrite guarded by {context.preferences.confirm_before_write}.

Context Update

After this skill completes successfully, update .kiss/context.yml:

• Do not modify context.yml (implementation is artifact creation, not context progression)
• Leave all current.* fields unchanged