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.
- package/README.md +92 -36
- package/dist/index.js +96 -94
- 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
|
-
|
|
34
|
-
|
|
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
|
-
- **
|
|
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
|
|
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
|
|
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
|
-
│ ├──
|
|
78
|
-
│ └──
|
|
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
|
-
|
|
94
|
-
|
|
95
|
-
|
|
96
|
-
|
|
97
|
-
|
|
98
|
-
|
|
99
|
-
|
|
100
|
-
|
|
101
|
-
|
|
102
|
-
|
|
103
|
-
|
|
104
|
-
|
|
105
|
-
|
|
106
|
-
|
|
107
|
-
|
|
108
|
-
|
|
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({
|
|
177
|
+
plan_read({ id: "feature_auth", view: "summary" });
|
|
122
178
|
|
|
123
179
|
// Spec View: Just the requirements (useful for the Planner)
|
|
124
|
-
plan_read({
|
|
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({
|
|
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
|
-
|
|
137
|
-
|
|
138
|
-
|
|
139
|
-
|
|
140
|
-
|
|
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
|
|