@orderful/droid 0.44.1 → 0.45.1

package/src/tools/tech-design/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "droid-tech-design",
-  "version": "0.3.0",
+  "version": "0.3.1",
   "description": "Technical design authoring tool for engineers. Create structured tech design docs with /tech-design start, iterate in brain, publish to codex. Three-document approach: research doc (codebase discoveries) + thought doc (design workspace) + roll-up (clean summary for review).",
   "author": {
     "name": "Orderful",

package/src/tools/tech-design/TOOL.yaml

@@ -1,6 +1,6 @@
 name: tech-design
 description: "Technical design authoring tool for engineers. Create structured tech design docs with /tech-design start, iterate in brain, publish to codex. Three-document approach: research doc (codebase discoveries) + thought doc (design workspace) + roll-up (clean summary for review)."
-version: 0.3.0
+version: 0.3.1
 status: beta
 
 includes:

package/src/tools/tech-design/skills/tech-design/SKILL.md

@@ -47,6 +47,12 @@ Tech-design has no configuration of its own. It delegates to:
 
 **Overrides:** This skill supports user-defined overrides. See `/droid` skill § Skill Overrides.
 
+## Custom Instructions
+
+Any command accepts a ` -- {instruction}` suffix. Split on the **first** ` -- ` (space-dash-dash-space): left is the command and its args, right is additional context or instruction to carry through the entire execution. Note: flag-style `--from` and similar flags use `--flag` syntax (no surrounding spaces) and are distinct from this separator.
+
+Example: `/tech-design draft rollout -- keep it concise, we have limited Ops bandwidth`
+
 ## Four-Document Approach
 
 | Document        | Created When | Purpose                                                  | Location                                         | Audience       | Length  |

package/src/tools/wrapup/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "droid-wrapup",
-  "version": "0.1.3",
+  "version": "0.1.5",
   "description": "Session wrap-up that captures decisions, learnings, and open items to persistent docs.",
   "author": {
     "name": "Orderful",

package/src/tools/wrapup/TOOL.yaml

@@ -1,6 +1,6 @@
 name: wrapup
 description: "Session wrap-up that captures decisions, learnings, and open items to persistent docs."
-version: 0.1.3
+version: 0.1.5
 status: alpha
 
 includes:
@@ -13,4 +13,8 @@ includes:
 
 dependencies: []
 
-config_schema: {}
+config_schema:
+  persist_recaps:
+    type: string
+    default: 'false'
+    description: 'Persist session recap files to brain vault wrapups folder'

package/src/tools/wrapup/skills/wrapup/SKILL.md

@@ -10,16 +10,25 @@ Session wrap-up that captures decisions, learnings, and open items before closin
 
 ## Configuration
 
-Wrapup has no configuration of its own. It reads config from other installed tools:
+Wrapup reads config from other installed tools, plus its own settings:
 
 - **Project skill** (optional): `droid config --get tools.project` → `projects_dir` to update project files
-- **Brain skill** (optional): `droid config --get tools.brain` → `brain_dir` to update brain docs
+- **Brain skill** (optional): `droid config --get tools.brain` → `brain_dir` and `inbox_folder` to update brain docs
 - **Codex skill** (optional): `droid config --get tools.codex` → `codex_repo` to suggest codex entries
+- **Wrapup own config** (optional): `droid config --get tools.wrapup` → `persist_recaps` (`'true'` / `'false'`, default `'false'`)
 
 If these tools aren't configured, wrapup skips those artifacts and focuses on git state and conversation summary.
 
+When `persist_recaps` is `'true'` and brain is configured, session briefs are saved to the brain vault in Phase 4 (see below).
+
 **Overrides:** This skill supports user-defined overrides. See `/droid` skill § Skill Overrides.
 
+## Custom Instructions
+
+Any command accepts a ` -- {instruction}` suffix. Split on the **first** ` -- ` (space-dash-dash-space): left is the command and its args, right is additional context or instruction to carry through the entire execution.
+
+Example: `/wrapup -- also capture the tech debt items we discussed`
+
 ## Context Lifeboat Pattern
 
 This skill runs at the END of sessions when context pressure is highest.
@@ -98,3 +107,17 @@ Present options using AskUserQuestion:
 - **"Skip"** → Close without updating
 
 On approval, write updates using appropriate format for each destination.
+
+**Session recap persistence (if `persist_recaps` is `'true'`):**
+
+After writing all other updates, check whether session briefs should be persisted:
+
+1. Run `droid config --get tools.wrapup` and check if `persist_recaps` equals `'true'`. If not, skip.
+2. Run `droid config --get tools.brain` and parse `brain_dir` and `inbox_folder`.
+   - If `brain_dir` is not set, skip.
+3. Construct the destination path:
+   - If `inbox_folder` is non-empty: `{brain_dir}/{inbox_folder}/wrapups/{session-id}.md`
+   - If `inbox_folder` is empty or absent: `{brain_dir}/wrapups/{session-id}.md`
+   - Avoid double slashes — do not append `inbox_folder` when it is an empty string.
+4. Create the `wrapups/` directory if it does not exist, then copy the Phase 1 brief from `/tmp/wrapup-{session-id}.md` to the constructed path.
+5. Inform the user the recap was saved and where.

package/src/tools/wrapup/skills/wrapup/references/output-schema.md

@@ -28,7 +28,7 @@ Structured format for subagent findings. Main agent uses this to synthesise the
   ],
   "suggested_actions": [
     {
-      "type": "commit | codex_topic | file_bug | update_docs",
+      "type": "commit | codex_topic | codex_update | file_bug | update_docs",
       "content": "description of suggested action",
       "priority": "high | medium | low"
     }
@@ -63,7 +63,8 @@ Item categories:
 
 Actions that need user judgment:
 - `commit`: Git changes ready to commit
-- `codex_topic`: Knowledge worth codifying
+- `codex_topic`: Net-new knowledge worth codifying as a new codex entry
+- `codex_update`: Update to an existing codex entry (distinct from `codex_topic` which suggests net-new content)
 - `file_bug`: Bug discovered but not filed
 - `update_docs`: Documentation that needs updating
 
@@ -87,7 +88,8 @@ Actions that need user judgment:
   ],
   "suggested_actions": [
     {"type": "commit", "content": "4 files ready: TOOL.yaml, SKILL.md, wrapup.md, changeset", "priority": "high"},
-    {"type": "codex_topic", "content": "Context lifeboat pattern for end-of-session tooling", "priority": "medium"}
+    {"type": "codex_topic", "content": "Context lifeboat pattern for end-of-session tooling", "priority": "medium"},
+    {"type": "codex_update", "content": "Update 'droid' codex entry: add context-lifeboat pattern and subagent parallelisation decision from today's session", "priority": "low"}
   ]
 }
 ```

package/src/tools/wrapup/skills/wrapup/references/subagent-prompts.md

@@ -76,20 +76,61 @@ Output:
 **Subagent type:** Explore
 
 ```
-Read {session_brief_path} for session context.
-
-Run `droid config --get tools.codex` and check if `codex_repo` is set.
-If not configured, skip codex analysis.
-
-If the session involved:
-- Deep research on a topic
-- Discovering patterns or best practices
-- Solving a non-trivial problem with reusable insights
-
-Then suggest potential codex topics:
-- Topic name
+Read {session_brief_path} for session context. Pay particular attention to the
+"Decisions Made" and "Key Learnings" sections — these are the primary signals
+for both new codex topics and updates to existing entries.
+
+Run `droid config --get tools.codex` and parse the JSON output for `codex_repo`.
+If `codex_repo` is not set, output "No codex suggestions (codex not configured)" and stop.
+
+--- Discover existing codex content ---
+
+1. Attempt to read `{codex_repo}/.codex/manifest.yaml` to get an inventory of
+   existing entries and projects.
+   - If the manifest does not exist, fall back: list the top-level directories
+     inside `{codex_repo}` to infer project names.
+2. Skim entry names, titles, and tags — you do NOT need to read full entry bodies
+   at this stage. Goal is a compact list of what already exists.
+
+--- Compare session against existing codex content ---
+
+3. For each decision or learning in the session brief, check whether it relates
+   to an existing codex entry or project:
+   - A decision "relates to" an entry if the topic, technology, or system name
+     overlaps (e.g., a decision about the droid project file format relates to
+     a codex entry named "droid" or "tool-configuration").
+   - Threshold: if 2 or more session decisions/learnings relate to the same
+     existing codex entry, emit a `codex_update` suggestion for that entry.
+   - For a single related decision/learning, use your judgment — only suggest
+     an update if the insight is clearly additive and not already captured.
+
+4. Read the full content of any existing entries flagged in step 3 to confirm
+   the insight is genuinely new (avoid duplicate suggestions).
+
+--- Identify net-new codex topics ---
+
+5. For decisions/learnings that do NOT relate to any existing entry, consider
+   whether they merit a brand-new codex topic:
+   - Deep research findings
+   - Discovered patterns or best practices
+   - Non-trivial problems solved with reusable insights
+
+--- Output ---
+
+Produce two buckets:
+
+**Suggested updates to existing codex entries (codex_update):**
+For each:
+- Entry name (as it appears in the codex)
+- What to add or amend (specific content, not vague)
+- Which session decisions/learnings drove this suggestion
+- Why the existing entry is incomplete without this update
+
+**Suggested new codex topics (codex_topic):**
+For each:
+- Proposed topic name
 - Brief description of what to capture
 - Why it's worth codifying (reusable, non-obvious, hard-won knowledge)
 
-Output: List of suggested codex topics, or "No codex suggestions" if session was routine.
+If neither bucket has entries, output "No codex suggestions".
 ```