@chris1807/claude-kit 2.1.57 → 2.1.58

package/README.md

@@ -17,7 +17,7 @@ The slash commands assume Azure DevOps as the system of record:
 - **Releases & deployments** — tracked as Azure DevOps iterations (`Release #N`) and tags; CD runs on Azure Pipelines
 - **Wiki, test plans, advanced security alerts** — all surfaced through the same Azure DevOps MCP server
 
-> **Not using Azure DevOps?** The Claude Code primitives (agents, hooks, memory) are still useful, but the slash commands and the deployment workflow won't apply out of the box — you'd need to rewrite the `/implement`, `/review`, `/deploy`, `/create-release`, `/deploy-release`, `/cherry-pick`, `/promote`, `/rollback`, `/status`, `/rework`, and `/resolve-feedback` commands against GitHub / GitLab / Jira / etc.
+> **Not using Azure DevOps?** The Claude Code primitives (agents, hooks, memory) are still useful, but the slash commands and the deployment workflow won't apply out of the box — you'd need to rewrite the `/implement`, `/review`, `/deploy`, `/create-release`, `/deploy-release`, `/cherry-pick`, `/promote`, `/rollback`, `/track`, `/rework`, and `/resolve-feedback` commands against GitHub / GitLab / Jira / etc.
 
 Every session Claude learns from your feedback and gets better at helping you specifically. The infrastructure is modular — install only what your project needs.
 
@@ -28,7 +28,7 @@ Every session Claude learns from your feedback and gets better at helping you sp
 | **Global Agents** | 10 | `~/.claude/agents/` (your machine, all projects) | backend, frontend, legacy (Lucee/CFML), mockup, reviewer, test-runner, build-validator, lint-checker, azure-ops, security-auditor |
 | **Project Agents** | 2 | `.claude/agents/` (in the project) | deployer, db-admin |
 | **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** | 24 | `.claude/commands/` (in the project) | `/implement`, `/review`, `/deep-review`, `/resolve-feedback`, `/fix-review`, `/deploy`, `/create-release`, `/deploy-release`, `/add-to-release`, `/cherry-pick`, `/promote`, `/rollback`, `/status`, `/plan-backlog`, `/plan-sprint`, `/quote-backlog`, `/cleanup-branches`, `/close-orphan-tasks`, `/quote`, `/explain`, `/create-work-item`, `/edit-work-item` |
+| **Slash Commands** | 24 | `.claude/commands/` (in the project) | `/implement`, `/review`, `/deep-review`, `/resolve-feedback`, `/fix-review`, `/deploy`, `/create-release`, `/deploy-release`, `/add-to-release`, `/cherry-pick`, `/promote`, `/rollback`, `/track`, `/plan-backlog`, `/plan-sprint`, `/quote-backlog`, `/cleanup-branches`, `/close-orphan-tasks`, `/quote`, `/explain`, `/create-work-item`, `/edit-work-item` |
 | **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 |
@@ -73,7 +73,7 @@ You'll be asked:
 2. **Components** — checkboxes to pick which parts to install:
    - ☑ Project Agents (deployer, db-admin)
    - ☑ Hooks (secret blocker, auto-format, etc.)
-   - ☑ Slash Commands (/implement, /review, /resolve-feedback, /deploy, /create-release, /deploy-release, /add-to-release, /cherry-pick, /promote, /rollback, /status, /cleanup-branches, /quote, /explain)
+   - ☑ Slash Commands (/implement, /review, /resolve-feedback, /deploy, /create-release, /deploy-release, /add-to-release, /cherry-pick, /promote, /rollback, /track, /cleanup-branches, /quote, /explain)
    - ☑ MCP Servers
    - ☑ Settings
    - ☑ CLAUDE.md Workflow
@@ -214,7 +214,7 @@ your-project/                      ← Project-specific
 │   │   ├── promote.md             # /promote main dev
 │   │   ├── rollback.md            # /rollback AB#1234 prod
 │   │   ├── add-to-release.md      # /add-to-release 24 AB#4599
-│   │   ├── status.md              # /status release 24
+│   │   ├── track.md               # /track release 24
 │   │   ├── cleanup-branches.md    # /cleanup-branches
 │   │   ├── close-orphan-tasks.md  # /close-orphan-tasks
 │   │   ├── quote.md               # /quote AB#1234
@@ -261,7 +261,7 @@ Kit operations that benefit from ultracode when it's on:
 | 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`) don't need ultracode — they're already one pass and gain nothing from fan-out. Reach for it when the work-list is large and the per-item work is independent.
+Short, single-query operations (`/track`, `/explain`, `/close-orphan-tasks`) don't need ultracode — they're already one pass and gain nothing from fan-out. Reach for it when the work-list is large and the per-item work is independent.
 
 ### Implement a Work Item
 
@@ -373,11 +373,11 @@ Adds work items to an existing release — assigns them to the iteration and tag
 ### Check Status
 
 ```
-/status release 24
-/status pipeline
-/status AB#4521
-/status staging
-/status
+/track release 24
+/track pipeline
+/track AB#4521
+/track staging
+/track
 ```
 
 Shows the status of a release, pipeline, work item, environment, or a high-level overview of everything.
@@ -441,7 +441,7 @@ Every environment has a work item state, and the promotion commands keep them in
 | `test → staging` | `Ready for Staging` (QA sign-off) | `Staging` |
 | `staging → prod` | `Ready to Deploy` (stakeholder sign-off) | `Deployed` |
 
-`/deploy-release`, `/cherry-pick`, and `/promote` check the gate before creating the PR, ask who verifies each product group while the PR is in review, then watch the PR and the environment's CD pipeline — on a green pipeline they set the state and the assignee together. A failed pipeline changes nothing. `/status` flags anything whose state lags the branch it's on.
+`/deploy-release`, `/cherry-pick`, and `/promote` check the gate before creating the PR, ask who verifies each product group while the PR is in review, then watch the PR and the environment's CD pipeline — on a green pipeline they set the state and the assignee together. A failed pipeline changes nothing. `/track` flags anything whose state lags the branch it's on.
 
 ### Branch Naming
 
@@ -679,7 +679,7 @@ Claude reviews for:
 | `/cherry-pick` | `/cherry-pick AB#1234 AB#1235 prod` | Gate-check → cherry-pick specific work items to environment via PR → ask who verifies → advance + assign on a green pipeline |
 | `/promote` | `/promote main dev` | PR to promote all code to the next branch in the chain (`main → dev → test → staging → prod`) → ask who verifies → advance + assign on a green pipeline |
 | `/rollback` | `/rollback AB#1234 prod` | Revert specific commits on an environment via PR |
-| `/status` | `/status release 24` | Check status of a release, pipeline, work item, or environment; flags work items whose state lags their environment |
+| `/track` | `/track release 24` | Check status of a release, pipeline, work item, or environment; flags work items whose state lags their environment |
 | `/qa` | `/qa AB#1234 [env]` | Verify the item is fully deployed with a green pipeline → open the app in a real browser → sign in as a test account → full regression of the screens the story touched → pass/fail comment on the work item (never a state change). Environments: `local`, `dev`, `test`, `staging` |
 | `/plan-backlog` | `/plan-backlog [project]` | Sweep backlog for Dev Ready stories with points and no tasks → propose one child task with hours per story |
 | `/plan-sprint` | `/plan-sprint [project]` | Sweep the current sprint for stories/bugs with no child tasks → propose one child task with hours per item |

package/bin/cli.js

@@ -231,10 +231,14 @@ function splitWorkflowSection(existing) {
 
 const RETIRED_GLOBAL_AGENTS = ['manager.md', 'uat-generator.md', 'api-tester.md'];
 const RETIRED_PROJECT_AGENTS = ['devops-tracker.md'];
+// status.md was renamed to track.md in 2.1.58 — Claude Code ships a built-in /status,
+// which shadowed the kit's command. The old file has to be deleted from existing
+// installs or the collision never goes away, since installs only ever add files.
+const RETIRED_COMMANDS = ['status.md'];
 
-async function removeRetiredAgents(agentsDir, retired) {
+async function removeRetiredFiles(dir, retired) {
   for (const file of retired) {
-    const target = join(agentsDir, file);
+    const target = join(dir, file);
     if (await fs.pathExists(target)) {
       await fs.remove(target);
       console.log(chalk.gray(`  - ${file} (retired, removed)`));
@@ -258,7 +262,7 @@ async function installGlobalAgents() {
       );
     }
   }
-  await removeRetiredAgents(globalAgentsDir, RETIRED_GLOBAL_AGENTS);
+  await removeRetiredFiles(globalAgentsDir, RETIRED_GLOBAL_AGENTS);
 }
 
 // ============================================================================
@@ -308,7 +312,7 @@ async function main() {
       choices: [
         { name: 'Project Agents (deployer, db-admin)', value: 'agents', checked: true },
         { name: 'Hooks (secret blocker, auto-format, test suggestions)', value: 'hooks', checked: true },
-        { name: 'Slash Commands (implement, review, deploy, releases, cherry-pick, promote, rollback, status, cleanup, create-work-item, …)', value: 'commands', checked: true },
+        { name: 'Slash Commands (implement, review, deploy, releases, cherry-pick, promote, rollback, track, cleanup, create-work-item, …)', value: 'commands', checked: true },
         { name: 'MCP Servers (Playwright, DB, Teams, Stripe, Azure, Azure DevOps)', value: 'mcp', checked: true },
         { name: 'Settings (hook registration)', value: 'settings', checked: true },
         { name: 'CLAUDE.md Workflow Section', value: 'workflow', checked: true },
@@ -333,7 +337,7 @@ async function main() {
         );
       }
     }
-    await removeRetiredAgents(agentsDir, RETIRED_PROJECT_AGENTS);
+    await removeRetiredFiles(agentsDir, RETIRED_PROJECT_AGENTS);
   }
 
   // ── Hooks ─────────────────────────────────────────────────────────────
@@ -369,6 +373,7 @@ async function main() {
         );
       }
     }
+    await removeRetiredFiles(cmdsDir, RETIRED_COMMANDS);
   }
 
   // ── MCP Servers (interactive selection) ───────────────────────────────

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@chris1807/claude-kit",
-  "version": "2.1.57",
+  "version": "2.1.58",
   "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/commands/cherry-pick.md

@@ -233,4 +233,4 @@ Cherry-pick is deployed to {environment} (pipeline {build-number}, succeeded).
 Next: {the human step — "QA tests on Test and sets Ready for Staging" / "stakeholders verify on Staging and set Ready to Deploy" / "verify in production, then Close"}.
 ```
 
-If the user said `stop watching`, or an update fails, leave the rest alone, say exactly which items were and were not updated, and note that `/status` will flag the lag later.
+If the user said `stop watching`, or an update fails, leave the rest alone, say exactly which items were and were not updated, and note that `/track` will flag the lag later.

package/templates/commands/deploy-release.md

@@ -292,7 +292,7 @@ Release #{N} is on {environment} (pipeline {build-number}, succeeded).
 Next: {the human step — "QA tests on Test and sets Ready for Staging" / "stakeholders verify on Staging and set Ready to Deploy" / "verify in production, then Close"}.
 ```
 
-If the user said `stop watching`, or an update fails, leave the rest alone, say exactly which items were and were not updated, and note that `/status release {N}` will flag the lag later.
+If the user said `stop watching`, or an update fails, leave the rest alone, say exactly which items were and were not updated, and note that `/track release {N}` will flag the lag later.
 
 ## Step 11: Notify Team (if Teams MCP is configured)
 

package/templates/commands/promote.md

@@ -227,4 +227,4 @@ Report both fields, so a wrong assignment is easy to put back:
 Next: {the human step — "QA tests on Test and sets Ready for Staging" / "stakeholders verify on Staging and set Ready to Deploy" / "verify in production, then Close"}.
 ```
 
-If the user said `stop watching`, or an update fails, leave the rest alone, say exactly which items were and were not updated, and note that `/status` will flag the lag later.
+If the user said `stop watching`, or an update fails, leave the rest alone, say exactly which items were and were not updated, and note that `/track` will flag the lag later.

package/templates/commands/{status.md → track.md}

@@ -1,4 +1,4 @@
-Check the status of a release, pipeline, environment, or work item. Usage: `/status <target>`
+Check the status of a release, pipeline, environment, or work item. Usage: `/track <target>`
 
 Parse `$ARGUMENTS` to determine what to check:
 - **Release**: "release 24" or "r24" → show release status
@@ -23,7 +23,7 @@ Work item states track environments. Use this to spot **state lag** — an item
 
 `Ready for Staging` and `Ready to Deploy` are human sign-offs and are never "lag". Only User Stories, Bugs, and Hot Fixes are checked — Features and Tasks have no environment state.
 
-## If Release (e.g., `/status release 24`):
+## If Release (e.g., `/track release 24`):
 
 Query all work items tagged `release-{N}` or in the `Release #{N}` iteration. For each, find which environment branches contain its commits (`repo_search_commits` with `includeWorkItems: true`, or `git merge-base --is-ancestor`).
 
@@ -51,7 +51,7 @@ Catch these up? (yes/no)
 
 If the user says yes, set `System.State` on each lagging item to the expected state via `wit_update_work_item` — never backward, never on a Feature or Task — and report `Was → Now`.
 
-## If Pipeline (e.g., `/status pipeline` or `/status build`):
+## If Pipeline (e.g., `/track pipeline` or `/track build`):
 
 Query recent builds for each pipeline in the Pipeline Configuration table.
 
@@ -67,7 +67,7 @@ Query recent builds for each pipeline in the Pipeline Configuration table.
 
 A run on `main` would be unexpected — `main` has no pipeline. If one appears, say so.
 
-## If Work Item (e.g., `/status AB#4521`):
+## If Work Item (e.g., `/track AB#4521`):
 
 Read the work item from Azure DevOps and show its full status, including which environment branches contain its commits.
 
@@ -102,7 +102,7 @@ State `Staging` matches the furthest environment. ✓
 
 If the state lags the furthest environment, flag it and offer to catch it up as in the release view.
 
-## If Environment (e.g., `/status staging`):
+## If Environment (e.g., `/track staging`):
 
 Map the name to its branch through the Pipeline Configuration table. Show the last deployment and what's currently there.
 
@@ -123,9 +123,9 @@ Map the name to its branch through the Pipeline Configuration table. Show the la
 {count} commits on `test` are not on `staging` — run `/promote test staging` or `/deploy-release <N> staging`.
 ```
 
-`/status main` is allowed but reports "compare branch — nothing deploys from main" and lists what's on `main` that hasn't been promoted to `dev`.
+`/track main` is allowed but reports "compare branch — nothing deploys from main" and lists what's on `main` that hasn't been promoted to `dev`.
 
-## If No Argument (e.g., `/status`):
+## If No Argument (e.g., `/track`):
 
 Show a high-level overview.
 

package/templates/commands/where.md

@@ -88,6 +88,6 @@ Open PRs:
 - PR #<n> → <target branch> (<status>)
 ```
 
-Finally, compare the work item's state with its furthest environment (`dev` → `Ready for Testing`, `test` → `Testing`, `staging` → `Staging`, `prod` → `Deployed`). If the state lags — e.g. commits on `staging` but the item is still `Testing` — add one line: `⚠ State lags environment: Testing, expected at least Staging — /status AB#<id> can catch it up.`
+Finally, compare the work item's state with its furthest environment (`dev` → `Ready for Testing`, `test` → `Testing`, `staging` → `Staging`, `prod` → `Deployed`). If the state lags — e.g. commits on `staging` but the item is still `Testing` — add one line: `⚠ State lags environment: Testing, expected at least Staging — /track AB#<id> can catch it up.`
 
 That's it — read-only. Do not modify branches, push, create PRs, or change states.

package/templates/infrastructure/CLAUDE-WORKFLOW.md

@@ -47,7 +47,7 @@ Ultracode is **opt-in**. It is on only when a system-reminder confirms it, when
 | 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.
+Short, single-query operations (`/track`, `/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.
 
 **`/rework` always uses ultracode** — it does not wait to be asked. It fans out feedback gathering, codebase exploration, per-acceptance-criterion coverage checks, and the find → adversarially-verify review, while keeping every approval gate and write in the main loop.
 
@@ -178,7 +178,7 @@ Human-only transitions — no slash command ever makes these: `Testing → Ready
 How the commands use this table:
 
 - **Gate check before the PR.** `/deploy-release`, `/cherry-pick`, and `/promote` compare each carried work item's state against the gate for the target environment. Anything behind the gate (e.g. still `Testing` when deploying to `staging`) is flagged and the user decides whether to include it. Items *ahead* of the gate (e.g. already `Deployed` on a cherry-pick to `prod`) are reported and left alone.
-- **Advance on a green pipeline, automatically.** `/promote`, `/cherry-pick`, and `/deploy-release` do not stop at the PR. They poll it until it is `completed`, then poll the target branch's CD pipeline until every run finishes. Only on `succeeded` do they write the new state — for every carried User Story, Bug, and Hot Fix, never a Feature or Task, and never backward. A failed or canceled run changes **nothing** and is reported with the log link. `/status` reports items whose state lags the branch their commits are on and offers to catch them up.
+- **Advance on a green pipeline, automatically.** `/promote`, `/cherry-pick`, and `/deploy-release` do not stop at the PR. They poll it until it is `completed`, then poll the target branch's CD pipeline until every run finishes. Only on `succeeded` do they write the new state — for every carried User Story, Bug, and Hot Fix, never a Feature or Task, and never backward. A failed or canceled run changes **nothing** and is reported with the log link. `/track` reports items whose state lags the branch their commits are on and offers to catch them up.
 - **Assign the verifier at the same time.** The state change hands the item to a person, so the same three commands ask **before the merge** who each group of items should go to, then apply the assignee alongside the state once the pipeline is green. See **Verifier Assignment** below.
 - **Never assume the state list.** Confirm with `mcp__azure-devops__wit_work_item` (`action: get_type`) on an unfamiliar project before writing a state name — a bad name is accepted silently by a query and rejected only at write time.
 
@@ -307,7 +307,7 @@ All deployment and release operations are available as slash commands:
 | `/cherry-pick` | `/cherry-pick AB#1234 AB#1235 prod` | Gate-check → cherry-pick specific work items → PR → ask who verifies → advance + assign on a green pipeline |
 | `/promote` | `/promote main dev` | Promote all code between environments (`main → dev → test → staging → prod`) → ask who verifies → advance + assign on a green pipeline |
 | `/rollback` | `/rollback AB#1234 prod` | Revert commits on an environment |
-| `/status` | `/status release 24` | Check release, pipeline, environment, or work item status; flags work items whose state lags their environment |
+| `/track` | `/track release 24` | Check release, pipeline, environment, or work item status; flags work items whose state lags their environment |
 | `/where` | `/where AB#1234` | Show which environment branches contain a work item's commits |
 | `/qa` | `/qa AB#1234 [env]` | Verify the item is fully deployed with a green pipeline → open the app in a real browser → sign in as a test account → full regression of the screens the story touched → pass/fail comment (never a state change) |
 | `/plan-backlog` | `/plan-backlog [project]` | Sweep backlog for Dev Ready stories with points and no tasks → propose child tasks with hours |
@@ -323,7 +323,7 @@ The CD pipeline is only triggered manually when pushing directly to an environme
 
 ### Pipeline Configuration
 
-Each project must define its compare branch, its environment chain, and its pipeline IDs so the slash commands (`/deploy`, `/promote`, `/deploy-release`, `/cherry-pick`, `/where`, `/status`) know which pipelines to trigger and what the promotion order is.
+Each project must define its compare branch, its environment chain, and its pipeline IDs so the slash commands (`/deploy`, `/promote`, `/deploy-release`, `/cherry-pick`, `/where`, `/track`) know which pipelines to trigger and what the promotion order is.
 
 Add this section to your project's `CLAUDE.md`:
 
@@ -345,7 +345,7 @@ Add this section to your project's `CLAUDE.md`:
 - `/deploy` triggers the pipeline(s) listed for the current branch. If the current branch is not in this table, or its pipeline cell is `—`, no pipeline is triggered.
 - `/promote` uses this table to determine the next environment (the next row down).
 - `/deploy-release` and `/cherry-pick` create PRs targeting environment branches listed here, and use the **Work Item States ↔ Environments** table to gate-check and advance work items.
-- `/where` and `/status` check every row; the compare branch reports as "merged to main", not as a deployment.
+- `/where` and `/track` check every row; the compare branch reports as "merged to main", not as a deployment.
 
 **Examples from actual projects:**