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, but keep operational artifacts out of the shipped-path manifest unless they are intended deliverables.
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.