spec-kitty.accept

Prompt file imported from wildcard/caro (.codex/prompts/spec-kitty.accept.md). Fill in {{arguments}} before use. Copyright stays with the author.

Path reference rule: When you mention directories or files, provide either the absolute path or a path relative to the project root (for example, kitty-specs/<feature>/tasks/). Never refer to a folder by name alone.

Path: .kittify/templates/commands/accept.md

User Input

{{arguments}}

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

Discovery (mandatory)

Before running the acceptance workflow, gather the following:

1. Feature slug (e.g., 005-awesome-thing). If omitted, detect automatically.
2. Acceptance mode:
   • pr when the feature will merge via hosted pull request.
   • local when the feature will merge locally without a PR.
   • checklist to run the readiness checklist without committing or producing merge instructions.
3. Validation commands executed (tests/builds). Collect each command verbatim; omit if none.
4. Acceptance actor (optional, defaults to the current agent name).

Ask one focused question per item and confirm the summary before continuing. End the discovery turn with WAITING_FOR_ACCEPTANCE_INPUT until all answers are provided.

Execution Plan

1. Compile the acceptance options into an argument list:
   • Always include --actor "codex".
   • Append --feature "<slug>" when the user supplied a slug.
   • Append --mode <mode> (pr, local, or checklist).
   • Append --test "<command>" for each validation command provided.
2. Run .kittify/scripts/bash/accept-feature.sh --json {{arguments}} (the CLI wrapper) with the assembled arguments and --json.
3. Parse the JSON response. It contains:
   • summary.ok (boolean) and other readiness details.
   • summary.outstanding categories when issues remain.
   • instructions (merge steps) and cleanup_instructions.
   • notes (e.g., acceptance commit hash).
4. Present the outcome:
   • If summary.ok is false, list each outstanding category with bullet points and advise the user to resolve them before retrying acceptance.
   • If summary.ok is true, display:
     • Acceptance timestamp, actor, and (if present) acceptance commit hash.
     • Merge instructions and cleanup instructions as ordered steps.
     • Validation commands executed (if any).
5. When the mode is checklist, make it clear no commits or merge instructions were produced.

Output Requirements

• Summaries must be in plain text (no tables). Use short bullet lists for instructions.
• Surface outstanding issues before any congratulations or success messages.
• If the JSON payload includes warnings, surface them under an explicit Warnings section.
• Never fabricate results; only report what the JSON contains.

Error Handling

• If the command fails or returns invalid JSON, report the failure and request user guidance (do not retry automatically).
• When outstanding issues exist, do not attempt to force acceptance—return the checklist and prompt the user to fix the blockers.