Add managed-agents plugin (command + verifier agents)

.claude-plugin/marketplace.json

@@ -435,17 +435,6 @@
       },
       "homepage": "https://github.com/cockroachdb/claude-plugin"
     },
-    {
-      "name": "code-modernization",
-      "description": "Modernize legacy codebases (COBOL, legacy Java/C++, monolith web apps) with a structured assess / map / extract-rules / reimagine / transform / harden workflow and specialist review agents",
-      "author": {
-        "name": "Anthropic",
-        "email": "support@anthropic.com"
-      },
-      "source": "./plugins/code-modernization",
-      "category": "development",
-      "homepage": "https://github.com/anthropics/claude-plugins-official/tree/main/plugins/code-modernization"
-    },
     {
       "name": "code-review",
       "description": "Automated code review for pull requests using multiple specialized agents with confidence-based scoring to filter false positives",
@@ -997,6 +986,17 @@
         }
       }
     },
+    {
+      "name": "managed-agents",
+      "description": "Development kit for building on Claude Managed Agents",
+      "author": {
+        "name": "Anthropic",
+        "email": "support@anthropic.com"
+      },
+      "source": "./plugins/managed-agents",
+      "category": "development",
+      "homepage": "https://github.com/anthropics/claude-plugins-public/tree/main/plugins/managed-agents"
+    },
     {
       "name": "math-olympiad",
       "description": "Solve competition math (IMO, Putnam, USAMO) with adversarial verification that catches what self-verification misses. Fresh-context verifiers attack proofs with specific failure patterns. Calibrated abstention over bluffing.",
@@ -1366,19 +1366,6 @@
       },
       "homepage": "https://www.qt.io/"
     },
-    {
-      "name": "quarkus-agent",
-      "description": "MCP server for AI coding agents to create, manage, and interact with Quarkus applications. Provides tools for project scaffolding, dev mode lifecycle, extension skills, Dev MCP proxy, and documentation search.",
-      "author": {
-        "name": "Quarkus"
-      },
-      "category": "development",
-      "source": {
-        "source": "url",
-        "url": "https://github.com/quarkusio/quarkus-agent-mcp.git"
-      },
-      "homepage": "https://quarkus.io"
-    },
     {
       "name": "railway",
       "description": "Deploy and manage apps, databases, and infrastructure on Railway. Covers project setup, deploys, environment configuration, networking, troubleshooting, and monitoring.",
@@ -1820,20 +1807,6 @@
       },
       "homepage": "https://github.com/UI5/plugins-claude"
     },
-    {
-      "name": "vanta-mcp-plugin",
-      "description": "The Vanta plugin connects Claude Code to Vanta's security and compliance platform through the Vanta MCP server. It combines Vanta's test-specific remediation intelligence with your local repository context to help you fix compliance failures faster.",
-      "author": {
-        "name": "Vanta"
-      },
-      "category": "security",
-      "source": {
-        "source": "url",
-        "url": "https://github.com/VantaInc/vanta-mcp-plugin.git",
-        "sha": "46e5bebf0484f08fc4a3c4054437cf5ec06298c9"
-      },
-      "homepage": "https://help.vanta.com/en/articles/14094979-connecting-to-vanta-mcp#h_887ce3f337"
-    },
     {
       "name": "vercel",
       "description": "Vercel deployment platform integration. Manage deployments, check build status, access logs, configure domains, and control your frontend infrastructure directly from Claude Code.",

plugins/code-modernization/.claude-plugin/plugin.json

@@ -1,8 +0,0 @@
-{
-  "name": "code-modernization",
-  "description": "Modernize legacy codebases (COBOL, legacy Java/C++, monolith web apps) with a structured assess → map → extract-rules → brief → reimagine/transform → harden workflow and specialist review agents",
-  "author": {
-    "name": "Anthropic",
-    "email": "support@anthropic.com"
-  }
-}

plugins/code-modernization/README.md

@@ -1,119 +0,0 @@
-# Code Modernization Plugin
-
-A structured workflow and set of specialist agents for modernizing legacy codebases — COBOL, legacy Java/C++, monolith web apps — into current stacks while preserving behavior.
-
-## Overview
-
-Legacy modernization fails most often not because the target technology is wrong, but because teams skip steps: they transform code before understanding it, reimagine architecture before extracting business rules, or ship without a harness that would catch behavior drift. This plugin enforces a sequence:
-
-```
-assess → map → extract-rules → brief → reimagine | transform → harden
-```
-
-The discovery commands (`assess`, `map`, `extract-rules`) build artifacts under `analysis/<system>/`. The `brief` command synthesizes them into an approval gate. The build commands (`reimagine`, `transform`) write new code under `modernized/`. The `harden` command audits the legacy system and produces a reviewable remediation patch. Each step has a dedicated slash command, and specialist agents (legacy analyst, business rules extractor, architecture critic, security auditor, test engineer) are invoked from within those commands — or directly — to keep the work honest.
-
-## Expected layout
-
-Commands take a `<system-dir>` argument and assume the system being modernized lives at `legacy/<system-dir>/`. Discovery artifacts go to `analysis/<system-dir>/`, transformed code to `modernized/<system-dir>/…`. If your codebase lives elsewhere, symlink it in:
-
-```bash
-mkdir -p legacy && ln -s /path/to/your/legacy/codebase legacy/billing
-```
-
-## Optional tooling
-
-`/modernize-assess` works best with [`scc`](https://github.com/boyter/scc) (LOC + complexity + COCOMO) or [`cloc`](https://github.com/AlDanial/cloc), and falls back to `find`/`wc` if neither is installed. Portfolio mode also benefits from [`lizard`](https://github.com/terryyin/lizard) (cyclomatic complexity). The commands degrade gracefully without them, but the metrics will be coarser.
-
-## Commands
-
-The commands are designed to be run in order, but each produces a standalone artifact so you can stop, review, and resume.
-
-### `/modernize-assess <system-dir>`  — or — `/modernize-assess --portfolio <parent-dir>`
-Inventory the legacy codebase: languages, line counts, complexity, build system, integrations, technical debt, security posture, documentation gaps, and a COCOMO-derived effort estimate. Produces `analysis/<system>/ASSESSMENT.md` and `analysis/<system>/ARCHITECTURE.mmd`. Spawns `legacy-analyst` (×2) and `security-auditor` in parallel for deep reads. With `--portfolio`, sweeps every subdirectory of a parent directory and writes a sequencing heat-map to `analysis/portfolio.html`.
-
-### `/modernize-map <system-dir>`
-Build a dependency and topology map of the **legacy** system: program/module call graph, data lineage (programs ↔ data stores), entry points, dead-end candidates, and one traced critical-path business flow. Writes a re-runnable extraction script and produces `analysis/<system>/topology.json` (machine-readable), `analysis/<system>/TOPOLOGY.html` (rendered Mermaid + architect observations), and standalone `call-graph.mmd`, `data-lineage.mmd`, and `critical-path.mmd`.
-
-### `/modernize-extract-rules <system-dir> [module-pattern]`
-Mine the business rules embedded in the legacy code — calculations, validations, eligibility, state transitions, policies — into Given/When/Then "Rule Cards" with `file:line` citations and confidence ratings. Spawns three `business-rules-extractor` agents in parallel (calculations, validations, lifecycle). Produces `analysis/<system>/BUSINESS_RULES.md` and `analysis/<system>/DATA_OBJECTS.md`.
-
-### `/modernize-brief <system-dir> [target-stack]`
-Synthesize the discovery artifacts into a phased **Modernization Brief** — the single document a steering committee approves and engineering executes: target architecture, strangler-fig phase plan with entry/exit criteria, behavior contract, validation strategy, open questions, and an approval block. Reads `ASSESSMENT.md`, `TOPOLOGY.html`, and `BUSINESS_RULES.md` and **stops if any are missing** — run the discovery commands first. Produces `analysis/<system>/MODERNIZATION_BRIEF.md` and enters plan mode as a human-in-the-loop gate.
-
-### `/modernize-reimagine <system-dir> <target-vision>`
-Greenfield rebuild from extracted intent rather than a structural port. Mines a spec (`analysis/<system>/AI_NATIVE_SPEC.md`), designs a target architecture and has it adversarially reviewed (`analysis/<system>/REIMAGINED_ARCHITECTURE.md`), then **scaffolds services with executable acceptance tests** under `modernized/<system>-reimagined/` and writes a `CLAUDE.md` knowledge handoff for the new system. Two human-in-the-loop checkpoints. Spawns `business-rules-extractor`, `legacy-analyst` (×2), `architecture-critic`, and general-purpose scaffolding agents.
-
-### `/modernize-transform <system-dir> <module> <target-stack>`
-Surgical, single-module strangler-fig rewrite. Plans first (HITL gate), then writes characterization tests via `test-engineer`, then an idiomatic target implementation under `modernized/<system>/<module>/`, proves equivalence by running the tests, and produces `TRANSFORMATION_NOTES.md` mapping legacy → modern with deliberate deviations called out. Reviewed by `architecture-critic`.
-
-### `/modernize-harden <system-dir>`
-Security hardening pass on the **legacy** system: OWASP/CWE scan, dependency CVEs, secrets, injection. Spawns `security-auditor`. Produces `analysis/<system>/SECURITY_FINDINGS.md` ranked Critical / High / Medium / Low and a reviewed `analysis/<system>/security_remediation.patch` with minimal fixes for the Critical/High findings. The patch is reviewed by a second `security-auditor` pass before you see it. **Never edits `legacy/`** — you review and apply the patch yourself when ready, then re-run to verify. Useful as a pre-modernization step when the legacy system will keep running in production during the migration.
-
-## Agents
-
-- **`legacy-analyst`** — Reads legacy code (COBOL, legacy Java/C++, procedural PHP, classic ASP) and produces structured summaries. Good at spotting implicit dependencies, copybook inheritance, and "JOBOL" patterns (procedural code wearing a modern syntax). Used by `assess` and `reimagine`.
-- **`business-rules-extractor`** — Extracts business rules from procedural code with source citations. Each rule includes: what, where it's implemented, which conditions fire it, and any corner cases hidden in data. Used by `extract-rules` and `reimagine`.
-- **`architecture-critic`** — Adversarial reviewer for target architectures and transformed code. Default stance is skeptical: asks "do we actually need this?" Flags microservices-for-the-resume, ceremonial error handling, abstractions with one implementation. Used by `reimagine` and `transform`.
-- **`security-auditor`** — Reviews code for auth, input validation, secret handling, and dependency CVEs. Tuned for the kinds of issues that appear when translating security primitives across stacks (e.g., session handling from servlet to stateless JWT). Used by `assess` and `harden`.
-- **`test-engineer`** — Writes characterization, contract, and equivalence tests that pin legacy behavior so transformation can be proven correct. Flags tests that exercise code paths without asserting outcomes. Used by `transform`.
-
-## Installation
-
-```
-/plugin install code-modernization@claude-plugins-official
-```
-
-## Recommended Workspace Setup
-
-This plugin ships commands and agents, but modernization projects benefit from a workspace permission layout that enforces the "never touch legacy, freely edit modernized" rule. A starting-point `.claude/settings.json` for the project directory you're modernizing:
-
-```json
-{
-  "permissions": {
-    "allow": [
-      "Bash(git diff:*)",
-      "Bash(git log:*)",
-      "Bash(git status:*)",
-      "Read(**)",
-      "Write(analysis/**)",
-      "Write(modernized/**)",
-      "Edit(analysis/**)",
-      "Edit(modernized/**)"
-    ],
-    "deny": [
-      "Edit(legacy/**)"
-    ]
-  }
-}
-```
-
-Adjust `legacy/` and `modernized/` to match your actual layout. The key invariants: `Edit` under `legacy/` is denied, and writes are scoped to `analysis/` (for documents) and `modernized/` (for the new code). Every command in this plugin respects this — `/modernize-harden` writes a patch to `analysis/` rather than editing `legacy/` in place.
-
-## Typical Workflow
-
-```bash
-# 1. Inventory the legacy system (or sweep a portfolio of them)
-/modernize-assess billing
-
-# 2. Map call graph, data lineage, and the critical path
-/modernize-map billing
-
-# 3. Extract business rules into testable Rule Cards
-/modernize-extract-rules billing
-
-# 4. Synthesize the approved Modernization Brief (human-in-the-loop gate)
-/modernize-brief billing java-spring
-
-# 5a. Greenfield rebuild from the extracted spec…
-/modernize-reimagine billing "event-driven services on Java 21 / Spring Boot"
-
-# 5b. …or transform module by module (strangler fig)
-/modernize-transform billing interest-calc java-spring
-
-# 6. Security-harden the legacy system that's still in production
-/modernize-harden billing
-```
-
-## License
-
-Apache 2.0. See `LICENSE`.

plugins/code-modernization/agents/architecture-critic.md

@@ -1,36 +0,0 @@
----
-name: architecture-critic
-description: Reviews proposed target architectures and transformed code against modern best practice. Adversarial — looks for over-engineering, missed requirements, and simpler alternatives.
-tools: Read, Glob, Grep, Bash
----
-
-You are a principal engineer reviewing a modernization design or a freshly
-transformed module. Your default stance is **skeptical**. The team is excited
-about the new shiny; your job is to ask "do we actually need this?"
-
-## Review lens
-
-For **architecture proposals**:
-- Does every service boundary correspond to a real domain seam, or is this
-  microservices-for-the-resume?
-- What's the simplest design that meets the stated requirements? How does
-  the proposal compare?
-- Which non-functional requirements (latency, throughput, consistency) are
-  unstated, and does the design accidentally violate them?
-- What's the data migration story? "We'll figure it out" is a finding.
-- What happens when service X is down? Trace one failure mode end-to-end.
-
-For **transformed code**:
-- Is this idiomatic for the target stack, or is legacy structure leaking
-  through? (Flag "JOBOL" — procedural Java with COBOL variable names.)
-- Is error handling meaningful or ceremonial?
-- Are there abstractions with exactly one implementation and no second use
-  case in sight?
-- Does the test suite actually pin behavior, or just exercise code paths?
-- What would the on-call engineer need at 3am that isn't here?
-
-## Output
-
-Findings ranked **Blocker / High / Medium / Nit**. Each with: what, where,
-why it matters, and a concrete suggested change. End with one paragraph:
-"If I could only change one thing, it would be ___."

plugins/code-modernization/agents/business-rules-extractor.md

@@ -1,46 +0,0 @@
----
-name: business-rules-extractor
-description: Mines domain logic, calculations, validations, and policies from legacy code into testable Given/When/Then specifications. Use when you need to separate "what the business requires" from "how the old code happened to implement it."
-tools: Read, Glob, Grep, Bash
----
-
-You are a business analyst who reads code. Your job is to find the **rules**
-hidden inside legacy systems — the calculations, thresholds, eligibility
-checks, and policies that define how the business actually operates — and
-express them in a form that survives the rewrite.
-
-## What counts as a business rule
-
-- **Calculations**: interest, fees, taxes, discounts, scores, aggregates
-- **Validations**: required fields, format checks, range limits, cross-field
-- **Eligibility / authorization**: who can do what, when, under which conditions
-- **State transitions**: status lifecycles, what triggers each transition
-- **Policies**: retention periods, retry limits, cutoff times, rounding rules
-
-## What does NOT count
-
-Infrastructure, logging, error handling, UI layout, technical retries,
-connection pooling. If a rule would be the same regardless of what language
-the system was written in, it's a business rule. If it only exists because
-of the technology, skip it.
-
-## Extraction discipline
-
-1. Find the rule in code. Record exact `file:line-line`.
-2. State it in plain English a non-engineer would recognize.
-3. Encode it as Given/When/Then with **concrete values**:
-   ```
-   Given an account with balance $1,250.00 and APR 18.5%
-   When the monthly interest batch runs
-   Then the interest charged is $19.27 (balance × APR ÷ 12, rounded half-up to cents)
-   ```
-4. List the parameters (rates, limits, magic numbers) with their current
-   hardcoded values — these often need to become configuration.
-5. Rate your confidence: **High** (logic is explicit), **Medium** (inferred
-   from structure/names), **Low** (ambiguous; needs SME).
-6. If confidence < High, write the exact question an SME must answer.
-
-## Output format
-
-One "Rule Card" per rule (see the format in the `/modernize-extract-rules`
-command). Group by category. Lead with a summary table.

plugins/code-modernization/agents/legacy-analyst.md

@@ -1,39 +0,0 @@
----
-name: legacy-analyst
-description: Deep-reads legacy codebases (COBOL, Java, .NET, Node, anything) to build structural and behavioral understanding. Use for discovery, dependency mapping, dead-code detection, and "what does this system actually do" questions.
-tools: Read, Glob, Grep, Bash
----
-
-You are a senior legacy systems analyst with 20 years of experience reading
-code nobody else wants to read — COBOL, JCL, RPG, classic ASP, EJB 2,
-Struts 1, raw servlets, Perl CGI.
-
-Your job is **understanding, not judgment**. The code in front of you kept a
-business running for decades. Treat it with respect, figure out what it does,
-and explain it in terms a modern engineer can act on.
-
-## How you work
-
-- **Read before you grep.** Open the entry points (main programs, JCL jobs,
-  controllers, routes) and trace the actual flow. Pattern-matching on names
-  lies; control flow doesn't.
-- **Cite everything.** Every claim gets a `path/to/file:line` reference.
-  If you can't point to a line, you don't know it — say so.
-- **Distinguish "is" from "appears to be."** When you're inferring intent
-  from structure, flag it: "appears to handle X (inferred from variable
-  names; no comments confirm)."
-- **Use the right vocabulary for the stack.** COBOL has paragraphs,
-  copybooks, and FD entries. CICS has transactions and BMS maps. JCL has
-  steps and DD statements. Java has packages and beans. Use the native
-  terms so SMEs trust your output.
-- **Find the data first.** In legacy systems, the data structures (copybooks,
-  DDL, schemas) are usually more stable and truthful than the procedural
-  code. Map the data, then map who touches it.
-- **Note what's missing.** Unhandled error paths, TODO comments, commented-out
-  blocks, magic numbers — these are signals about history and risk.
-
-## Output format
-
-Default to structured markdown: tables for inventories, Mermaid for graphs,
-bullet lists for findings. Always include a "Confidence & Gaps" footer
-listing what you couldn't determine and what you'd ask an SME.

plugins/code-modernization/agents/security-auditor.md

@@ -1,56 +0,0 @@
----
-name: security-auditor
-description: Adversarial security reviewer — OWASP Top 10, CWE, dependency CVEs, secrets, injection. Use for security debt scanning and pre-modernization hardening.
-tools: Read, Glob, Grep, Bash
----
-
-You are an application security engineer performing an adversarial review.
-Assume the code is hostile until proven otherwise. Your job is to find
-vulnerabilities a real attacker would find — and explain them in terms an
-engineer can fix.
-
-## Coverage checklist
-
-Adapt to the target stack — web items don't apply to a batch system,
-terminal/screen items don't apply to a SPA. Work through what's relevant:
-
-- **Injection** (SQL, NoSQL, OS command, LDAP, XPath, template) — trace every
-  user-controlled input to every sink, including dynamic SQL and shell-outs
-- **Authentication / session** — hardcoded creds, weak session handling,
-  missing auth checks on sensitive routes/transactions/jobs
-- **Sensitive data exposure** — secrets in source, weak crypto, PII in logs,
-  cleartext sensitive data in record layouts, flat files, or temp datasets
-- **Access control** — IDOR, missing ownership checks, privilege escalation;
-  missing/permissive resource ACLs (RACF profiles, IAM policies, file perms);
-  unguarded admin functions
-- **XSS / CSRF** — unescaped output, missing tokens (web targets)
-- **Insecure deserialization** — untrusted data into pickle/yaml.load/
-  `ObjectInputStream` or custom record parsers
-- **Vulnerable dependencies** — run `npm audit` / `pip-audit` /
-  read manifests and flag versions with known CVEs
-- **SSRF / path traversal / open redirect** (web/network targets)
-- **Input validation** — missing length/range/format checks at trust
-  boundaries (form/screen fields, API params, batch input records) before
-  persistence or downstream calls
-- **Security misconfiguration** — debug mode, verbose errors, default creds,
-  hardcoded credentials in deployment scripts, job definitions, or config
-
-## Tooling
-
-Use available SAST where it helps (npm audit, pip-audit, grep for known-bad
-patterns) but **read the code** — tools miss logic flaws. Show tool output
-verbatim, then add your manual findings.
-
-## Reporting standard
-
-For each finding:
-| Field | Content |
-|---|---|
-| **ID** | SEC-NNN |
-| **CWE** | CWE-XXX with name |
-| **Severity** | Critical / High / Medium / Low (CVSS-ish reasoning) |
-| **Location** | `file:line` |
-| **Exploit scenario** | One sentence: how an attacker uses this |
-| **Fix** | Concrete code-level remediation |
-
-No hand-waving. If you can't write the exploit scenario, downgrade severity.

plugins/code-modernization/agents/test-engineer.md

@@ -1,36 +0,0 @@
----
-name: test-engineer
-description: Writes characterization, contract, and equivalence tests that pin down legacy behavior so transformation can be proven correct. Use before any rewrite.
-tools: Read, Write, Edit, Glob, Grep, Bash
----
-
-You are a test engineer specializing in **characterization testing** —
-writing tests that capture what legacy code *actually does* (not what
-someone thinks it should do) so that a rewrite can be proven equivalent.
-
-## Principles
-
-- **The legacy code is the oracle.** If the legacy computes 19.27 and the
-  spec says 19.28, the test asserts 19.27 and you flag the discrepancy
-  separately. We're proving equivalence first; fixing bugs is a separate
-  decision.
-- **Concrete over abstract.** Every test has literal input values and literal
-  expected outputs. No "should calculate correctly" — instead "given balance
-  1250.00 and APR 18.5%, returns 19.27".
-- **Cover the edges the legacy covers.** Read the legacy code's branches.
-  Every IF/EVALUATE/switch arm gets at least one test case. Boundary values
-  (zero, negative, max, empty) get explicit cases.
-- **Tests must run against BOTH.** Structure tests so the same inputs can be
-  fed to the legacy implementation (or a recorded trace of it) and the modern
-  one. The test harness compares.
-- **Executable, not aspirational.** Tests compile and run from day one.
-  Behaviors not yet implemented in the target are marked
-  `@Disabled("pending RULE-NNN")` / `@pytest.mark.skip` / `it.todo()` — never
-  deleted.
-
-## Output
-
-Idiomatic tests for the requested target stack (JUnit 5 / pytest / Vitest /
-xUnit), one test class/file per legacy module, test method names that read
-as specifications. Include a `README.md` in the test directory explaining
-how to run them and how to add a new case.

plugins/code-modernization/commands/modernize-assess.md

@@ -1,161 +0,0 @@
----
-description: Full discovery & portfolio analysis of a legacy system — inventory, complexity, debt, effort estimation
-argument-hint: <system-dir> | --portfolio <parent-dir>
----
-
-**Mode select.** If `$ARGUMENTS` starts with `--portfolio`, run **Portfolio
-mode** against the directory that follows. Otherwise run **Single-system
-mode** against `legacy/$1`.
-
----
-
-# Portfolio mode (`--portfolio <parent-dir>`)
-
-Sweep every immediate subdirectory of the parent dir and produce a
-heat-map a steering committee can use to sequence a multi-year program.
-
-## Step P1 — Per-system metrics
-
-For each subdirectory `<sys>`:
-
-```bash
-cloc --quiet --csv <parent>/<sys>          # LOC by language
-lizard -s cyclomatic_complexity <parent>/<sys> 2>/dev/null | tail -1
-```
-
-If `cloc`/`lizard` are not installed, fall back to `scc <parent>/<sys>`
-(LOC + complexity) or `find` + `wc -l` grouped by extension, and estimate
-complexity by counting decision keywords per file. Note which tool you used.
-
-Capture: total SLOC, dominant language, file count, mean & max
-cyclomatic complexity (CCN). For dependency freshness, locate the
-manifest (`package.json`, `pom.xml`, `*.csproj`, `requirements*.txt`,
-copybook dir) and note its age / pinned-version count.
-
-## Step P2 — COCOMO-II effort
-
-Compute person-months per system using COCOMO-II basic:
-`PM = 2.94 × (KSLOC)^1.10` (nominal scale factors). Show the formula and
-inputs so the figure is defensible, not a guess.
-
-## Step P3 — Documentation coverage
-
-For each system, count source files with vs without a header comment
-block, and list architecture docs present (`README`, `docs/`, ADRs).
-Report coverage % and the top undocumented subsystems.
-
-## Step P4 — Render the heat-map
-
-Write `analysis/portfolio.html` (dark `#1e1e1e` bg, `#d4d4d4` text,
-`#cc785c` accent, system-ui font, all CSS inline). One row per system;
-columns: **System · Lang · KSLOC · Files · Mean CCN · Max CCN · Dep
-Freshness · Doc Coverage % · COCOMO PM · Risk**. Color-grade the PM and
-Risk cells (green→amber→red). Below the table, a 2-3 sentence
-sequencing recommendation: which system first and why.
-
-Then stop. Tell the user to open `analysis/portfolio.html`.
-
----
-
-# Single-system mode
-
-Perform a complete **modernization assessment** of `legacy/$1`.
-
-This is the discovery phase — the goal is a fact-grounded executive brief that
-a VP of Engineering could take into a budget meeting. Work in this order:
-
-## Step 1 — Quantitative inventory
-
-Run and show the output of:
-```bash
-scc legacy/$1
-```
-Then run `scc --by-file -s complexity legacy/$1 | head -25` to identify the
-highest-complexity files. Capture the COCOMO effort/cost estimate scc provides.
-
-If `scc` is not installed, fall back in order:
-1. `cloc legacy/$1` for the LOC table, then compute COCOMO-II effort
-   yourself: `PM = 2.94 × (KSLOC)^1.10` (nominal scale factors). Show the
-   inputs.
-2. If `cloc` is also missing, use `find` + `wc -l` grouped by extension
-   for LOC, and rank file complexity by counting decision keywords
-   (`IF`/`EVALUATE`/`WHEN`/`PERFORM` for COBOL; `if`/`for`/`while`/`case`/
-   `catch` for C-family). Compute COCOMO from KSLOC as above.
-
-Note in the assessment which tool was used so the figures are reproducible.
-
-## Step 2 — Technology fingerprint
-
-Identify, with file evidence:
-- Languages, frameworks, and runtime versions in use
-- Build system and dependency manifest locations
-- Data stores (schemas, copybooks, DDL, ORM configs)
-- Integration points (queues, APIs, batch interfaces, screen maps)
-- Test presence and approximate coverage signal
-
-## Step 3 — Parallel deep analysis
-
-Spawn three subagents **in parallel**:
-
-1. **legacy-analyst** — "Build a structural map of legacy/$1: what are the
-   5-12 major functional domains (group optional/feature-gated subsystems
-   under one umbrella), which source files belong to each, and how do they
-   depend on each other (control flow + shared data)? Return a markdown
-   table + a Mermaid `graph TD` of domain-level dependencies — use
-   `subgraph` to cluster and cap at ~40 edges. Cite repo-relative file
-   paths. Flag dangling references (defined but no source, or unused)."
-
-2. **legacy-analyst** — "Identify technical debt in legacy/$1: dead code,
-   deprecated APIs, copy-paste duplication, god objects/programs, missing
-   error handling, hardcoded config. Return the top 10 findings ranked by
-   remediation value, each with file:line evidence."
-
-3. **security-auditor** — "Scan legacy/$1 for security vulnerabilities:
-   injection, auth weaknesses, hardcoded secrets, vulnerable dependencies,
-   missing input validation. Return findings in CWE-tagged table form with
-   file:line evidence and severity."
-
-Wait for all three. Synthesize their findings.
-
-## Step 4 — Production runtime overlay (optional)
-
-If production telemetry is available — an observability/APM MCP server, batch
-job logs, or runtime exports the user can supply — gather p50/p95/p99
-wall-clock for the system's key jobs/transactions (e.g. JCL members under
-`legacy/$1/jcl/`, scheduled batches, top API routes). Use it to:
-
-- Tag each functional domain from Step 3 with its production wall-clock
-  cost and **p99 variance** (p99/p50 ratio).
-- Flag the highest-variance domain as the highest operational risk —
-  this is telemetry-grounded, not a static-analysis opinion.
-
-Include a small **Runtime Profile** table (Job/Route · Domain · p50 · p95 ·
-p99 · p99/p50) in the assessment. If no telemetry is available, skip this
-step and note the gap in the assessment.
-
-## Step 5 — Documentation gap analysis
-
-Compare what the code *does* against what README/docs/comments *say*. List
-the top 5 undocumented behaviors or subsystems that a new engineer would
-need explained.
-
-## Step 6 — Write the assessment
-
-Create `analysis/$1/ASSESSMENT.md` with these sections:
-- **Executive Summary** (3-4 sentences: what it is, how big, how risky, headline recommendation)
-- **System Inventory** (the scc table + tech fingerprint)
-- **Architecture-at-a-Glance** (the domain table; reference the diagram)
-- **Production Runtime Profile** (the runtime table from Step 4 with the highest-variance domain called out — or "no telemetry available")
-- **Technical Debt** (top 10, ranked)
-- **Security Findings** (CWE table)
-- **Documentation Gaps** (top 5)
-- **Effort Estimation** (COCOMO-derived person-months, ±range, key cost drivers)
-- **Recommended Modernization Pattern** (one of: Rehost / Replatform / Refactor / Rearchitect / Rebuild / Replace — with one-paragraph rationale)
-
-Also create `analysis/$1/ARCHITECTURE.mmd` containing the Mermaid domain
-dependency diagram from the legacy-analyst.
-
-## Step 7 — Present
-
-Tell the user the assessment is ready and suggest:
-`glow -p analysis/$1/ASSESSMENT.md`

plugins/code-modernization/commands/modernize-brief.md

@@ -1,65 +0,0 @@
----
-description: Generate a phased Modernization Brief — the approved plan that transformation agents will execute against
-argument-hint: <system-dir> [target-stack]
----
-
-Synthesize everything in `analysis/$1/` into a **Modernization Brief** — the
-single document a steering committee approves and engineering executes.
-
-Target stack: `$2` (if blank, recommend one based on the assessment findings).
-
-Read `analysis/$1/ASSESSMENT.md`, `analysis/$1/TOPOLOGY.html` (and the `.mmd`
-files alongside it), and `analysis/$1/BUSINESS_RULES.md` first. If any are
-missing, say so and stop — they come from `/modernize-assess`, `/modernize-map`,
-and `/modernize-extract-rules` respectively. Run those first.
-
-## The Brief
-
-Write `analysis/$1/MODERNIZATION_BRIEF.md`:
-
-### 1. Objective
-One paragraph: from what, to what, why now.
-
-### 2. Target Architecture
-Mermaid C4 Container diagram of the *end state*. Name every service, data
-store, and integration. Below it, a table mapping legacy component → target
-component(s).
-
-### 3. Phased Sequence
-Break the work into 3-6 phases using **strangler-fig ordering** — lowest-risk,
-fewest-dependencies first. For each phase:
-- Scope (which legacy modules, which target services)
-- Entry criteria (what must be true to start)
-- Exit criteria (what tests/metrics prove it's done)
-- Estimated effort (person-weeks, derived from COCOMO + complexity data)
-- Risk level + top 2 risks + mitigation
-
-Render the phases as a Mermaid `gantt` chart.
-
-### 4. Behavior Contract
-List the **P0 rules** from BUSINESS_RULES.md (the ones tagged `Priority: P0` —
-money, regulatory, data integrity) that MUST be proven equivalent before any
-phase ships. These become the regression suite. Flag any P0 rule with
-Confidence < High as a blocker requiring SME confirmation before its phase
-starts.
-
-### 5. Validation Strategy
-State which combination applies: characterization tests, contract tests,
-parallel-run / dual-execution diff, property-based tests, manual UAT.
-Justify per phase.
-
-### 6. Open Questions
-Anything requiring human/SME decision before Phase 1 starts. Each as a
-checkbox the approver must tick.
-
-### 7. Approval Block
-```
-Approved by: ________________  Date: __________
-Approval covers: Phase 1 only | Full plan
-```
-
-## Present
-
-Enter **plan mode** and present a summary of the brief. Do NOT proceed to any
-transformation until the user explicitly approves. This gate is the
-human-in-the-loop control point.

plugins/code-modernization/commands/modernize-extract-rules.md

@@ -1,76 +0,0 @@
----
-description: Mine business logic from legacy code into testable, human-readable rule specifications
-argument-hint: <system-dir> [module-pattern]
----
-
-Extract the **business rules** embedded in `legacy/$1` into a structured,
-testable specification — the institutional knowledge that's currently locked
-in code and in the heads of engineers who are about to retire.
-
-Scope: if a module pattern was given (`$2`), focus there; otherwise cover the
-entire system. Either way, prioritize calculation, validation, eligibility,
-and state-transition logic over plumbing.
-
-## Method
-
-Spawn **three business-rules-extractor subagents in parallel**, each assigned
-a different lens. If `$2` is non-empty, include "focusing on files matching
-$2" in each prompt.
-
-1. **Calculations** — "Find every formula, rate, threshold, and computed value
-   in legacy/$1. For each: what does it compute, what are the inputs, what is
-   the exact formula/algorithm, where is it implemented (file:line), and what
-   edge cases does the code handle?"
-
-2. **Validations & eligibility** — "Find every business validation, eligibility
-   check, and guard condition in legacy/$1. For each: what is being checked,
-   what happens on pass/fail, where is it (file:line)?"
-
-3. **State & lifecycle** — "Find every status field, state machine, and
-   lifecycle transition in legacy/$1. For each entity: what states exist,
-   what triggers transitions, what side-effects fire?"
-
-## Synthesize
-
-Merge the three result sets. Deduplicate. For each distinct rule, write a
-**Rule Card** in this exact format:
-
-```
-### RULE-NNN: <plain-English name>
-**Category:** Calculation | Validation | Lifecycle | Policy
-**Priority:** P0 | P1 | P2
-**Source:** `path/to/file.ext:line-line`
-**Plain English:** One sentence a business analyst would recognize.
-**Specification:**
-  Given <precondition>
-  When  <trigger>
-  Then  <outcome>
-  [And  <additional outcome>]
-**Parameters:** <constants, rates, thresholds with their current values>
-**Edge cases handled:** <list>
-**Suspected defect:** <optional — legacy behavior that looks wrong; decide preserve-vs-fix during transform>
-**Confidence:** High | Medium | Low — <why; if < High, state the exact SME question>
-```
-
-Priority heuristic — default to **P1**. Assign **P0** if the rule moves money,
-enforces a regulatory/compliance requirement, or guards data integrity (and
-flag P0 rules at <High confidence as SME-required). Assign **P2** for
-display/formatting/convenience rules. The downstream `/modernize-brief`
-behavior contract is built from the P0 rules, so assign deliberately.
-
-Write all rule cards to `analysis/$1/BUSINESS_RULES.md` with:
-- A summary table at top (ID, name, category, priority, source, confidence)
-- Rule cards grouped by category
-- A final **"Rules requiring SME confirmation"** section listing every
-  Medium/Low confidence rule with the specific question a human needs to answer
-
-## Generate the DTO catalog
-
-As a companion, create `analysis/$1/DATA_OBJECTS.md` cataloging the core
-data transfer objects / records / entities: name, fields with types, which
-rules consume/produce them, source location.
-
-## Present
-
-Report: total rules found, breakdown by category, count needing SME review.
-Suggest: `glow -p analysis/$1/BUSINESS_RULES.md`

plugins/code-modernization/commands/modernize-harden.md

@@ -1,64 +0,0 @@
----
-description: Security vulnerability scan with a reviewable remediation patch — OWASP, CWE, CVE, secrets, injection
-argument-hint: <system-dir>
----
-
-Run a **security hardening pass** on `legacy/$1`: find vulnerabilities, rank
-them, and produce a reviewable patch for the critical ones.
-
-This command never edits `legacy/` — it writes findings and a proposed patch
-to `analysis/$1/`. The user reviews and applies (or not).
-
-## Scan
-
-Spawn the **security-auditor** subagent:
-
-"Adversarially audit legacy/$1 for security vulnerabilities. Cover what's
-relevant to the stack: injection (SQL/NoSQL/OS command/template), broken
-auth, sensitive data exposure, access control gaps, insecure deserialization,
-hardcoded secrets, vulnerable dependency versions, missing input validation,
-path traversal. For each finding return: CWE ID, severity
-(Critical/High/Med/Low), file:line, one-sentence exploit scenario, and
-recommended fix. Run any available SAST tooling (npm audit, pip-audit,
-OWASP dependency-check) and include its raw output."
-
-## Triage
-
-Write `analysis/$1/SECURITY_FINDINGS.md`:
-- Summary scorecard (count by severity, top CWE categories)
-- Findings table sorted by severity
-- Dependency CVE table (package, installed version, CVE, fixed version)
-
-## Remediate
-
-For each **Critical** and **High** finding, draft a minimal, targeted fix.
-Do **not** edit `legacy/` — write all fixes as a single unified diff to
-`analysis/$1/security_remediation.patch`, with a comment line above each
-hunk citing the finding ID it addresses (`# SEC-001: parameterize the query`).
-
-Add a **Remediation Log** section to SECURITY_FINDINGS.md mapping each
-finding ID → one-line summary of the proposed fix and the patch hunk that
-implements it.
-
-## Verify
-
-Spawn the **security-auditor** again to **review the patch** against the
-original code:
-
-"Review analysis/$1/security_remediation.patch against legacy/$1. For each
-hunk: does it fully remediate the cited finding? Does it introduce new
-vulnerabilities or change behavior beyond the fix? Return one verdict per
-hunk: RESOLVES / PARTIAL / INTRODUCES-RISK, with a one-line reason."
-
-Add a **Patch Review** section to SECURITY_FINDINGS.md with the verdicts.
-If any hunk is PARTIAL or INTRODUCES-RISK, revise the patch and re-review.
-
-## Present
-
-Tell the user the artifacts are ready:
-- `analysis/$1/SECURITY_FINDINGS.md` — findings, remediation log, patch review
-- `analysis/$1/security_remediation.patch` — review, then apply if appropriate
-  with `git -C legacy/$1 apply ../../analysis/$1/security_remediation.patch`
-- Re-run `/modernize-harden $1` after applying to confirm resolution
-
-Suggest: `glow -p analysis/$1/SECURITY_FINDINGS.md`

plugins/code-modernization/commands/modernize-map.md

@@ -1,104 +0,0 @@
----
-description: Dependency & topology mapping — call graphs, data lineage, batch flows, rendered as navigable diagrams
-argument-hint: <system-dir>
----
-
-Build a **dependency and topology map** of `legacy/$1` and render it visually.
-
-The assessment gave us domains. Now go one level deeper: how do the *pieces*
-connect? This is the map an engineer needs before touching anything.
-
-## What to produce
-
-Write a one-off analysis script (Python or shell — your choice) that parses
-the source under `legacy/$1` and extracts the four datasets below. Three
-principles apply across stacks; getting them wrong produces a misleading map:
-
-1. **Edges live in two places** — direct calls in source, *and* dispatcher/
-   router calls whose targets are variables (config tables, route maps,
-   dependency injection, dynamic dispatch). Resolve variables against config
-   before declaring an edge unresolvable.
-2. **The code↔storage join is usually external configuration**, not source —
-   job/deployment descriptors map logical names to physical stores.
-3. **Entry points usually live in deployment config**, not source — without
-   parsing it, every top-level module looks unreachable.
-
-Extract:
-
-- **Program/module call graph** — direct calls (`CALL`, method invocations,
-  `import`/`require`) *and* dispatcher calls (`EXEC CICS LINK/XCTL`, DI
-  container wiring, framework routing, reflection/factory). Resolve variable
-  call targets against route tables, copybooks, config, or constant pools.
-- **Data dependency graph** — which modules read/write which data stores,
-  joined through the relevant config: `SELECT…ASSIGN TO` ↔ JCL `DD` (batch
-  COBOL), `EXEC CICS READ/WRITE…FILE()` ↔ CSD `DEFINE FILE` (CICS online),
-  `EXEC SQL` table refs (embedded SQL), ORM annotations/mappings (Java/.NET),
-  model files (Node/Python/Ruby). Include UI/screen bindings (BMS maps, JSPs,
-  templates) — they're dependencies too.
-- **Entry points** — whatever the stack's outermost invoker is, read from
-  where it's defined: JCL `EXEC PGM=` and CICS CSD `DEFINE TRANSACTION`
-  (mainframe), `web.xml`/route annotations/route files (web), `main()`/argv
-  parsing (CLI), queue/scheduler subscriptions (event-driven).
-- **Dead-end candidates** — modules with no inbound edges. **Only meaningful
-  once all the entry-point and call-edge types above are in the graph.**
-  Suppress the dead claim for anything that could be the target of an
-  unresolved dynamic call. A grep-only graph will mark most dispatcher-driven
-  modules (CICS programs, Spring controllers, ORM-bound DAOs) dead when they
-  aren't.
-
-If the source is fixed-column (COBOL columns 8–72, RPG, etc.), slice the
-code area and strip comment lines before regex matching, or you'll match
-sequence numbers and commented-out code.
-
-Save the script as `analysis/$1/extract_topology.py` (or `.sh`) so it can be
-re-run and audited. Have it write a machine-readable
-`analysis/$1/topology.json` and print a human summary. Run it; show the
-summary (cap at ~200 lines for very large estates).
-
-## Render
-
-From the extracted data, generate **three Mermaid diagrams** and write them
-to `analysis/$1/TOPOLOGY.html` as a self-contained page that renders in any
-browser.
-
-The HTML page must use: dark `#1e1e1e` background, `#d4d4d4` text,
-`#cc785c` for `<h2>`/accents, `system-ui` font, all CSS **inline** (no
-external stylesheets). Load Mermaid from a CDN in `<head>`:
-
-```html
-<script type="module">
-  import mermaid from 'https://cdn.jsdelivr.net/npm/mermaid@11/dist/mermaid.esm.min.mjs';
-  mermaid.initialize({ startOnLoad: true, theme: 'dark' });
-</script>
-```
-
-Each diagram goes in a `<pre class="mermaid">...</pre>` block. Do **not**
-wrap diagrams in markdown ` ``` ` fences inside the HTML.
-
-1. **`graph TD` — Module call graph.** Cluster by domain (use `subgraph`).
-   Highlight entry points in a distinct style. Cap at ~40 nodes — if larger,
-   show domain-level with one expanded domain.
-
-2. **`graph LR` — Data lineage.** Programs → data stores.
-   Mark read vs write edges.
-
-3. **`flowchart TD` — Critical path.** Trace ONE end-to-end business flow
-   (e.g., "monthly billing run" or "process payment") through every program
-   and data store it touches, in execution order. If production telemetry is
-   available (see `/modernize-assess` Step 4), annotate each step with its
-   p50/p99 wall-clock.
-
-Also export the three diagrams as standalone `.mmd` files for re-use:
-`analysis/$1/call-graph.mmd`, `analysis/$1/data-lineage.mmd`,
-`analysis/$1/critical-path.mmd`.
-
-## Annotate
-
-Below each `<pre class="mermaid">` block in TOPOLOGY.html, add a `<ul>`
-with 3-5 **architect observations**: tight coupling clusters, single
-points of failure, candidates for service extraction, data stores
-touched by too many writers.
-
-## Present
-
-Tell the user to open `analysis/$1/TOPOLOGY.html` in a browser.

plugins/code-modernization/commands/modernize-reimagine.md

@@ -1,83 +0,0 @@
----
-description: Multi-agent greenfield rebuild — extract specs from legacy, design AI-native, scaffold & validate with HITL
-argument-hint: <system-dir> <target-vision>
----
-
-**Reimagine** `legacy/$1` as: $2
-
-This is not a port — it's a rebuild from extracted intent. The legacy system
-becomes the *specification source*, not the structural template. This command
-orchestrates a multi-agent team with explicit human checkpoints.
-
-## Phase A — Specification mining (parallel agents)
-
-Spawn concurrently and show the user that all three are running:
-
-1. **business-rules-extractor** — "Extract every business rule from legacy/$1
-   into Given/When/Then form. Output to a structured list I can parse."
-
-2. **legacy-analyst** — "Catalog every external interface of legacy/$1:
-   inbound (screens, APIs, batch triggers, queues) and outbound (reports,
-   files, downstream calls, DB writes). For each: name, direction, payload
-   shape, frequency/SLA if discernible."
-
-3. **legacy-analyst** — "Identify the core domain entities in legacy/$1 and
-   their relationships. Return as an entity list + Mermaid erDiagram."
-
-Collect results. Write `analysis/$1/AI_NATIVE_SPEC.md` containing:
-- **Capabilities** (what the system must do — derived from rules + interfaces)
-- **Domain Model** (entities + erDiagram)
-- **Interface Contracts** (each external interface as an OpenAPI fragment or
-  AsyncAPI fragment)
-- **Non-functional requirements** inferred from legacy (batch windows, volumes)
-- **Behavior Contract** (the Given/When/Then rules — these are the acceptance tests)
-
-## Phase B — HITL checkpoint #1
-
-Present the spec summary. Ask the user **one focused question**: "Which of
-these capabilities are P0 for the reimagined system, and are there any we
-should deliberately drop?" Wait for the answer. Record it in the spec.
-
-## Phase C — Architecture (single agent, then critique)
-
-Design the target architecture for "$2":
-- Mermaid C4 Container diagram
-- Service boundaries with rationale (which rules/entities live where)
-- Technology choices with one-line justification each
-- Data migration approach from legacy stores
-
-Then spawn **architecture-critic**: "Review this proposed architecture for
-$2 against the spec in analysis/$1/AI_NATIVE_SPEC.md. Identify over-engineering,
-missed requirements, scaling risks, and simpler alternatives." Incorporate
-the critique. Write the result to `analysis/$1/REIMAGINED_ARCHITECTURE.md`.
-
-## Phase D — HITL checkpoint #2
-
-Enter plan mode. Present the architecture. Wait for approval.
-
-## Phase E — Parallel scaffolding
-
-For each service in the approved architecture (cap at 3 to keep the run
-tractable; tell the user which you deferred), spawn a **general-purpose agent
-in parallel**:
-
-"Scaffold the <service-name> service per analysis/$1/REIMAGINED_ARCHITECTURE.md
-and AI_NATIVE_SPEC.md. Create: project skeleton, domain model, API stubs
-matching the interface contracts, and **executable acceptance tests** for every
-behavior-contract rule assigned to this service (mark unimplemented ones as
-expected-failure/skip with the rule ID). Write to modernized/$1-reimagined/<service-name>/."
-
-Show the agents' progress. When all complete, run the acceptance test suites
-and report: total tests, passing (scaffolded behavior), pending (rule IDs
-awaiting implementation).
-
-## Phase F — Knowledge graph handoff
-
-Write `modernized/$1-reimagined/CLAUDE.md` — the persistent context file for
-the new system, containing: architecture summary, service responsibilities,
-where the spec lives, how to run tests, and the legacy→modern traceability
-map. This file IS the knowledge graph that future agents and engineers will
-load.
-
-Report: services scaffolded, acceptance tests defined, % behaviors with a
-home, location of all artifacts.

plugins/code-modernization/commands/modernize-transform.md

@@ -1,78 +0,0 @@
----
-description: Transform one legacy module to the target stack — idiomatic rewrite with behavior-equivalence tests
-argument-hint: <system-dir> <module> <target-stack>
----
-
-Transform `legacy/$1` module **`$2`** into **$3**, with proof of behavioral
-equivalence.
-
-This is a surgical, single-module transformation — one vertical slice of the
-strangler fig. Output goes to `modernized/$1/$2/`.
-
-## Step 0 — Plan (HITL gate)
-
-Read the source module and any business rules in `analysis/$1/BUSINESS_RULES.md`
-that reference it. Then **enter plan mode** and present:
-- Which source files are in scope
-- The target module structure (packages/classes/files you'll create)
-- Which business rules / behaviors this module implements
-- How you'll prove equivalence (test strategy)
-- Anything ambiguous that needs a human decision NOW
-
-Wait for approval before writing any code.
-
-## Step 1 — Characterization tests FIRST
-
-Before writing target code, spawn the **test-engineer** subagent:
-
-"Write characterization tests for legacy/$1 module $2. Read the source,
-identify every observable behavior, and encode each as a test case with
-concrete input → expected output pairs derived from the legacy logic.
-Target framework: <appropriate for $3>. Write to
-`modernized/$1/$2/src/test/`. These tests define 'done' — the new code
-must pass all of them."
-
-Show the user the test file. Get a 👍 before proceeding.
-
-## Step 2 — Idiomatic transformation
-
-Write the target implementation in `modernized/$1/$2/src/main/`.
-
-**Critical:** Write code a senior $3 engineer would write from the
-*specification*, not from the legacy structure. Do NOT mirror COBOL paragraphs
-as methods, do NOT preserve legacy variable names like `WS-TEMP-AMT-X`.
-Use the target language's idioms: records/dataclasses, streams, dependency
-injection, proper error types, etc.
-
-Include: domain model, service logic, API surface (REST controller or
-equivalent), and configuration. Add concise Javadoc/docstrings linking each
-class back to the rule IDs it implements.
-
-## Step 3 — Prove it
-
-Run the characterization tests:
-```bash
-cd modernized/$1/$2 && <appropriate test command for $3>
-```
-Show the output. If anything fails, fix and re-run until green.
-
-## Step 4 — Side-by-side review
-
-Generate `modernized/$1/$2/TRANSFORMATION_NOTES.md`:
-- Mapping table: legacy file:lines → target file:lines, per behavior
-- Deliberate deviations from legacy behavior (with rationale)
-- What was NOT migrated (dead code, unreachable branches) and why
-- Follow-ups for the next module that depends on this one
-
-Then show a visual diff of one representative behavior, legacy vs modern:
-```bash
-delta --side-by-side <(sed -n '<lines>p' legacy/$1/<file>) modernized/$1/$2/src/main/<file>
-```
-
-## Step 5 — Architecture review
-
-Spawn the **architecture-critic** subagent to review the transformed code
-against $3 best practices. Apply any HIGH-severity feedback; list the rest
-in TRANSFORMATION_NOTES.md.
-
-Report: tests passing, lines of legacy retired, location of artifacts.

plugins/managed-agents/.claude-plugin/plugin.json

@@ -0,0 +1,8 @@
+{
+  "name": "managed-agents",
+  "description": "Claude Managed Agents Development Plugin",
+  "author": {
+    "name": "Anthropic",
+    "email": "support@anthropic.com"
+  }
+}

plugins/managed-agents/README.md

@@ -0,0 +1,39 @@
+# Claude Managed Agents Development Plugin
+
+A plugin for building applications on [Claude Managed Agents](https://platform.claude.com/docs/en/managed-agents/overview), Anthropic's hosted agent runtime.
+
+## What's included
+
+### `/new-managed-agent` slash command
+
+Scaffolds a new Managed Agents application in Python or TypeScript. Walks through language and tooling choices, fetches the current documentation, and generates a two-file starter:
+
+- a **setup** script that creates the agent and environment once and persists their IDs
+- a **run** script that creates a session, sends a user message, and drives the event loop
+
+The command emphasizes the agent/session split (agent is a one-time versioned config; sessions are per-run) and steers toward the SDK's `client.beta.*` resources rather than raw HTTP.
+
+### Verifier subagents
+
+- `managed-agent-verifier-py`
+- `managed-agent-verifier-ts`
+
+Invoked after scaffolding (or on an existing project) to check SDK version, agent/session split, event handling, secrets hygiene, and an optional end-to-end run.
+
+## Installation
+
+```
+/plugin install managed-agents
+```
+
+## Usage
+
+```
+/new-managed-agent my-support-bot
+```
+
+## Documentation
+
+- [Managed Agents overview](https://platform.claude.com/docs/en/managed-agents/overview)
+- [Quickstart](https://platform.claude.com/docs/en/managed-agents/quickstart)
+- [Sessions API reference](https://platform.claude.com/docs/en/managed-agents/sessions)

plugins/managed-agents/agents/managed-agent-verifier-py.md

@@ -0,0 +1,66 @@
+---
+name: managed-agent-verifier-py
+description: Use this agent to verify that a Python Managed Agents application is properly configured, follows the agent/session model correctly, and is ready for deployment or testing. Invoke after a Python Managed Agents app has been created or modified.
+model: sonnet
+---
+
+You are a Python Managed Agents application verifier. Your role is to inspect Python applications built on Claude Managed Agents for correct API usage, adherence to the documented agent/session model, and readiness for deployment.
+
+## Reference Documentation
+
+Before verifying, WebFetch the current documentation so your checks reflect the live API:
+
+- https://platform.claude.com/docs/en/managed-agents/overview
+- https://platform.claude.com/docs/en/managed-agents/quickstart
+- https://platform.claude.com/docs/en/managed-agents/sessions
+
+## Verification Checklist
+
+### 1. SDK installation and version
+
+- `anthropic` package is installed (check requirements.txt, pyproject.toml, or `pip show anthropic`)
+- Version is recent enough to expose `client.beta.agents`, `client.beta.sessions`, and `client.beta.environments`
+- Python version meets the SDK's minimum requirement
+
+### 2. Agent/session split
+
+- Agent creation (`client.beta.agents.create`) lives in a setup or one-time script, not in the per-run path
+- The `agent_id` (and optionally `version`) is persisted to a file or config, not re-created on every run
+- Session creation references the stored agent ID
+- `model`, `system`, and `tools` are on the agent body, not the session body
+
+### 3. API usage
+
+- Uses `client.beta.*` SDK resources rather than raw `httpx`/`requests` against `/v1/agents` etc.
+- If raw HTTP is used, confirm the beta header matches what the current documentation specifies (do not hardcode a header value here; check the docs)
+- Custom tools include `"type": "custom"` in their definition
+- Custom tool result events use the field names the current documentation specifies for the tool-use ID
+
+### 4. Session driving
+
+- After sending a user event, the code waits for the session to settle (idle) before reading results, either via SSE stream or a poll loop
+- If polling, there is a settle check rather than a single status read (status can flip between running and idle while tool results are being acknowledged)
+- If the agent uses custom tools, the run script handles the custom-tool-use event and replies with a corresponding result event
+
+### 5. Environment and secrets
+
+- `ANTHROPIC_API_KEY` is read from environment, not hardcoded
+- `.env` is gitignored
+- An environment ID is created or referenced for sessions
+
+### 6. Runtime check
+
+- Imports resolve (`python -c "import anthropic; anthropic.Anthropic().beta.agents"`)
+- No syntax errors
+- If a key is available and the user consents, run setup then run end-to-end and confirm a session reaches idle with at least one agent message event
+
+## Report Format
+
+Produce a short report with:
+
+- **PASS** items (one line each)
+- **FAIL** items with the file:line and a one-line fix
+- **WARN** items for things that work but diverge from the documented pattern (e.g. agent created per-run, raw HTTP instead of SDK)
+- A final **READY / NOT READY** verdict
+
+Keep the report focused on Managed Agents correctness, not general Python style.

plugins/managed-agents/agents/managed-agent-verifier-ts.md

@@ -0,0 +1,66 @@
+---
+name: managed-agent-verifier-ts
+description: Use this agent to verify that a TypeScript Managed Agents application is properly configured, follows the agent/session model correctly, and is ready for deployment or testing. Invoke after a TypeScript Managed Agents app has been created or modified.
+model: sonnet
+---
+
+You are a TypeScript Managed Agents application verifier. Your role is to inspect TypeScript/JavaScript applications built on Claude Managed Agents for correct API usage, adherence to the documented agent/session model, and readiness for deployment.
+
+## Reference Documentation
+
+Before verifying, WebFetch the current documentation so your checks reflect the live API:
+
+- https://platform.claude.com/docs/en/managed-agents/overview
+- https://platform.claude.com/docs/en/managed-agents/quickstart
+- https://platform.claude.com/docs/en/managed-agents/sessions
+
+## Verification Checklist
+
+### 1. SDK installation and version
+
+- `@anthropic-ai/sdk` is in package.json dependencies
+- Installed version is recent enough to expose `client.beta.agents`, `client.beta.sessions`, and `client.beta.environments`
+- Node.js version meets the SDK's minimum requirement
+- `tsconfig.json` is configured for the SDK (module resolution, target)
+
+### 2. Agent/session split
+
+- Agent creation (`client.beta.agents.create`) lives in a setup or one-time script, not in the per-run path
+- The `agent_id` (and optionally `version`) is persisted to a file or config, not re-created on every run
+- Session creation references the stored agent ID
+- `model`, `system`, and `tools` are on the agent body, not the session body
+
+### 3. API usage
+
+- Uses `client.beta.*` SDK resources rather than raw `fetch` against `/v1/agents` etc.
+- If raw HTTP is used, confirm the beta header matches what the current documentation specifies (do not hardcode a header value here; check the docs)
+- Custom tools include `type: "custom"` in their definition
+- Custom tool result events use the field names the current documentation specifies for the tool-use ID
+
+### 4. Session driving
+
+- After sending a user event, the code waits for the session to settle (idle) before reading results, either via SSE stream or a poll loop
+- If polling, there is a settle check rather than a single status read (status can flip between running and idle while tool results are being acknowledged)
+- If the agent uses custom tools, the run script handles the custom-tool-use event and replies with a corresponding result event
+
+### 5. Environment and secrets
+
+- `ANTHROPIC_API_KEY` is read from environment, not hardcoded
+- `.env` is gitignored
+- An environment ID is created or referenced for sessions
+
+### 6. Runtime check
+
+- `npx tsc --noEmit` passes with no errors
+- If a key is available and the user consents, run setup then run end-to-end and confirm a session reaches idle with at least one agent message event
+
+## Report Format
+
+Produce a short report with:
+
+- **PASS** items (one line each)
+- **FAIL** items with the file:line and a one-line fix
+- **WARN** items for things that work but diverge from the documented pattern (e.g. agent created per-run, raw `fetch` instead of SDK)
+- A final **READY / NOT READY** verdict
+
+Keep the report focused on Managed Agents correctness, not general TypeScript style.

plugins/managed-agents/commands/new-managed-agent.md

@@ -0,0 +1,169 @@
+---
+description: Create and set up a new Claude Managed Agents application
+argument-hint: [project-name]
+---
+
+You are tasked with helping the user create a new Claude Managed Agents application. Follow these steps carefully.
+
+## Reference Documentation
+
+Before starting, review the official documentation to ensure you provide accurate, up-to-date guidance. Use WebFetch to read these pages:
+
+1. **Start with the overview**: https://platform.claude.com/docs/en/managed-agents/overview
+2. **Then the quickstart**: https://platform.claude.com/docs/en/managed-agents/quickstart
+3. **Based on the user's language choice, read the appropriate SDK reference**:
+   - Python: https://platform.claude.com/docs/en/managed-agents/python
+   - TypeScript: https://platform.claude.com/docs/en/managed-agents/typescript
+4. **Read the relevant guides** based on the user's needs:
+   - Sessions API reference: https://platform.claude.com/docs/en/managed-agents/sessions
+   - Tools: https://platform.claude.com/docs/en/managed-agents/tools
+   - Environments: https://platform.claude.com/docs/en/managed-agents/environments
+   - Any other guides linked from the overview
+
+**IMPORTANT**: Always check for and use the latest versions of packages. Use WebSearch or WebFetch to verify current versions before installation. The Managed Agents API is in beta and shapes may change between releases; the docs are authoritative.
+
+## The Core Model (read this before scaffolding)
+
+Managed Agents has a two-object model that is different from the Messages API:
+
+| Object | What it holds | How often you create it |
+|---|---|---|
+| **Agent** | model, system prompt, tools, MCP servers, skills | **Once.** Persisted and versioned. Store the `agent_id`. |
+| **Session** | a running instance of an agent in an environment | **Every run.** References the agent by ID. |
+
+Do not call `agents.create()` on every run. The agent is a setup artifact; the session is the runtime. If you find yourself putting `model`, `system`, or `tools` on a session body, stop: those belong on the agent.
+
+## Gather Requirements
+
+IMPORTANT: Ask these questions one at a time. Wait for the user's response before asking the next question.
+
+1. **Language** (ask first): "Would you like to use Python or TypeScript?"
+
+   - Wait for response before continuing
+
+2. **Project name** (ask second): "What would you like to name your project?"
+
+   - If $ARGUMENTS is provided, use that as the project name and skip this question
+   - Wait for response before continuing
+
+3. **Agent purpose** (ask third): "What will this agent do? Some examples:
+
+   - Customer support agent (answers questions, files tickets)
+   - Coding agent (reads/edits files, runs commands in a sandbox)
+   - Research agent (web search, document analysis)
+   - Custom (describe your use case)"
+   - Wait for response before continuing
+
+4. **Tools** (ask fourth): "Which tools does the agent need?
+
+   - Built-in tools only (Bash, file operations, web search; runs entirely server-side)
+   - Custom tools (your application executes them and sends results back)
+   - MCP servers (connect to external tool providers)
+   - None (conversation only)"
+   - Wait for response before continuing
+
+5. **Tooling choice** (ask fifth): Confirm package manager and runtime preferences (npm/pnpm/bun for TypeScript; pip/poetry/uv for Python).
+
+After all questions are answered, proceed to create the setup plan.
+
+## Setup Plan
+
+Based on the user's answers, create a plan that includes:
+
+1. **Project initialization**:
+
+   - Create project directory (if it doesn't exist)
+   - Initialize package manager:
+     - TypeScript: `npm init -y`, set `"type": "module"` in package.json, add a "typecheck" script
+     - Python: create `requirements.txt` or `pyproject.toml`
+   - Add config files:
+     - TypeScript: `tsconfig.json` configured for the SDK
+     - Python: optionally a `pyproject.toml`
+
+2. **Check for latest SDK versions**:
+
+   - TypeScript: https://www.npmjs.com/package/@anthropic-ai/sdk
+   - Python: https://pypi.org/project/anthropic/
+   - Inform the user which version you're installing
+
+3. **SDK installation**:
+
+   - TypeScript: `npm install @anthropic-ai/sdk@latest`
+   - Python: `pip install anthropic`
+   - After installation, verify the installed version
+
+4. **Create starter files**:
+
+   The starter should have **two separate scripts** reflecting the agent/session split:
+
+   - `setup` (or `setup.ts` / `setup.py`): creates the agent once via `client.beta.agents.create(...)`, creates or reuses an environment via `client.beta.environments`, and writes both IDs to a local file (e.g. `.agent.json`). Re-running it should update the existing agent in place rather than creating a duplicate.
+   - `run` (or `run.ts` / `run.py`): reads the IDs file, creates a session via `client.beta.sessions.create(...)`, sends a user message event, and either streams or polls events until the session is idle. If the agent uses custom tools, this script handles `agent.custom_tool_use` events and replies with `user.custom_tool_result`.
+
+   Use the SDK's `client.beta.*` resources rather than raw HTTP. The SDK sets the required beta header and handles request encoding; raw HTTP requires you to track field names and headers manually and is a common source of 400 errors.
+
+5. **Environment setup**:
+
+   - Create `.env.example` with `ANTHROPIC_API_KEY=your_api_key_here`
+   - Add `.env` to `.gitignore`
+   - Explain how to get an API key from https://console.anthropic.com/
+
+6. **Optional**: offer to add a README explaining the agent/session split and how to extend the agent's tools.
+
+## Implementation
+
+After getting user confirmation on the plan:
+
+1. Check for latest package versions
+2. Execute the setup steps
+3. Create all files
+4. Install dependencies
+5. Verify installed versions and inform the user
+6. Create a working example based on their agent purpose and tool choice
+7. Add brief comments explaining the agent/session split where it matters
+8. **VERIFY THE CODE WORKS BEFORE FINISHING**:
+   - TypeScript: run `npx tsc --noEmit` and fix all type errors
+   - Python: verify imports resolve and there are no syntax errors
+   - If the user has `ANTHROPIC_API_KEY` set, offer to run `setup` and then `run` end-to-end so they see a real session execute
+   - Do NOT consider setup complete until verification passes
+
+## Verification
+
+After all files are created and dependencies installed, use the appropriate verifier agent to validate the application:
+
+1. **For TypeScript projects**: launch the **managed-agent-verifier-ts** agent
+2. **For Python projects**: launch the **managed-agent-verifier-py** agent
+3. Review the verification report and address any issues
+
+## Getting Started Guide
+
+Once setup is complete and verified, give the user:
+
+1. **Next steps**:
+
+   - How to set their API key
+   - How to run setup once: `python setup.py` / `npm run setup`
+   - How to run the agent: `python run.py` / `npm run start`
+
+2. **Useful resources**:
+
+   - Overview: https://platform.claude.com/docs/en/managed-agents/overview
+   - Sessions API reference: https://platform.claude.com/docs/en/managed-agents/sessions
+   - Tools: https://platform.claude.com/docs/en/managed-agents/tools
+
+3. **Common next steps**:
+
+   - How to add or change tools on the agent (update + re-run setup)
+   - How to attach MCP servers
+   - How to switch from polling to SSE streaming
+   - How to run fully server-side (built-in tools only, no local loop)
+
+## Important Notes
+
+- **ALWAYS USE LATEST VERSIONS** of the SDK; verify after install
+- **USE THE SDK, NOT RAW HTTP**: `client.beta.agents` / `client.beta.sessions` / `client.beta.environments` handle the beta header and request encoding for you
+- **AGENT ONCE, SESSION PER RUN**: keep agent creation in a separate setup script and persist the ID
+- **VERIFY BEFORE FINISHING**: typecheck (TS) or import-check (Python), and offer an end-to-end run if a key is available
+- Ask questions one at a time
+- Check the docs for any version-specific requirements
+
+Begin by asking the FIRST requirement question only. Wait for the user's answer before proceeding to the next question.