@chris1807/claude-kit 2.1.21 → 2.1.23

package/README.md

@@ -28,7 +28,7 @@ Every session Claude learns from your feedback and gets better at helping you sp
 | **Global Agents** | 13 | `~/.claude/agents/` (your machine, all projects) | backend, frontend, legacy (Lucee/CFML), manager, mockup, reviewer, test-runner, build-validator, lint-checker, uat-generator, azure-ops, security-auditor, api-tester |
 | **Project Agents** | 3 | `.claude/agents/` (in the project) | deployer, db-admin, devops-tracker |
 | **Hooks** | 9 | `.claude/hooks/` (in the project) | Secret blocker, sensitive data blocker (Bash + MCP + output), protected files, auto-format, test suggestions, UAT reminder, self-improve |
-| **Slash Commands** | 13 | `.claude/commands/` (in the project) | `/implement`, `/review`, `/resolve-feedback`, `/deploy`, `/create-release`, `/deploy-release`, `/add-to-release`, `/cherry-pick`, `/promote`, `/rollback`, `/status`, `/cleanup-branches`, `/quote`, `/explain` |
+| **Slash Commands** | 13 | `.claude/commands/` (in the project) | `/implement`, `/review`, `/resolve-feedback`, `/deploy`, `/create-release`, `/deploy-release`, `/add-to-release`, `/cherry-pick`, `/promote`, `/rollback`, `/status`, `/cleanup-branches`, `/close-orphan-tasks`, `/quote`, `/explain` |
 | **MCP Servers** | Up to 6 | `.mcp.json` (in the project) | **Azure DevOps** (work items, repos, pipelines, wiki), Playwright, MongoDB/SQL/Postgres, Teams, Stripe, Azure CLI |
 | **Workflow Template** | 1 | Appended to `CLAUDE.md` | Documents the full development process |
 | **Settings** | 1 | `.claude/settings.json` (in the project) | Registers all hooks and MCP servers |
@@ -220,6 +220,7 @@ your-project/                      ← Project-specific
 │   │   ├── add-to-release.md      # /add-to-release 24 AB#4599
 │   │   ├── status.md              # /status release 24
 │   │   ├── cleanup-branches.md    # /cleanup-branches
+│   │   ├── close-orphan-tasks.md  # /close-orphan-tasks
 │   │   ├── quote.md               # /quote AB#1234
 │   │   └── explain.md             # /explain AB#1234
 │   │
@@ -629,6 +630,7 @@ Claude reviews for:
 | `/quote` | `/quote AB#1234` | Display a work item as a formatted blockquote |
 | `/explain` | `/explain AB#1234` | Summarize and explain a work item in plain language |
 | `/cleanup-branches` | `/cleanup-branches` | Delete merged feature/work branches |
+| `/close-orphan-tasks` | `/close-orphan-tasks --dry-run` | Close open Tasks whose parent is Ready to Deploy / Deployed / Closed |
 
 ---
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@chris1807/claude-kit",
-  "version": "2.1.21",
+  "version": "2.1.23",
   "description": "Claude Code starter kit for Azure DevOps teams — agents, hooks, MCP servers, slash commands, and end-to-end work item → PR → release → deploy workflow automation",
   "type": "module",
   "bin": {

package/templates/agents/global/manager.md

@@ -67,6 +67,12 @@ When tasks are independent, delegate in parallel:
 - Build validation and lint checking can run simultaneously
 - Frontend work depends on backend APIs being defined (but not necessarily implemented)
 
+Issue independent delegations as multiple `Task` calls in a single message so they run concurrently.
+
+### Ultracode is not yours to run
+
+**Ultracode** (the `Workflow` tool — deterministic fan-out across many agents) is a *main-loop* capability. You run as a subagent under `Task` and do **not** have the `Workflow` tool, so never assume you can author a workflow. Your parallelism is limited to issuing several `Task` delegations at once (above). If a job genuinely calls for ultracode-scale fan-out — e.g. one agent per work item across a whole backlog — that belongs to the main loop or a slash command; surface the suggestion to the user rather than attempting it yourself.
+
 ## How to Start a Feature
 
 When the user says "implement Feature X" or "work on [feature]":
@@ -111,6 +117,8 @@ The user may invoke slash commands directly instead of asking you to orchestrate
 | `/status release 24` | Check release, pipeline, or work item status |
 | `/review 142` | Code review a PR |
 | `/cleanup-branches` | Delete merged branches |
+| `/close-orphan-tasks` | Close open Tasks whose parent has shipped (Ready to Deploy / Deployed / Closed) |
+| `/plan-backlog` | Sweep the backlog for Dev Ready stories and propose child tasks |
 
 If the user asks you to "deploy to staging" or "create a release", suggest the appropriate slash command.
 

package/templates/commands/close-orphan-tasks.md

@@ -0,0 +1,86 @@
+Close orphaned tasks — open Tasks whose parent has already moved to a deploy/done state. Usage: `/close-orphan-tasks [scope] [--dry-run]`
+
+An **orphaned task** here means a child Task that is still open while its parent work item has already reached one of these states:
+
+- `Ready to Deploy`
+- `Deployed`
+- `Closed`
+
+When a parent is deployed or closed, leftover open child Tasks just add noise to the board. This command finds them and closes them in a single pass.
+
+Parse `$ARGUMENTS`:
+- If it contains `dry-run` or `--dry-run`, only list the orphaned tasks — do **not** close anything.
+- Any other text is an optional **scope** filter — an Area Path, product prefix (`COM`, `PAY`, …), or iteration to narrow the search. With no scope, search the whole project.
+
+All work items live in the **CSI Development** Azure DevOps project (see CLAUDE.md). Target that project unless the repo's CLAUDE.md says otherwise.
+
+## Step 1: Find Orphaned Tasks
+
+Use the Azure DevOps MCP `wit_query_by_wiql` with a hierarchy link query. The Source is the parent, the Target is the child Task:
+
+```sql
+SELECT [System.Id]
+FROM WorkItemLinks
+WHERE
+  ([Source].[System.State] IN ('Ready to Deploy', 'Deployed', 'Closed'))
+  AND ([System.Links.LinkType] = 'System.LinkTypes.Hierarchy-Forward')
+  AND ([Target].[System.WorkItemType] = 'Task')
+  AND ([Target].[System.State] NOT IN ('Closed', 'Removed', 'Done'))
+MODE (MustContain)
+```
+
+If a **scope** was given, add the matching constraint to the `[Target]` clause (e.g. `AND [Target].[System.AreaPath] UNDER 'CSI Development\\Compass'`, or `AND [Target].[System.Title] CONTAINS 'PAY'`).
+
+> **Note on state names:** Process templates vary. Some projects close tasks to `Done` instead of `Closed`, or use `Resolved`. If the query returns nothing or errors on an unknown state, first confirm the valid states for the Task type via `wit_get_work_item_type`, then adjust the `NOT IN` list and the close target in Step 3 accordingly.
+
+If the link query is unsupported or returns no usable pairs, fall back to: query all open Tasks in scope with a flat WIQL, fetch each task's parent via `relations`, and keep only those whose parent state is in the three target states.
+
+Fetch the matched tasks (and their parents) in a batch via `wit_get_work_items_batch_by_ids` to get titles, states, assignees, and parent context.
+
+## Step 2: Present the Candidates
+
+```
+## Orphaned Tasks ({count})
+
+| Task | Title | State | Parent | Parent State |
+|------|-------|-------|--------|--------------|
+| AB#4710 | Add export endpoint | Active | AB#4521 | Deployed |
+| AB#4711 | Wire up CSV service | New | AB#4521 | Deployed |
+| AB#4733 | Fix null check | Active | AB#4598 | Closed |
+
+These tasks will be set to **Closed** with a comment noting the parent's state.
+
+Close {count} orphaned tasks? (yes/no)
+```
+
+If `--dry-run`, show the table but do **not** ask for confirmation and do **not** close anything. Stop here.
+
+Otherwise, wait for explicit confirmation before proceeding. Never close tasks without a yes.
+
+## Step 3: Close the Tasks
+
+For each confirmed task, use `wit_update_work_items_batch`:
+- **path**: `/fields/System.State`
+- **value**: `Closed` (or the project's terminal Task state confirmed in Step 1)
+
+Then add a comment on each via `wit_add_work_item_comment` so the auto-close is traceable:
+
+> Auto-closed by `/close-orphan-tasks` — parent AB#{parentId} is in state "{parentState}".
+
+Do not modify the parent items. Do not touch tasks whose parent is in any other state.
+
+## Step 4: Report
+
+```
+Closed {count} orphaned tasks.
+
+| Task | Title | Parent | Parent State |
+|------|-------|--------|--------------|
+| AB#4710 | Add export endpoint | AB#4521 | Deployed |
+| AB#4711 | Wire up CSV service | AB#4521 | Deployed |
+| AB#4733 | Fix null check | AB#4598 | Closed |
+
+Skipped: {n} (state transition not permitted — list any that the board rejected)
+```
+
+If any update was rejected (e.g. a required field or an invalid state transition), list it under **Skipped** with the reason rather than silently dropping it.

package/templates/commands/plan-backlog.md

@@ -89,6 +89,15 @@ Continue? (yes / cancel)
 
 **Wait for the user.** If `cancel`, stop with no changes.
 
+### Ultracode mode (optional fan-out)
+
+Only when **ultracode is on** (a system-reminder confirms it, or the user typed `ultracode`): the analysis in 5a–5c is independent per story, so pre-compute all proposals in parallel with the `Workflow` tool instead of analyzing one story at a time.
+
+- Fan out **one agent per story** that does 5a–5c — re-read the story, map points → budget, tailor the task list — and returns a structured proposal (story id, points, budget, and the list of `{title, hours}` tasks). Use a `schema` so each agent returns validated JSON.
+- Then run Step 5's loop **using the pre-computed proposals** — but keep 5d (approval) and 5e (creation) exactly as written: present each proposal, wait for `yes / edit / skip / cancel-all`, and create tasks only after approval. **Never fan out the approval or the work-item creation** — those stay sequential and interactive.
+
+If ultracode is off, ignore this and run Step 5 the normal sequential way. The output is identical either way; ultracode only makes the analysis faster for large backlogs.
+
 ## Step 5: Per-Story Task Breakdown (loop)
 
 For each remaining story, in order:

package/templates/infrastructure/CLAUDE-WORKFLOW.md

@@ -29,6 +29,25 @@ You (give task)
   └── reviewer → reviews code quality
 ```
 
+### Ultracode (multi-agent workflows)
+
+The **agent pipeline** above (`manager` → specialists) is sequential delegation: one agent at a time, through the `Task` tool. **Ultracode** is a different, harness-level gear — it authorizes the `Workflow` tool to fan out many agents in parallel under a deterministic script. The two compose; ultracode does not replace the pipeline, it parallelizes the parts of it that are embarrassingly parallel.
+
+Ultracode is **opt-in**. It is on only when a system-reminder confirms it, when you type `ultracode` in a prompt, or when a slash command's instructions say to use `Workflow`. When it is off, everything below runs the normal sequential way — nothing changes.
+
+**Who can call `Workflow`:** the main Claude Code loop, and slash commands (they expand into the main conversation). **Subagents cannot** — so the `manager` agent, running under `Task`, never authors a workflow. Ultracode-scale fan-out is a main-loop / slash-command concern.
+
+**Kit operations that benefit from ultracode (when it's on):**
+
+| Operation | Fan-out unit |
+|-----------|--------------|
+| `/plan-backlog` | one agent per Dev Ready story — analyze, point, and propose tasks in parallel |
+| Backlog / board audits | one agent per work item — find stale, mislabeled, orphaned, or unestimated items |
+| Multi-file or cross-layer review | one agent per file/dimension, then adversarial verify before reporting |
+| Repo-wide sweeps (rename, dependency bump, pattern migration) | one agent per site, worktree-isolated |
+
+Short, single-query operations (`/status`, `/explain`, `/close-orphan-tasks`) do **not** need ultracode — they are already one pass and gain nothing from fan-out. Reach for `Workflow` when the work-list is large and the per-item work is independent.
+
 ### Sensitive Data Policy
 
 **NEVER query, display, or expose sensitive PII fields from the database — even if the values are encrypted.** This includes TIN, SSN, EIN, TaxId, BankAccountNumber, RoutingNumber, and any `Encrypted*` variants. Even encrypted/hashed values must not appear in output, logs, or summaries. When querying collections that may contain sensitive fields, always use explicit inclusion projections listing only the non-sensitive fields needed. If a user requests access to sensitive data, direct them to use the application UI.
@@ -213,6 +232,7 @@ All deployment and release operations are available as slash commands:
 | `/status` | `/status release 24` | Check release, pipeline, or work item status |
 | `/plan-backlog` | `/plan-backlog [project]` | Sweep backlog for Dev Ready stories with points and no tasks → propose child tasks with hours |
 | `/cleanup-branches` | `/cleanup-branches` | Delete merged branches |
+| `/close-orphan-tasks` | `/close-orphan-tasks [scope] [--dry-run]` | Close open Tasks whose parent is Ready to Deploy / Deployed / Closed |
 
 The CD pipeline is only triggered manually when pushing directly to an environment branch. For feature/work branches, the pipeline triggers on PR merge.