Track V1 Change For V2

opencode v2 is a complete rewrite, so Kilo v1 fixes and features do not carry over automatically. This skill records what the behavior was and why it mattered in enough detail that a v2 agent can either confirm v2 already covers it or implement it from scratch without reading v1 code.

The /pr-track-v1 command is the normal entry point. Its arguments are optional context, not text to paste blindly into the issue.

Outcome

Finish with an issue in Kilo-Org/kilocode that:

• Is titled [v2-port] <summary>, labeled core-v1-changes-port, and assigned to @me.
• Opens with the auto-created provenance banner naming the source PR.
• Describes the problem, the user-visible behavior contract, edge cases, and acceptance criteria, not a file-by-file diff narration.
• Ends with a paste-ready Prompt For V2 Agent block.
• Is linked back from a comment on the source v1 PR.
• Contains no placeholders, invented motivations, or unverified claims.
• Is reused rather than duplicated when a tracking issue for the same PR already exists.

Resolve The Source PR

1. Run gh auth status and confirm access.

2. Resolve the target repo explicitly on every gh call: pass --repo Kilo-Org/kilocode. The user may invoke this from a worktree or from another repository.

3. Arguments may contain PR numbers, PR URLs, or several of them. With no argument, resolve the current branch's PR and confirm it is the intended one:

   gh pr view --repo Kilo-Org/kilocode --json number,url,title,state
   

4. Do not guess. If no PR can be resolved, ask for the PR number instead of inventing one.

Inspect The Change

Gather the behavior, not the implementation:

gh pr view <N> --repo Kilo-Org/kilocode \
  --json number,url,title,body,state,mergedAt,mergeCommit,author,labels,files,commits,comments,reviews,closingIssuesReferences
gh pr diff <N> --repo Kilo-Org/kilocode

Priority sources for functional detail, in order: