@mindfoldhq/trellis 0.6.0-beta.2 → 0.6.0-beta.20

package/dist/templates/copilot/prompts/parallel.prompt.md

@@ -122,18 +122,26 @@ python3 ./.trellis/scripts/task.py add-context "$TASK_DIR" implement "<path>" "<
 python3 ./.trellis/scripts/task.py add-context "$TASK_DIR" check "<path>" "<reason>"
 ```
 
-#### Step 4: Create prd.md
+#### Step 4: Update prd.md
 
 ```bash
-cat > "$TASK_DIR/prd.md" << 'EOF'
+# task.py create already created prd.md; edit it with requirements and acceptance criteria.
+$EDITOR "$TASK_DIR/prd.md"
+```
+
+Use this shape:
+
+```markdown
 # Feature: <name>
 
+## Goal
+...
+
 ## Requirements
 - ...
 
 ## Acceptance Criteria
-- ...
-EOF
+- [ ] ...
 ```
 
 #### Step 5: Validate and Start
@@ -181,10 +189,10 @@ python3 ./.trellis/scripts/multi_agent/cleanup.py <branch>          # Cleanup wo
 
 The dispatch agent in worktree will automatically execute:
 
-1. implement �?Implement feature
-2. check �?Check code quality
-3. finish �?Final verification
-4. create-pr �?Create PR
+1. implement �?Implement feature
+2. check �?Check code quality
+3. finish �?Final verification
+4. create-pr �?Create PR
 
 ---
 

package/dist/templates/copilot/prompts/start.prompt.md

@@ -4,394 +4,60 @@ description: "Trellis Copilot prompt: Start Session"
 
 # Start Session
 
-Initialize your AI development session and begin working on tasks.
+Initialize a Trellis-managed development session. This platform has no session-start hook, so manually load the equivalent context by following these steps (each one mirrors a section the hook would otherwise inject).
 
 ---
 
-## Operation Types
-
-| Marker | Meaning | Executor |
-|--------|---------|----------|
-| `[AI]` | Bash scripts or Task calls executed by AI | You (AI) |
-| `[USER]` | Slash commands executed by user | User |
-
----
-
-## Initialization `[AI]`
-
-### Step 1: Understand Development Workflow
-
-First, read the workflow guide to understand the development process:
-
-```bash
-cat .trellis/workflow.md
-```
-
-**Follow the instructions in workflow.md** - it contains:
-- Core principles (Read Before Write, Follow Standards, etc.)
-- File system structure
-- Development process
-- Best practices
-
-### Step 2: Get Current Context
-
-```bash
-python3 ./.trellis/scripts/get_context.py
-```
-
-This shows: developer identity, git status, current task (if any), active tasks.
-
-### Step 3: Read Guidelines Index
-
-```bash
-python3 ./.trellis/scripts/get_context.py --mode packages
-```
-
-This shows available packages and their spec layers. Read the relevant spec indexes:
-
-```bash
-cat .trellis/spec/<package>/<layer>/index.md   # Package-specific guidelines
-cat .trellis/spec/guides/index.md              # Thinking guides (always read)
-```
-
-> **Important**: The index files are navigation �?they list the actual guideline files (e.g., `error-handling.md`, `conventions.md`, `mock-strategies.md`).
-> At this step, just read the indexes to understand what's available.
-> When you start actual development, you MUST go back and read the specific guideline files relevant to your task, as listed in the index's Pre-Development Checklist.
-
-### Step 4: Report and Ask
-
-Report what you learned and ask: "What would you like to work on?"
-
----
-
-## Task Classification
-
-When user describes a task, classify it:
-
-| Type | Criteria | Workflow |
-|------|----------|----------|
-| **Question** | User asks about code, architecture, or how something works | Answer directly |
-| **Trivial Fix** | Typo fix, comment update, single-line change | Direct Edit |
-| **Simple Task** | Clear goal, 1-2 files, well-defined scope | Quick confirm �?Implement |
-| **Complex Task** | Vague goal, multiple files, architectural decisions | **Brainstorm �?Task Workflow** |
-
-### Classification Signals
-
-**Trivial/Simple indicators:**
-- User specifies exact file and change
-- "Fix the typo in X"
-- "Add field Y to component Z"
-- Clear acceptance criteria already stated
-
-**Complex indicators:**
-- "I want to add a feature for..."
-- "Can you help me improve..."
-- Mentions multiple areas or systems
-- No clear implementation path
-- User seems unsure about approach
-
-### Decision Rule
-
-> **If in doubt, use Brainstorm + Task Workflow.**
->
-> Task Workflow ensures code-spec context is injected to agents, resulting in higher quality code.
-> The overhead is minimal, but the benefit is significant.
-
----
-
-## Question / Trivial Fix
-
-For questions or trivial fixes, work directly:
-
-1. Answer question or make the fix
-2. If code was changed, remind user to run `/`
-
----
-
-## Simple Task
-
-For simple, well-defined tasks:
-
-1. Quick confirm: "I understand you want to [goal]. Shall I proceed?"
-2. If no, clarify and confirm again
-3. **If yes: execute ALL steps below without stopping. Do NOT ask for additional confirmation between steps.**
-   - Create task directory (Phase 1 Path B, Step 2)
-   - Write PRD (Step 3)
-   - Research codebase (Phase 2, Step 5)
-   - Configure context (Step 6)
-   - Activate task (Step 7)
-   - Implement (Phase 3, Step 8)
-   - Check quality (Step 9)
-   - Complete (Step 10)
-
----
-
-## Complex Task - Brainstorm First
-
-For complex or vague tasks, **automatically start the brainstorm process** �?do NOT skip directly to implementation.
-
-See `/` for the full process. Summary:
-
-1. **Acknowledge and classify** - State your understanding
-2. **Create task directory** - Track evolving requirements in `prd.md`
-3. **Ask questions one at a time** - Update PRD after each answer
-4. **Propose approaches** - For architectural decisions
-5. **Confirm final requirements** - Get explicit approval
-6. **Proceed to Task Workflow** - With clear requirements in PRD
-
-> **Subtask Decomposition**: If brainstorm reveals multiple independent work items,
-> consider creating subtasks using `--parent` flag or `add-subtask` command.
-> See `/` Step 8 for details.
-
-### Key Brainstorm Principles
-
-| Principle | Description |
-|-----------|-------------|
-| **One question at a time** | Never overwhelm with multiple questions |
-| **Update PRD immediately** | After each answer, update the document |
-| **Prefer multiple choice** | Easier for users to answer |
-| **YAGNI** | Challenge unnecessary complexity |
-
----
-
-## Task Workflow (Development Tasks)
-
-**Why this workflow?**
-- Research Agent analyzes what code-spec files are needed
-- Code-spec files are configured in jsonl files
-- Implement Agent receives code-spec context via Hook injection
-- Check Agent verifies against code-spec requirements
-- Result: Code that follows project conventions automatically
-
-### Overview: Two Entry Points
-
-```
-From Brainstorm (Complex Task):
-  PRD confirmed �?Research �?Configure Context �?Activate �?Implement �?Check �?Complete
-
-From Simple Task:
-  Confirm �?Create Task �?Write PRD �?Research �?Configure Context �?Activate �?Implement �?Check �?Complete
-```
-
-**Key principle: Research happens AFTER requirements are clear (PRD exists).**
-
----
-
-### Phase 1: Establish Requirements
-
-#### Path A: From Brainstorm (skip to Phase 2)
-
-PRD and task directory already exist from brainstorm. Skip directly to Phase 2.
-
-#### Path B: From Simple Task
-
-**Step 1: Confirm Understanding** `[AI]`
-
-Quick confirm:
-- What is the goal?
-- What type of development? (frontend / backend / fullstack)
-- Any specific requirements or constraints?
-
-**Step 2: Create Task Directory** `[AI]`
+## Step 1: Current state
+Identity, git status, current task, active tasks, journal location.
 
 ```bash
-TASK_DIR=$(python3 ./.trellis/scripts/task.py create "<title>" --slug <name>)
-```
-
-**Step 3: Write PRD** `[AI]`
-
-Create `prd.md` in the task directory with:
-
-```markdown
-# <Task Title>
-
-## Goal
-<What we're trying to achieve>
-
-## Requirements
-- <Requirement 1>
-- <Requirement 2>
-
-## Acceptance Criteria
-- [ ] <Criterion 1>
-- [ ] <Criterion 2>
-
-## Technical Notes
-<Any technical decisions or constraints>
-```
-
----
-
-### Phase 2: Prepare for Implementation (shared)
-
-> Both paths converge here. PRD and task directory must exist before proceeding.
-
-**Step 4: Code-Spec Depth Check** `[AI]`
-
-If the task touches infra or cross-layer contracts, do not start implementation until code-spec depth is defined.
-
-Trigger this requirement when the change includes any of:
-- New or changed command/API signatures
-- Database schema or migration changes
-- Infra integrations (storage, queue, cache, secrets, env contracts)
-- Cross-layer payload transformations
-
-Must-have before proceeding:
-- [ ] Target code-spec files to update are identified
-- [ ] Concrete contract is defined (signature, fields, env keys)
-- [ ] Validation and error matrix is defined
-- [ ] At least one Good/Base/Bad case is defined
-
-**Step 5: Research the Codebase** `[AI]`
-
-Based on the confirmed PRD, call Research Agent to find relevant specs and patterns:
-
-```
-Task(
-  subagent_type: "trellis-research",
-  prompt: "Analyze the codebase for this task:
-
-  Task: <goal from PRD>
-  Type: <frontend/backend/fullstack>
-
-  Please find:
-  1. Relevant code-spec files in .trellis/spec/
-  2. Existing code patterns to follow (find 2-3 examples)
-  3. Files that will likely need modification
-
-  Output:
-  ## Relevant Code-Specs
-  - <path>: <why it's relevant>
-
-  ## Code Patterns Found
-  - <pattern>: <example file path>
-
-  ## Files to Modify
-  - <path>: <what change>"
-)
+{{PYTHON_CMD}} ./.trellis/scripts/get_context.py
 ```
 
-**Step 6: Configure Context** `[AI]`
-
-`implement.jsonl` and `check.jsonl` were seeded on `task.py create` with a single self-describing `_example` line. Curate real entries now (see workflow.md Phase 1.3 for the full rule):
+If this output includes a line beginning `Trellis update available:`, copy the full line verbatim when summarizing session context. Do not shorten operational command hints.
 
-- Put **spec files** (`.trellis/spec/<package>/<layer>/*.md`) and **research files** (`{TASK_DIR}/research/*.md`) only.
-- Do NOT put code files — those are read during implementation, not pre-registered here.
-- Split: `implement.jsonl` = specs the implement sub-agent needs; `check.jsonl` = specs the check sub-agent needs.
-
-Discover available specs:
+## Step 2: Workflow overview
+Phase Index + skill routing table + DO-NOT-skip rules.
 
 ```bash
-python3 ./.trellis/scripts/get_context.py --mode packages
+{{PYTHON_CMD}} ./.trellis/scripts/get_context.py --mode phase
 ```
 
-Append entries (either edit the jsonl file directly, or):
+Full guide in `.trellis/workflow.md` (read on demand).
 
-```bash
-python3 ./.trellis/scripts/task.py add-context "$TASK_DIR" implement "<path>" "<reason>"
-python3 ./.trellis/scripts/task.py add-context "$TASK_DIR" check "<path>" "<reason>"
-```
-
-**Step 7: Activate Task** `[AI]`
+## Step 3: Guideline indexes
+Discover packages + spec layers, then read each relevant index file.
 
 ```bash
-python3 ./.trellis/scripts/task.py start "$TASK_DIR"
+{{PYTHON_CMD}} ./.trellis/scripts/get_context.py --mode packages
+cat .trellis/spec/guides/index.md
+cat .trellis/spec/<package>/<layer>/index.md   # for each relevant layer
 ```
 
-This sets the active task through Trellis' session resolver so hooks can inject context for this AI session. If the command fails because no session identity is available, rerun it from an IDE/session that exposes session identity or set `TRELLIS_CONTEXT_ID`.
+Index files list the specific guideline docs to read when you actually start coding.
 
----
+## Step 4: Decide next action
+From Step 1 you know the current task and status. Check the task directory:
 
-### Phase 3: Execute (shared)
-
-**Step 8: Implement** `[AI]`
-
-Call Implement Agent (code-spec context is auto-injected by hook):
-
-```
-Task(
-  subagent_type: "trellis-implement",
-  prompt: "Implement the task described in prd.md.
-
-  Follow all code-spec files that have been injected into your context.
-  Run lint and typecheck before finishing."
-)
-```
-
-**Step 9: Check Quality** `[AI]`
-
-Call Check Agent (code-spec context is auto-injected by hook):
-
-```
-Task(
-  subagent_type: "trellis-check",
-  prompt: "Review all code changes against the code-spec requirements.
-
-  Fix any issues you find directly.
-  Ensure lint and typecheck pass."
-)
-```
-
-**Step 10: Complete** `[AI]`
-
-1. Verify lint and typecheck pass
-2. Report what was implemented
-3. Remind user to:
-   - Test the changes
-   - Commit when ready
-   - Run `/` to record this session
-
----
-
-## Continuing Existing Task
-
-If `get_context.py` shows a current task:
-
-1. Read the task's `prd.md` to understand the goal
-2. Check `task.json` for current status and phase
-3. Ask user: "Continue working on <task-name>?"
-
-If yes, resume from the appropriate step (usually Step 7 or 8).
+- **Active task status `planning` + no `prd.md`** → Phase 1.1. Load the `trellis-brainstorm` skill.
+- **Active task status `planning` + `prd.md` exists** → stay in Phase 1. Lightweight tasks can be PRD-only; complex tasks need `design.md` + `implement.md`. Load the relevant Phase 1 step detail before `task.py start`.
+- **Active task status `in_progress`** → Phase 2 step 2.1. Load the step detail:
+  ```bash
+  {{PYTHON_CMD}} ./.trellis/scripts/get_context.py --mode phase --step 2.1 --platform {{CLI_FLAG}}
+  ```
+- **No active task** → classify first. For simple conversation / small task, ask only whether this turn should create a Trellis task. For complex work, ask whether you may create a Trellis task and enter planning. If the user says no, skip Trellis for this session.
 
 ---
 
-## Commands Reference
-
-### User Commands `[USER]`
-
-| Command | When to Use |
-|---------|-------------|
-| `/` | Begin a session (this command) |
-| `/` | Clarify vague requirements (called from start) |
-| `/` | Complex tasks needing isolated worktree |
-| `/` | Before committing changes |
-| `/` | After completing a task |
-
-### AI Scripts `[AI]`
-
-| Script | Purpose |
-|--------|---------|
-| `python3 ./.trellis/scripts/get_context.py` | Get session context |
-| `python3 ./.trellis/scripts/task.py create` | Create task directory (seeds jsonl on sub-agent platforms) |
-| `python3 ./.trellis/scripts/task.py add-context` | Append code-spec/research entry to jsonl |
-| `python3 ./.trellis/scripts/task.py start` | Set current task |
-| `python3 ./.trellis/scripts/task.py finish` | Clear current task |
-| `python3 ./.trellis/scripts/task.py archive` | Archive completed task |
-
-### Sub Agents `[AI]`
-
-| Agent | Purpose | Hook Injection |
-|-------|---------|----------------|
-| research | Analyze codebase | No (reads directly) |
-| implement | Write code | Yes (implement.jsonl) |
-| check | Review & fix | Yes (check.jsonl) |
-| debug | Fix specific issues | Yes (debug.jsonl) |
-
----
+## Skill routing (quick reference)
 
-## Key Principle
+| User intent | Skill |
+|---|---|
+| New feature / unclear requirements | `trellis-brainstorm` |
+| About to write code | `trellis-before-dev` |
+| Done coding / quality check | `trellis-check` |
+| Stuck / fixed same bug multiple times | `trellis-break-loop` |
+| Learned something worth capturing | `trellis-update-spec` |
 
-> **Code-spec context is injected, not remembered.**
->
-> The Task Workflow ensures agents receive relevant code-spec context automatically.
-> This is more reliable than hoping the AI "remembers" conventions.
+Full rules + anti-rationalization table in `.trellis/workflow.md`.

package/dist/templates/cursor/agents/trellis-check.md

@@ -19,21 +19,25 @@ You are already the `trellis-check` sub-agent that the main session dispatched.
 
 Look for the `<!-- trellis-hook-injected -->` marker in your input above.
 
-- **If the marker is present**: prd / spec / research files have already been auto-loaded for you above. Proceed with the check work directly.
-- **If the marker is absent**: hook injection didn't fire (Windows + Claude Code, `--continue` resume, fork distribution, hooks disabled, etc.). Find the active task path from your dispatch prompt's first line `Active task: <path>`, then Read `<task-path>/prd.md` and the spec files listed in `<task-path>/check.jsonl` yourself before doing the work.
+- **If the marker is present**: task artifacts, spec, and research files have already been auto-loaded for you above. Proceed with the check work directly.
+- **If the marker is absent**: hook injection didn't fire (Windows + Claude Code, `--continue` resume, fork distribution, hooks disabled, etc.). Find the active task path from your dispatch prompt's first line `Active task: <path>`, then Read `<task-path>/check.jsonl`, each listed file, `<task-path>/prd.md`, `<task-path>/design.md` if present, and `<task-path>/implement.md` if present before doing the work.
 
 ## Context
 
 Before checking, read:
 - `.trellis/spec/` - Development guidelines
+- Task `prd.md` - Requirements document
+- Task `design.md` - Technical design (if exists)
+- Task `implement.md` - Execution plan (if exists)
 - Pre-commit checklist for quality standards
 
 ## Core Responsibilities
 
 1. **Get code changes** - Use git diff to get uncommitted code
-2. **Check against specs** - Verify code follows guidelines
-3. **Self-fix** - Fix issues yourself, not just report them
-4. **Run verification** - typecheck and lint
+2. **Review task artifacts** - Check changes against prd.md, design.md if present, and implement.md if present
+3. **Check against specs** - Verify code follows guidelines
+4. **Self-fix** - Fix issues yourself, not just report them
+5. **Run verification** - typecheck and lint
 
 ## Important
 
@@ -52,10 +56,12 @@ git diff --name-only  # List changed files
 git diff              # View specific changes
 ```
 
-### Step 2: Check Against Specs
+### Step 2: Check Against Specs and Task Artifacts
 
-Read relevant specs in `.trellis/spec/` to check code:
+Read the task's prd.md, design.md if present, and implement.md if present, then read relevant specs in `.trellis/spec/` to check code:
 
+- Does it satisfy the task requirements
+- Does it follow the technical design and implementation plan when present
 - Does it follow directory structure conventions
 - Does it follow naming conventions
 - Does it follow code patterns

package/dist/templates/cursor/agents/trellis-implement.md

@@ -20,7 +20,7 @@ You are already the `trellis-implement` sub-agent that the main session dispatch
 Look for the `<!-- trellis-hook-injected -->` marker in your input above.
 
 - **If the marker is present**: prd / spec / research files have already been auto-loaded for you above. Proceed with the implementation work directly.
-- **If the marker is absent**: hook injection didn't fire (Windows + Claude Code, `--continue` resume, fork distribution, hooks disabled, etc.). Find the active task path from your dispatch prompt's first line `Active task: <path>`, then Read `<task-path>/prd.md`, `<task-path>/info.md` (if it exists), and the spec files listed in `<task-path>/implement.jsonl` yourself before doing the work.
+- **If the marker is absent**: hook injection didn't fire (Windows + Claude Code, `--continue` resume, fork distribution, hooks disabled, etc.). Find the active task path from your dispatch prompt's first line `Active task: <path>`, then Read `<task-path>/implement.jsonl`, each listed file, `<task-path>/prd.md`, `<task-path>/design.md` if present, and `<task-path>/implement.md` if present before doing the work.
 
 ## Context
 
@@ -28,13 +28,14 @@ Before implementing, read:
 - `.trellis/workflow.md` - Project workflow
 - `.trellis/spec/` - Development guidelines
 - Task `prd.md` - Requirements document
-- Task `info.md` - Technical design (if exists)
+- Task `design.md` - Technical design (if exists)
+- Task `implement.md` - Execution plan (if exists)
 
 ## Core Responsibilities
 
 1. **Understand specs** - Read relevant spec files in `.trellis/spec/`
-2. **Understand requirements** - Read prd.md and info.md
-3. **Implement features** - Write code following specs and design
+2. **Understand task artifacts** - Read prd.md, design.md if present, and implement.md if present
+3. **Implement features** - Write code following specs and task artifacts
 4. **Self-check** - Ensure code quality
 5. **Report results** - Report completion status
 
@@ -59,15 +60,15 @@ Read relevant specs based on task type:
 
 ### 2. Understand Requirements
 
-Read the task's prd.md and info.md:
+Read the task's prd.md, design.md if present, and implement.md if present:
 
 - What are the core requirements
 - Key points of technical design
-- Which files to modify/create
+- Implementation order, validation commands, and rollback points
 
 ### 3. Implement Features
 
-- Write code following specs and technical design
+- Write code following specs and task artifacts
 - Follow existing code patterns
 - Only do what's required, no over-engineering
 

package/dist/templates/cursor/hooks.json

@@ -11,13 +11,7 @@
     "sessionStart": [
       {
         "command": "{{PYTHON_CMD}} .cursor/hooks/session-start.py",
-        "timeout": 10
-      }
-    ],
-    "beforeSubmitPrompt": [
-      {
-        "command": "{{PYTHON_CMD}} .cursor/hooks/inject-workflow-state.py",
-        "timeout": 5
+        "timeout": 30
       }
     ],
     "beforeShellExecution": [

package/dist/templates/droid/droids/trellis-check.md

@@ -12,21 +12,25 @@ You are the Check Agent in the Trellis workflow.
 
 Look for the `<!-- trellis-hook-injected -->` marker in your input above.
 
-- **If the marker is present**: prd / spec / research files have already been auto-loaded for you above. Proceed with the check work directly.
-- **If the marker is absent**: hook injection didn't fire (Windows + Claude Code, `--continue` resume, fork distribution, hooks disabled, etc.). Find the active task path from your dispatch prompt's first line `Active task: <path>`, then Read `<task-path>/prd.md` and the spec files listed in `<task-path>/check.jsonl` yourself before doing the work.
+- **If the marker is present**: task artifacts, spec, and research files have already been auto-loaded for you above. Proceed with the check work directly.
+- **If the marker is absent**: hook injection didn't fire (Windows + Claude Code, `--continue` resume, fork distribution, hooks disabled, etc.). Find the active task path from your dispatch prompt's first line `Active task: <path>`, then Read `<task-path>/check.jsonl`, each listed file, `<task-path>/prd.md`, `<task-path>/design.md` if present, and `<task-path>/implement.md` if present before doing the work.
 
 ## Context
 
 Before checking, read:
 - `.trellis/spec/` - Development guidelines
+- Task `prd.md` - Requirements document
+- Task `design.md` - Technical design (if exists)
+- Task `implement.md` - Execution plan (if exists)
 - Pre-commit checklist for quality standards
 
 ## Core Responsibilities
 
 1. **Get code changes** - Use git diff to get uncommitted code
-2. **Check against specs** - Verify code follows guidelines
-3. **Self-fix** - Fix issues yourself, not just report them
-4. **Run verification** - typecheck and lint
+2. **Review task artifacts** - Check changes against prd.md, design.md if present, and implement.md if present
+3. **Check against specs** - Verify code follows guidelines
+4. **Self-fix** - Fix issues yourself, not just report them
+5. **Run verification** - typecheck and lint
 
 ## Important
 
@@ -45,10 +49,12 @@ git diff --name-only  # List changed files
 git diff              # View specific changes
 ```
 
-### Step 2: Check Against Specs
+### Step 2: Check Against Specs and Task Artifacts
 
-Read relevant specs in `.trellis/spec/` to check code:
+Read the task's prd.md, design.md if present, and implement.md if present, then read relevant specs in `.trellis/spec/` to check code:
 
+- Does it satisfy the task requirements
+- Does it follow the technical design and implementation plan when present
 - Does it follow directory structure conventions
 - Does it follow naming conventions
 - Does it follow code patterns

package/dist/templates/droid/droids/trellis-implement.md

@@ -13,7 +13,7 @@ You are the Implement Agent in the Trellis workflow.
 Look for the `<!-- trellis-hook-injected -->` marker in your input above.
 
 - **If the marker is present**: prd / spec / research files have already been auto-loaded for you above. Proceed with the implementation work directly.
-- **If the marker is absent**: hook injection didn't fire (Windows + Claude Code, `--continue` resume, fork distribution, hooks disabled, etc.). Find the active task path from your dispatch prompt's first line `Active task: <path>`, then Read `<task-path>/prd.md`, `<task-path>/info.md` (if it exists), and the spec files listed in `<task-path>/implement.jsonl` yourself before doing the work.
+- **If the marker is absent**: hook injection didn't fire (Windows + Claude Code, `--continue` resume, fork distribution, hooks disabled, etc.). Find the active task path from your dispatch prompt's first line `Active task: <path>`, then Read `<task-path>/implement.jsonl`, each listed file, `<task-path>/prd.md`, `<task-path>/design.md` if present, and `<task-path>/implement.md` if present before doing the work.
 
 ## Context
 
@@ -21,13 +21,14 @@ Before implementing, read:
 - `.trellis/workflow.md` - Project workflow
 - `.trellis/spec/` - Development guidelines
 - Task `prd.md` - Requirements document
-- Task `info.md` - Technical design (if exists)
+- Task `design.md` - Technical design (if exists)
+- Task `implement.md` - Execution plan (if exists)
 
 ## Core Responsibilities
 
 1. **Understand specs** - Read relevant spec files in `.trellis/spec/`
-2. **Understand requirements** - Read prd.md and info.md
-3. **Implement features** - Write code following specs and design
+2. **Understand task artifacts** - Read prd.md, design.md if present, and implement.md if present
+3. **Implement features** - Write code following specs and task artifacts
 4. **Self-check** - Ensure code quality
 5. **Report results** - Report completion status
 
@@ -52,15 +53,15 @@ Read relevant specs based on task type:
 
 ### 2. Understand Requirements
 
-Read the task's prd.md and info.md:
+Read the task's prd.md, design.md if present, and implement.md if present:
 
 - What are the core requirements
 - Key points of technical design
-- Which files to modify/create
+- Implementation order, validation commands, and rollback points
 
 ### 3. Implement Features
 
-- Write code following specs and technical design
+- Write code following specs and task artifacts
 - Follow existing code patterns
 - Only do what's required, no over-engineering