anti-legacy-skill-forge

name

anti-legacy:skill-forge

description

A meta-skill — a skill that WRITES skills. Once the blueprint exists, it generates one target-tailored `build-<domain>` SKILL.md per domain into .anti-legacy/generated-skills/, baking the blueprint component specs + each requirement's business rules / validations / error paths + entity parity into reusable build instructions a CLI/IDE agent FOLLOWS to build the target natively and consistently. Inverse of anti-legacy:develop-plugin (which evolves the plugin): this generates the TARGET system's build skills. Use when: "generate the build skills", "create skills to build the target", "scaffold the target build", "forge build skills", "make it natural to build the target state".

anti-legacy:skill-forge

The pipeline already designs the target (blueprint.json) and records patterns/decisions. But building the target has been a per-task micro-context assembly inside swarm each run — it isn't a first-class thing a CLI/IDE agent just does. skill-forge closes that: it turns the target design into target-tailored build skills the agent invokes by name.

It is the target-system analog of anti-legacy:develop-plugin: develop-plugin evolves this plugin from learnings; skill-forge generates skills for the target system. The product is SKILL.md files (instructions the agent follows), not scripts — because building is an agent task. They are deterministic projections of the design (no LLM), regenerated whenever the blueprint changes.

Cross-Platform Notes

One command through the dispatcher (python3 .anti-legacy/run.py skill_forge), pure Python — macOS / Linux / WSL / Windows.

When it runs / prerequisites

• After anti-legacy:blueprint — it reads blueprint.json (the target architecture: domains → components with class_name/component_type/api/methods/schema) + requirements_graph.json (each component's business_rules / validations / error_paths / legacy_components) + config.json (target stack). No blueprint ⇒ it refuses (won't forge hollow skills).
• It owns no manifest phase enum value — it's a generation utility that runs in/after the blueprint phase. It does not manifest advance.

Step 1: Generate the build skills

python3 .anti-legacy/run.py skill_forge

This writes, per target domain, .anti-legacy/generated-skills/build-<domain>/SKILL.md — a self-contained build contract for that capability — plus a README.md index. Each generated skill contains:

• Target (stack, package, style) + conventions (idiomatic code, @ImplementsRule on every rule, rule-coverage 1.0, no stubs, numeric-precision parity).
• A dependency-sorted build order.
• Per component: the blueprint spec (class/type/target_file/api/methods/deps) + the requirement's business rules (with their RULE-/VAL-/ERR- ids to annotate), the legacy provenance (§2 traceability), and the data model with source_type parity (COMP-3/DECIMAL).

Step 1.5: Adversarially review the generated skills (same critic as the deliverables)

Before any code is built from them, subject each generated build-<domain> skill to the same adversarial review the deliverables get — run anti-legacy:adversarial-review over .anti-legacy/generated-skills/. A read-only critic challenges each generated skill: is every component grounded in the blueprint + requirements (no behavior invented beyond the spec)? is the §2 trace (req_id → legacy_components → rule) intact? is COMP-3/DECIMAL parity preserved? is the build order sound? It returns a per-skill verdict (findings + PASS / REVISE / BLOCK). Fix the upstream (regenerate from a corrected blueprint/graph) before the agent builds from a BLOCK'd skill. Advisory — it never clears a gate. (A generated skill is AI-derived output, so it gets the same critic treatment as every other generated artifact.)

Step 2: Build the target by FOLLOWING the generated skills

To build a capability, the agent reads + follows the matching generated skill — e.g. "build the billing domain" → .anti-legacy/generated-skills/build-billing/SKILL.md. (anti-legacy:swarm can dispatch these per task instead of re-deriving a micro-context.) Because the spec, rules, parity, and conventions are baked in, the build is consistent and traceable across any CLI/IDE agent — and re-running skill_forge after a blueprint change regenerates them (idempotent).

Step 3: Done-gate + report

The generator exits non-zero if there is no blueprint with domains. On success it prints the generated skills. Confirm the index exists and report which domains got build skills (and any domain whose components carry no business rules — the forge flags those ⚠ in-skill rather than inventing behavior; they need extraction/human review, not a guess).

Output

• .anti-legacy/generated-skills/build-<domain>/SKILL.md — one target-tailored build skill per domain (agent-followed).
• .anti-legacy/generated-skills/README.md — the index.

Don'ts (AGENTS.md)

• DON'T invent behavior for a component with no business_rules — the forge flags it ⚠; send it back to extraction or human review.
• DON'T drop the legacy_components trace or the source_type parity from a generated skill.
• DON'T hand-edit generated skills — regenerate from the blueprint (they're deterministic output).