anti-legacy-deliverables

Stars1

Forks0

UpdatedJune 19, 2026 at 05:52

Render the full stakeholder DELIVERABLES package once the requirements graph is ready — product requirements (PRD), architecture diagrams, detailed test strategy, functional test scripts, end-to-end migration plan, and the living risk / decisions / evidence logs — into .anti-legacy/deliverables/, then compile an index. Register-only; does not advance the pipeline. Use when: "produce the deliverables", "generate all the deliverables", "the deliverables package", "PRD + diagrams + plan + risk/decision logs".

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Source

mikeparcewski

mikeparcewski/anti-legacy

View GitHub Repository View Creator Repositories

Download

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

File Explorer

2 files

SKILL.md

readonly

More from this repository

same repository

anti-legacy-graph-validator

mikeparcewski/anti-legacy

Validates the requirements graph against the wicked-estate code graph before the blueprint phase. Checks every requirement's legacy field resolves to a real program node in the graph (not a JCL step), finds uncaptured behavior-bearing nodes with business logic that need requirements, and flags duplicate program references. Blocks if errors are found; warns and requires human review if only gaps remain. Run after extraction/graph-translator, before blueprint. Use when: "validate requirements graph", "audit the graph", "check graph accuracy", "are we missing any programs", "graph audit before dev", "validate before blueprint".

2026-06-191

anti-legacy-analyze

mikeparcewski/anti-legacy

Apply structural lenses to the legacy code graph to identify entry points, domain boundaries, shared data coupling, operational modes (batch vs online), and risk hotspots. Queries the wicked-estate code graph via the helper (never raw SQLite, never legacy_graph.json). Produces an analysis report. Use when: "analyze the legacy code", "identify entry points", "find domain boundaries", "what are the hotspots", "classify the programs".

2026-06-191

anti-legacy-antagonist

mikeparcewski/anti-legacy

Pre-build threat modeler — the adversarial half of the Phase Execution Protocol (PEP, AGENTS.md §10). Given a phase plan and its threat surface, generates a structured threat list BEFORE the producer runs so the producer can address each threat in its output rather than discovering the gap post-build. CRITICAL threats block the phase from advancing until the producer acknowledges them (fix or documented waiver). MEDIUM/MINOR are advisory. Distinct from anti-legacy:adversarial-review (which reviews rendered output AFTER production) — the antagonist attacks the plan BEFORE production, while it is still cheap to change. Use when: any phase producer is about to run; "antagonist check"; "threat model this phase"; "what could go wrong"; PEP step 3 in orchestrate.

2026-06-191

anti-legacy-expert

mikeparcewski/anti-legacy

The anti-legacy pipeline internals SME, and the home of the shared antilegacy_core Python library. Use when: understanding or operating the pipeline core, diagnosing a core module (estate seam, requirements-graph builder, coverage, manifest state machine, validator), checking pipeline readiness, or extending antilegacy_core.

2026-06-191

anti-legacy-blueprint

mikeparcewski/anti-legacy

Map the Requirements Graph to a target state architecture blueprint. Defines the modern package structure, API surface (REST/gRPC), database schemas, class boundaries, and repository patterns for the target stack. Produces blueprint.json + blueprint.md. Use when: "design the target architecture", "create the blueprint", "map requirements to target stack", "design the Spring Boot structure", "what does the modern version look like".

2026-06-191

anti-legacy-deploy

mikeparcewski/anti-legacy

Package and deploy the modernized application to the configured deployment target. Supports GCP Cloud Run, AWS ECS/Fargate, Azure AKS, and generic Kubernetes. Generates Dockerfile, CI/CD pipeline config, and deployment manifests. Requires GATE_4_UAT to be cleared. Use when: "deploy the app", "generate the Dockerfile", "create CI/CD config", "package for Cloud Run", "generate Kubernetes manifests", "deployment".

2026-06-191

name

anti-legacy:deliverables

description

anti-legacy:deliverables

The umbrella that produces the human-facing deliverables package from the pipeline's structured artifacts. It runs when the graph is ready (after graph-translate, ideally with blueprint + test-strategy available) and writes everything under .anti-legacy/deliverables/.

This is not the review-packet (that is the single offline GATE_1 review document). These are the detailed, individually-consumable deliverables a delivery team needs:

Deliverable	Skill	Output
Product Requirements (PRD)	`anti-legacy:prd`	`deliverables/product-requirements.md`
Architecture Diagrams (Mermaid)	`anti-legacy:diagrams`	`deliverables/diagrams/*.mmd` + index
Test Strategy (data-parity / UAT / E2E / API)	`anti-legacy:test-plan`	`deliverables/test-strategy.md`
Functional Test Scripts	`anti-legacy:test-scripts`	`deliverables/tests/{data-parity,uat,e2e,api}/…`
Migration Plan (epics→subtasks) + Jira CSV	`anti-legacy:migration-plan`	`deliverables/migration-plan.md` + `.jira.csv`
Risk Log (living)	`anti-legacy:risk-log`	`deliverables/risk-log.md`
Decisions Log / ADRs (living)	`anti-legacy:decisions-log`	`deliverables/decisions-log.md`
Evidence Log with receipts (living)	`anti-legacy:evidence-log`	`deliverables/evidence-log.md`

Each deliverable registers its artifact (deliverable-*) in the manifest and never advances the phase — phase advancement stays owned by the phase skills. The living deliverables (risk / decisions / evidence) reflect current state, so re-run them at each gate.

Cross-Platform Notes

Every command runs through the dispatcher (python3 .anti-legacy/run.py <stem>), which is pure Python — identical on macOS, Linux, WSL, and Windows.

When it runs / prerequisites

Required: .anti-legacy/requirements/requirements_graph.json (produced by anti-legacy:graph-translator). Without it the renders refuse to write hollow output.
Enriches when present (degrade gracefully when absent, naming the gap): blueprint.json (diagrams, test-plan, migration-plan), contracts/ (test-plan, test-scripts), the manifest + audit.jsonl (decisions-log, evidence-log), coverage-report.json + annotations.jsonl (risk-log).
Natural home in the pipeline: the review-packet stage (graph + blueprint + test-strategy ready, feeding GATE_1). Also runnable standalone anytime the graph exists.

Step 1: Verify the graph is ready

python3 .anti-legacy/run.py manifest status

Confirm .anti-legacy/requirements/requirements_graph.json exists. If it does not, stop and run anti-legacy:graph-translator first — the deliverables render FROM the graph.

Then run the readiness gate — the authoritative precondition. Unlike a file-exists check it refuses on an incomplete or state-desynced pipeline (a confidence-less rule, coverage < 1.0, or an orphaned requirements-graph whose legacy-graph evidence is gone — ROOT A/B):

python3 .anti-legacy/run.py precheck deliverables

If it exits non-zero, STOP and resolve the named blockers. The Tier-A renders below call this same gate internally and will refuse on their own; --force is the explicit, loud override (only for a deliberate partial/preview run). The living logs (risk_log, decisions_log, evidence_log) are intentionally not gated — they must run on an incomplete pipeline to SURFACE its gaps.

Step 2: Render the deliverables

Run each render through the dispatcher, in this order. A render that must degrade (e.g. test-scripts on a stack it cannot script yet, or any Tier-A render with no blueprint) prints a note and still exits 0 — do not abort the suite on a soft note; collect it for the report.

python3 .anti-legacy/run.py prd
python3 .anti-legacy/run.py diagrams
python3 .anti-legacy/run.py test_plan
python3 .anti-legacy/run.py test_scripts
python3 .anti-legacy/run.py migration_plan
python3 .anti-legacy/run.py risk_log
python3 .anti-legacy/run.py decisions_log
python3 .anti-legacy/run.py evidence_log

A hard non-zero exit means a true precondition failure (no graph, or no manifest for the evidence log) — surface it and stop; do not paper over it.

Optional — richer output via parallel subagents. The renders above are deterministic and fast. Two deliverables benefit from agent reasoning on top of the deterministic skeleton: the PRD (narrative framing of each requirement) and the functional test scripts (concrete assertions fleshed out from each contract scenario). When you want that, dispatch anti-legacy:prd and anti-legacy:test-scripts as subagents — they have no ordering dependency on each other, so run them in parallel.

Step 3: Compile the index

python3 .anti-legacy/run.py deliverables_index

This writes + registers .anti-legacy/deliverables/README.md — the package table of contents: each deliverable's path, status, produced-at, and a present/absent receipt, plus the canonical expected set so anything not yet produced is named, not silently absent.

Step 4: Adversarial review (advisory — not a gate)

The renders are deterministic and trusting — they lay out what the data says. Before sharing the package, run the adversarial review that distrusts them: it dispatches one read-only critic subagent per deliverable, in parallel, to challenge each rendered file against the source data it was rendered from — hunting unsupported/optimistic claims, dropped §2 traceability, empty/weak sections, missing parity rules on numeric outputs, "done" that hides a gap, and divergence from the requirements graph.

Run anti-legacy:adversarial-review (see that skill for the critic micro-context and the parallel-dispatch protocol). It assembles the worklist via:

python3 .anti-legacy/run.py deliverable_review_worklist --json

then dispatches the critics and returns a structured per-deliverable verdict (findings[] with severity → PASS / REVISE / BLOCK) plus an aggregated package verdict.

This is advisory adversarial review, NOT a gate. It clears no gate, advances no phase, and registers no artifact. On REVISE/BLOCK, re-run the named producing deliverable to fix the render at its source and re-review, or proceed with an explicit, stated --force reason (mirroring the precheck override — never a silent skip). Collect the verdicts for the report in Step 5.

Step 5: Done-gate, then report

Done-gate (BLOCKING). Assert the index exists and is non-empty and at least one deliverable was produced:

python3 -c "import os,sys; \
idx='.anti-legacy/deliverables/README.md'; \
ok=os.path.isfile(idx) and os.path.getsize(idx)>0; \
sys.stderr.write('' if ok else 'deliverables done-gate FAILED: index missing/empty\n'); \
sys.exit(0 if ok else 1)"

If it fails, surface which renders errored and stop. This skill never calls manifest advance — it registers artifacts only.

Report to the user:

Deliverables package: .anti-legacy/deliverables/ (open README.md for the index)
Produced N / 9 and any deliverable that degraded (which input it was missing)
Adversarial review verdict (Step 4): the package verdict (PASS / REVISE / BLOCK) and any CRITICAL/MAJOR findings per deliverable — advisory, cleared no gate
Reminder: re-run risk-log, decisions-log, evidence-log at each gate to refresh the living deliverables

Output

.anti-legacy/deliverables/ — the full package (PRD, diagrams/, test-strategy, tests/, migration-plan + Jira CSV, risk/decisions/evidence logs)
.anti-legacy/deliverables/README.md — the registered index (deliverables-index)
Manifest: deliverable-* artifacts registered; phase unchanged
Adversarial-review verdicts (anti-legacy:adversarial-review, Step 4) — advisory, no artifact

Next step: address any REVISE/BLOCK from the adversarial review (re-run the named producing deliverable, then re-review), then share the package via git/fileshare and feed it into the review-packet / GATE_1 design review. Re-run the living logs at later gates.