Choose what the repository is for
Build on it: connect the local or GitHub repository you want to change. Use it as reference: explain what the agents should learn from it and make clear that it is not the implementation target.
Prepare the handoff
- Connect the intended repository. Choose your local repository or a GitHub connection. Make sure the connected execution machine can access the local project, or that the GitHub connection has appropriate permissions. Confirm the target before starting work.
- Explain the current state. Share what works, what needs to change, the relevant documents and how the project is run or tested.
- Name the boundaries. Identify important architecture decisions, areas that should stay unchanged and any work already in progress.
- Ask for an assessment and plan. Have the manager explain the proposed change and unresolved questions before implementation.
- Review the work. Inspect proposed changes and checks, request corrections and decide when the result is ready to integrate.
What you should have at the end
A scoped plan tied to the correct project, with clear boundaries and a reviewable next change. Repository access alone does not communicate the product’s priorities; explain those too.
Keep your starting point
Preserve the project’s history and review what is being changed. A local repository does not automatically imply GitHub access. If you choose a GitHub workflow, confirm the remote connection, permissions and pull-request review policy before relying on them.