@chris1807/claude-kit 2.1.31 → 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.31",
+  "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/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>
-```