Code Porting

职业

分类

调试

Phases

Phase 0: Enter plan mode

Main thread enters plan mode before any work begins. All phases 1–5 execute within plan mode. Exit plan mode at Phase 6 for user review.

Phase 1: Feature extraction

Spawn extraction agent. Prompt must include:

• Source codebase paths and user-specified scope.
• "List AS MUCH AS POSSIBLE. Err on over-listing. The critique phases prune — you do not."

Semantic context tree (required, before feature list)

Extract the full semantic hierarchy from project root to modified parts:

Project: what it is, who it serves, core purpose
  └── Module: what this module does within the project
        └── Component: what this component does within the module
              └── Modified parts: what changed and how it affects the component/module/project semantics

Every feature in the inventory must be anchored to its branch in this tree. Reviewers need to understand not just WHAT was changed but HOW it affects the system's meaning at every level.

Per-feature output format

• Agent must read source code comprehensively — no summaries from memory.
• Word cap: 3000 words.

Phase 2: Gap analysis

Spawn a DIFFERENT agent — not the extraction agent.

Prompt must include:

• Feature inventory from Phase 1 verbatim.
• Target codebase paths.
• "Read target code independently. Do not trust the extraction agent's claims about the target."

Required output per feature:

Word cap: 2000 words.

Phase 3: Critique the list

Spawn a DIFFERENT agent — not the extractor or gap analyzer.

Prompt must include:

• Feature inventory + gap analysis.
• Source and target codebase paths (critic reads code independently).
• "Assume every entry is wrong until you prove otherwise."

Required output:

• Per-feature verdict: CONFIRMED / CORRECTED / REJECTED / MISSING (new feature the extractor missed).
• For CORRECTED: what was wrong and the fix.
• For REJECTED: evidence it's not a real feature or not in scope.
• For MISSING: full feature entry (same format as Phase 1).
• "Be harsh. Over-extraction is expected — prune noise, but do not prune real features to look selective."

Word cap: 2000 words.

Phase 4: Critique the critique

Spawn a DIFFERENT agent — not any prior agent.

Purpose: prevent single-critic bias. The Phase 3 critic may be too aggressive (pruning real features) or too lenient (rubber-stamping).

Prompt must include:

• All Phase 1–3 outputs.
• Source and target codebase paths.
• "Review the critic's work, not the original list. Is the critic accurate? Too aggressive? Too lenient? Missing patterns?"

Required output:

• Per-verdict assessment: AGREE / OVERTURN / AMEND.
• For OVERTURN: evidence the critic was wrong, restored feature entry.
• For AMEND: what the critic got partially right and the correction.
• Systemic patterns: is the critic consistently biased in a direction?

Word cap: 1500 words.

Phase 5: Design loop

Iterative loop, max 3 iterations.

Phase 5a: Plan designer

Spawn plan designer agent. Prompt must include:

• Reconciled feature list (main thread resolves Phase 3 + Phase 4 verdicts into a single adjudicated inventory before spawning this agent).
• Gap analysis.
• Target codebase paths.
• "Design a concrete porting plan."

Required output:

Word cap: 3000 words.

Phase 5b: Plan critic

Spawn a DIFFERENT agent — not the plan designer.

Prompt must include:

• The porting plan from 5a.
• All prior phase outputs.
• "Assume the plan is wrong."

Checks:

• Dependency ordering correct?
• Missing steps?
• Over-engineering (porting things that aren't needed)?
• Under-scoping (missing integration glue)?
• File-to-binary assignment coherence — does each file belong in the binary whose purpose matches?
• Task granularity appropriate for explore-critique-implement?

Verdict: PASS (with NITs) or FAIL (with mandatory fixes). On FAIL, loop back to 5a with critic's feedback. Word cap: 1500 words.

Loop exit

• Plan critic passes, OR
• 3 iterations exhausted → present best plan to user with unresolved critic issues flagged.

Phase 6: User configuration

Exit plan mode. Present the final plan to the user:

• Full task list with ordering.
• Unresolved critic issues (if any).
• Estimated total scope.

User may: approve all, approve subset, modify tasks, reject and restart.

Proceed only with user-approved tasks.

Phase 7: Implementation

For each approved task, invoke explore-critique-implement. Each task goes through the full explore→critique→implement→review gate loop independently.

Per-task prompt must include:

• Original user requirements verbatim.
• Specific task from porting plan (Task ID, features, approach, files, risks).
• Source file paths relevant to the feature being ported.
• Target file paths from the porting plan.
• Dependencies on prior completed tasks and their outcomes.
• "This is a porting task. Read the source implementation before exploring options."

explore-critique-implement handles coding-style loading per its own prerequisites.

Task ordering from Phase 5 is mandatory — do not parallelize tasks with dependencies.

Independent tasks (no dependency relationship) may run in parallel via agent-teams-execution.

Escalation

Red flags

Relationship to other skills