@orderful/droid 0.50.0 → 0.51.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/CHANGELOG.md +10 -0
- package/dist/tools/brain/.claude-plugin/plugin.json +1 -1
- package/dist/tools/brain/TOOL.yaml +1 -1
- package/dist/tools/brain/skills/brain/SKILL.md +4 -0
- package/dist/tools/brain/skills/brain/references/workflows.md +21 -7
- package/dist/tools/plan/.claude-plugin/plugin.json +1 -1
- package/dist/tools/plan/TOOL.yaml +1 -1
- package/dist/tools/plan/commands/plan.md +3 -2
- package/dist/tools/plan/skills/plan/SKILL.md +31 -10
- package/dist/tools/plan/skills/plan/references/workflows.md +44 -14
- package/dist/tools/project/.claude-plugin/plugin.json +1 -1
- package/dist/tools/project/TOOL.yaml +5 -1
- package/dist/tools/project/skills/project/SKILL.md +32 -1
- package/dist/tools/project/skills/project/references/loading.md +1 -0
- package/dist/tools/project/skills/project/references/pulling.md +57 -0
- package/dist/tools/project/skills/project/references/pushing.md +79 -0
- package/package.json +1 -1
- package/src/tools/brain/.claude-plugin/plugin.json +1 -1
- package/src/tools/brain/TOOL.yaml +1 -1
- package/src/tools/brain/skills/brain/SKILL.md +4 -0
- package/src/tools/brain/skills/brain/references/workflows.md +21 -7
- package/src/tools/plan/.claude-plugin/plugin.json +1 -1
- package/src/tools/plan/TOOL.yaml +1 -1
- package/src/tools/plan/commands/plan.md +3 -2
- package/src/tools/plan/skills/plan/SKILL.md +31 -10
- package/src/tools/plan/skills/plan/references/workflows.md +44 -14
- package/src/tools/project/.claude-plugin/plugin.json +1 -1
- package/src/tools/project/TOOL.yaml +5 -1
- package/src/tools/project/skills/project/SKILL.md +32 -1
- package/src/tools/project/skills/project/references/loading.md +1 -0
- package/src/tools/project/skills/project/references/pulling.md +57 -0
- package/src/tools/project/skills/project/references/pushing.md +79 -0
package/CHANGELOG.md
CHANGED
|
@@ -1,5 +1,15 @@
|
|
|
1
1
|
# @orderful/droid
|
|
2
2
|
|
|
3
|
+
## 0.51.0
|
|
4
|
+
|
|
5
|
+
### Minor Changes
|
|
6
|
+
|
|
7
|
+
- [#315](https://github.com/Orderful/droid/pull/315) [`71ea142`](https://github.com/Orderful/droid/commit/71ea14245f3a2339a3b0e1fb3bf816df669405af) Thanks [@frytyler](https://github.com/frytyler)! - Project tool improvements: project-aware routing for plan/brain skills, `/project pull` and `/project push` for bidirectional codex sync
|
|
8
|
+
|
|
9
|
+
### Patch Changes
|
|
10
|
+
|
|
11
|
+
- [#313](https://github.com/Orderful/droid/pull/313) [`82d14c3`](https://github.com/Orderful/droid/commit/82d14c3a60f5935829d5a3cfbaf583d9a1f4329d) Thanks [@frytyler](https://github.com/frytyler)! - Plan tool improvements: plan mode review in `/plan implement` (with `--no-review` escape hatch), cleanup folded into `/plan ready`, plan mode integration guidance
|
|
12
|
+
|
|
3
13
|
## 0.50.0
|
|
4
14
|
|
|
5
15
|
### Minor Changes
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "droid-brain",
|
|
3
|
-
"version": "0.4.
|
|
3
|
+
"version": "0.4.3",
|
|
4
4
|
"description": "Your scratchpad (or brain) - a collaborative space for planning and research. Create docs with /brain plan, /brain research, or /brain review. Use @mentions for async discussion. Docs persist across sessions.",
|
|
5
5
|
"author": {
|
|
6
6
|
"name": "Orderful",
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
name: brain
|
|
2
2
|
description: "Your scratchpad (or brain) - a collaborative space for planning and research. Create docs with /brain plan, /brain research, or /brain review. Use @mentions for async discussion. Docs persist across sessions."
|
|
3
|
-
version: 0.4.
|
|
3
|
+
version: 0.4.3
|
|
4
4
|
status: beta
|
|
5
5
|
audience:
|
|
6
6
|
- all
|
|
@@ -34,6 +34,8 @@ Your **scratchpad** (or **brain**) - a collaborative space for planning, researc
|
|
|
34
34
|
| `inbox_folder` | (empty) | Root folder for new docs (e.g., `0-Inbox`) |
|
|
35
35
|
| `override` | (none) | User-defined behaviour overrides |
|
|
36
36
|
|
|
37
|
+
**Optional dependency:** `droid config --get tools.project` → `save_related_in_project` (for project-aware routing)
|
|
38
|
+
|
|
37
39
|
**If not configured:** Ask the user:
|
|
38
40
|
> "Where would you like to store brain docs? Common choices:
|
|
39
41
|
> - `~/Documents/brain` - Easy to find in Finder
|
|
@@ -107,6 +109,8 @@ Full procedure: `references/workflows.md` § Opening
|
|
|
107
109
|
|
|
108
110
|
Templates vary by category (see `references/templates.md`), but all follow the same creation flow.
|
|
109
111
|
|
|
112
|
+
**Project-aware routing:** When a `/project` is active and `save_related_in_project` is true (check `droid config --get tools.project`), ALL new docs route to `{project_folder}/{category}s/` instead of the brain inbox — no category filtering. Plans, research, ideas, thoughts, spikes, whatever the user creates. If it's related to the project, it lives with the project. Disable with `save_related_in_project: false` in project config.
|
|
113
|
+
|
|
110
114
|
**Note:** `idea` category docs do NOT become active (fire-and-forget capture).
|
|
111
115
|
|
|
112
116
|
Full procedure: `references/workflows.md` § Creating
|
|
@@ -62,13 +62,27 @@ Detailed procedures for each brain operation.
|
|
|
62
62
|
- Example: `auth-refactor.md` or `caching-strategies.md`
|
|
63
63
|
|
|
64
64
|
3. **Determine target path based on category:**
|
|
65
|
-
|
|
66
|
-
|
|
67
|
-
|
|
68
|
-
|
|
69
|
-
|
|
70
|
-
|
|
71
|
-
|
|
65
|
+
|
|
66
|
+
a. **Check for active project:**
|
|
67
|
+
- If `/project` is active in session AND `save_related_in_project` is true
|
|
68
|
+
(run `droid config --get tools.project` to check):
|
|
69
|
+
- Route ALL categories to project folder: `{projects_dir}/{project}/{category}s/{filename}`
|
|
70
|
+
- No category filtering — plans, research, ideas, thoughts, spikes, anything goes
|
|
71
|
+
- Example: `/brain research caching` with project "droid" active
|
|
72
|
+
→ `{projects_dir}/droid/research/caching.md`
|
|
73
|
+
- Example: `/brain idea wild-thought` with project "droid" active
|
|
74
|
+
→ `{projects_dir}/droid/ideas/wild-thought.md`
|
|
75
|
+
- If `/project` active but `save_related_in_project` is false (default), OR no project active:
|
|
76
|
+
- Fall through to default routing below
|
|
77
|
+
|
|
78
|
+
b. **Default routing (no active project or opt-out):**
|
|
79
|
+
- Base: `{brain_dir}/{inbox_folder}` (or just `{brain_dir}` if no inbox_folder)
|
|
80
|
+
- Category becomes plural folder: `{base}/{category}s/{filename}`
|
|
81
|
+
- Examples:
|
|
82
|
+
- `plan` → `{base}/plans/{filename}`
|
|
83
|
+
- `research` → `{base}/research/{filename}`
|
|
84
|
+
- `spike` → `{base}/spikes/{filename}`
|
|
85
|
+
- `meeting` → `{base}/meetings/{filename}`
|
|
72
86
|
|
|
73
87
|
4. **Create directory** if needed (category folder may not exist yet)
|
|
74
88
|
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "droid-plan",
|
|
3
|
-
"version": "0.1.
|
|
3
|
+
"version": "0.1.8",
|
|
4
4
|
"description": "Task-scoped planning with portable, structured plans. Use when planning implementation for a PR, ticket, or small feature. User prompts like 'let's plan this', 'can we start a plan', 'think through the implementation'.",
|
|
5
5
|
"author": {
|
|
6
6
|
"name": "Orderful",
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
name: plan
|
|
2
2
|
description: "Task-scoped planning with portable, structured plans. Use when planning implementation for a PR, ticket, or small feature. User prompts like 'let's plan this', 'can we start a plan', 'think through the implementation'."
|
|
3
|
-
version: 0.1.
|
|
3
|
+
version: 0.1.8
|
|
4
4
|
status: alpha
|
|
5
5
|
audience:
|
|
6
6
|
- engineering
|
|
@@ -19,7 +19,7 @@ argument-hint: "new|search|check|cleanup|ready|implement [topic]"
|
|
|
19
19
|
| `/plan check` | Address @droid comments |
|
|
20
20
|
| `/plan cleanup` | Resolve threads, log decisions |
|
|
21
21
|
| `/plan ready` | Finalize and validate |
|
|
22
|
-
| `/plan implement` |
|
|
22
|
+
| `/plan implement` | Review plan, then execute |
|
|
23
23
|
|
|
24
24
|
## Examples
|
|
25
25
|
|
|
@@ -29,7 +29,8 @@ argument-hint: "new|search|check|cleanup|ready|implement [topic]"
|
|
|
29
29
|
/plan check # Address open comments
|
|
30
30
|
/plan cleanup # Resolve threads, log decisions
|
|
31
31
|
/plan ready # Mark plan as ready
|
|
32
|
-
/plan implement #
|
|
32
|
+
/plan implement # Review plan, then execute
|
|
33
|
+
/plan implement --no-review # Skip review, execute directly
|
|
33
34
|
```
|
|
34
35
|
|
|
35
36
|
See the **plan skill** for complete documentation.
|
|
@@ -27,6 +27,7 @@ Task-scoped planning for PRs, tickets, and small features. Lighter than `/tech-d
|
|
|
27
27
|
Uses config from dependencies:
|
|
28
28
|
- `droid config --get tools.brain` → `brain_dir`, `inbox_folder`
|
|
29
29
|
- `droid config --get user_mention` → `user_mention` (global config)
|
|
30
|
+
- `droid config --get tools.project` → `save_related_in_project` (optional, for project-aware routing)
|
|
30
31
|
|
|
31
32
|
**Overrides:** This skill supports user-defined overrides. See `/droid` skill § Skill Overrides.
|
|
32
33
|
|
|
@@ -45,7 +46,7 @@ Example: `/plan new auth-refactor -- we must stay backward compatible with v1 cl
|
|
|
45
46
|
| `/plan check` | Address `@droid` comments, respond to questions |
|
|
46
47
|
| `/plan cleanup` | Resolve threads, apply changes, log decisions |
|
|
47
48
|
| `/plan ready` | Finalize: validate and update status |
|
|
48
|
-
| `/plan implement` |
|
|
49
|
+
| `/plan implement` | Review plan, then execute tasks |
|
|
49
50
|
|
|
50
51
|
## `/plan new {topic}`
|
|
51
52
|
|
|
@@ -54,7 +55,8 @@ Example: `/plan new auth-refactor -- we must stay backward compatible with v1 cl
|
|
|
54
55
|
- Run `droid config --get user_mention` for user's mention tag
|
|
55
56
|
- If `brain_dir` not configured, ask user where to store plans
|
|
56
57
|
2. Determine location:
|
|
57
|
-
- If `/project` active →
|
|
58
|
+
- If `/project` active AND `save_related_in_project` is true (check `droid config --get tools.project`) → use `{projects_dir}/{project}/plans/` (no prompt)
|
|
59
|
+
- If `/project` active AND `save_related_in_project` is false (default) → offer choice between project folder and inbox
|
|
58
60
|
- Otherwise → `{brain_dir}/{inbox_folder}/plans/`
|
|
59
61
|
3. Offer context loading (`/project`, `/codex` search)
|
|
60
62
|
4. Ask clarifying questions (goal, scope, constraints)
|
|
@@ -90,21 +92,26 @@ See `references/workflows.md` § Cleanup for the full graduation pattern.
|
|
|
90
92
|
|
|
91
93
|
## `/plan ready`
|
|
92
94
|
|
|
93
|
-
1.
|
|
94
|
-
2.
|
|
95
|
-
3.
|
|
96
|
-
4.
|
|
95
|
+
1. **Run cleanup pass** — graduate resolved threads to decisions, archive (same as `/plan cleanup`)
|
|
96
|
+
2. Check for unresolved discussions (warn if any)
|
|
97
|
+
3. Validate required sections (Context, at least one Task)
|
|
98
|
+
4. Update status to `ready`
|
|
99
|
+
5. Offer: stay in brain, copy to PR description, link in project
|
|
97
100
|
|
|
98
101
|
## `/plan implement`
|
|
99
102
|
|
|
100
|
-
1.
|
|
101
|
-
2.
|
|
102
|
-
3.
|
|
103
|
+
1. Load plan (warn if status is not `ready`)
|
|
104
|
+
2. **Review plan** — validate tasks against codebase, identify gaps (uses platform plan mode if available, otherwise structured self-review)
|
|
105
|
+
3. Parse tasks from `### Task N:` sections
|
|
106
|
+
4. Optionally convert to XML (see `references/xml-conversion.md`)
|
|
107
|
+
5. For each task:
|
|
103
108
|
- Execute per `**Files:**` section
|
|
104
109
|
- Run `**Verify:**` command
|
|
105
110
|
- Check `**Done:**` criteria
|
|
106
111
|
- Mark complete in plan doc
|
|
107
|
-
|
|
112
|
+
6. Update status to `done`
|
|
113
|
+
|
|
114
|
+
Use `--no-review` to skip the review step (e.g., re-running after partial implementation).
|
|
108
115
|
|
|
109
116
|
## Comment Conventions
|
|
110
117
|
|
|
@@ -122,6 +129,20 @@ Recognise planning intent and offer `/plan new`:
|
|
|
122
129
|
- "Let's think through the implementation"
|
|
123
130
|
- "Before we start coding..."
|
|
124
131
|
|
|
132
|
+
## Plan Review Integration
|
|
133
|
+
|
|
134
|
+
Plan docs and the review step in `/plan implement` are complementary:
|
|
135
|
+
|
|
136
|
+
| Plan doc (persistent) | Review step (ephemeral) |
|
|
137
|
+
|-----------------------|-------------------------|
|
|
138
|
+
| Captures decisions and intent (*why*) | Validates against codebase (*how*) |
|
|
139
|
+
| Shareable, auditable trail | Private to the session |
|
|
140
|
+
| Survives across sessions | Scoped to current session |
|
|
141
|
+
|
|
142
|
+
**The workflow:** Write the plan doc to capture decisions. The review step validates and refines before implementing — it enriches, not duplicates.
|
|
143
|
+
|
|
144
|
+
**Platform-adaptive:** Some platforms offer a dedicated plan/review mode (e.g., Claude Code). Others get a structured self-review. The behaviour is the same — validate the plan against the codebase before executing.
|
|
145
|
+
|
|
125
146
|
## References
|
|
126
147
|
|
|
127
148
|
- `references/templates.md` - Plan doc template with examples
|
|
@@ -15,9 +15,15 @@ If brain not configured, ask user for `brain_dir` location.
|
|
|
15
15
|
|
|
16
16
|
### Step 2: Determine Location
|
|
17
17
|
|
|
18
|
-
Check if `/project` is active (check `{projects_dir}/{project}/PROJECT.md` exists)
|
|
18
|
+
Check if `/project` is active (check `{projects_dir}/{project}/PROJECT.md` exists) and read `save_related_in_project` from `droid config --get tools.project`:
|
|
19
19
|
|
|
20
|
-
**If project active:**
|
|
20
|
+
**If project active AND `save_related_in_project` is true:**
|
|
21
|
+
```
|
|
22
|
+
Use: {projects_dir}/{project}/plans/plan-{topic}.md
|
|
23
|
+
(No prompt — project folder is the default when opted in)
|
|
24
|
+
```
|
|
25
|
+
|
|
26
|
+
**If project active AND `save_related_in_project` is false (default):**
|
|
21
27
|
```
|
|
22
28
|
Offer choice via AskUserQuestion:
|
|
23
29
|
- "Project folder" → {projects_dir}/{project}/plans/plan-{topic}.md
|
|
@@ -221,13 +227,18 @@ Report what was cleaned up:
|
|
|
221
227
|
|
|
222
228
|
If no active plan, prompt to search for one.
|
|
223
229
|
|
|
224
|
-
### Step 2:
|
|
230
|
+
### Step 2: Run Cleanup Pass
|
|
225
231
|
|
|
226
|
-
|
|
232
|
+
Run the same logic as `/plan cleanup`:
|
|
233
|
+
- Find resolved `@droid` / `@{user_mention}` threads
|
|
234
|
+
- Graduate decisions to the Locked-In Decisions table
|
|
235
|
+
- Archive resolved threads to Discussion Log
|
|
227
236
|
|
|
228
|
-
|
|
229
|
-
|
|
230
|
-
|
|
237
|
+
If nothing to clean up, this is a no-op. `/plan cleanup` still exists as a standalone command for mid-iteration use.
|
|
238
|
+
|
|
239
|
+
### Step 3: Check Unresolved Discussions
|
|
240
|
+
|
|
241
|
+
Search for remaining `@droid` / `@{user_mention}` threads that weren't resolved:
|
|
231
242
|
|
|
232
243
|
If any found, warn:
|
|
233
244
|
```
|
|
@@ -236,7 +247,7 @@ If any found, warn:
|
|
|
236
247
|
- "Mark ready anyway" → Continue
|
|
237
248
|
```
|
|
238
249
|
|
|
239
|
-
### Step
|
|
250
|
+
### Step 4: Validate Required Sections
|
|
240
251
|
|
|
241
252
|
Check for:
|
|
242
253
|
- `## Context` section with content
|
|
@@ -244,11 +255,11 @@ Check for:
|
|
|
244
255
|
|
|
245
256
|
If missing, warn and list what's needed.
|
|
246
257
|
|
|
247
|
-
### Step
|
|
258
|
+
### Step 5: Update Status
|
|
248
259
|
|
|
249
260
|
Change `**Status:** draft` or `**Status:** in-progress` to `**Status:** ready`
|
|
250
261
|
|
|
251
|
-
### Step
|
|
262
|
+
### Step 6: Offer Distribution
|
|
252
263
|
|
|
253
264
|
Ask via AskUserQuestion:
|
|
254
265
|
```
|
|
@@ -271,7 +282,26 @@ Check status - warn if not `ready`:
|
|
|
271
282
|
"This plan is still '{status}'. Implement anyway?"
|
|
272
283
|
```
|
|
273
284
|
|
|
274
|
-
### Step 2:
|
|
285
|
+
### Step 2: Plan Review
|
|
286
|
+
|
|
287
|
+
**Default behaviour.** Skip if user passes `--no-review` (or says "skip review", "just implement").
|
|
288
|
+
|
|
289
|
+
Review the plan against the codebase before executing:
|
|
290
|
+
|
|
291
|
+
1. **Read each task's `**Files:**` section** — verify referenced files and patterns exist in the codebase
|
|
292
|
+
2. **Check for gaps** — missing files, outdated patterns, unaccounted dependencies between tasks
|
|
293
|
+
3. **Validate `**Verify:**` commands** — confirm they're runnable
|
|
294
|
+
4. **Note concerns or refinements** — anything that needs adjusting before execution
|
|
295
|
+
|
|
296
|
+
If the platform supports a dedicated plan/review mode, use it for this step. Otherwise, perform the review inline as a structured self-review before proceeding.
|
|
297
|
+
|
|
298
|
+
**Plan preservation:** If the review produces material refinements, save the revised plan as `{original-name}-implementation.md` alongside the original. The original plan is **never modified** during review — it's the decision record. The implementation variant includes `Parent plan: [[{original-name}]]` at the top.
|
|
299
|
+
|
|
300
|
+
After review, implementation executes from whichever plan came out of this step:
|
|
301
|
+
- No material changes → execute from the original
|
|
302
|
+
- Revised plan produced → execute from the `-implementation` variant
|
|
303
|
+
|
|
304
|
+
### Step 3: Parse Tasks
|
|
275
305
|
|
|
276
306
|
Find all `### Task N:` sections. For each, extract:
|
|
277
307
|
- **Name** from header
|
|
@@ -280,7 +310,7 @@ Find all `### Task N:` sections. For each, extract:
|
|
|
280
310
|
- **Verify** from `**Verify:**` line
|
|
281
311
|
- **Done** from `**Done:**` line
|
|
282
312
|
|
|
283
|
-
### Step
|
|
313
|
+
### Step 4: Optional XML Conversion
|
|
284
314
|
|
|
285
315
|
For complex multi-task plans, offer:
|
|
286
316
|
```
|
|
@@ -289,7 +319,7 @@ For complex multi-task plans, offer:
|
|
|
289
319
|
- "No" → Use markdown as-is
|
|
290
320
|
```
|
|
291
321
|
|
|
292
|
-
### Step
|
|
322
|
+
### Step 5: Execute Tasks
|
|
293
323
|
|
|
294
324
|
For each task in order:
|
|
295
325
|
|
|
@@ -308,7 +338,7 @@ If verification fails:
|
|
|
308
338
|
- "Stop implementation"
|
|
309
339
|
```
|
|
310
340
|
|
|
311
|
-
### Step
|
|
341
|
+
### Step 6: Update Status
|
|
312
342
|
|
|
313
343
|
When all tasks complete, change `**Status:** ready` to `**Status:** done`
|
|
314
344
|
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "droid-project",
|
|
3
|
-
"version": "0.
|
|
3
|
+
"version": "0.5.0",
|
|
4
4
|
"description": "Manage project context files for persistent AI memory across sessions. Load, update, or create project context before working on multi-session features.",
|
|
5
5
|
"author": {
|
|
6
6
|
"name": "Orderful",
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
name: project
|
|
2
2
|
description: "Manage project context files for persistent AI memory across sessions. Load, update, or create project context before working on multi-session features."
|
|
3
|
-
version: 0.
|
|
3
|
+
version: 0.5.0
|
|
4
4
|
status: beta
|
|
5
5
|
audience:
|
|
6
6
|
- all
|
|
@@ -21,6 +21,10 @@ config_schema:
|
|
|
21
21
|
type: string
|
|
22
22
|
description: Path to projects directory (required - no default)
|
|
23
23
|
required: true
|
|
24
|
+
save_related_in_project:
|
|
25
|
+
type: boolean
|
|
26
|
+
description: "When true, plan/brain skills default to saving artifacts under the active project folder"
|
|
27
|
+
default: false
|
|
24
28
|
preset:
|
|
25
29
|
type: select
|
|
26
30
|
description: "Link style: obsidian uses [[wikilinks]], markdown uses [standard](links)"
|
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: project
|
|
3
3
|
description: "Persistent project context for AI memory across sessions. Use when working on multi-session features, refactors, or any work that benefits from accumulated context. User prompts like 'load the project', 'update project context', 'what's the current project?'."
|
|
4
|
-
argument-hint: "[{keywords} | update | create {name}]"
|
|
4
|
+
argument-hint: "[search {keywords} | update | create {name} | pull [codex:{name}] | push [codex:{name}]]"
|
|
5
5
|
allowed-tools: [Read, Write, Glob, Grep, Bash]
|
|
6
6
|
---
|
|
7
7
|
|
|
@@ -32,6 +32,7 @@ Chat history disappears. Projects persist.
|
|
|
32
32
|
| -------------- | ------------ | -------------------------------------------------- |
|
|
33
33
|
| `projects_dir` | **required** | Where projects are stored (must be configured) |
|
|
34
34
|
| `preset` | `markdown` | Link style: `obsidian` uses `[[wikilinks]]`, `markdown` uses `[standard](links)` |
|
|
35
|
+
| `save_related_in_project` | `false` | When true, plan/brain skills default to saving artifacts under the active project folder instead of the brain inbox |
|
|
35
36
|
| `override` | (none) | User-defined behaviour overrides |
|
|
36
37
|
|
|
37
38
|
**Overrides:** This skill supports user-defined overrides. See `/droid` skill § Skill Overrides.
|
|
@@ -58,9 +59,17 @@ echo "projects_dir: /path/to/projects" >> ~/.droid/skills/project/overrides.yaml
|
|
|
58
59
|
| `/project create {name}` | Create new project (requires `create` keyword) |
|
|
59
60
|
| `/project create --from codex:{name}` | Create project seeded with codex context |
|
|
60
61
|
| `/project update` | Update from conversation context |
|
|
62
|
+
| `/project pull [codex:{name}]` | Pull codex updates into existing project |
|
|
63
|
+
| `/project push [codex:{name}]` | Push team-relevant content to codex via PR |
|
|
61
64
|
|
|
62
65
|
**IMPORTANT:** Use `/project search {keywords}` to find and load existing projects. Only use `/project create {name}` when the user explicitly wants to create a new project.
|
|
63
66
|
|
|
67
|
+
## PROJECT.md Frontmatter
|
|
68
|
+
|
|
69
|
+
| Field | Purpose |
|
|
70
|
+
| ---------------- | -------------------------------------------------------------------- |
|
|
71
|
+
| `codex_project` | Codex project name for pull/push (set on first use, remembered) |
|
|
72
|
+
|
|
64
73
|
## Loading a Project
|
|
65
74
|
|
|
66
75
|
**Trigger:** `/project search {keywords}` or user asks to load/open a project
|
|
@@ -86,6 +95,28 @@ Full procedure: `references/updating.md`
|
|
|
86
95
|
Version rules: `references/versioning.md`
|
|
87
96
|
Changelog format: `references/changelog.md`
|
|
88
97
|
|
|
98
|
+
## Pulling from Codex
|
|
99
|
+
|
|
100
|
+
**Trigger:** `/project pull [codex:{name}]`
|
|
101
|
+
|
|
102
|
+
**TLDR:** Read codex project docs, diff against current PROJECT.md, propose only critical updates that fit within context limits, apply with changelog entry.
|
|
103
|
+
|
|
104
|
+
First use: `/project pull codex:transaction-templates` — saves `codex_project` to frontmatter.
|
|
105
|
+
Subsequent: `/project pull` — reads from frontmatter.
|
|
106
|
+
|
|
107
|
+
Full procedure: `references/pulling.md`
|
|
108
|
+
|
|
109
|
+
## Pushing to Codex
|
|
110
|
+
|
|
111
|
+
**Trigger:** `/project push` or user asks to push learnings to codex
|
|
112
|
+
|
|
113
|
+
**TLDR:** Extract team-relevant decisions, patterns, and architecture updates from PROJECT.md. Propose codex updates via PR.
|
|
114
|
+
|
|
115
|
+
First use: `/project push codex:transaction-templates` — saves `codex_project` to frontmatter.
|
|
116
|
+
Subsequent: `/project push` — reads from frontmatter. Either push or pull can set it first.
|
|
117
|
+
|
|
118
|
+
Full procedure: `references/pushing.md`
|
|
119
|
+
|
|
89
120
|
## Creating a Project
|
|
90
121
|
|
|
91
122
|
**Trigger:** `/project create {name?}` or user asks to start a new project
|
|
@@ -34,6 +34,7 @@
|
|
|
34
34
|
- Use project contents for all subsequent work in the session
|
|
35
35
|
- **Do NOT read companion docs by default** — CHANGELOG.md, DECISIONS.md, and WORKLOG.md exist for on-demand lookup only. PROJECT.md already references them; that is enough context.
|
|
36
36
|
- If the user asks about decisions, past work, or history, THEN read the relevant companion doc.
|
|
37
|
+
- **Cross-skill routing:** When `save_related_in_project` is true (check `droid config --get tools.project`), signal to the session that related artifacts (plans, research, ideas) should default to `{project_folder}/plans/`, `{project_folder}/research/`, etc. Other skills (plan, brain) check for an active project and route accordingly.
|
|
37
38
|
|
|
38
39
|
7. **If `-- {instruction}` provided:** Execute the follow-up instruction against the loaded project
|
|
39
40
|
|
|
@@ -0,0 +1,57 @@
|
|
|
1
|
+
# Pulling from Codex
|
|
2
|
+
|
|
3
|
+
**Trigger:** `/project pull [codex:{name}]`
|
|
4
|
+
|
|
5
|
+
Pull shared organizational context into an existing local project.
|
|
6
|
+
|
|
7
|
+
## Procedure
|
|
8
|
+
|
|
9
|
+
1. **Resolve codex project name:**
|
|
10
|
+
- If `codex:{name}` provided → use it, save to PROJECT.md frontmatter as `codex_project: {name}`
|
|
11
|
+
- If not provided → read `codex_project` from PROJECT.md frontmatter
|
|
12
|
+
- If neither → ask user
|
|
13
|
+
|
|
14
|
+
2. **Identify the local project:**
|
|
15
|
+
- If in a loaded project session → use that project
|
|
16
|
+
- If no project loaded → search and load first (same as `/project search`)
|
|
17
|
+
|
|
18
|
+
3. **Load codex entry:**
|
|
19
|
+
- Run `droid config --get tools.codex` and get `codex_repo` from the JSON output
|
|
20
|
+
- Sync: `git -C {codex_repo} pull --rebase --quiet`
|
|
21
|
+
- Locate `{codex_repo}/projects/{name}/`
|
|
22
|
+
- If not found → error with suggestions from available codex projects
|
|
23
|
+
|
|
24
|
+
4. **Read codex documents:**
|
|
25
|
+
- PRD.md → goals, requirements, status
|
|
26
|
+
- TECH-DESIGN.md → architecture, patterns, key paths
|
|
27
|
+
- DECISIONS.md → recent decisions
|
|
28
|
+
- Any other docs in the codex project folder
|
|
29
|
+
|
|
30
|
+
5. **Read current PROJECT.md** and identify:
|
|
31
|
+
- Sections that overlap with codex content
|
|
32
|
+
- Codex content that's newer or more detailed
|
|
33
|
+
- Local content that has no codex equivalent (leave untouched)
|
|
34
|
+
|
|
35
|
+
6. **Propose updates** (never auto-apply):
|
|
36
|
+
- **Be highly selective** — PROJECT.md has context limits. Only propose content that is critical for the AI to have when working on this project.
|
|
37
|
+
- Categorise: "New from codex", "Updated in codex", "No change needed"
|
|
38
|
+
- Preserve local implementation details — codex updates should ADD context, not overwrite working notes
|
|
39
|
+
- Prefer links to codex over copying large sections
|
|
40
|
+
|
|
41
|
+
7. **After approval:**
|
|
42
|
+
- Apply approved changes
|
|
43
|
+
- Update frontmatter: `codex_project: {name}`
|
|
44
|
+
- Add `## Codex Sync` entry or update existing one:
|
|
45
|
+
```
|
|
46
|
+
**Last pulled:** {date} from codex:{name}
|
|
47
|
+
```
|
|
48
|
+
- Determine version bump (patch for context updates, minor if goals/scope changed)
|
|
49
|
+
- Add changelog entry noting codex pull
|
|
50
|
+
|
|
51
|
+
## Key Principles
|
|
52
|
+
|
|
53
|
+
- **Selective, not exhaustive** — only pull what's critical for project context. The project file has size limits.
|
|
54
|
+
- **Additive, not destructive** — codex updates enrich the local project, they don't replace local work
|
|
55
|
+
- **User reviews every change** — always propose, never auto-apply
|
|
56
|
+
- **Provenance tracked** — changelog and sync date show where context came from
|
|
57
|
+
- **Links over copies** — for large sections, link to codex rather than duplicating
|
|
@@ -0,0 +1,79 @@
|
|
|
1
|
+
# Pushing to Codex
|
|
2
|
+
|
|
3
|
+
**Trigger:** `/project push [codex:{name}]`
|
|
4
|
+
|
|
5
|
+
Push team-relevant content from a local project back to the shared codex.
|
|
6
|
+
|
|
7
|
+
## What Gets Shared
|
|
8
|
+
|
|
9
|
+
Not everything in a project is codex-worthy. Extract only team-relevant content:
|
|
10
|
+
|
|
11
|
+
| Share | Don't Share |
|
|
12
|
+
|-------|-------------|
|
|
13
|
+
| Architecture decisions with rationale | Personal work notes |
|
|
14
|
+
| New patterns discovered during implementation | In-progress tasks |
|
|
15
|
+
| Updated technical constraints | Session logs or worklogs |
|
|
16
|
+
| Status changes (shipped, blocked, pivoted) | Brain docs or research drafts |
|
|
17
|
+
| Key file paths or API changes | Local configuration |
|
|
18
|
+
|
|
19
|
+
## Procedure
|
|
20
|
+
|
|
21
|
+
1. **Resolve codex project name:**
|
|
22
|
+
- If `codex:{name}` provided → use it, save to PROJECT.md frontmatter as `codex_project: {name}`
|
|
23
|
+
- If not provided → read `codex_project` from PROJECT.md frontmatter
|
|
24
|
+
- If neither → ask user which codex project to update, save to frontmatter
|
|
25
|
+
- Codex project must already exist. If it doesn't, suggest `/codex new project {name}` first.
|
|
26
|
+
|
|
27
|
+
2. **Identify the local project:**
|
|
28
|
+
- If in a loaded project session → use that project
|
|
29
|
+
- If no project loaded → search and load first
|
|
30
|
+
|
|
31
|
+
3. **Read PROJECT.md** and companion docs (DECISIONS.md, WORKLOG.md if they exist)
|
|
32
|
+
|
|
33
|
+
4. **Load codex entry:**
|
|
34
|
+
- Run `droid config --get tools.codex` and get `codex_repo` from the JSON output
|
|
35
|
+
- Sync: `git -C {codex_repo} pull --rebase --quiet`
|
|
36
|
+
- Read existing codex project docs
|
|
37
|
+
|
|
38
|
+
5. **Extract and categorise shareable content:**
|
|
39
|
+
- **Decisions:** New entries from DECISIONS.md or inline decisions in PROJECT.md
|
|
40
|
+
- **Architecture:** Changes to technical approach, new patterns, updated diagrams
|
|
41
|
+
- **Status:** Phase changes, milestones hit, scope changes
|
|
42
|
+
- **Constraints:** Newly discovered technical constraints or gotchas
|
|
43
|
+
|
|
44
|
+
6. **Propose codex updates** (never auto-apply):
|
|
45
|
+
- For each item, show:
|
|
46
|
+
- What will be added/changed in codex
|
|
47
|
+
- Which codex file it targets (DECISIONS.md, TECH-DESIGN.md, PRD.md)
|
|
48
|
+
- A diff preview
|
|
49
|
+
- Let user accept, reject, or edit each item
|
|
50
|
+
|
|
51
|
+
7. **After approval:**
|
|
52
|
+
- Use codex git scripts for the write operation:
|
|
53
|
+
```bash
|
|
54
|
+
# Start write
|
|
55
|
+
droid config --get tools.codex | droid exec codex git-start-write --config - \
|
|
56
|
+
--branch codex/sync-{project-name}
|
|
57
|
+
|
|
58
|
+
# Make changes to codex files
|
|
59
|
+
|
|
60
|
+
# Normalize frontmatter
|
|
61
|
+
droid config --get tools.codex | droid exec codex normalize-frontmatter --config -
|
|
62
|
+
|
|
63
|
+
# Finish write (commit + PR)
|
|
64
|
+
droid config --get tools.codex | droid exec codex git-finish-write --config - \
|
|
65
|
+
--message "sync({project}): {summary}" \
|
|
66
|
+
--pr-title "sync({project}): Update from local project" \
|
|
67
|
+
--pr-body "{description of changes}"
|
|
68
|
+
```
|
|
69
|
+
- Update local PROJECT.md sync marker:
|
|
70
|
+
```
|
|
71
|
+
**Last pushed:** {date} to codex:{name}
|
|
72
|
+
```
|
|
73
|
+
|
|
74
|
+
## Key Principles
|
|
75
|
+
|
|
76
|
+
- **Curated, not automated** — user explicitly reviews what gets shared
|
|
77
|
+
- **PR-based** — codex changes go through PR review, not direct commits
|
|
78
|
+
- **Additive** — adds to codex content, doesn't overwrite others' contributions
|
|
79
|
+
- **Idempotent** — running `/project push` twice proposes only new/changed content
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "droid-brain",
|
|
3
|
-
"version": "0.4.
|
|
3
|
+
"version": "0.4.3",
|
|
4
4
|
"description": "Your scratchpad (or brain) - a collaborative space for planning and research. Create docs with /brain plan, /brain research, or /brain review. Use @mentions for async discussion. Docs persist across sessions.",
|
|
5
5
|
"author": {
|
|
6
6
|
"name": "Orderful",
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
name: brain
|
|
2
2
|
description: "Your scratchpad (or brain) - a collaborative space for planning and research. Create docs with /brain plan, /brain research, or /brain review. Use @mentions for async discussion. Docs persist across sessions."
|
|
3
|
-
version: 0.4.
|
|
3
|
+
version: 0.4.3
|
|
4
4
|
status: beta
|
|
5
5
|
audience:
|
|
6
6
|
- all
|
|
@@ -34,6 +34,8 @@ Your **scratchpad** (or **brain**) - a collaborative space for planning, researc
|
|
|
34
34
|
| `inbox_folder` | (empty) | Root folder for new docs (e.g., `0-Inbox`) |
|
|
35
35
|
| `override` | (none) | User-defined behaviour overrides |
|
|
36
36
|
|
|
37
|
+
**Optional dependency:** `droid config --get tools.project` → `save_related_in_project` (for project-aware routing)
|
|
38
|
+
|
|
37
39
|
**If not configured:** Ask the user:
|
|
38
40
|
> "Where would you like to store brain docs? Common choices:
|
|
39
41
|
> - `~/Documents/brain` - Easy to find in Finder
|
|
@@ -107,6 +109,8 @@ Full procedure: `references/workflows.md` § Opening
|
|
|
107
109
|
|
|
108
110
|
Templates vary by category (see `references/templates.md`), but all follow the same creation flow.
|
|
109
111
|
|
|
112
|
+
**Project-aware routing:** When a `/project` is active and `save_related_in_project` is true (check `droid config --get tools.project`), ALL new docs route to `{project_folder}/{category}s/` instead of the brain inbox — no category filtering. Plans, research, ideas, thoughts, spikes, whatever the user creates. If it's related to the project, it lives with the project. Disable with `save_related_in_project: false` in project config.
|
|
113
|
+
|
|
110
114
|
**Note:** `idea` category docs do NOT become active (fire-and-forget capture).
|
|
111
115
|
|
|
112
116
|
Full procedure: `references/workflows.md` § Creating
|
|
@@ -62,13 +62,27 @@ Detailed procedures for each brain operation.
|
|
|
62
62
|
- Example: `auth-refactor.md` or `caching-strategies.md`
|
|
63
63
|
|
|
64
64
|
3. **Determine target path based on category:**
|
|
65
|
-
|
|
66
|
-
|
|
67
|
-
|
|
68
|
-
|
|
69
|
-
|
|
70
|
-
|
|
71
|
-
|
|
65
|
+
|
|
66
|
+
a. **Check for active project:**
|
|
67
|
+
- If `/project` is active in session AND `save_related_in_project` is true
|
|
68
|
+
(run `droid config --get tools.project` to check):
|
|
69
|
+
- Route ALL categories to project folder: `{projects_dir}/{project}/{category}s/{filename}`
|
|
70
|
+
- No category filtering — plans, research, ideas, thoughts, spikes, anything goes
|
|
71
|
+
- Example: `/brain research caching` with project "droid" active
|
|
72
|
+
→ `{projects_dir}/droid/research/caching.md`
|
|
73
|
+
- Example: `/brain idea wild-thought` with project "droid" active
|
|
74
|
+
→ `{projects_dir}/droid/ideas/wild-thought.md`
|
|
75
|
+
- If `/project` active but `save_related_in_project` is false (default), OR no project active:
|
|
76
|
+
- Fall through to default routing below
|
|
77
|
+
|
|
78
|
+
b. **Default routing (no active project or opt-out):**
|
|
79
|
+
- Base: `{brain_dir}/{inbox_folder}` (or just `{brain_dir}` if no inbox_folder)
|
|
80
|
+
- Category becomes plural folder: `{base}/{category}s/{filename}`
|
|
81
|
+
- Examples:
|
|
82
|
+
- `plan` → `{base}/plans/{filename}`
|
|
83
|
+
- `research` → `{base}/research/{filename}`
|
|
84
|
+
- `spike` → `{base}/spikes/{filename}`
|
|
85
|
+
- `meeting` → `{base}/meetings/{filename}`
|
|
72
86
|
|
|
73
87
|
4. **Create directory** if needed (category folder may not exist yet)
|
|
74
88
|
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "droid-plan",
|
|
3
|
-
"version": "0.1.
|
|
3
|
+
"version": "0.1.8",
|
|
4
4
|
"description": "Task-scoped planning with portable, structured plans. Use when planning implementation for a PR, ticket, or small feature. User prompts like 'let's plan this', 'can we start a plan', 'think through the implementation'.",
|
|
5
5
|
"author": {
|
|
6
6
|
"name": "Orderful",
|
package/src/tools/plan/TOOL.yaml
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
name: plan
|
|
2
2
|
description: "Task-scoped planning with portable, structured plans. Use when planning implementation for a PR, ticket, or small feature. User prompts like 'let's plan this', 'can we start a plan', 'think through the implementation'."
|
|
3
|
-
version: 0.1.
|
|
3
|
+
version: 0.1.8
|
|
4
4
|
status: alpha
|
|
5
5
|
audience:
|
|
6
6
|
- engineering
|
|
@@ -19,7 +19,7 @@ argument-hint: "new|search|check|cleanup|ready|implement [topic]"
|
|
|
19
19
|
| `/plan check` | Address @droid comments |
|
|
20
20
|
| `/plan cleanup` | Resolve threads, log decisions |
|
|
21
21
|
| `/plan ready` | Finalize and validate |
|
|
22
|
-
| `/plan implement` |
|
|
22
|
+
| `/plan implement` | Review plan, then execute |
|
|
23
23
|
|
|
24
24
|
## Examples
|
|
25
25
|
|
|
@@ -29,7 +29,8 @@ argument-hint: "new|search|check|cleanup|ready|implement [topic]"
|
|
|
29
29
|
/plan check # Address open comments
|
|
30
30
|
/plan cleanup # Resolve threads, log decisions
|
|
31
31
|
/plan ready # Mark plan as ready
|
|
32
|
-
/plan implement #
|
|
32
|
+
/plan implement # Review plan, then execute
|
|
33
|
+
/plan implement --no-review # Skip review, execute directly
|
|
33
34
|
```
|
|
34
35
|
|
|
35
36
|
See the **plan skill** for complete documentation.
|
|
@@ -27,6 +27,7 @@ Task-scoped planning for PRs, tickets, and small features. Lighter than `/tech-d
|
|
|
27
27
|
Uses config from dependencies:
|
|
28
28
|
- `droid config --get tools.brain` → `brain_dir`, `inbox_folder`
|
|
29
29
|
- `droid config --get user_mention` → `user_mention` (global config)
|
|
30
|
+
- `droid config --get tools.project` → `save_related_in_project` (optional, for project-aware routing)
|
|
30
31
|
|
|
31
32
|
**Overrides:** This skill supports user-defined overrides. See `/droid` skill § Skill Overrides.
|
|
32
33
|
|
|
@@ -45,7 +46,7 @@ Example: `/plan new auth-refactor -- we must stay backward compatible with v1 cl
|
|
|
45
46
|
| `/plan check` | Address `@droid` comments, respond to questions |
|
|
46
47
|
| `/plan cleanup` | Resolve threads, apply changes, log decisions |
|
|
47
48
|
| `/plan ready` | Finalize: validate and update status |
|
|
48
|
-
| `/plan implement` |
|
|
49
|
+
| `/plan implement` | Review plan, then execute tasks |
|
|
49
50
|
|
|
50
51
|
## `/plan new {topic}`
|
|
51
52
|
|
|
@@ -54,7 +55,8 @@ Example: `/plan new auth-refactor -- we must stay backward compatible with v1 cl
|
|
|
54
55
|
- Run `droid config --get user_mention` for user's mention tag
|
|
55
56
|
- If `brain_dir` not configured, ask user where to store plans
|
|
56
57
|
2. Determine location:
|
|
57
|
-
- If `/project` active →
|
|
58
|
+
- If `/project` active AND `save_related_in_project` is true (check `droid config --get tools.project`) → use `{projects_dir}/{project}/plans/` (no prompt)
|
|
59
|
+
- If `/project` active AND `save_related_in_project` is false (default) → offer choice between project folder and inbox
|
|
58
60
|
- Otherwise → `{brain_dir}/{inbox_folder}/plans/`
|
|
59
61
|
3. Offer context loading (`/project`, `/codex` search)
|
|
60
62
|
4. Ask clarifying questions (goal, scope, constraints)
|
|
@@ -90,21 +92,26 @@ See `references/workflows.md` § Cleanup for the full graduation pattern.
|
|
|
90
92
|
|
|
91
93
|
## `/plan ready`
|
|
92
94
|
|
|
93
|
-
1.
|
|
94
|
-
2.
|
|
95
|
-
3.
|
|
96
|
-
4.
|
|
95
|
+
1. **Run cleanup pass** — graduate resolved threads to decisions, archive (same as `/plan cleanup`)
|
|
96
|
+
2. Check for unresolved discussions (warn if any)
|
|
97
|
+
3. Validate required sections (Context, at least one Task)
|
|
98
|
+
4. Update status to `ready`
|
|
99
|
+
5. Offer: stay in brain, copy to PR description, link in project
|
|
97
100
|
|
|
98
101
|
## `/plan implement`
|
|
99
102
|
|
|
100
|
-
1.
|
|
101
|
-
2.
|
|
102
|
-
3.
|
|
103
|
+
1. Load plan (warn if status is not `ready`)
|
|
104
|
+
2. **Review plan** — validate tasks against codebase, identify gaps (uses platform plan mode if available, otherwise structured self-review)
|
|
105
|
+
3. Parse tasks from `### Task N:` sections
|
|
106
|
+
4. Optionally convert to XML (see `references/xml-conversion.md`)
|
|
107
|
+
5. For each task:
|
|
103
108
|
- Execute per `**Files:**` section
|
|
104
109
|
- Run `**Verify:**` command
|
|
105
110
|
- Check `**Done:**` criteria
|
|
106
111
|
- Mark complete in plan doc
|
|
107
|
-
|
|
112
|
+
6. Update status to `done`
|
|
113
|
+
|
|
114
|
+
Use `--no-review` to skip the review step (e.g., re-running after partial implementation).
|
|
108
115
|
|
|
109
116
|
## Comment Conventions
|
|
110
117
|
|
|
@@ -122,6 +129,20 @@ Recognise planning intent and offer `/plan new`:
|
|
|
122
129
|
- "Let's think through the implementation"
|
|
123
130
|
- "Before we start coding..."
|
|
124
131
|
|
|
132
|
+
## Plan Review Integration
|
|
133
|
+
|
|
134
|
+
Plan docs and the review step in `/plan implement` are complementary:
|
|
135
|
+
|
|
136
|
+
| Plan doc (persistent) | Review step (ephemeral) |
|
|
137
|
+
|-----------------------|-------------------------|
|
|
138
|
+
| Captures decisions and intent (*why*) | Validates against codebase (*how*) |
|
|
139
|
+
| Shareable, auditable trail | Private to the session |
|
|
140
|
+
| Survives across sessions | Scoped to current session |
|
|
141
|
+
|
|
142
|
+
**The workflow:** Write the plan doc to capture decisions. The review step validates and refines before implementing — it enriches, not duplicates.
|
|
143
|
+
|
|
144
|
+
**Platform-adaptive:** Some platforms offer a dedicated plan/review mode (e.g., Claude Code). Others get a structured self-review. The behaviour is the same — validate the plan against the codebase before executing.
|
|
145
|
+
|
|
125
146
|
## References
|
|
126
147
|
|
|
127
148
|
- `references/templates.md` - Plan doc template with examples
|
|
@@ -15,9 +15,15 @@ If brain not configured, ask user for `brain_dir` location.
|
|
|
15
15
|
|
|
16
16
|
### Step 2: Determine Location
|
|
17
17
|
|
|
18
|
-
Check if `/project` is active (check `{projects_dir}/{project}/PROJECT.md` exists)
|
|
18
|
+
Check if `/project` is active (check `{projects_dir}/{project}/PROJECT.md` exists) and read `save_related_in_project` from `droid config --get tools.project`:
|
|
19
19
|
|
|
20
|
-
**If project active:**
|
|
20
|
+
**If project active AND `save_related_in_project` is true:**
|
|
21
|
+
```
|
|
22
|
+
Use: {projects_dir}/{project}/plans/plan-{topic}.md
|
|
23
|
+
(No prompt — project folder is the default when opted in)
|
|
24
|
+
```
|
|
25
|
+
|
|
26
|
+
**If project active AND `save_related_in_project` is false (default):**
|
|
21
27
|
```
|
|
22
28
|
Offer choice via AskUserQuestion:
|
|
23
29
|
- "Project folder" → {projects_dir}/{project}/plans/plan-{topic}.md
|
|
@@ -221,13 +227,18 @@ Report what was cleaned up:
|
|
|
221
227
|
|
|
222
228
|
If no active plan, prompt to search for one.
|
|
223
229
|
|
|
224
|
-
### Step 2:
|
|
230
|
+
### Step 2: Run Cleanup Pass
|
|
225
231
|
|
|
226
|
-
|
|
232
|
+
Run the same logic as `/plan cleanup`:
|
|
233
|
+
- Find resolved `@droid` / `@{user_mention}` threads
|
|
234
|
+
- Graduate decisions to the Locked-In Decisions table
|
|
235
|
+
- Archive resolved threads to Discussion Log
|
|
227
236
|
|
|
228
|
-
|
|
229
|
-
|
|
230
|
-
|
|
237
|
+
If nothing to clean up, this is a no-op. `/plan cleanup` still exists as a standalone command for mid-iteration use.
|
|
238
|
+
|
|
239
|
+
### Step 3: Check Unresolved Discussions
|
|
240
|
+
|
|
241
|
+
Search for remaining `@droid` / `@{user_mention}` threads that weren't resolved:
|
|
231
242
|
|
|
232
243
|
If any found, warn:
|
|
233
244
|
```
|
|
@@ -236,7 +247,7 @@ If any found, warn:
|
|
|
236
247
|
- "Mark ready anyway" → Continue
|
|
237
248
|
```
|
|
238
249
|
|
|
239
|
-
### Step
|
|
250
|
+
### Step 4: Validate Required Sections
|
|
240
251
|
|
|
241
252
|
Check for:
|
|
242
253
|
- `## Context` section with content
|
|
@@ -244,11 +255,11 @@ Check for:
|
|
|
244
255
|
|
|
245
256
|
If missing, warn and list what's needed.
|
|
246
257
|
|
|
247
|
-
### Step
|
|
258
|
+
### Step 5: Update Status
|
|
248
259
|
|
|
249
260
|
Change `**Status:** draft` or `**Status:** in-progress` to `**Status:** ready`
|
|
250
261
|
|
|
251
|
-
### Step
|
|
262
|
+
### Step 6: Offer Distribution
|
|
252
263
|
|
|
253
264
|
Ask via AskUserQuestion:
|
|
254
265
|
```
|
|
@@ -271,7 +282,26 @@ Check status - warn if not `ready`:
|
|
|
271
282
|
"This plan is still '{status}'. Implement anyway?"
|
|
272
283
|
```
|
|
273
284
|
|
|
274
|
-
### Step 2:
|
|
285
|
+
### Step 2: Plan Review
|
|
286
|
+
|
|
287
|
+
**Default behaviour.** Skip if user passes `--no-review` (or says "skip review", "just implement").
|
|
288
|
+
|
|
289
|
+
Review the plan against the codebase before executing:
|
|
290
|
+
|
|
291
|
+
1. **Read each task's `**Files:**` section** — verify referenced files and patterns exist in the codebase
|
|
292
|
+
2. **Check for gaps** — missing files, outdated patterns, unaccounted dependencies between tasks
|
|
293
|
+
3. **Validate `**Verify:**` commands** — confirm they're runnable
|
|
294
|
+
4. **Note concerns or refinements** — anything that needs adjusting before execution
|
|
295
|
+
|
|
296
|
+
If the platform supports a dedicated plan/review mode, use it for this step. Otherwise, perform the review inline as a structured self-review before proceeding.
|
|
297
|
+
|
|
298
|
+
**Plan preservation:** If the review produces material refinements, save the revised plan as `{original-name}-implementation.md` alongside the original. The original plan is **never modified** during review — it's the decision record. The implementation variant includes `Parent plan: [[{original-name}]]` at the top.
|
|
299
|
+
|
|
300
|
+
After review, implementation executes from whichever plan came out of this step:
|
|
301
|
+
- No material changes → execute from the original
|
|
302
|
+
- Revised plan produced → execute from the `-implementation` variant
|
|
303
|
+
|
|
304
|
+
### Step 3: Parse Tasks
|
|
275
305
|
|
|
276
306
|
Find all `### Task N:` sections. For each, extract:
|
|
277
307
|
- **Name** from header
|
|
@@ -280,7 +310,7 @@ Find all `### Task N:` sections. For each, extract:
|
|
|
280
310
|
- **Verify** from `**Verify:**` line
|
|
281
311
|
- **Done** from `**Done:**` line
|
|
282
312
|
|
|
283
|
-
### Step
|
|
313
|
+
### Step 4: Optional XML Conversion
|
|
284
314
|
|
|
285
315
|
For complex multi-task plans, offer:
|
|
286
316
|
```
|
|
@@ -289,7 +319,7 @@ For complex multi-task plans, offer:
|
|
|
289
319
|
- "No" → Use markdown as-is
|
|
290
320
|
```
|
|
291
321
|
|
|
292
|
-
### Step
|
|
322
|
+
### Step 5: Execute Tasks
|
|
293
323
|
|
|
294
324
|
For each task in order:
|
|
295
325
|
|
|
@@ -308,7 +338,7 @@ If verification fails:
|
|
|
308
338
|
- "Stop implementation"
|
|
309
339
|
```
|
|
310
340
|
|
|
311
|
-
### Step
|
|
341
|
+
### Step 6: Update Status
|
|
312
342
|
|
|
313
343
|
When all tasks complete, change `**Status:** ready` to `**Status:** done`
|
|
314
344
|
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "droid-project",
|
|
3
|
-
"version": "0.
|
|
3
|
+
"version": "0.5.0",
|
|
4
4
|
"description": "Manage project context files for persistent AI memory across sessions. Load, update, or create project context before working on multi-session features.",
|
|
5
5
|
"author": {
|
|
6
6
|
"name": "Orderful",
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
name: project
|
|
2
2
|
description: "Manage project context files for persistent AI memory across sessions. Load, update, or create project context before working on multi-session features."
|
|
3
|
-
version: 0.
|
|
3
|
+
version: 0.5.0
|
|
4
4
|
status: beta
|
|
5
5
|
audience:
|
|
6
6
|
- all
|
|
@@ -21,6 +21,10 @@ config_schema:
|
|
|
21
21
|
type: string
|
|
22
22
|
description: Path to projects directory (required - no default)
|
|
23
23
|
required: true
|
|
24
|
+
save_related_in_project:
|
|
25
|
+
type: boolean
|
|
26
|
+
description: "When true, plan/brain skills default to saving artifacts under the active project folder"
|
|
27
|
+
default: false
|
|
24
28
|
preset:
|
|
25
29
|
type: select
|
|
26
30
|
description: "Link style: obsidian uses [[wikilinks]], markdown uses [standard](links)"
|
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: project
|
|
3
3
|
description: "Persistent project context for AI memory across sessions. Use when working on multi-session features, refactors, or any work that benefits from accumulated context. User prompts like 'load the project', 'update project context', 'what's the current project?'."
|
|
4
|
-
argument-hint: "[{keywords} | update | create {name}]"
|
|
4
|
+
argument-hint: "[search {keywords} | update | create {name} | pull [codex:{name}] | push [codex:{name}]]"
|
|
5
5
|
allowed-tools: [Read, Write, Glob, Grep, Bash]
|
|
6
6
|
---
|
|
7
7
|
|
|
@@ -32,6 +32,7 @@ Chat history disappears. Projects persist.
|
|
|
32
32
|
| -------------- | ------------ | -------------------------------------------------- |
|
|
33
33
|
| `projects_dir` | **required** | Where projects are stored (must be configured) |
|
|
34
34
|
| `preset` | `markdown` | Link style: `obsidian` uses `[[wikilinks]]`, `markdown` uses `[standard](links)` |
|
|
35
|
+
| `save_related_in_project` | `false` | When true, plan/brain skills default to saving artifacts under the active project folder instead of the brain inbox |
|
|
35
36
|
| `override` | (none) | User-defined behaviour overrides |
|
|
36
37
|
|
|
37
38
|
**Overrides:** This skill supports user-defined overrides. See `/droid` skill § Skill Overrides.
|
|
@@ -58,9 +59,17 @@ echo "projects_dir: /path/to/projects" >> ~/.droid/skills/project/overrides.yaml
|
|
|
58
59
|
| `/project create {name}` | Create new project (requires `create` keyword) |
|
|
59
60
|
| `/project create --from codex:{name}` | Create project seeded with codex context |
|
|
60
61
|
| `/project update` | Update from conversation context |
|
|
62
|
+
| `/project pull [codex:{name}]` | Pull codex updates into existing project |
|
|
63
|
+
| `/project push [codex:{name}]` | Push team-relevant content to codex via PR |
|
|
61
64
|
|
|
62
65
|
**IMPORTANT:** Use `/project search {keywords}` to find and load existing projects. Only use `/project create {name}` when the user explicitly wants to create a new project.
|
|
63
66
|
|
|
67
|
+
## PROJECT.md Frontmatter
|
|
68
|
+
|
|
69
|
+
| Field | Purpose |
|
|
70
|
+
| ---------------- | -------------------------------------------------------------------- |
|
|
71
|
+
| `codex_project` | Codex project name for pull/push (set on first use, remembered) |
|
|
72
|
+
|
|
64
73
|
## Loading a Project
|
|
65
74
|
|
|
66
75
|
**Trigger:** `/project search {keywords}` or user asks to load/open a project
|
|
@@ -86,6 +95,28 @@ Full procedure: `references/updating.md`
|
|
|
86
95
|
Version rules: `references/versioning.md`
|
|
87
96
|
Changelog format: `references/changelog.md`
|
|
88
97
|
|
|
98
|
+
## Pulling from Codex
|
|
99
|
+
|
|
100
|
+
**Trigger:** `/project pull [codex:{name}]`
|
|
101
|
+
|
|
102
|
+
**TLDR:** Read codex project docs, diff against current PROJECT.md, propose only critical updates that fit within context limits, apply with changelog entry.
|
|
103
|
+
|
|
104
|
+
First use: `/project pull codex:transaction-templates` — saves `codex_project` to frontmatter.
|
|
105
|
+
Subsequent: `/project pull` — reads from frontmatter.
|
|
106
|
+
|
|
107
|
+
Full procedure: `references/pulling.md`
|
|
108
|
+
|
|
109
|
+
## Pushing to Codex
|
|
110
|
+
|
|
111
|
+
**Trigger:** `/project push` or user asks to push learnings to codex
|
|
112
|
+
|
|
113
|
+
**TLDR:** Extract team-relevant decisions, patterns, and architecture updates from PROJECT.md. Propose codex updates via PR.
|
|
114
|
+
|
|
115
|
+
First use: `/project push codex:transaction-templates` — saves `codex_project` to frontmatter.
|
|
116
|
+
Subsequent: `/project push` — reads from frontmatter. Either push or pull can set it first.
|
|
117
|
+
|
|
118
|
+
Full procedure: `references/pushing.md`
|
|
119
|
+
|
|
89
120
|
## Creating a Project
|
|
90
121
|
|
|
91
122
|
**Trigger:** `/project create {name?}` or user asks to start a new project
|
|
@@ -34,6 +34,7 @@
|
|
|
34
34
|
- Use project contents for all subsequent work in the session
|
|
35
35
|
- **Do NOT read companion docs by default** — CHANGELOG.md, DECISIONS.md, and WORKLOG.md exist for on-demand lookup only. PROJECT.md already references them; that is enough context.
|
|
36
36
|
- If the user asks about decisions, past work, or history, THEN read the relevant companion doc.
|
|
37
|
+
- **Cross-skill routing:** When `save_related_in_project` is true (check `droid config --get tools.project`), signal to the session that related artifacts (plans, research, ideas) should default to `{project_folder}/plans/`, `{project_folder}/research/`, etc. Other skills (plan, brain) check for an active project and route accordingly.
|
|
37
38
|
|
|
38
39
|
7. **If `-- {instruction}` provided:** Execute the follow-up instruction against the loaded project
|
|
39
40
|
|
|
@@ -0,0 +1,57 @@
|
|
|
1
|
+
# Pulling from Codex
|
|
2
|
+
|
|
3
|
+
**Trigger:** `/project pull [codex:{name}]`
|
|
4
|
+
|
|
5
|
+
Pull shared organizational context into an existing local project.
|
|
6
|
+
|
|
7
|
+
## Procedure
|
|
8
|
+
|
|
9
|
+
1. **Resolve codex project name:**
|
|
10
|
+
- If `codex:{name}` provided → use it, save to PROJECT.md frontmatter as `codex_project: {name}`
|
|
11
|
+
- If not provided → read `codex_project` from PROJECT.md frontmatter
|
|
12
|
+
- If neither → ask user
|
|
13
|
+
|
|
14
|
+
2. **Identify the local project:**
|
|
15
|
+
- If in a loaded project session → use that project
|
|
16
|
+
- If no project loaded → search and load first (same as `/project search`)
|
|
17
|
+
|
|
18
|
+
3. **Load codex entry:**
|
|
19
|
+
- Run `droid config --get tools.codex` and get `codex_repo` from the JSON output
|
|
20
|
+
- Sync: `git -C {codex_repo} pull --rebase --quiet`
|
|
21
|
+
- Locate `{codex_repo}/projects/{name}/`
|
|
22
|
+
- If not found → error with suggestions from available codex projects
|
|
23
|
+
|
|
24
|
+
4. **Read codex documents:**
|
|
25
|
+
- PRD.md → goals, requirements, status
|
|
26
|
+
- TECH-DESIGN.md → architecture, patterns, key paths
|
|
27
|
+
- DECISIONS.md → recent decisions
|
|
28
|
+
- Any other docs in the codex project folder
|
|
29
|
+
|
|
30
|
+
5. **Read current PROJECT.md** and identify:
|
|
31
|
+
- Sections that overlap with codex content
|
|
32
|
+
- Codex content that's newer or more detailed
|
|
33
|
+
- Local content that has no codex equivalent (leave untouched)
|
|
34
|
+
|
|
35
|
+
6. **Propose updates** (never auto-apply):
|
|
36
|
+
- **Be highly selective** — PROJECT.md has context limits. Only propose content that is critical for the AI to have when working on this project.
|
|
37
|
+
- Categorise: "New from codex", "Updated in codex", "No change needed"
|
|
38
|
+
- Preserve local implementation details — codex updates should ADD context, not overwrite working notes
|
|
39
|
+
- Prefer links to codex over copying large sections
|
|
40
|
+
|
|
41
|
+
7. **After approval:**
|
|
42
|
+
- Apply approved changes
|
|
43
|
+
- Update frontmatter: `codex_project: {name}`
|
|
44
|
+
- Add `## Codex Sync` entry or update existing one:
|
|
45
|
+
```
|
|
46
|
+
**Last pulled:** {date} from codex:{name}
|
|
47
|
+
```
|
|
48
|
+
- Determine version bump (patch for context updates, minor if goals/scope changed)
|
|
49
|
+
- Add changelog entry noting codex pull
|
|
50
|
+
|
|
51
|
+
## Key Principles
|
|
52
|
+
|
|
53
|
+
- **Selective, not exhaustive** — only pull what's critical for project context. The project file has size limits.
|
|
54
|
+
- **Additive, not destructive** — codex updates enrich the local project, they don't replace local work
|
|
55
|
+
- **User reviews every change** — always propose, never auto-apply
|
|
56
|
+
- **Provenance tracked** — changelog and sync date show where context came from
|
|
57
|
+
- **Links over copies** — for large sections, link to codex rather than duplicating
|
|
@@ -0,0 +1,79 @@
|
|
|
1
|
+
# Pushing to Codex
|
|
2
|
+
|
|
3
|
+
**Trigger:** `/project push [codex:{name}]`
|
|
4
|
+
|
|
5
|
+
Push team-relevant content from a local project back to the shared codex.
|
|
6
|
+
|
|
7
|
+
## What Gets Shared
|
|
8
|
+
|
|
9
|
+
Not everything in a project is codex-worthy. Extract only team-relevant content:
|
|
10
|
+
|
|
11
|
+
| Share | Don't Share |
|
|
12
|
+
|-------|-------------|
|
|
13
|
+
| Architecture decisions with rationale | Personal work notes |
|
|
14
|
+
| New patterns discovered during implementation | In-progress tasks |
|
|
15
|
+
| Updated technical constraints | Session logs or worklogs |
|
|
16
|
+
| Status changes (shipped, blocked, pivoted) | Brain docs or research drafts |
|
|
17
|
+
| Key file paths or API changes | Local configuration |
|
|
18
|
+
|
|
19
|
+
## Procedure
|
|
20
|
+
|
|
21
|
+
1. **Resolve codex project name:**
|
|
22
|
+
- If `codex:{name}` provided → use it, save to PROJECT.md frontmatter as `codex_project: {name}`
|
|
23
|
+
- If not provided → read `codex_project` from PROJECT.md frontmatter
|
|
24
|
+
- If neither → ask user which codex project to update, save to frontmatter
|
|
25
|
+
- Codex project must already exist. If it doesn't, suggest `/codex new project {name}` first.
|
|
26
|
+
|
|
27
|
+
2. **Identify the local project:**
|
|
28
|
+
- If in a loaded project session → use that project
|
|
29
|
+
- If no project loaded → search and load first
|
|
30
|
+
|
|
31
|
+
3. **Read PROJECT.md** and companion docs (DECISIONS.md, WORKLOG.md if they exist)
|
|
32
|
+
|
|
33
|
+
4. **Load codex entry:**
|
|
34
|
+
- Run `droid config --get tools.codex` and get `codex_repo` from the JSON output
|
|
35
|
+
- Sync: `git -C {codex_repo} pull --rebase --quiet`
|
|
36
|
+
- Read existing codex project docs
|
|
37
|
+
|
|
38
|
+
5. **Extract and categorise shareable content:**
|
|
39
|
+
- **Decisions:** New entries from DECISIONS.md or inline decisions in PROJECT.md
|
|
40
|
+
- **Architecture:** Changes to technical approach, new patterns, updated diagrams
|
|
41
|
+
- **Status:** Phase changes, milestones hit, scope changes
|
|
42
|
+
- **Constraints:** Newly discovered technical constraints or gotchas
|
|
43
|
+
|
|
44
|
+
6. **Propose codex updates** (never auto-apply):
|
|
45
|
+
- For each item, show:
|
|
46
|
+
- What will be added/changed in codex
|
|
47
|
+
- Which codex file it targets (DECISIONS.md, TECH-DESIGN.md, PRD.md)
|
|
48
|
+
- A diff preview
|
|
49
|
+
- Let user accept, reject, or edit each item
|
|
50
|
+
|
|
51
|
+
7. **After approval:**
|
|
52
|
+
- Use codex git scripts for the write operation:
|
|
53
|
+
```bash
|
|
54
|
+
# Start write
|
|
55
|
+
droid config --get tools.codex | droid exec codex git-start-write --config - \
|
|
56
|
+
--branch codex/sync-{project-name}
|
|
57
|
+
|
|
58
|
+
# Make changes to codex files
|
|
59
|
+
|
|
60
|
+
# Normalize frontmatter
|
|
61
|
+
droid config --get tools.codex | droid exec codex normalize-frontmatter --config -
|
|
62
|
+
|
|
63
|
+
# Finish write (commit + PR)
|
|
64
|
+
droid config --get tools.codex | droid exec codex git-finish-write --config - \
|
|
65
|
+
--message "sync({project}): {summary}" \
|
|
66
|
+
--pr-title "sync({project}): Update from local project" \
|
|
67
|
+
--pr-body "{description of changes}"
|
|
68
|
+
```
|
|
69
|
+
- Update local PROJECT.md sync marker:
|
|
70
|
+
```
|
|
71
|
+
**Last pushed:** {date} to codex:{name}
|
|
72
|
+
```
|
|
73
|
+
|
|
74
|
+
## Key Principles
|
|
75
|
+
|
|
76
|
+
- **Curated, not automated** — user explicitly reviews what gets shared
|
|
77
|
+
- **PR-based** — codex changes go through PR review, not direct commits
|
|
78
|
+
- **Additive** — adds to codex content, doesn't overwrite others' contributions
|
|
79
|
+
- **Idempotent** — running `/project push` twice proposes only new/changed content
|