create-agentic-app 1.1.53 → 1.1.55

package/template/.agents/skills/implement-feature/references/coder-prompt-template.md

@@ -0,0 +1,46 @@
+# Coder Agent Prompt Template
+
+Use this template when constructing prompts for coder subagents. Replace the placeholders (`{requirements}`, `{completed_tasks_summary}`, `{task_content}`) with actual content from the spec files.
+
+## Template
+
+```
+You are implementing a single task from a feature specification. Your job is to write the code described below — nothing more, nothing less.
+
+## Feature Context
+
+{requirements}
+
+## What's Already Been Built
+
+{completed_tasks_summary}
+
+## Your Task
+
+{task_content}
+
+## Instructions
+
+1. Read the relevant parts of the codebase to understand existing patterns, imports, and conventions
+2. Implement everything described in the task's Technical Details and Implementation Steps
+3. Follow the project's existing code patterns and conventions
+4. Run the project's lint and typecheck commands after making changes. Fix any errors before finishing.
+5. Do NOT commit your changes — the orchestrator handles commits after review
+6. When done, report:
+   - Files created (with paths)
+   - Files modified (with paths)
+   - A one-paragraph summary of what you implemented
+```
+
+## Placeholder Details
+
+- **{requirements}**: paste the full text of `requirements.md`. This gives the agent overall feature context — the "what" and "why" — so it can make good judgment calls during implementation.
+
+- **{completed_tasks_summary}**: for each previously completed task, include a brief summary like:
+  ```
+  - task-01-setup-database: Created PostgreSQL schema with users and sessions tables. Files: src/db/schema.ts, src/db/migrations/001_initial.sql
+  - task-02-auth-config: Set up Better Auth with email/password provider. Files: src/lib/auth.ts, src/lib/auth-client.ts
+  ```
+  Keep each entry to 1-2 lines. The purpose is to give the agent awareness of what exists, not full implementation details.
+
+- **{task_content}**: paste the full text of the task file (task-{nn}-{name}.md). This is the agent's primary instruction set — it contains the description, technical details, files to create/modify, and acceptance criteria.

package/template/.agents/skills/implement-feature/references/fix-prompt-template.md

@@ -0,0 +1,38 @@
+# Fix Agent Prompt Template
+
+Use this template when constructing prompts for coder agents that fix issues found during code review. Replace the placeholders with actual content.
+
+## Template
+
+```
+You are fixing specific issues found during code review. Address every issue listed below — do not skip any.
+
+## Issues to Fix
+
+{issues}
+
+## Original Task Context
+
+{task_content}
+
+## Instructions
+
+1. Fix each issue listed above. The review provided file paths, line numbers, and suggested fixes — use those as your starting point.
+2. Run the project's lint and typecheck commands after making fixes. Resolve any new errors your fixes introduce.
+3. Do NOT commit your changes — the orchestrator handles commits.
+4. Do NOT make changes beyond what's needed to fix the listed issues. Stay within scope.
+5. When done, report:
+   - What you fixed (reference each issue)
+   - Any files modified
+   - If you could NOT fix an issue, explain why
+```
+
+## Placeholder Details
+
+- **{issues}**: the specific issues from the review that relate to this task. Include file paths, line numbers, descriptions, severity, and suggested fixes. Example:
+  ```
+  - Issue 1: src/api/users.ts:42 — Missing error handling for database connection failure — Severity: high — Suggested fix: wrap the query in try/catch and return a 500 response
+  - Issue 2: src/api/users.ts:15 — Unused import 'Session' — Severity: low — Suggested fix: remove the import
+  ```
+
+- **{task_content}**: the full text of the original task file for context. The fix agent may need to reference the task's technical details or acceptance criteria to understand the intended behavior.

package/template/.agents/skills/implement-feature/references/review-prompt-template.md

@@ -0,0 +1,50 @@
+# Review Agent Prompt Template
+
+Use this template when constructing prompts for the code review agent that runs between waves. Replace the placeholders with actual content.
+
+## Template
+
+```
+You are reviewing the combined output of Wave {wave_number} of a feature implementation. Multiple coder agents worked in parallel on separate tasks — your job is to verify everything integrates correctly and meets quality standards.
+
+## Feature Context
+
+{requirements}
+
+## Tasks Completed in This Wave
+
+{task_summaries}
+
+## Review Checklist
+
+1. **Verification**: Run `{verification_commands}` and report results. Fix nothing — just report.
+2. **Acceptance Criteria**: For each task listed above, check whether the implementation meets the acceptance criteria from its task file.
+3. **Integration**: Verify that files created by different tasks work together:
+   - Imports resolve correctly
+   - Types match across module boundaries
+   - No duplicate or conflicting definitions
+   - Shared state (env vars, config) is consistent
+4. **Code Quality**: Check for security issues, performance problems, and adherence to project conventions.
+5. **Scope**: Verify each task stayed within its defined scope (Files to Create/Modify). Flag any unexpected file changes.
+
+## Verdict
+
+Respond with one of:
+
+**VERDICT: PASS**
+All checks passed. Include any minor observations as notes.
+
+**VERDICT: FAIL**
+Include a structured list of issues:
+- **Issue 1**: {file:line} — {description} — Severity: {high/medium/low} — Suggested fix: {fix}
+- **Issue 2**: ...
+
+Group issues by the task they most closely relate to (based on which task's files are affected). This helps the orchestrator dispatch targeted fix agents.
+```
+
+## Placeholder Details
+
+- **{wave_number}**: the current wave number (e.g., "2")
+- **{requirements}**: full text of `requirements.md`
+- **{task_summaries}**: for each task in the wave, include the task title and the coder agent's completion summary (files created/modified + what was implemented)
+- **{verification_commands}**: the project's lint and typecheck commands. Check for `package.json` scripts — typically `pnpm lint && pnpm typecheck` or similar.

package/template/.agents/skills/review-pr/SKILL.md

@@ -0,0 +1,97 @@
+---
+name: review-pr
+description: >
+  Review pull requests with complexity-adaptive depth — spawning deep-dive agents for medium
+  and complex PRs. Use this skill when the user says "review this PR", "review PR #123",
+  "check this pull request", "give me a code review", or wants feedback on a PR before merging.
+  Also use when the user says "/review-pr" or pastes a GitHub PR URL. Requires the GitHub CLI (gh).
+---
+
+# Review Pull Request
+
+Review pull requests with a depth that matches their complexity. Simple PRs get a direct review; complex PRs get parallel deep-dive agents analyzing security, performance, and architecture.
+
+## Arguments
+
+The user should provide PR number(s) or URL(s). If none provided, ask for them.
+
+## Instructions
+
+### Step 1: Retrieve PR Details
+
+Use the GitHub CLI to get the full picture:
+
+```bash
+gh pr view {pr_number} --json title,body,files,additions,deletions,commits,author,reviews,comments
+gh pr diff {pr_number}
+```
+
+### Step 2: Assess Complexity
+
+Score the PR based on:
+- Number of files changed
+- Lines added/removed
+- Number of commits
+- Whether changes touch core/architectural files
+
+**Simple** (direct review, no agents):
+- 5 or fewer files AND 100 or fewer lines AND single author
+
+**Medium** (1-2 deep-dive agents):
+- 6-15 files, OR 100-500 lines, OR 2 contributors
+
+**Complex** (up to 3 deep-dive agents):
+- More than 15 files, OR more than 500 lines, OR more than 2 contributors, OR touches core architecture
+
+### Step 3: Analyze
+
+**For Simple PRs**: review directly — read the diff, check for issues, provide feedback.
+
+**For Medium/Complex PRs**: spawn deep-dive agents in parallel using the `Agent` tool with `subagent_type: "deep-dive"`. Each agent gets a focused area:
+
+- **Agent 1 — Code Quality**: conventions, patterns, maintainability, test coverage
+- **Agent 2 — Security**: input validation, auth checks, injection risks, data exposure
+- **Agent 3 — Architecture** (Complex only): design patterns, separation of concerns, performance implications, backwards compatibility
+
+Each agent receives the PR diff and description and returns a structured review.
+
+### Step 4: Vision Alignment
+
+Read the project's `README.md` and `CLAUDE.md` to understand the application's purpose. Assess whether the PR aligns with the project's intended direction. Flag significant deviations — not as a blocker, but as a consideration for the reviewer.
+
+### Step 5: Safety Assessment
+
+Provide an overall assessment:
+- **Safe to merge**: no significant issues found
+- **Merge with caution**: minor issues that should be noted but aren't blocking
+- **Needs changes**: issues that should be fixed before merging
+
+Include a risk level (low/medium/high) with justification.
+
+### Step 6: Report
+
+Structure the review as:
+
+```
+## PR Review: #{pr_number} — {title}
+
+### Complexity: {Simple|Medium|Complex}
+{Brief justification}
+
+### Summary
+{2-3 sentence overview of what the PR does}
+
+### Issues Found
+{Grouped by severity: high → medium → low}
+- **{severity}**: {file:line} — {description}
+
+### Improvements Suggested
+{Optional improvements ranked by importance and implementation complexity}
+
+### Vision Alignment
+{Does this PR align with the project's direction?}
+
+### Verdict: {Safe to merge | Merge with caution | Needs changes}
+Risk level: {low|medium|high}
+{Brief justification}
+```

package/template/.claude/skills/checkpoint/SKILL.md

@@ -0,0 +1,75 @@
+---
+name: checkpoint
+description: >
+  Create a comprehensive checkpoint commit with detailed analysis of all changes. Use this skill
+  when the user says "checkpoint", "commit everything", "save my progress", "create a commit",
+  or wants to stage and commit all current changes with a well-crafted message. Also use when
+  the user says "/checkpoint" or asks to snapshot current work. This skill stages all changes
+  and creates a descriptive commit — it does not push.
+---
+
+# Checkpoint Commit
+
+Create a comprehensive checkpoint commit that captures all current changes with a detailed, well-structured commit message.
+
+## Instructions
+
+### Step 1: Analyze Changes
+
+Run these commands to understand the full picture:
+
+1. `git status` — see all tracked and untracked files
+2. `git diff` — see detailed changes in tracked files
+3. `git diff --cached` — see already-staged changes
+4. `git log -5 --oneline` — understand this repo's commit message style
+
+### Step 2: Stage Everything
+
+Stage all changes — tracked modifications, deletions, and new untracked files:
+
+```bash
+git add -A
+```
+
+### Step 3: Craft the Commit Message
+
+Write a commit message following the project's existing conventions (observed from `git log`). Structure:
+
+- **First line**: clear, concise summary in imperative mood (50-72 chars)
+  - Use conventional commit prefixes where the project uses them: `feat:`, `fix:`, `refactor:`, `docs:`, `chore:`, etc.
+- **Body** (separated by blank line): detailed description including:
+  - What changes were made (key modifications)
+  - Why these changes were made (purpose/motivation)
+  - Important technical details or decisions
+  - Breaking changes or migration notes if applicable
+- **Footer**: co-author attribution
+
+### Step 4: Commit
+
+Create the commit using a heredoc for proper formatting:
+
+```bash
+git commit -m "$(cat <<'EOF'
+{first line}
+
+{body}
+
+Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
+EOF
+)"
+```
+
+### Step 5: Report
+
+Display:
+- The commit hash and message summary
+- Files changed count
+- Insertions/deletions summary
+
+## Important
+
+- Stage and commit everything — do not skip files unless they are clearly sensitive (`.env`, credentials)
+- If the repo has no git history, run `git init` first
+- Make the commit message descriptive enough that someone reading `git log` understands what was accomplished
+- Follow the project's existing commit conventions (check the log first)
+- Do not push — only commit locally

package/template/.claude/skills/create-spec/SKILL.md

@@ -0,0 +1,132 @@
+---
+name: create-spec
+description: >
+  Create a structured feature specification with self-contained task files organized into
+  parallel execution waves. Use this skill when the user says "create a spec", "plan this feature",
+  "write up an implementation plan", "break this into tasks", or after any planning conversation
+  where the user wants to capture decisions as actionable spec files. Also use when the user
+  says "/create-spec" or wants to decompose a feature into work items that agents can implement
+  independently. This skill produces local spec files under specs/{feature}/ — no GitHub integration.
+---
+
+# Create Feature Specification
+
+Transform a planning conversation into a structured spec folder that enables parallel agent implementation. The spec breaks a feature into self-contained task files — each one detailed enough that a coder agent can pick it up cold and implement it without reading anything else.
+
+The key insight: implementation plans that live in a single file are either too large for a context window or too shallow for independent execution. By splitting into one file per task with full context in each, we enable multiple agents to work in parallel while keeping each agent's context focused.
+
+## When to Use
+
+- After a planning conversation where requirements and technical details have been discussed
+- When the user asks to create a spec, plan a feature, or break work into tasks
+- When the user wants to prepare work for parallel agent implementation
+
+## Instructions
+
+### Step 1: Gather Requirements
+
+If the conversation already contains planning context (requirements discussed, technical decisions made, architecture outlined), extract all of it. Review the entire conversation to ensure nothing is lost — the spec is the single source of truth, and anything not captured here disappears.
+
+If no planning conversation exists, interview the user:
+- What does this feature do and why does it matter?
+- What are the acceptance criteria?
+- What technical constraints or decisions have been made?
+- What files, APIs, schemas, or patterns are involved?
+
+### Step 2: Name the Feature
+
+Choose a kebab-case name that clearly identifies the feature (e.g., `add-user-auth`, `migrate-to-postgres`, `dashboard-redesign`). This becomes the folder name under `specs/`.
+
+### Step 3: Decompose into Tasks
+
+Break the implementation into atomic tasks. Each task should:
+- Be completable in a single coding session by one agent
+- Have a clear, specific scope (one concern per task)
+- Produce working, testable code when complete
+- Not overlap in files modified with other tasks in the same wave
+
+Think carefully about granularity. Too coarse and agents can't work in parallel. Too fine and the overhead of context-switching between tasks dominates. A good task typically creates or modifies 1-5 files around a single concern.
+
+Do NOT include testing tasks (unit tests, e2e tests) unless the user explicitly asks for them.
+
+### Step 4: Build the Dependency Graph
+
+For each task, identify:
+- **What it depends on**: which tasks must complete before this one can start
+- **What depends on it**: which tasks are blocked until this one finishes
+
+Tasks with no dependencies form Wave 1. Tasks whose dependencies are all in Wave 1 form Wave 2. And so on. All tasks within a wave can execute in parallel.
+
+When assigning waves, verify that tasks within the same wave do not modify overlapping files. If two tasks in the same wave would touch the same file, move one to a later wave — parallel agents on the same branch cannot safely modify the same file.
+
+### Step 5: Create the Spec Folder
+
+Create the following structure at `specs/{feature-name}/`:
+
+```
+specs/{feature-name}/
+├── README.md
+├── requirements.md
+├── action-required.md
+└── tasks/
+    ���── task-01-{name}.md
+    ├── task-02-{name}.md
+    └── ...
+```
+
+Read the templates in `references/` before writing each file:
+- `references/readme-template.md` — for the README (dependency graph, wave table, status tracking)
+- `references/task-template.md` — for each task file (self-contained with all context)
+- `references/requirements-template.md` ��� for the requirements document
+- `references/action-required-template.md` — for manual human steps
+
+Task files are numbered with zero-padded two-digit prefixes in topological order: Wave 1 tasks first, then Wave 2, etc. Within a wave, order is arbitrary but stable.
+
+### Step 6: Write Self-Contained Task Files
+
+This is the most important step. Each task file is the **only thing** a coder agent will read before implementing. It must contain everything the agent needs:
+
+- **Description**: what to build and why it matters in context
+- **Dependency context**: what prior tasks produce that this task needs (summarized in prose, not just filenames). The agent should not need to read other task files.
+- **Technical details**: CLI commands, code snippets, schemas, file paths, env vars, API endpoints — every implementation-specific detail from the planning conversation
+- **Files to create/modify**: explicit list with purpose for each
+- **Acceptance criteria**: specific, verifiable conditions
+
+Review each task file with fresh eyes: could an agent who has never seen the planning conversation implement this correctly using only this file? If not, add what's missing.
+
+### Step 7: Extract Manual Actions
+
+Identify any steps that require human action (account creation, API key setup, DNS configuration, environment variables, third-party service registration, etc.). Write these to `action-required.md` grouped by timing (Before/During/After implementation). If none exist, note "No manual steps required."
+
+### Step 8: Report to User
+
+After creating the spec, display:
+
+```
+Feature specification created at specs/{feature-name}/
+
+Files created:
+- README.md (dependency graph, {N} waves, {T} tasks)
+- requirements.md
+- action-required.md
+- tasks/ ({T} task files)
+
+Wave breakdown:
+- Wave 1: {count} tasks (parallel) — {brief description}
+- Wave 2: {count} tasks (parallel) — {brief description}
+- ...
+
+Next steps:
+1. Review action-required.md for tasks you need to complete manually
+2. Review the requirements and task files
+3. Use /implement-feature to start parallel implementation
+```
+
+## Critical Rules
+
+- Every task file must be fully self-contained — this is the entire point of the spec structure. A coder agent reading only that file must know exactly what to do.
+- Capture ALL technical details from the planning conversation. The spec is the single source of truth — CLI commands, schemas, code snippets, file paths, env vars, API endpoints. Anything not captured here is lost.
+- Tasks within the same wave must not modify overlapping files. Parallel agents on the same branch cannot safely touch the same files.
+- Keep tasks atomic — one concern per task. If a task has more than 5-7 files to modify, consider splitting it.
+- Do not create testing tasks unless the user explicitly asks for them.
+- Number task files in topological order (wave 1 first, then wave 2, etc.) for easy scanning.

package/template/.claude/skills/create-spec/references/action-required-template.md

@@ -0,0 +1,53 @@
+# Action Required Template
+
+Use this structure for the action-required.md at the root of each spec folder. This file captures manual steps that require human action and cannot be automated by agents.
+
+## Template (when manual steps exist)
+
+```markdown
+# Action Required: {Feature Name}
+
+Manual steps that must be completed by a human. These cannot be automated.
+
+## Before Implementation
+
+- [ ] **{Action}** — {Brief reason why this is needed}
+- [ ] **{Action}** — {Brief reason}
+
+## During Implementation
+
+- [ ] **{Action}** — {Brief reason}
+
+## After Implementation
+
+- [ ] **{Action}** — {Brief reason}
+
+---
+
+> These tasks are also referenced in context within the relevant task files.
+```
+
+## Template (when no manual steps exist)
+
+```markdown
+# Action Required: {Feature Name}
+
+No manual steps required for this feature. All tasks can be implemented automatically.
+```
+
+## Common Manual Steps
+
+- Account creation (third-party services, OAuth apps)
+- API key generation and setup
+- Environment variable configuration
+- DNS or domain settings
+- Billing or subscription setup
+- Third-party service registration (webhooks, integrations)
+- Certificate provisioning
+- Access permissions or IAM roles
+
+## Key Points
+
+- Group actions by timing: before, during, and after implementation. This helps the user know when they need to act.
+- Keep descriptions brief — one line explaining what to do and why.
+- Also reference these manual steps in the relevant task files so agents know to pause or skip that part.

package/template/.claude/skills/create-spec/references/readme-template.md

@@ -0,0 +1,53 @@
+# README Template
+
+Use this structure for the README.md at the root of each spec folder. The README serves as the orchestration index — the `implement-feature` skill reads it to determine wave order, task assignments, and completion status.
+
+## Template
+
+```markdown
+# {Feature Name}
+
+## Overview
+
+{One paragraph summary of what the feature does and why it exists.}
+
+## Quick Links
+
+- [Requirements](./requirements.md) — full requirements and acceptance criteria
+- [Action Required](./action-required.md) — manual steps needing human action
+
+## Dependency Graph
+
+​```mermaid
+graph TD
+    task-01-name["01: Task Title"]
+    task-02-name["02: Task Title"]
+    task-03-name["03: Task Title"]
+    task-01-name --> task-03-name
+    task-02-name --> task-03-name
+​```
+
+## Waves
+
+| Wave | Tasks | Description |
+|------|-------|-------------|
+| 1 | task-01, task-02 | {Brief description of what this wave accomplishes} |
+| 2 | task-03 | {Brief description} |
+
+## Task Status
+
+### Wave 1
+- [ ] [task-01-{name}](./tasks/task-01-{name}.md) — {One-line title}
+- [ ] [task-02-{name}](./tasks/task-02-{name}.md) — {One-line title}
+
+### Wave 2
+- [ ] [task-03-{name}](./tasks/task-03-{name}.md) — {One-line title}
+```
+
+## Key Points
+
+- The **Dependency Graph** uses Mermaid syntax (widely rendered in GitHub, VS Code, etc.). Each node shows the task number and title for quick reference.
+- The **Waves** table provides a scannable overview of what runs in parallel.
+- The **Task Status** section uses markdown checkboxes that the `implement-feature` skill updates as tasks complete. The orchestrator parses these to determine which wave to resume from.
+- Links to task files use relative paths pointing into the `tasks/` subfolder.
+- Tasks without dependencies have no incoming arrows in the graph — these form Wave 1.

package/template/.claude/skills/create-spec/references/requirements-template.md

@@ -0,0 +1,54 @@
+# Requirements Template
+
+Use this structure for the requirements.md at the root of each spec folder.
+
+## Template
+
+```markdown
+# Requirements: {Feature Name}
+
+## Summary
+
+{What the feature does and why it exists — 2-3 paragraphs covering the problem, the solution, and the expected outcome.}
+
+## Goals
+
+- {Goal 1}
+- {Goal 2}
+- {Goal 3}
+
+## Non-Goals
+
+{Explicitly out of scope — things that might seem related but are not part of this feature.}
+
+- {Non-goal 1}
+- {Non-goal 2}
+
+## Acceptance Criteria
+
+{High-level criteria for the entire feature. Individual task files have their own granular criteria.}
+
+- [ ] {Criterion 1}
+- [ ] {Criterion 2}
+- [ ] {Criterion 3}
+
+## Assumptions
+
+{Things assumed to be true that could affect implementation if they turn out to be false.}
+
+- {Assumption 1}
+- {Assumption 2}
+
+## Technical Constraints
+
+{Architecture decisions, technology choices, or constraints that affect all tasks.}
+
+- {Constraint 1}
+- {Constraint 2}
+```
+
+## Key Points
+
+- The requirements doc provides **overall feature context** that each coder agent receives alongside its task file. Keep it focused on the "what" and "why" — individual task files handle the "how."
+- Non-goals are important: they prevent agents from over-building. If search functionality is out of scope, say so — otherwise a well-meaning agent might add it.
+- Acceptance criteria here are feature-level (the whole thing works end-to-end). Task-level criteria live in each task file.

package/template/.claude/skills/create-spec/references/task-template.md

@@ -0,0 +1,79 @@
+# Task File Template
+
+Use this structure for each task file in the `tasks/` subfolder. Each task file must be **fully self-contained** — a coder agent reading only this file should know exactly what to implement, why, and how.
+
+## Template
+
+```markdown
+# Task {nn}: {Title}
+
+## Status
+
+pending
+
+## Wave
+
+{N}
+
+## Description
+
+{2-5 sentences describing what this task accomplishes and why it matters in the context of the overall feature. Include enough context that an agent unfamiliar with the planning conversation understands the purpose.}
+
+## Dependencies
+
+**Depends on:** {Comma-separated list of task filenames, or "None (Wave 1)"}
+**Blocks:** {Comma-separated list of task filenames, or "None"}
+
+**Context from dependencies:** {Prose summary of what the dependency tasks produce that this task needs. For example: "task-01-setup-database.md creates the PostgreSQL schema with users and sessions tables. This task builds the API routes that query those tables." This is what makes each file self-contained — the agent does not need to read other task files to understand its inputs.}
+
+## Files to Create
+
+- `path/to/new-file.ts` — {Brief purpose}
+- `path/to/another-file.ts` — {Brief purpose}
+
+## Files to Modify
+
+- `path/to/existing-file.ts` — {What changes and why}
+
+## Technical Details
+
+{All implementation-specific details from the planning conversation. This section is the single source of truth. Include:}
+
+### Implementation Steps
+
+1. {Step-by-step instructions with enough detail for independent implementation}
+2. {Include CLI commands where relevant: `pnpm add package-name`}
+3. {Include code snippets for non-obvious patterns}
+
+### Code Snippets
+
+{Key type definitions, schemas, configuration blocks, or patterns that the implementer needs. Use fenced code blocks with language tags.}
+
+### Environment Variables
+
+{If applicable:}
+- `VAR_NAME` — {Purpose and example value}
+
+### API Endpoints
+
+{If applicable:}
+- `METHOD /path` — {Request/response shape}
+
+## Acceptance Criteria
+
+- [ ] {Criterion 1 — specific and verifiable}
+- [ ] {Criterion 2}
+- [ ] {Criterion 3}
+
+## Notes
+
+{Any additional context, edge cases, warnings, or architectural decisions relevant to this task. Omit this section if there's nothing to add.}
+```
+
+## Key Points
+
+- The **Status** field is updated by the `implement-feature` skill: `pending` → `in-progress` → `complete`.
+- The **Dependencies** section includes prose context (not just filenames) so the agent understands its inputs without reading other files. This is the most important part of making task files self-contained.
+- **Files to Create** and **Files to Modify** make the task's scope explicit. Tasks in the same wave should not overlap on these lists.
+- **Technical Details** captures everything from the planning conversation — CLI commands, schemas, code snippets, file paths, env vars, API endpoints. If it was discussed during planning and is relevant to this task, it belongs here.
+- **Acceptance Criteria** should be specific enough that completion can be verified objectively (by a code review agent or a human).