@chris1807/claude-kit 2.1.30 → 2.1.32

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, the `devops-tracker` agent, 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`, `/status`, `/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.
 
@@ -25,8 +25,8 @@ Every session Claude learns from your feedback and gets better at helping you sp
 
 | Component | Count | Where Installed | Description |
 |-----------|-------|----------------|-------------|
-| **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 |
+| **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** | 21 | `.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`, `/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 |
@@ -71,7 +71,7 @@ npx @chris1807/claude-kit init
 You'll be asked:
 1. **Target directory** — where is your project?
 2. **Components** — checkboxes to pick which parts to install:
-   - ☑ Project Agents (deployer, db-admin, devops-tracker)
+   - ☑ 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)
    - ☑ MCP Servers
@@ -103,8 +103,8 @@ npx @chris1807/claude-kit init --all
 ```
 
 This installs:
-- ✅ Global agents (backend, frontend, legacy, manager, mockup, reviewer, test-runner, build-validator, lint-checker, uat-generator, azure-ops, security-auditor, api-tester)
-- ✅ Project agents (deployer, db-admin, devops-tracker)
+- ✅ Global agents (backend, frontend, legacy, mockup, reviewer, test-runner, build-validator, lint-checker, azure-ops, security-auditor)
+- ✅ Project agents (deployer, db-admin)
 - ✅ All 9 hooks
 - ✅ All 13 slash commands
 - ✅ MCP servers: Playwright, Teams, Azure CLI (+ your DB choice)
@@ -161,12 +161,11 @@ The installer automatically **skips global agents** that are already installed (
 📦 Global Agents → ~/.claude/agents/
   = azure-ops.md (identical, skipped)       ← already installed, skipped
   = security-auditor.md (identical, skipped)
-  = api-tester.md (identical, skipped)
+  = reviewer.md (identical, skipped)
 
 📦 Project Agents → .claude/agents/         ← fresh install for this project
   ✓ deployer.md
   ✓ db-admin.md
-  ✓ devops-tracker.md
   ...
 ```
 
@@ -179,23 +178,19 @@ The installer automatically **skips global agents** that are already installed (
 ├── backend.md                     # .NET/C# backend developer (Clean Architecture)
 ├── frontend.md                    # React/TypeScript frontend developer
 ├── legacy.md                      # Lucee/CFML legacy app developer (RBWO + others)
-├── manager.md                     # Workflow orchestrator (delegates to other agents)
 ├── mockup.md                      # HTML mockup designer
 ├── reviewer.md                    # Code reviewer (read-only)
 ├── test-runner.md                 # Test executor — xUnit, Vitest, Playwright (read-only)
 ├── build-validator.md             # Build checker (read-only)
 ├── lint-checker.md                # ESLint + dotnet format checker
-├── uat-generator.md               # UAT checklist generator (read-only)
 ├── azure-ops.md                   # Azure infrastructure management
-├── security-auditor.md            # Security scanning (read-only)
-└── api-tester.md                  # API endpoint testing
+└── security-auditor.md            # Security scanning (read-only)
 
 your-project/                      ← Project-specific
 ├── .claude/
 │   ├── agents/
 │   │   ├── deployer.md            # Commit → push → deploy → monitor
-│   │   ├── db-admin.md            # Database queries and data management
-│   │   └── devops-tracker.md      # Azure DevOps work item management
+│   │   └── db-admin.md            # Database queries and data management
 │   │
 │   ├── hooks/
 │   │   ├── sensitive-data-blocker.sh       # BLOCKS mongosh queries for TIN/SSN/PII
@@ -248,11 +243,11 @@ Verify MCP servers are connected:
 
 ### Ultracode (multi-agent workflows)
 
-The kit's agents normally run as **sequential delegation** — the `manager` agent hands work to one specialist at a time through the `Task` tool. **Ultracode** is a separate, harness-level gear that authorizes the `Workflow` tool to fan out many agents in parallel under a deterministic script. The two compose: ultracode doesn't replace the pipeline, it parallelizes the parts that are embarrassingly parallel.
+The kit's agents normally run as **sequential delegation** — the main loop hands work to one specialist at a time through the `Task` tool. **Ultracode** is a separate, harness-level gear that authorizes the `Workflow` tool to fan out many agents in parallel under a deterministic script. The two compose: ultracode doesn't replace the pipeline, it parallelizes the parts that are embarrassingly parallel.
 
 Ultracode is **opt-in**. It's on only when you type `ultracode` in a prompt, when a system-reminder confirms it, or when a slash command's instructions say to use `Workflow`. When it's off, everything runs the normal sequential way — nothing changes.
 
-Only the **main Claude Code loop** and **slash commands** can call `Workflow`. Subagents (anything running under `Task`, including `manager`) cannot — so ultracode-scale fan-out is a main-loop / slash-command concern.
+Only the **main Claude Code loop** and **slash commands** can call `Workflow`. Subagents (anything running under `Task`) cannot — so ultracode-scale fan-out is a main-loop / slash-command concern.
 
 Kit operations that benefit from ultracode when it's on:
 

package/bin/cli.js

@@ -156,6 +156,24 @@ function mergeHooks(existing, template) {
 // ============================================================================
 // Step 1: Global Agents (always)
 // ============================================================================
+
+// Agents removed from the kit, cleaned up on install/update so stale copies
+// don't linger. manager/uat-generator/api-tester were superseded by the
+// Workflow tool and inline command steps; devops-tracker by direct Azure
+// DevOps MCP access in the main loop.
+const RETIRED_GLOBAL_AGENTS = ['manager.md', 'uat-generator.md', 'api-tester.md'];
+const RETIRED_PROJECT_AGENTS = ['devops-tracker.md'];
+
+async function removeRetiredAgents(agentsDir, retired) {
+  for (const file of retired) {
+    const target = join(agentsDir, file);
+    if (await fs.pathExists(target)) {
+      await fs.remove(target);
+      console.log(chalk.gray(`  - ${file} (retired, removed)`));
+    }
+  }
+}
+
 async function installGlobalAgents() {
   console.log(chalk.yellow.bold('\n📦 Global Agents → ~/.claude/agents/\n'));
 
@@ -172,6 +190,7 @@ async function installGlobalAgents() {
       );
     }
   }
+  await removeRetiredAgents(globalAgentsDir, RETIRED_GLOBAL_AGENTS);
 }
 
 // ============================================================================
@@ -219,7 +238,7 @@ async function main() {
       name: 'selected',
       message: 'Select components to install:',
       choices: [
-        { name: 'Project Agents (deployer, db-admin, devops-tracker)', value: 'agents', checked: true },
+        { 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: 'MCP Servers (Playwright, DB, Teams, Stripe, Azure, Azure DevOps)', value: 'mcp', checked: true },
@@ -246,6 +265,7 @@ async function main() {
         );
       }
     }
+    await removeRetiredAgents(agentsDir, RETIRED_PROJECT_AGENTS);
   }
 
   // ── Hooks ─────────────────────────────────────────────────────────────

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@chris1807/claude-kit",
-  "version": "2.1.30",
+  "version": "2.1.32",
   "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/implement.md

@@ -1,13 +1,15 @@
 Implement work item AB#$ARGUMENTS. Follow this workflow:
 
-## Ultracode (scaled to the change)
+## Ultracode (opt-in — ask the user)
 
-This command orchestrates its analysis phases with the `Workflow` tool, but **scaled to the size of the work** — `/implement` is the daily driver and spans one-line config tweaks to full features, so it does not blanket-fan-out the way `/rework` does. The slash command runs in the main loop, which has the `Workflow` tool.
+This command **can** orchestrate its analysis phases with the `Workflow` tool, but only if the user opts in. The user is asked once, as part of the Step 2 confirmation, whether to use Ultracode effort for this run. Do not fan out before that answer, and do not silently decide for the user.
 
-The rule:
+- **If the user says yes:** apply the fan-out rules below — review (Step 8) runs as the find → adversarially-verify pipeline, and exploration / per-AC coverage (Steps 3, 7) fan out when the change is non-trivial (a full-stack story, multiple subsystems, or several acceptance criteria; skip the fan-out for a trivial single-file or config change).
+- **If the user says no:** run every phase sequentially in the main loop — same steps, same gates, no `Workflow` calls.
 
-- **Code review (Step 8) always fans out** — the find → adversarially-verify pipeline. Review is bounded by the diff, so cost scales with the change, and review quality matters as much for fresh code as for rework.
-- **Exploration and per-AC coverage (Steps 3, 7) fan out only when the change is non-trivial** — a full-stack story, multiple subsystems, or several acceptance criteria. For a trivial single-file or config change, skip the fan-out and run those steps lean in the main loop. Judge this from the plan in Step 3.
+When recommending a default in the Step 2 prompt, suggest **yes** for multi-subsystem / multi-AC work and **no** for trivial changes.
+
+The remaining rules apply whenever Ultracode is in use:
 - **Never fan out an interactive gate or a write.** Every user prompt (Steps 2, 3-approval, 8-decisions, 9) and every git / work-item mutation (Steps 4, 5, 10) stays in the **main loop**. Workflow agents here are **read-only analysts** — they use MCP read tools, `Read`, and `Grep`, and return structured findings. They do not write code, create/close work items, switch branches, or ask the user anything.
 - **Stay in the loop between phases** — one short workflow per phase, read its results, present/await the user, then continue.
 
@@ -48,13 +50,15 @@ Present a summary of the work item to the user:
 {acceptance criteria — numbered list}
 
 Does this look correct? Do you have any additional context or requirements?
+
+Use **Ultracode effort** for this run? Ultracode fans out exploration, AC-coverage checks, and code review across parallel agents — more thorough, but slower and more token-hungry. (yes / no — suggested: {yes for multi-subsystem / multi-AC work, no for trivial changes})
 ```
 
-**Wait for the user to respond.** Do NOT proceed until the user confirms or provides additional context. If they add context, incorporate it into the plan.
+**Wait for the user to respond.** Do NOT proceed until the user confirms or provides additional context. If they add context, incorporate it into the plan. Record the Ultracode answer — it governs whether the `Workflow` fan-outs in Steps 3, 7, and 8 run at all.
 
 ## Step 3: Explore & Plan
 
-> **Ultracode (non-trivial only):** If the work is full-stack, spans multiple subsystems, or has several acceptance criteria, fan out the exploration with `Workflow` — one read-only agent per subsystem/area, each returning the relevant files and how they relate to the requirements, plus one agent per acceptance criterion reporting what already exists and what's missing. Synthesize into a single plan in the main loop. For a trivial single-file or config change, skip the fan-out and explore directly. Either way, the plan synthesis and the approval gate stay in the main loop.
+> **Ultracode (if opted in, non-trivial only):** If the work is full-stack, spans multiple subsystems, or has several acceptance criteria, fan out the exploration with `Workflow` — one read-only agent per subsystem/area, each returning the relevant files and how they relate to the requirements, plus one agent per acceptance criterion reporting what already exists and what's missing. Synthesize into a single plan in the main loop. For a trivial single-file or config change, skip the fan-out and explore directly. Either way, the plan synthesis and the approval gate stay in the main loop.
 
 1. **Explore** the codebase to map relevant files
 2. **Plan** the implementation approach
@@ -164,11 +168,11 @@ Run a build check **before** any other quality checks. Use the `build-validator`
 
    Do not advance to Step 8 with any AC unverified.
 
-   > **Ultracode (non-trivial only):** When the story has several acceptance criteria, fan out this check with `Workflow` — one read-only agent per AC, each returning `{ac, covered: bool, evidence, gap?}`. Collect the results in the main loop and act on any `covered: false`. For a story with one or two ACs, just check them directly.
+   > **Ultracode (if opted in, non-trivial only):** When the story has several acceptance criteria, fan out this check with `Workflow` — one read-only agent per AC, each returning `{ac, covered: bool, evidence, gap?}`. Collect the results in the main loop and act on any `covered: false`. For a story with one or two ACs, just check them directly.
 
 ## Step 8: Code Review
 
-> **Ultracode (always):** Run the review as a `Workflow` find → verify pipeline. **Find:** fan out one agent per dimension — correctness/quality, security, Clean Architecture compliance, and CLAUDE.md adherence — each scoped to the diff and returning structured findings. **Verify:** for each finding, spawn independent skeptic agents prompted to *refute* it, and drop any finding the majority refute. Only confirmed findings reach the user. Use the `reviewer` agent type for the dimension agents (`agentType: 'reviewer'`) so they inherit its review rules. The fix/decision loop below stays in the main loop — workflow agents never edit code.
+> **Ultracode (if opted in):** Run the review as a `Workflow` find → verify pipeline. **Find:** fan out one agent per dimension — correctness/quality, security, Clean Architecture compliance, and CLAUDE.md adherence — each scoped to the diff and returning structured findings. **Verify:** for each finding, spawn independent skeptic agents prompted to *refute* it, and drop any finding the majority refute. Only confirmed findings reach the user. Use the `reviewer` agent type for the dimension agents (`agentType: 'reviewer'`) so they inherit its review rules. The fix/decision loop below stays in the main loop — workflow agents never edit code.
 
 Review the diff for quality, security, Clean Architecture compliance, and CLAUDE.md adherence. Review is read-only — it reports findings, you act on them.
 

package/templates/commands/rework.md

@@ -1,10 +1,15 @@
 Rework work item AB#$ARGUMENTS based on feedback received after the last pull request. Follow this workflow:
 
-## Always Use Ultracode
+## Ultracode (opt-in — ask the user)
 
-This command **always orchestrates its analysis-heavy phases with the `Workflow` tool** — you do not wait to be asked, and you do not need the `ultracode` keyword. The slash command runs in the main loop, which has the `Workflow` tool, so fan-out is available throughout.
+This command **can** orchestrate its analysis-heavy phases with the `Workflow` tool, but only if the user opts in. The user is asked once, as part of the Step 3 confirmation, whether to use Ultracode effort for this run. Do not fan out before that answer, and do not silently decide for the user.
 
-What this means in practice:
+- **If the user says yes:** apply the fan-out rules below and the per-step **Ultracode** callouts throughout this document.
+- **If the user says no:** run every phase sequentially in the main loop — same steps, same gates, no `Workflow` calls. Skip the per-step **Ultracode** callouts.
+
+The one exception is Step 2 (gathering feedback), which runs **before** the Step 3 prompt — run it in the main loop regardless; only fan it out if the user already opted in via the `ultracode` keyword in their invocation.
+
+When Ultracode is in use, these rules apply:
 
 - **Fan out the read / analyze / verify work** — gathering feedback (Step 2), exploring the codebase (Step 4), and reviewing + verifying the diff and AC coverage (Steps 9–10) are run as `Workflow` scripts with one agent per independent unit (per comment, per subsystem, per review dimension, per acceptance criterion). Each agent returns **structured findings** via a `schema`; you synthesize the results in the main loop.
 - **Never fan out an interactive gate or a write.** Every user prompt (Steps 3, 4-approval, 5, 10-decisions, 11) and every work-item or git mutation (Step 5 create, Step 6 branch, Step 7 implement, Step 12 push/close) stays in the **main loop**. Workflow agents here are **read-only analysts** — they use MCP read tools, `Read`, and `Grep`, and they return data. They do not create or close work items, switch branches, write code, or ask the user anything.
@@ -27,7 +32,7 @@ Save the PR's `creationDate` as `LAST_PR_DATE` — everything after this timesta
 
 ## Step 2: Gather Rework Feedback
 
-> **Ultracode:** Fan out the gathering with `Workflow` — one agent per new comment (parse its text and **download + view every embedded image** via `WebFetch`), plus one agent analyzing the description / acceptance-criteria revisions since `LAST_PR_DATE`. Each agent returns a structured feedback item (`{source, summary, imageObservations, referencedAC?}`). Synthesize them into the Step 3 list in the main loop. Reading and image analysis are independent per comment — this is the fan-out unit.
+> **Ultracode (if opted in):** Fan out the gathering with `Workflow` — one agent per new comment (parse its text and **download + view every embedded image** via `WebFetch`), plus one agent analyzing the description / acceptance-criteria revisions since `LAST_PR_DATE`. Each agent returns a structured feedback item (`{source, summary, imageObservations, referencedAC?}`). Synthesize them into the Step 3 list in the main loop. Reading and image analysis are independent per comment — this is the fan-out unit.
 
 ### New Comments
 
@@ -72,13 +77,15 @@ Present a summary of the rework feedback to the user. **Every feedback item must
 {description/acceptance criteria changes since last PR, or "No changes to description or acceptance criteria since last PR"}
 
 Does this capture the rework correctly? Any feedback items that should be flagged as scope-creep (separate work item) instead of being addressed here?
+
+Use **Ultracode effort** for this rework? Ultracode fans out exploration, AC-coverage checks, and code review across parallel agents — more thorough, but slower and more token-hungry. (yes / no — suggested: {yes for multi-file / multi-AC rework, no for a small targeted fix})
 ```
 
-**Wait for the user to respond.** Do NOT proceed until the user confirms the AC mapping. If they reclassify any item as scope-creep, drop it from the plan and note it in the final summary. If they add context, incorporate it.
+**Wait for the user to respond.** Do NOT proceed until the user confirms the AC mapping. Record the Ultracode answer — it governs whether the `Workflow` fan-outs in Steps 4, 9, and 10 run at all. If they reclassify any item as scope-creep, drop it from the plan and note it in the final summary. If they add context, incorporate it.
 
 ## Step 4: Explore & Plan
 
-> **Ultracode:** Fan out the exploration with `Workflow` — one read-only agent per subsystem touched by the last PR (and per new area the feedback implies), each returning the relevant files and how they relate to the feedback. In the same pass, fan out **one agent per acceptance criterion** to report whether the current code covers it and what's missing. Synthesize all findings into a single plan in the main loop, then present it. Exploration and per-AC coverage analysis are independent — fan them out; the plan synthesis and the approval gate stay in the main loop.
+> **Ultracode (if opted in):** Fan out the exploration with `Workflow` — one read-only agent per subsystem touched by the last PR (and per new area the feedback implies), each returning the relevant files and how they relate to the feedback. In the same pass, fan out **one agent per acceptance criterion** to report whether the current code covers it and what's missing. Synthesize all findings into a single plan in the main loop, then present it. Exploration and per-AC coverage analysis are independent — fan them out; the plan synthesis and the approval gate stay in the main loop.
 
 1. **Explore** the codebase to map relevant files — focus on files changed in the last PR and any new areas needed
 2. **Plan** the rework approach
@@ -240,7 +247,7 @@ Run a build check **before** any other quality checks. Use the `build-validator`
 3. **Environment configuration parity** — if the rework added or changed any key in `appsettings.*.json` or `.env*`, verify every parallel environment file (Development/Staging/QA/Production for backend; `.env.development`/`.env.staging`/`.env.production`/`.env.example` for React — whichever exist in the repo) has a corresponding entry. Present a (key × environment) table. Prompt the user to fill in any missing values (real, placeholder, or empty) **before pushing**, or to explicitly confirm the omission is intentional (e.g., supplied via a pipeline variable group, Key Vault, or App Configuration).
 4. **Acceptance Criteria check** — re-read the work item's full Acceptance Criteria (the same list captured in Step 3). For each AC, identify the test or piece of code that proves it's met. If any AC has no covering test or visible code path, flag it before moving on.
 
-   > **Ultracode:** Fan out this check with `Workflow` — one read-only agent per acceptance criterion, each returning `{ac, covered: bool, evidence, gap?}`. Collect the results in the main loop and act on any `covered: false`.
+   > **Ultracode (if opted in):** Fan out this check with `Workflow` — one read-only agent per acceptance criterion, each returning `{ac, covered: bool, evidence, gap?}`. Collect the results in the main loop and act on any `covered: false`.
 
    ```
    ⚠ AC #{n} ({short form}) has no covering test or clear code path.
@@ -251,7 +258,7 @@ Run a build check **before** any other quality checks. Use the `build-validator`
 
 ## Step 10: Code Review
 
-> **Ultracode:** Run the review as a `Workflow` find → verify pipeline. **Find:** fan out one agent per dimension — correctness/quality, security, Clean Architecture compliance, CLAUDE.md adherence, and regression risk from the rework — each scoped to the files changed since the last PR and returning structured findings. **Verify:** for each finding, spawn independent skeptic agents prompted to *refute* it, and drop any finding the majority refute. Only confirmed findings reach the user. Use the `reviewer` agent type for the dimension agents (`agentType: 'reviewer'`) so they inherit its review rules. The fix/decision loop below stays in the main loop — workflow agents never edit code.
+> **Ultracode (if opted in):** Run the review as a `Workflow` find → verify pipeline. **Find:** fan out one agent per dimension — correctness/quality, security, Clean Architecture compliance, CLAUDE.md adherence, and regression risk from the rework — each scoped to the files changed since the last PR and returning structured findings. **Verify:** for each finding, spawn independent skeptic agents prompted to *refute* it, and drop any finding the majority refute. Only confirmed findings reach the user. Use the `reviewer` agent type for the dimension agents (`agentType: 'reviewer'`) so they inherit its review rules. The fix/decision loop below stays in the main loop — workflow agents never edit code.
 
 Review the rework diff for quality, security, Clean Architecture compliance, and CLAUDE.md adherence. Focus the review on the files changed since the last PR — call out any regression risk introduced by the rework. Review is read-only — it reports findings, you act on them.
 

package/templates/hooks/uat-reminder.sh

@@ -1,9 +1,9 @@
 #!/bin/bash
-# UAT Reminder Hook for Glasswing-and-Monarch
+# UAT Reminder Hook
 # Fires on the Stop event to remind about UAT after feature implementation
 #
 # This checks if recent conversation context suggests a feature was being
 # implemented and reminds the user to run UAT before marking it complete.
 
 echo "Reminder: If you just completed a feature implementation, run UAT before marking it done."
-echo "Use: 'Use gm-uat-generator to create UAT checklist for [Feature ID]'"
+echo "Ask Claude to generate a UAT checklist from the work item's acceptance criteria."

package/templates/infrastructure/CLAUDE-WORKFLOW.md

@@ -11,31 +11,29 @@ When given a task, Claude Code can delegate through specialized agents:
 
 ```
 You (give task)
-  ├── manager → orchestrates workflow, delegates to agents below
-  ├── Explore → finds relevant files
-  ├── Plan → designs the approach
+  ├── Explore → finds relevant files (built-in)
+  ├── Plan → designs the approach (built-in)
   ├── mockup → creates HTML screen mockups before implementation
   ├── backend / frontend / legacy → implements code
   ├── deployer → commits, pushes, triggers CD pipeline
   ├── db-admin → queries/fixes MongoDB data
-  ├── devops-tracker → creates/updates Azure DevOps work items
   ├── test-runner → runs xUnit, Vitest, Playwright tests
   ├── build-validator → confirms builds pass
   ├── lint-checker → runs ESLint and dotnet format
-  ├── uat-generator → generates UAT checklists from requirements
   ├── security-auditor → scans for secrets, vulnerabilities
-  ├── api-tester → tests API endpoints with curl
   ├── azure-ops → manages Azure infrastructure
   └── reviewer → reviews code quality
 ```
 
+Orchestration, Azure DevOps work-item management, UAT checklist generation, and ad-hoc API testing are handled directly by the main Claude Code loop (via the `Workflow` tool, the Azure DevOps MCP server, the `/implement`/`/rework` UAT steps, and curl) — they no longer have dedicated agents.
+
 ### 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.
+The **agent pipeline** above is sequential delegation: one specialist 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.
+**Who can call `Workflow`:** the main Claude Code loop, and slash commands (they expand into the main conversation). **Subagents cannot** — ultracode-scale fan-out is a main-loop / slash-command concern.
 
 **Kit operations that benefit from ultracode (when it's on):**
 
@@ -102,7 +100,7 @@ Claude maintains persistent memory across sessions in `~/.claude/projects/.../me
 5. **Create a release** using `/create-release <N>` to group work items
 6. **Deploy the release** using `/deploy-release 23 staging` then `/deploy-release 23 production`
 7. **Test** using Playwright MCP for browser testing
-8. **Track** work items using the devops-tracker agent
+8. **Track** work items via the Azure DevOps MCP server
 9. **Learn** — Claude saves what worked for next time
 
 ### Branching Strategy

package/templates/agents/global/api-tester.md

@@ -1,75 +0,0 @@
----
-name: api-tester
-description: Tests API endpoints — auth flows, CRUD operations, error handling. Use to verify APIs work correctly after changes.
-tools:
-  - Bash
-  - Read
-  - Grep
-  - Glob
-model: sonnet
----
-
-# API Tester Agent
-
-You test REST API endpoints using `curl`. You verify authentication, request/response formats, error handling, and business logic.
-
-## Testing Flow
-
-### 1. Authenticate First
-```bash
-# Get a JWT token
-TOKEN=$(curl -s -X POST "$API_URL/api/v1/auth/login" \
-  -H "Content-Type: application/json" \
-  -H "X-Organization-Subdomain: $SUBDOMAIN" \
-  -d '{"email":"EMAIL","password":"PASSWORD"}' \
-  | python3 -c "import sys,json; print(json.load(sys.stdin)['data']['accessToken'])")
-```
-
-### 2. Test Endpoint
-```bash
-curl -s "$API_URL/api/v1/ENDPOINT" \
-  -H "Authorization: Bearer $TOKEN" \
-  -H "Content-Type: application/json" \
-  -H "X-Organization-Subdomain: $SUBDOMAIN"
-```
-
-### 3. Report Results
-
-For each endpoint tested, report:
-```
-ENDPOINT: METHOD /api/v1/path
-STATUS: 200 | 400 | 401 | 403 | 404 | 500
-RESPONSE: (summarized)
-RESULT: PASS | FAIL
-NOTES: any issues found
-```
-
-## Test Categories
-
-### Happy Path
-- Valid request → expected response
-- Correct status code
-- Response body matches expected schema
-
-### Authentication
-- No token → 401
-- Invalid token → 401
-- Wrong role → 403
-- Expired token → 401
-
-### Validation
-- Missing required fields → 400 with field errors
-- Invalid data types → 400
-- Boundary values (empty strings, very long strings, negative numbers)
-
-### Error Handling
-- Non-existent resource → 404
-- Duplicate creation → 400 or 409
-- Server error → 500 (should not happen)
-
-## Rules
-- Never use real SSNs, bank accounts, or PII in test data — use placeholders
-- Always clean up test data you create (or note what was created)
-- Test both the success AND failure paths
-- Use `python3 -c "import sys,json; ..."` for JSON parsing (more reliable than jq)
-- Report ALL failures, even intermittent ones

package/templates/agents/global/manager.md

@@ -1,146 +0,0 @@
----
-name: manager
-description: Orchestrates the development workflow. Breaks down features, delegates to specialized agents, and enforces the Phase/Feature/Test/UAT workflow.
-tools: Task, Read, Write, Edit, Glob, Grep, Bash
-model: inherit
----
-
-# Team Manager
-
-You are the team manager. You orchestrate the development workflow by breaking down features into tasks, delegating to specialized agents, and enforcing the Phase -> Feature -> Implement -> Test -> UAT workflow.
-
-## Project Discovery
-
-Before starting work, discover the project:
-1. **Read `CLAUDE.md`** in the project root for project-specific rules, structure, and conventions
-2. **Find progress tracker** — Look for progress-tracker.md or similar in docs/
-3. **Find implementation roadmap** — Look for roadmap or implementation docs
-4. **Identify tech stack** — Check for .sln (backend), package.json (frontend), etc.
-
-## Your Team
-
-You have the following specialized agents available:
-
-| Agent | Role | When to Use |
-|-------|------|-------------|
-| `backend` | .NET/C# backend developer | Writing backend code (Domain, Application, Infrastructure, API layers) |
-| `frontend` | React/TypeScript frontend developer | Writing frontend code (pages, components, forms, state) |
-| `legacy` | Lucee/CFML developer | Writing and maintaining legacy CFML apps (RBWO and others) |
-| `mockup` | HTML mockup designer | Creating/updating screen mockups before implementation |
-| `reviewer` | Code reviewer | After code is written, before merge |
-| `test-runner` | Test executor | Running xUnit, Vitest, Playwright tests |
-| `uat-generator` | UAT checklist creator | After feature implementation, before sign-off |
-| `build-validator` | Build checker | After code changes, verify builds pass |
-| `lint-checker` | Lint/format checker | Check code style, optionally auto-fix |
-
-## Development Workflow
-
-Follow this workflow for every Feature:
-
-```
-1. PLAN        → Read feature requirements, break down into tasks
-2. APPROVE     → Present plan to user with files to create/modify, wait for approval
-3. MOCKUP      → If UI work: delegate to mockup for screen design
-4. IMPLEMENT   → Delegate to backend and/or frontend
-5. BUILD       → Delegate to build-validator
-6. LINT        → Delegate to lint-checker
-7. TEST        → Delegate to test-runner
-8. REVIEW      → Delegate to reviewer
-9. UAT         → Delegate to uat-generator, present to user
-10. COMPLETE   → Update progress tracker
-```
-
-### Delegation Rules
-
-- **Backend-only features** (API endpoints, business logic): Use `backend` only
-- **Frontend-only features** (UI pages, components): Use `mockup` first (if new screen), then `frontend`
-- **Full-stack features**: Use `backend` first (APIs), then `frontend` (UI consuming APIs)
-- **Always validate builds** after implementation with `build-validator`
-- **Always run tests** after builds pass with `test-runner`
-- **Always review** after tests pass with `reviewer`
-- **Always generate UAT** after review with `uat-generator`
-
-### Parallel Work
-
-When tasks are independent, delegate in parallel:
-- Backend and mockup design can run simultaneously
-- 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]":
-
-1. **Read project docs** — CLAUDE.md, progress tracker, roadmap
-2. **Read relevant architecture docs** — API, database, auth
-3. **Present a plan** to the user:
-   ```markdown
-   ## Feature: [ID] - [Title]
-
-   ### Tasks
-   1. [Backend/Frontend/Both] - [Description]
-   2. [Backend/Frontend/Both] - [Description]
-   ...
-
-   ### Agent Delegation Plan
-   - backend: [what it will do]
-   - frontend: [what it will do]
-   - build-validator: Validate builds
-   - test-runner: Run tests
-   - reviewer: Review code
-   - uat-generator: Generate UAT checklist
-
-   Shall I proceed?
-   ```
-4. **Wait for user approval** before delegating
-
-## Slash Commands Awareness
-
-The user may invoke slash commands directly instead of asking you to orchestrate. Be aware of these:
-
-| Command | What It Does |
-|---------|-------------|
-| `/implement AB#1234` | Full work item implementation with approval gates |
-| `/deploy "message"` | Commit, push, trigger pipeline |
-| `/create-release 24` | Group work items into a release |
-| `/deploy-release 24 staging` | Cherry-pick a release to an environment |
-| `/add-to-release 24 AB#4599` | Add work items to an existing release |
-| `/cherry-pick AB#1234 production` | Cherry-pick specific items to an environment |
-| `/promote staging production` | Promote all code between environments |
-| `/rollback AB#1234 production` | Revert commits on an environment |
-| `/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.
-
-## Completion Criteria
-
-A Feature is **complete** when:
-
-1. All code is implemented (backend + frontend as needed)
-2. Build passes (build-validator reports all green)
-3. Lint/format passes (lint-checker reports clean)
-4. Tests pass (test-runner reports all green)
-5. Code review passes (reviewer approves with no critical issues)
-6. UAT checklist generated (uat-generator produces checklist)
-7. User confirms UAT passes
-
-## Critical Rules
-
-1. **Always follow the workflow** — Never skip steps
-2. **Always wait for user approval** before starting implementation
-3. **Never mark a feature complete** without UAT sign-off
-4. **Delegate, don't implement** — Use specialized agents for code, tests, reviews
-5. **Track progress** — Update the progress tracker after each feature
-6. **Enforce CLAUDE.md rules** — Check project rules and enforce them
-7. **Present UAT** — After implementation, always generate and present the UAT checklist
-8. **One feature at a time** — Complete one feature fully before starting the next

package/templates/agents/global/uat-generator.md

@@ -1,107 +0,0 @@
----
-name: uat-generator
-description: Generates UAT (User Acceptance Testing) checklists from feature requirements. Use after completing a feature implementation.
-tools: Read, Glob, Grep
-disallowedTools: Write, Edit, Bash
-model: sonnet
----
-
-# UAT Generator
-
-You generate User Acceptance Testing (UAT) checklists for completed features. You read requirements and produce structured test checklists for the user to verify.
-
-## Project Discovery
-
-Before generating UAT, discover the project:
-1. **Read `CLAUDE.md`** for project-specific rules, UAT format, and testing requirements
-2. **Find progress tracker:** Look for progress-tracker.md or similar docs
-3. **Find technical docs:** Look for architecture, API, and feature documentation
-4. **Find mockups:** Look for HTML mockups in `Docs/` for UI expectations
-5. **Read source code:** Check the actual implementation to verify against
-
-## UAT Template
-
-Always output in this exact format:
-
-```markdown
-## UAT: [Feature ID] - [Feature Title]
-
-**Feature:** [Full feature name]
-**Date:** [Current date]
-**Environment:** Local Dev
-
-### Test Cases
-
-| # | Test | Steps | Expected Result | Pass? |
-|---|------|-------|-----------------|-------|
-| 1 | [Test name] | [Specific steps to execute] | [What should happen] | [ ] |
-| 2 | [Test name] | [Specific steps to execute] | [What should happen] | [ ] |
-| ... | | | | |
-
-### Test Data Required
-- [List any test data needed]
-
-### Prerequisites
-- [List any setup steps or running services needed]
-
-### Result
-- [ ] **PASS** — All requirements met
-- [ ] **FAIL** — Issues found (list below)
-
-### Issues Found
-(Leave blank — to be filled during testing)
-```
-
-## Test Type Templates
-
-### For API Endpoints (Backend Features)
-
-| Test | Steps | Expected Result |
-|------|-------|-----------------|
-| Endpoint exists | Call `[METHOD] /api/[path]` | Returns valid response (not 404) |
-| Authentication required | Call without auth token | Returns 401 Unauthorized |
-| Authorization works | Call with wrong role | Returns 403 Forbidden |
-| Request validation | Send invalid/empty body | Returns 400 with validation errors |
-| Success response | Send valid request with auth | Returns 200/201 with correct body |
-| Database updated | Check database after success | Record created/updated correctly |
-| Audit logged | Check audit collection | Audit entry exists for action |
-
-### For UI Components (Frontend Features)
-
-| Test | Steps | Expected Result |
-|------|-------|-----------------|
-| Matches mockup | Compare screen to HTML mockup | Layout, colors, typography match |
-| Form validation | Submit empty/invalid form | Inline error messages shown |
-| Loading states | Throttle network in DevTools | Spinner/skeleton displayed |
-| Error handling | Disconnect API/return 500 | User-friendly error message |
-| Empty state | No data available | Shows empty state message (not blank) |
-| Responsive layout | Resize to 320px, 768px, 1024px, 1440px | Layout adapts correctly |
-
-### For Workflows (Business Logic)
-
-| Test | Steps | Expected Result |
-|------|-------|-----------------|
-| Happy path | Complete full workflow | All steps succeed, final state correct |
-| Edge cases | Test boundary values | Handles gracefully |
-| Error recovery | Introduce failure mid-flow | System recovers, no data corruption |
-| State transitions | Check status at each step | Correct status progression |
-
-## Process
-
-1. **Read the feature requirements** — Check progress tracker, roadmap, and any relevant docs
-2. **Read the implementation** — Scan the actual code to understand what was built
-3. **Cross-reference mockups** — For UI features, check the HTML mockup expectations
-4. **Generate comprehensive test cases** — Cover all requirements plus edge cases
-5. **Include specific steps** — Tests must be actionable, not vague
-6. **Add prerequisites** — Note any setup, running services, or test data needed
-
-## Rules
-
-- Never modify any files — you are strictly read-only
-- Always use the exact UAT template format from above
-- Test cases must be specific and actionable (not "verify it works")
-- Include both positive tests (happy path) and negative tests (error cases)
-- Reference specific URLs, endpoints, or UI elements in test steps
-- Number test cases sequentially
-- Group related tests together
-- End with the pause prompt: `Please confirm all tests pass before proceeding to the next feature.`

package/templates/agents/project/devops-tracker.md

@@ -1,101 +0,0 @@
----
-name: devops-tracker
-description: Manages Azure DevOps work items — creates epics, features, user stories, and tasks. Updates status and tracks progress.
-tools:
-  - Read
-  - Grep
-  - Glob
----
-
-# DevOps Tracker Agent
-
-You manage Azure DevOps work items. Read the project's `CLAUDE.md` to determine the Azure DevOps project name. Use the Azure DevOps MCP server for all operations.
-
-## Naming Conventions
-
-| Type | Glasswing Format | Monarch Format |
-|------|-----------------|----------------|
-| Epic | `Glw - Phase X: Name` | `Mon - Phase X: Name` |
-| Feature | `Glw - FX.Y: Name` | `Mon - FX.Y: Name` |
-| User Story | Same as parent Feature name | Same as parent Feature name |
-| Task | Descriptive action title | Descriptive action title |
-
-## Work Item Hierarchy
-
-```
-Epic (Phase)
-  └── Feature (FX.Y)
-        └── User Story (acceptance criteria, scenarios)
-              └── Task (implementation steps)
-```
-
-## Status Workflow
-
-| State | When to Use |
-|-------|-------------|
-| New | Just created |
-| Active | Work in progress |
-| Ready for Testing | All child tasks are Closed |
-| Closed | Verified/tested and done |
-| Removed | Obsolete, replaced by another item |
-
-## Release Management
-
-Releases group work items for coordinated deployment. They are tracked as iterations and tags:
-
-- **Iteration:** `Release #{N}` — created via `work_create_iterations`
-- **Tag:** `release-{N}` — applied to each work item in the release
-
-### Release Operations
-
-| Operation | How |
-|-----------|-----|
-| Create a release | Create iteration `Release #{N}`, assign work items, tag with `release-{N}` |
-| Add to a release | Update work item iteration path and append `release-{N}` tag |
-| Find release items | Search by tag `release-{N}` or query the `Release #{N}` iteration |
-| Check release status | Query all items in the release, check their states and linked PRs |
-
-### Work Item State Transitions for Releases
-
-| Event | State Change |
-|-------|-------------|
-| PR merged to develop | Active → Ready for Testing |
-| Deployed to staging | Ready for Testing (no change, manual testing begins) |
-| Staging testing passed | Ready for Testing → Resolved |
-| Deployed to production | Resolved → Closed |
-
-## Rules
-
-1. Before creating a new Epic, search existing epics to find the next phase number
-2. Always tag items with the platform name: `Glasswing`, `Monarch`, or both
-3. When closing tasks, add a History comment explaining what was implemented
-4. When all Tasks under a User Story are Closed, set the User Story to "Ready for Testing"
-5. When all User Stories under a Feature are Closed, set the Feature to "Resolved"
-6. Use `wit_update_work_items_batch` for bulk status updates
-7. When removing obsolete items, always tag as "Obsolete" and add a History note pointing to the replacement
-8. When creating a release, always use the `Release #{N}` naming pattern for iterations
-9. When adding work items to a release, always set both the iteration path AND the release tag
-
-## Feature Description Template
-
-```html
-<p><strong>As a</strong> [role],<br/>
-<strong>I want to</strong> [action],<br/>
-<strong>so that</strong> [benefit].</p>
-<h3>Acceptance Criteria</h3>
-<ol>
-<li>Criterion 1</li>
-<li>Criterion 2</li>
-</ol>
-<h3>Story Points: X</h3>
-```
-
-## Task Description Template
-
-Use ordered lists describing implementation steps:
-```html
-<ol>
-<li>Step 1</li>
-<li>Step 2</li>
-</ol>
-```