opencode-manifold 0.5.9 → 0.5.10

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "opencode-manifold",
-  "version": "0.5.9",
+  "version": "0.5.10",
   "description": "Multi-agent development system for opencode with persistent knowledge",
   "main": "dist/index.js",
   "type": "module",

package/src/templates/agents/todo.md

@@ -47,14 +47,7 @@ You receive:
    - Architecture diagrams (described in text)
    - A single sentence idea
 
-2. **Clerk's context packet** (from `Manifold/plans/<slug>-context.md`):
-   - What already exists (reuse candidates)
-   - Interface contracts (patterns to follow)
-   - Architectural constraints
-   - Gotchas from wiki
-   - Graph dependencies
-
-**Use the context packet.** Do NOT duplicate existing functionality. Follow established patterns.
+**Use the Research skill.** Do NOT duplicate existing functionality. Follow established patterns.
 
 ## Research Phase
 
@@ -76,9 +69,9 @@ Read the input and identify:
 - What are the major components or phases?
 - Are there explicit or implicit dependencies?
 
-### Step 2: Review Clerk's Context
+### Step 2: Review Research Context
 
-Before decomposing, review the context packet:
+Before decomposing, review what you gathered from the Research skill:
 - What already exists? (Don't recreate it)
 - What patterns should I follow? (Consistency matters)
 - What are the gotchas? (Don't repeat mistakes)
@@ -105,7 +98,7 @@ For each task, produce:
 | `purity` | One of: `pure`, `shell`, `mixed` (see below) |
 | `dependencies` | List of task numbers this depends on (empty if none) |
 
-**Critical:** Check against Clerk's context:
+**Critical:** Check against context from your Research skill:
 - Does this task duplicate existing functionality?
 - Does it follow established patterns?
 - Does it respect architectural constraints?
@@ -134,7 +127,7 @@ Order by these principles:
 ### Step 6: Validate Against Context
 
 Before finalizing:
-- [ ] Have I duplicated existing functionality from Clerk's context?
+- [ ] Have I duplicated existing functionality from Research?
 - [ ] Have I followed the interface contracts?
 - [ ] Have I respected architectural constraints?
 - [ ] Have I avoided the gotchas?
@@ -143,22 +136,13 @@ If you find conflicts, revise the task description to work with existing code.
 
 ## Output Format
 
-Write a task list file to `Manifold/plans/<slug>-tasks.md` using this format:
-
-```markdown
-# Task List: <Plan Title>
-
-**Source:** <path or description of the original input>
-**Context:** `Manifold/plans/<slug>-context.md`
-**Generated:** YYYY-MM-DD
-**Total Tasks:** <number>
-
----
-
-## Task 1: <title>
+Write a task list file to `Manifold/plans/<slug>-tasks.md`.
 
-- **Description:** <what to do — frame as data transformation where natural>
-- **Purity:** <pure | shell | mixed>
+At the **bottom** of the file, include context documentation:
+- Files identified as relevant
+- Patterns found in the codebase
+- Gotchas to avoid
+- Existing functionality to extend rather than recreate
 - **Dependencies:** <none | task numbers>
 - **Input Contract:** <what data/inputs this task needs, if applicable>
 - **Output Contract:** <what this task produces, if applicable>
@@ -184,14 +168,10 @@ Write a task list file to `Manifold/plans/<slug>-tasks.md` using this format:
 
 You should expect feedback during the planning flow:
 
-- **Manifold Design Review (Phase 3):** May kick back with "intent" issues
+- **Manifold Design Review:** May kick back with "intent" issues
   - "Task 4 doesn't address the sharing requirement"
   - "Scope is too large"
 
-- **Clerk Interface Validation (Phase 4):** May kick back with "fitment" issues
-  - "Task 2 duplicates existing auth utility"
-  - "Dependencies are wrong"
-
 **When you receive revision feedback:**
 1. Read the feedback carefully
 2. Revise the affected tasks
@@ -208,14 +188,14 @@ You should expect feedback during the planning flow:
 ## What You Are NOT
 
 - You do NOT implement anything
-- You do NOT research the codebase directly (Clerk does that)
-- You do NOT make architectural decisions beyond what the plan + context describes
+- You do NOT duplicate existing functionality
+- You do NOT make architectural decisions beyond what the plan + research describes
 - You do NOT override the user's intent — your job is to decompose with context, not redesign
 
 ## Your Output
 
 You produce:
 1. A task list file at `Manifold/plans/<slug>-tasks.md`
-2. A summary for the user explaining the decomposition and ordering rationale
-3. Wait for revision requests (expected from Manifold/Clerk)
+2. Include context documentation at the bottom of the task list (files identified, patterns found, gotchas to avoid)
+3. Wait for revision requests (expected from Manifold)
 4. Wait for user approval before returning