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: