@orderful/droid 0.44.0 → 0.45.0

package/src/tools/release/skills/release/references/workflows.md

@@ -7,8 +7,8 @@ Detailed step-by-step procedures for each `/release` subcommand. All commands us
 ```bash
 # 1. Read config
 SLACK_CHANNEL=$(droid config --get tools.release.slack_channel)
-# Default to #release-management if not set
-SLACK_CHANNEL="${SLACK_CHANNEL:-#release-management}"
+# Default to #release_management if not set
+SLACK_CHANNEL="${SLACK_CHANNEL:-#release_management}"
 
 # 2. Get repos and filter for release repos (those with release_branch set)
 droid config --get repos
@@ -25,9 +25,11 @@ git -C {repo_path} remote get-url origin
 
 ---
 
-## `/release start [repo]`
+## `/release start [repo] [--no-lock]`
 
-Create a release PR and notify Slack.
+Create a release PR, auto-lock the release branch, and notify Slack.
+
+**Auto-lock is on by default.** The branch is locked immediately after the PR is created to prevent blind merges during CI. Pass `--no-lock` (or natural language like "start without locking") to skip.
 
 ### Steps
 
@@ -44,10 +46,21 @@ Create a release PR and notify Slack.
    # Get commits in release_branch that aren't in production_branch
    gh api repos/{owner}/{repo}/compare/{production_branch}...{release_branch} --jq '.commits[].commit.message'
    ```
-   Extract PR numbers from commit messages (e.g. `(#1234)`) and format as a bulleted list for the PR body.
+   Extract PR numbers from commit messages (e.g. `(#1234)`). For each extracted PR number, fetch metadata including labels:
+   ```bash
+   gh pr view {pr_number} --json number,title,author,labels --repo {owner}/{repo}
+   ```
+   Build the PR list for the body from the results. Collect `HIGH_RISK_PRS` — an array of `{number, title, author}` for any PR whose `labels` array includes an entry with `name: "high-risk"`.
 
    **Do NOT use** `gh pr list --base {release_branch} --state merged` — that returns ALL historically merged PRs, not just the ones since the last release.
 
+3.5. **Warn if high-risk PRs found** — if `HIGH_RISK_PRS` is non-empty, print a terminal warning:
+   ```
+   ⚠️  {n} high-risk PR(s) detected in this release:
+     - #{number} {title} (@{author})
+     ...
+   ```
+
 4. **Ask risk level** — use AskUserQuestion:
    - Low Risk (routine release, no breaking changes)
    - High Risk (breaking changes, data migrations, or high-traffic feature)
@@ -62,9 +75,29 @@ Create a release PR and notify Slack.
      --body "{release_pr_body}" \
      --repo {owner}/{repo}
    ```
+   If `HIGH_RISK_PRS` is non-empty, also add `--label "high-risk"` to the command above. If the `high-risk` label does not exist on the repo, `gh pr create` will fail — in that case, retry without `--label "high-risk"` and warn the user:
+   ```
+   ⚠️  Could not apply 'high-risk' label — label does not exist on {repo_name}. Create it in GitHub Labels settings, then add it manually to PR #{number}.
+   ```
+
    See `templates.md` for the PR body template.
 
-6. **Post to Slack:**
+6. **Auto-lock branch** (unless `--no-lock`):
+   ```bash
+   gh workflow run branch-lock.yml \
+     -f action=lock \
+     -f branch={release_branch} \
+     --repo {owner}/{repo}
+   ```
+   Verify lock applied:
+   ```bash
+   sleep 5
+   gh api repos/{owner}/{repo}/branches/{release_branch}/protection --jq '.lock_branch.enabled'
+   ```
+   If `branch-lock.yml` is not found in the repo, warn but don't fail:
+   "Could not auto-lock — `branch-lock.yml` not found in `{repo_name}`. Use `/release lock` manually after adding the workflow."
+
+7. **Post to Slack:**
    ```bash
    node -e 'process.stdout.write(JSON.stringify({
      channel: "{slack_channel}",
@@ -72,9 +105,9 @@ Create a release PR and notify Slack.
      unfurl_links: false
    }))' | droid integrations slack post
    ```
-   See `templates.md` for the Slack message template (release started).
+   See `templates.md` for the Slack message template (release open for review — includes lock status).
 
-7. **Confirm to user** — show PR URL and Slack post confirmation.
+8. **Confirm to user** — show PR URL, lock status, and Slack post confirmation.
 
 ---
 
@@ -88,7 +121,7 @@ Merge the release PR if all checks are green, then notify Slack.
 
 2. **Find the open release PR:**
    ```bash
-   gh pr list --search "[RELEASE]" --state open --base {production_branch} --head {release_branch} --json number,title,url,statusCheckRollup --repo {owner}/{repo}
+   gh pr list --search "[RELEASE]" --state open --base {production_branch} --head {release_branch} --json number,title,url,statusCheckRollup,labels --repo {owner}/{repo}
    ```
    If no open release PR found, error: "No open release PR found. Run `/release start` first."
 
@@ -98,7 +131,10 @@ Merge the release PR if all checks are green, then notify Slack.
    If any checks are pending: "CI checks are still running on PR #{number}. Wait for them to finish."
    If any checks are failing: "CI checks are failing on PR #{number}. Fix them before merging." Show the failing checks.
 
-4. **Confirm with user** — use AskUserQuestion:
+4. **Confirm with user** — if the release PR's `labels` includes `"high-risk"`, first show an extra AskUserQuestion confirmation:
+   "⚠️ This release includes high-risk PRs. Confirm you have coordinated with the contributors and are ready to proceed."
+
+   Then (regardless of high-risk) show the standard AskUserQuestion:
    "All checks are green on PR #{number}. Merge `{release_branch}` → `{production_branch}`?"
 
 5. **Merge the PR:**
@@ -112,6 +148,81 @@ Merge the release PR if all checks are green, then notify Slack.
 
 ---
 
+## `/release lock [repo]`
+
+Manually lock the release branch. Use when you need to lock outside of `/release start` (which auto-locks).
+
+### Steps
+
+1. **Detect repo** — match cwd or ask user
+
+2. **Check current lock state:**
+   ```bash
+   gh api repos/{owner}/{repo}/branches/{release_branch}/protection --jq '.lock_branch.enabled // false'
+   ```
+   If already locked, warn: "Branch `{release_branch}` is already locked. Unlock first?"
+
+3. **Confirm with user** — use AskUserQuestion:
+   "Lock `{release_branch}` on `{repo_name}`? No one will be able to merge until unlocked."
+
+4. **Trigger the lock Action:**
+   ```bash
+   gh workflow run branch-lock.yml \
+     -f action=lock \
+     -f branch={release_branch} \
+     --repo {owner}/{repo}
+   ```
+
+5. **Verify lock applied** (wait a few seconds, then check):
+   ```bash
+   sleep 5
+   gh api repos/{owner}/{repo}/branches/{release_branch}/protection --jq '.lock_branch.enabled'
+   ```
+   If still not locked, check the workflow run status:
+   ```bash
+   gh run list --workflow=branch-lock.yml --limit 1 --json status,conclusion --repo {owner}/{repo}
+   ```
+
+6. **Post to Slack** — lock notification (see `templates.md`).
+
+7. **Confirm to user** — "Locked `{release_branch}` on `{repo_name}`."
+
+---
+
+## `/release unlock [repo]`
+
+Unlock the release branch.
+
+### Steps
+
+1. **Detect repo** — match cwd or ask user
+
+2. **Check current lock state:**
+   ```bash
+   gh api repos/{owner}/{repo}/branches/{release_branch}/protection --jq '.lock_branch.enabled // false'
+   ```
+   If not locked, inform: "Branch `{release_branch}` is not currently locked."
+
+3. **Trigger the unlock Action:**
+   ```bash
+   gh workflow run branch-lock.yml \
+     -f action=unlock \
+     -f branch={release_branch} \
+     --repo {owner}/{repo}
+   ```
+
+4. **Verify unlock applied:**
+   ```bash
+   sleep 5
+   gh api repos/{owner}/{repo}/branches/{release_branch}/protection --jq '.lock_branch.enabled'
+   ```
+
+5. **Post to Slack** — unlock notification (see `templates.md`).
+
+6. **Confirm to user** — "Unlocked `{release_branch}` on `{repo_name}`."
+
+---
+
 ## `/release status`
 
 Check release status across all configured release repos.
@@ -124,7 +235,12 @@ Check release status across all configured release repos.
 
    **Open release PRs:**
    ```bash
-   gh pr list --search "[RELEASE]" --state open --json number,title,url,statusCheckRollup --repo {owner}/{repo}
+   gh pr list --search "[RELEASE]" --state open --json number,title,url,statusCheckRollup,labels --repo {owner}/{repo}
+   ```
+
+   **Lock state:**
+   ```bash
+   gh api repos/{owner}/{repo}/branches/{release_branch}/protection --jq '.lock_branch.enabled // false'
    ```
 
 3. **Format and display** as a summary:
@@ -132,6 +248,12 @@ Check release status across all configured release repos.
    ```
    {repo_name}
      Release PR: #{number} — {CI status} (green/pending/failing)
+     Branch lock: {release_branch} — locked/unlocked
+   ```
+
+   If the release PR's `labels` includes `"high-risk"`, append to the repo's status block:
+   ```
+     ⚠️  High-risk PRs included
    ```
 
    If no open release PR: "No active release"
@@ -141,7 +263,7 @@ Check release status across all configured release repos.
 
 ## `/release complete [repo]`
 
-Close out a release — notify Slack.
+Close out a release — notify Slack and auto-unlock.
 
 ### Steps
 
@@ -161,6 +283,20 @@ Close out a release — notify Slack.
 
 3. **Post to Slack** — release complete notification (see `templates.md`).
 
-4. **Confirm to user:**
+4. **Auto-unlock if locked:**
+   ```bash
+   LOCKED=$(gh api repos/{owner}/{repo}/branches/{release_branch}/protection --jq '.lock_branch.enabled // false')
+   ```
+   If locked, trigger unlock:
+   ```bash
+   gh workflow run branch-lock.yml \
+     -f action=unlock \
+     -f branch={release_branch} \
+     --repo {owner}/{repo}
+   ```
+   Post unlock notification to Slack as well.
+
+5. **Confirm to user:**
    - "Release complete for `{repo_name}`"
+   - "Auto-unlocked `{release_branch}`" (if was locked)
    - Show Slack message confirmation

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

@@ -1,6 +1,6 @@
 {
   "name": "droid-share",
-  "version": "0.1.0",
+  "version": "0.1.1",
   "description": "Share content to external platforms. Publish docs to Confluence or post summaries to Slack.",
   "author": {
     "name": "Orderful",

package/src/tools/share/TOOL.yaml

@@ -1,6 +1,6 @@
 name: share
 description: "Share content to external platforms. Publish docs to Confluence or post summaries to Slack."
-version: 0.1.0
+version: 0.1.1
 status: beta
 
 includes:

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

@@ -26,6 +26,12 @@ Share content to external platforms. Two modes:
 | Confluence | Atlassian MCP (`mcp__claude_ai_Atlassian__*`) | Publish document as page |
 | Slack | `droid integrations slack post` | Process + post message |
 
+## 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. For the Slack flow specifically, the `--` instruction becomes the formatting directive (step S3).
+
+Example: `/share slack #eng -- summarise the action items and tag owners`
+
 ## Procedure
 
 ### 1. Resolve Platform

package/src/tools/status-update/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "droid-status-update",
-  "version": "0.2.1",
+  "version": "0.2.2",
   "description": "Generate and post project status updates. Aggregates context from codex projects, Jira epics, and manual input. Posts to Slack or prints to terminal.",
   "author": {
     "name": "Orderful",

package/src/tools/status-update/TOOL.yaml

@@ -1,6 +1,6 @@
 name: status-update
 description: "Generate and post project status updates. Aggregates context from codex projects, Jira epics, and manual input. Posts to Slack or prints to terminal."
-version: 0.2.1
+version: 0.2.2
 status: beta
 
 includes:

package/src/tools/status-update/skills/status-update/SKILL.md

@@ -30,6 +30,12 @@ Generate formatted project status updates from multiple sources and post to Slac
 |-------------|----------------|----------|
 | **Slack** | If slack.channel configured + SLACK_USER_TOKEN set | Print to terminal |
 
+## 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: `/status-update droid -- emphasise the auth refactor milestone we shipped`
+
 ## Procedure
 
 ### 1. Resolve Project Context

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".
 ```