Implementation Kickoff

Implementation Kickoff

Use this skill as the explicit transition from an agreed implementation scope to isolated execution. Keep the user's original checkout and existing branches unchanged, and finish with a clean local branch that is ready for the user to push.

Non-negotiable boundaries

• Treat explicit invocation of this skill as authorization to fetch, create one dedicated worktree, rebase or replay task-owned changes, create the final local branch, stage task-owned files, and create one local commit. It never authorizes push, pull-request creation, or any GitHub mutation.
• Do not start during an investigation-only phase or before a required user approval. Finish planning and any required implementation scope contract first.
• Use read-only GitHub access when remote PR evidence is required.
• Preserve unrelated and user-owned changes. Do not remove an existing worktree or rewrite an existing branch to make room for this workflow.

1. Establish the task boundary

Record the original requirement, success criteria, intended target (origin/main unless the user states otherwise), task-owned paths, compatibility boundary, intentionally unsupported cases, and required repository skills. For a multi-step task, create and maintain the repository's required ExecPlan. An ExecPlan, review packet, ledger, trace, or temporary report is operational-only by default even when repository policy requires creating it; do not add it to the shipped-path manifest unless the original requirement or repository policy explicitly makes that exact path a committed deliverable.

If the current directory is a worktree previously created for this same task in the current conversation, resume it. Otherwise, continue from the user's current checkout only long enough to create a new worktree.

2. Create a detached worktree from current main

1. Verify the source checkout's raw status without modifying it.
2. Fetch origin main. If the fetch fails, stop rather than claiming a stale ref is current.
3. Record the fetched origin/main commit.
4. Choose a unique task-oriented path under the configured Codex worktree root. Check both the filesystem and git worktree list; never reuse or delete a collision.
5. Run git worktree add --detach <worktree> origin/main and perform all subsequent implementation work there.
6. Confirm the new worktree is detached at the recorded commit and initially clean.

Do not create the final branch yet. A detached worktree makes the eventual $pr-draft-summary branch suggestion authoritative and prevents temporary naming from becoming accidental output.

3. Implement without task commits

Keep the task diff uncommitted through implementation, focused tests, formatting, and review fixes. Track new files explicitly because ordinary diff statistics omit untracked files. Maintain one canonical shipped-path manifest separately from operational artifacts and require a concrete deliverable reason for every path in it. Use the applicable repository skills and references, including $implementation-strategy before user-facing or runtime changes.

When the task can be decomposed without temporarily breaking a supported contract, implement one narrow end-to-end behavior slice at a time and run its focused test before adding the next slice. Do not force cross-cutting migrations or atomic compatibility changes into artificial slices that cannot remain valid independently.

Do not create checkpoint commits. If an external interruption requires extra protection, leave the dedicated worktree intact or use a clearly named temporary stash; restore the changes before continuing and do not treat the stash as a deliverable.

Taking over an existing pull request

When the user asks to complete another author's pull request:

1. Refresh the PR metadata, head, discussion, and complete three-dot diff through read-only access.
2. Confirm that the PR is still an appropriate takeover source. Do not treat an already merged PR as an active takeover.
3. Apply the original PR's complete task diff onto the worktree based on current origin/main; do not derive the final branch from the contributor branch and do not preserve its intermediate commit topology.
4. Record the original PR number, PR author login, verified commit identity, existing valid Co-authored-by trailers, linked issues, and the original intent that the replacement must preserve.
5. If a valid author identity cannot be obtained from the PR's commits, stop before committing and ask the user. Never invent an email address.

4. Replay the complete task onto the latest main

After implementation, focused tests, and formatting are stable, fetch origin main again. If it advanced:

1. Confirm that every local change is task-owned.
2. Save tracked and untracked task changes in a uniquely named temporary stash.
3. Rebase the detached HEAD onto origin/main. With no task commits, this updates the empty local commit range to the new base.
4. Reapply the stash and confirm it was removed only after a clean application.
5. Resolve conflicts only when the requirement and surrounding source make the correct result unambiguous. Otherwise preserve the stash and conflict evidence, then stop for user direction.
6. Rerun formatting and every focused check affected by the new base.

Record this observed origin/main commit as the final-base candidate. Do not call an older base "latest" merely because its changes appear unrelated.

5. Complete final review and verification

Run applicable completion gates against the complete task-owned diff on the final-base candidate. Apply formatting and safe hook-equivalent normalization before review, including generated-file provenance checks where relevant. Use $implementation-final-review to select lightweight, ordinary, or high-risk review; supply all task-owned untracked file contents as well as tracked changes. Only high-risk review requires review_state.py --complete-diff-output <complete.diff> and the strict packet/ledger protocol. Follow the selected procedure's evidence and invalidation rules.

Run $code-change-verification after clean review whenever its SDK eligibility rules apply. A lightweight review exemption does not waive an otherwise required SDK verification stack. Repo-meta work uses its applicable skill and focused checks. Do not create the branch or commit while required review, verification, or evidence remains incomplete.