opencode-plan-manager 0.2.0 → 0.3.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (3) hide show
  1. package/README.md +92 -36
  2. package/dist/index.js +96 -94
  3. package/package.json +57 -39
package/README.md CHANGED
@@ -11,6 +11,44 @@ OpenCode Plan Manager is a high-performance, minimalist plugin designed to bridg
11
11
 
12
12
  ---
13
13
 
14
+ <details>
15
+ <summary><strong>⚠️ v0.3.0 Breaking Changes – Read Before Upgrading!</strong></summary>
16
+
17
+ #### **This release introduces breaking changes that affect file structure, field names, and plan format.**
18
+
19
+ If you are upgrading from v0.2.x, you MUST migrate all existing plans and metadata for compatibility.
20
+
21
+ > Tip: AI Agents can still access old plans by reading their files directly (using Bash/list/read tools), then recreate plans in the new format using the latest plugin's API.
22
+
23
+ **What Changed?**
24
+
25
+ - **File naming:**
26
+ - `spec.md` → `specifications.md`
27
+ - `plan.md` → `implementation.md`
28
+ - **Metadata key:**
29
+ - `"plan_id"` → `"id"` in `metadata.json`
30
+ - **Markdown structure:**
31
+ - All `.md` files now require H1 headers:
32
+ - `# Specifications` at the top of `specifications.md`
33
+ - `# Implementation Plan` at the top of `implementation.md`
34
+ - Phases are now indicated using H2 (`##`) headers, not H3.
35
+ - No more `## Overview/Description` headers—put the summary right after the H1.
36
+ - **Tool arguments:**
37
+ - All APIs expect updated argument keys (e.g., `id` instead of `plan_id`)
38
+
39
+ **How to Migrate?**
40
+
41
+ 1. Rename all `spec.md` to `specifications.md` & `plan.md` to `implementation.md` in each plan folder.
42
+ 2. Open each `metadata.json` file and rename `plan_id` → `id`.
43
+ 3. Update the content of each markdown file to add the correct H1 headers and phase header levels as described above.
44
+ 4. Validate your plans by running `plan_list` and `plan_read`.
45
+
46
+ **Older plans will not load or load with errors until they are migrated to the new format.**
47
+
48
+ </details>
49
+
50
+ ---
51
+
14
52
  ## 🧠 Why Plan Manager?
15
53
 
16
54
  In agentic workflows, **Implementation Plans** are the source of truth. However, most implementations suffer from "Token Soup"—where agents are forced to parse massive, unstructured files, leading to hallucinations and lost context.
@@ -30,8 +68,8 @@ Add the plugin to your OpenCode configuration file (~/.config/opencode/opencode.
30
68
 
31
69
  ```json
32
70
  {
33
- "$schema": "https://opencode.ai/config.json",
34
- "plugin": ["opencode-plan-manager@0.1.0"]
71
+ "$schema": "https://opencode.ai/config.json",
72
+ "plugin": ["opencode-plan-manager@0.2.0"]
35
73
  }
36
74
  ```
37
75
 
@@ -39,19 +77,37 @@ Add the plugin to your OpenCode configuration file (~/.config/opencode/opencode.
39
77
 
40
78
  ---
41
79
 
80
+ ## ⚙️ Configuration
81
+
82
+ Configuration files are loaded with the following precedence (highest to lowest):
83
+
84
+ 1. **Local Config:** `<project-root>/.opencode/plan-manager.json` (project-specific settings)
85
+ 2. **User Config:** `~/.config/opencode/plan-manager.json` (global user settings)
86
+ 3. **Default Config:** Built-in defaults (used when no config files exist)
87
+
88
+ ```json
89
+ {
90
+ "outputFormat": "markdown" // "markdown" (default), "json" or "toon" (see https://github.com/toon-format/toon)
91
+ }
92
+ ```
93
+
94
+ ---
95
+
42
96
  ## 🤖 The Agentic Workflow
43
97
 
44
98
  This plugin is optimized for a dual-agent hierarchy, utilizing specialized prompts found in `src/prompts/`:
45
99
 
46
100
  1. **Plan Agent (`plan.txt`):** A high-reasoning architect that transforms vague requirements into structured, phased implementation plans.
47
- - **System Reminder:** Uses a custom `src/system/plan.txt` to inject planning rigor into the agent's core reasoning loop.
48
- - **Workflow:** Follows a 4-step process: Context Discovery → Strategy Mapping → Phase Definition → Task Breakdown.
101
+ - **Workflow:** Follows a 4-step process: Analysis Deduplication Context Decision Plan Creation.
49
102
  2. **Build Agent (`build.txt`):** An implementation specialist that executes plans with high precision.
50
103
  - **Logic:** If a plan exists, it _must_ follow it. If a task is too complex, it will suggest calling the Plan Agent first.
51
104
  - **Task Management:** Automatically handles task state transitions from `pending` to `in_progress` to `done`.
52
105
 
53
106
  > ⚠️ This plugin uses the built-in `Plan` and `Build` agents (see [https://opencode.ai/docs/agents/](https://opencode.ai/docs/agents/))
54
- > and adds custom prompts and system reminders to optimize them for the provided tools, but does not create new agent types.
107
+ > and adds custom system prompts to optimize them for the provided tools, but does not create new agent types.
108
+
109
+ > ℹ️ If you provide custom prompts for `Plan` or `Build` agents at your configuration file, this plugin will NOT inject its optimized prompts.
110
+ > Your prompts have priority over the plugin's defaults.
55
111
 
56
112
  ---
57
113
 
@@ -61,7 +117,7 @@ This plugin is optimized for a dual-agent hierarchy, utilizing specialized promp
61
117
  - 📉 **Token Optimization:** Native support for `summary` and `selective` views to keep agent context windows clean and focused.
62
118
  - 🔄 **Atomic State Transitions:** Safe folder movements (`rename()`) ensure that plan status is always in sync with the filesystem.
63
119
  - ✅ **Deterministic Task Management:** Support for three task states (`[ ]`, `[~]`, `[x]`) with batch update capabilities.
64
- - 🚀 **High Performance:** Metadata-only listing for fast scanning of 100+ plans in milliseconds.
120
+ - 🚀 **High Performance:** Metadata-only listing for fast scanning of plans.
65
121
 
66
122
  ---
67
123
 
@@ -74,8 +130,8 @@ Plan Manager organizes work into a structured directory tree that both humans an
74
130
  ├── pending/ # New ideas and upcoming features
75
131
  │ └── feature_auth/ # Each plan is a dedicated folder
76
132
  │ ├── metadata.json
77
- │ ├── spec.md
78
- │ └── plan.md
133
+ │ ├── specifications.md
134
+ │ └── implementation.md
79
135
  ├── in_progress/ # Currently active development
80
136
  └── done/ # Immutable history of completed work
81
137
  ```
@@ -90,25 +146,25 @@ Instead of loose markdown, agents use structured objects to ensure every plan ha
90
146
 
91
147
  ```typescript
92
148
  plan_create({
93
- title: "JWT Authentication",
94
- type: "feature",
95
- description: "Secure auth flow with refresh tokens",
96
- spec: {
97
- overview: "Implement secure JWT-based authentication",
98
- functionals: ["User login", "Token refresh"],
99
- nonFunctionals: ["Passwords hashed with bcrypt"],
100
- acceptanceCriterias: ["Successful login returns valid JWT"],
101
- outOfScope: ["Social OAuth"],
102
- },
103
- implementation: {
104
- description: "Phased rollout",
105
- phases: [
106
- {
107
- phase: "Phase 1: Database",
108
- tasks: ["Create users table", "Create sessions table"],
109
- },
110
- ],
111
- },
149
+ title: "JWT Authentication",
150
+ type: "feature",
151
+ description: "Secure auth flow with refresh tokens",
152
+ spec: {
153
+ overview: "Implement secure JWT-based authentication",
154
+ functionals: ["User login", "Token refresh"],
155
+ nonFunctionals: ["Passwords hashed with bcrypt"],
156
+ acceptanceCriterias: ["Successful login returns valid JWT"],
157
+ outOfScope: ["Social OAuth"],
158
+ },
159
+ implementation: {
160
+ description: "Phased rollout",
161
+ phases: [
162
+ {
163
+ phase: "Phase 1: Database",
164
+ tasks: ["Create users table", "Create sessions table"],
165
+ },
166
+ ],
167
+ },
112
168
  });
113
169
  ```
114
170
 
@@ -118,13 +174,13 @@ Agents can request only the information they need, significantly reducing token
118
174
 
119
175
  ```typescript
120
176
  // Summary View: Just the metadata and progress stats
121
- plan_read({ plan_id: "feature_auth", view: "summary" });
177
+ plan_read({ id: "feature_auth", view: "summary" });
122
178
 
123
179
  // Spec View: Just the requirements (useful for the Planner)
124
- plan_read({ plan_id: "feature_auth", view: "spec" });
180
+ plan_read({ id: "feature_auth", view: "spec" });
125
181
 
126
182
  // Plan View: Just the task list (useful for the Builder)
127
- plan_read({ plan_id: "feature_auth", view: "plan" });
183
+ plan_read({ id: "feature_auth", view: "plan" });
128
184
  ```
129
185
 
130
186
  ### 3. Batch Task Updates (`plan_update`)
@@ -133,12 +189,12 @@ Update multiple tasks or move a plan through the lifecycle with validation.
133
189
 
134
190
  ```typescript
135
191
  plan_update({
136
- plan_id: "feature_auth",
137
- status: "in_progress",
138
- taskUpdates: [
139
- { content: "Create users table", status: "done" },
140
- { content: "Create sessions table", status: "in_progress" },
141
- ],
192
+ id: "feature_auth",
193
+ status: "in_progress",
194
+ taskUpdates: [
195
+ { content: "Create users table", status: "done" },
196
+ { content: "Create sessions table", status: "in_progress" },
197
+ ],
142
198
  });
143
199
  ```
144
200