Menu
Understand another agent system and design a better base-native one. Use when the user explicitly invokes the migrate pipeline.
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
Understand another agent system and design a better base-native one.
Turn a repetitive manual procedure into a proven, repeatable mechanism. Use when the user explicitly invokes the automation pipeline.
Plan, approve, implement, verify, and record a software change. Use when the user explicitly invokes the build pipeline.
Record a durable architecture decision with alternatives and consequences.
Discover, approve, implement, prove, review, and record a software change. Use when the user explicitly invokes the delivery pipeline.
Leave unfinished repository work safe for another human or agent to resume.
| name | migrate |
| description | Understand another agent system and design a better base-native one. Use when the user explicitly invokes the 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.
Use the task supplied alongside this explicitly invoked skill.
Record the actual runtime, codex or copilot, as harness in the run ledger.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Run base verify delivery-foundation --run <run-slug>. A fail or inconclusive verdict is not passing evidence and must be reported before proceeding.
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.
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.
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.
