mirror of
https://github.com/github/spec-kit.git
synced 2026-03-19 20:03:07 +00:00
* feat(commands): wire before/after hook events into specify and plan templates Replicates the hook evaluation pattern from tasks.md and implement.md (introduced in PR #1702) into the specify and plan command templates. This completes the hook lifecycle across all SDD phases. Changes: - specify.md: Add before_specify/after_specify hook blocks - plan.md: Add before_plan/after_plan hook blocks - EXTENSION-API-REFERENCE.md: Document new hook events - EXTENSION-USER-GUIDE.md: List all available hook events Fixes #1788 Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * Mark before_commit/after_commit as planned in extension docs These hook events are defined in the API reference but not yet wired into any core command template. Marking them as planned rather than removing them, since the infrastructure supports them. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * Fix hook enablement to default true when field is absent Matches HookExecutor.get_hooks_for_event() semantics where hooks without an explicit enabled field are treated as enabled. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * fix(docs): mark commit hooks as planned in user guide config example The yaml config comment listed before_commit/after_commit as "Available events" but they are not yet wired into core templates. Moved them to a separate "Planned" line, consistent with the API reference. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * fix(commands): align enabled-filtering semantics across all hook templates tasks.md and implement.md previously said "Filter to only hooks where enabled: true", which would skip hooks that omit the enabled field. Updated to match specify.md/plan.md and HookExecutor's h.get('enabled', True) behavior: filter out only hooks where enabled is explicitly false. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Matt Van Horn <455140+mvanhorn@users.noreply.github.com> Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
160 lines
6.2 KiB
Markdown
160 lines
6.2 KiB
Markdown
---
|
|
description: Execute the implementation planning workflow using the plan template to generate design artifacts.
|
|
handoffs:
|
|
- label: Create Tasks
|
|
agent: speckit.tasks
|
|
prompt: Break the plan into tasks
|
|
send: true
|
|
- label: Create Checklist
|
|
agent: speckit.checklist
|
|
prompt: Create a checklist for the following domain...
|
|
scripts:
|
|
sh: scripts/bash/setup-plan.sh --json
|
|
ps: scripts/powershell/setup-plan.ps1 -Json
|
|
agent_scripts:
|
|
sh: scripts/bash/update-agent-context.sh __AGENT__
|
|
ps: scripts/powershell/update-agent-context.ps1 -AgentType __AGENT__
|
|
---
|
|
|
|
## User Input
|
|
|
|
```text
|
|
$ARGUMENTS
|
|
```
|
|
|
|
You **MUST** consider the user input before proceeding (if not empty).
|
|
|
|
## Pre-Execution Checks
|
|
|
|
**Check for extension hooks (before planning)**:
|
|
- Check if `.specify/extensions.yml` exists in the project root.
|
|
- If it exists, read it and look for entries under the `hooks.before_plan` 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
|
|
- 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. **Setup**: Run `{SCRIPT}` from repo root and parse JSON for FEATURE_SPEC, IMPL_PLAN, SPECS_DIR, BRANCH. 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. **Load context**: Read FEATURE_SPEC and `/memory/constitution.md`. Load IMPL_PLAN template (already copied).
|
|
|
|
3. **Execute plan workflow**: Follow the structure in IMPL_PLAN template to:
|
|
- Fill Technical Context (mark unknowns as "NEEDS CLARIFICATION")
|
|
- Fill Constitution Check section from constitution
|
|
- Evaluate gates (ERROR if violations unjustified)
|
|
- Phase 0: Generate research.md (resolve all NEEDS CLARIFICATION)
|
|
- Phase 1: Generate data-model.md, contracts/, quickstart.md
|
|
- Phase 1: Update agent context by running the agent script
|
|
- Re-evaluate Constitution Check post-design
|
|
|
|
4. **Stop and report**: Command ends after Phase 2 planning. Report branch, IMPL_PLAN path, and generated artifacts.
|
|
|
|
5. **Check for extension hooks**: After reporting, check if `.specify/extensions.yml` exists in the project root.
|
|
- If it exists, read it and look for entries under the `hooks.after_plan` 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
|
|
- 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
|
|
|
|
## Phases
|
|
|
|
### Phase 0: Outline & Research
|
|
|
|
1. **Extract unknowns from Technical Context** above:
|
|
- For each NEEDS CLARIFICATION → research task
|
|
- For each dependency → best practices task
|
|
- For each integration → patterns task
|
|
|
|
2. **Generate and dispatch research agents**:
|
|
|
|
```text
|
|
For each unknown in Technical Context:
|
|
Task: "Research {unknown} for {feature context}"
|
|
For each technology choice:
|
|
Task: "Find best practices for {tech} in {domain}"
|
|
```
|
|
|
|
3. **Consolidate findings** in `research.md` using format:
|
|
- Decision: [what was chosen]
|
|
- Rationale: [why chosen]
|
|
- Alternatives considered: [what else evaluated]
|
|
|
|
**Output**: research.md with all NEEDS CLARIFICATION resolved
|
|
|
|
### Phase 1: Design & Contracts
|
|
|
|
**Prerequisites:** `research.md` complete
|
|
|
|
1. **Extract entities from feature spec** → `data-model.md`:
|
|
- Entity name, fields, relationships
|
|
- Validation rules from requirements
|
|
- State transitions if applicable
|
|
|
|
2. **Define interface contracts** (if project has external interfaces) → `/contracts/`:
|
|
- Identify what interfaces the project exposes to users or other systems
|
|
- Document the contract format appropriate for the project type
|
|
- Examples: public APIs for libraries, command schemas for CLI tools, endpoints for web services, grammars for parsers, UI contracts for applications
|
|
- Skip if project is purely internal (build scripts, one-off tools, etc.)
|
|
|
|
3. **Agent context update**:
|
|
- Run `{AGENT_SCRIPT}`
|
|
- These scripts detect which AI agent is in use
|
|
- Update the appropriate agent-specific context file
|
|
- Add only new technology from current plan
|
|
- Preserve manual additions between markers
|
|
|
|
**Output**: data-model.md, /contracts/*, quickstart.md, agent-specific file
|
|
|
|
## Key rules
|
|
|
|
- Use absolute paths
|
|
- ERROR on gate failures or unresolved clarifications
|