migrate

name	migrate
description	Understand another agent system and design a better base-native one.
disable-model-invocation	true
argument-hint	<task>

Migrate pipeline

Use to migrate a client or legacy system (agents, skills, commands, hooks, workflows) into Base. Assume the source is messy and over-built. The goal is not a mirror — it is to understand what the system actually does and design a better one using Base's methodology: capability-first, a minimal set of role-based agents, capabilities as gated pipelines with verifiers, domain expertise as knowledge, base-native naming. base ingest understands the source and surfaces its fragmentation; the human approves an architecture; the agent authors the pack. Load knowledge/migration-architecture.md before designing.

Task: $ARGUMENTS Record harness as claude in the run ledger.

1. Migrate Inventory

Run base ingest <source-path> --run <run-slug>. It resolves the source (a project root or the .claude directory itself), summarizes harness config instead of enumerating it, classifies the whole tree into knowledge / state / tooling / generated raw material, and surfaces capability clusters and redundancy signals. Read the whole understanding report. Note the fragmentation signals (families of near-duplicate agents, over-large agent counts), the real capabilities behind them, and which raw material is durable knowledge versus runtime state versus tooling versus generated output. Do not design or author yet — understand first.

Assigned agent: delivery-analyst

Delegate this stage to the repository agent delivery-analyst when native agent delegation is available; otherwise follow that agent's generated contract directly and report the fallback.

2. Migrate Design

Design the target, do not port the source. Follow knowledge/migration-architecture.md. First state the real capabilities the system delivers (stripped of fragmentation — a security-* family is one capability, not eight). Then design the minimal base-native architecture that delivers them: a small set of role-based agents (analyst / implementer / reviewer + only genuinely distinct specialists), capabilities as gated pipelines with verifiers, reusable techniques as skills, durable domain facts as knowledge, with base-native names. Write an explicit consolidate / rename / drop list with the reasoning: what merges, what is renamed, and what (runtime state, generated output, bespoke tooling) is deliberately not migrated. This is a plan-approval gate: the human approves the architecture before anything is authored.

Assigned agent: delivery-analyst

Delegate this stage to the repository agent delivery-analyst when native agent delegation is available; otherwise follow that agent's generated contract directly and report the fallback.

Gate: plan-approval

STOP after completing this stage. Do not execute until the user explicitly approves the written plan. Request the verdict by writing approvals/plan-approval.md.request in the run folder describing what needs approval, then stop. The verdict is recorded from outside the session: base approve <run-slug> plan-approval (or --deny) writes approvals/plan-approval.md — a standing directive counts only when recorded that way, with --note citing it. Never create the verdict artifact yourself. If the recorded verdict is denied, skip to record with outcome aborted.

3. Migrate Author

Run base pack new <id>, then author the approved architecture. Write each definition fresh in vendor-neutral canon — never paste source bytes (D-019/D-023). Author the consolidated agents, pipelines, skills, and verifiers the design calls for, and rewrite the still-true domain knowledge into knowledge/ (an authored summary, not a copy of the source's memory/learnings dumps). Do not recreate the fragmentation you consolidated away. Run base pack check <path> as the tight loop until the manifest, paths, and every frontmatter document validate.

Assigned agent: delivery-implementer

Delegate this stage to the repository agent delivery-implementer when native agent delegation is available; otherwise follow that agent's generated contract directly and report the fallback.

4. Migrate Prove

Prove the authored pack. Run base pack check <path>, then adopt it into a scratch project and run base check and base sync --check there; the attached delivery-foundation verifier proves Base composition and generated-surface integrity. Classify each result as pass, fail, or inconclusive, and retain the evidence under the run. A pack that does not adopt cleanly is not done — record the non-passing outcome rather than narrating success.

Assigned agent: delivery-implementer

Delegate this stage to the repository agent delivery-implementer when native agent delegation is available; otherwise follow that agent's generated contract directly and report the fallback.

Verifier: delivery-foundation

Run base verify delivery-foundation --run <run-slug>. A fail or inconclusive verdict is not passing evidence and must be reported before proceeding.

5. Migrate Review

In a context that did not author the pack, judge the redesign against the retained understanding. Confirm every real capability the source delivered is still delivered — consolidation must not have dropped a capability, only its fragmentation. Confirm each merge, rename, and drop was a recorded, justified decision, and that the result is genuinely base-native (role-based agents, gated pipelines with verifiers, domain knowledge, clear names) rather than a thinned-out clone. Confirm the base improvements are present (gates, verifiers, work/handoff, cross-harness output). Raise anything lost, unproven, or still over-fragmented before the pack is trusted.

Assigned agent: delivery-auditor

Run this stage in a distinct delivery-auditor agent context that did not implement the change. If this target cannot provide separate agent execution, report the review as assisted and do not claim independent maker/checker separation.

6. Record

Always run this stage, including after rejection, failure, or abort. Append exactly one compact JSON object line to .base/history.jsonl with slug, date, pipeline, harness, outcome, and paths. Use completed, aborted, or failed for outcome; never rewrite previous lines.