harness-driven-renovate

Implement one Azure-backed strangler slice in the target repository after architecture, requirements, Azure review, rollback plan, and touched-seam harnesses are green. Produces tested, observable, reversible code and deployment evidence.

Use before any destructive refactor or UX/backend change to capture the legacy system's current behavior as characterization tests and golden-master fixtures — the safety net that catches regressions. This is the harness gate; it must be green before modernization code begins.

Implement a vetted legacy-web UX slice in the target repository after requirements and touched-seam harnesses are green. Discovers the real frontend stack, changes code test-first, and records implementation evidence before browser validation and review.

Use when starting or resuming a legacy web modernization (UI/UX and/or backend) — routes between renovation phases, tracks state in plan.md, and enforces the harness/test/review gates. Entry point for the harness-driven-renovate workflow.

Use to modernize a legacy backend incrementally using the strangler-fig pattern — route slices of traffic to new event-driven / cloud-native services behind stable seams while the characterization harness guards against regressions. Requires the harness gate to be green.

Use as a mandatory gate before any renovation change is considered done or merged — rigorous review focused on harness regressions, legacy parity, security, and readability. Cross-cutting; invoke on every change. Composes with requesting-code-review / code-review agent.

Use whenever you write new or refactored code during a renovation (frontend or backend) — author tests first (red-green-refactor) and build the automated test coverage the modernized system needs. Cross-cutting; invoke on every code-producing step. Composes with the tdd skill.

Use to modernize a legacy web UI/UX — collapse scroll/popup-heavy, multi-screen flows into a single coherent flow, remove accumulated dead features, and design a realtime operations dashboard. Requires the harness gate to be green before changing behavior.

Use this skill whenever UX modernization optionally needs Figma-based design review, human approval, Figma MCP, Figma frames/prototypes, design comments, design tokens/components, Code Connect, or “approve the design before implementation.” It provides opt-in design evidence for web-action-testing and strict-code-review; it is not required when Figma is not used.

Use this skill whenever UX modernization needs real browser action validation, Webwright/Playwright-style testing, screen-action walkthroughs, screenshots, traces, or “try the UI and improve from the result.” Runs after UX changes or prototypes to exercise actual user flows and feed findings back into ux-modernization before review.

Use to add AI/LLM features to a modernized web system — define concrete use cases, pilot them, and add evals. For this domain: message-draft generation, send anomaly detection, and natural-language operations-status summarization. Feasibility and cost of in-house LLMs are first-class concerns.

Use after legacy-discovery and before requirements-grilling to reverse-engineer the existing codebase and application architecture — recover the as-is tech stack, module structure, dependency graph, runtime topology, integration mechanics (DB2DB/TCP/API), coupling hotspots, and refactoring seams. Produces the technical baseline that grilling challenges the target (to-be) architecture against.

Use this skill whenever backend modernization, strangler-backend, event-driven refactoring, cloud-native transition, Azure services, Azure Architecture Center, Well-Architected Framework, Azure MCP, AKS, Container Apps, App Service, Functions, Service Bus, Event Grid, API Management, or Azure backend best practices are mentioned. It gates backend target architecture before implementation.

Use near the end of a renovation to measure before/after effect and package the result for scale-out — quantify UX, operational, and AI-driven improvements against the baseline captured during discovery, and produce a reusable rollout artifact.

Use at the start of a legacy renovation to build a BA-style current-state analysis — inventory every screen, feature, data flow, and system integration (DB2DB / TCP / API), and record concrete pain points before proposing any change.

Use after legacy-discovery and before any design or build to adversarially interrogate requirements — challenge assumptions, sharpen terminology, resolve ambiguity one question at a time until requirements are crisp. Matt Pocock style grilling. Acts as a gate.