How to hand off a project plan to an AI coding tool

Hand a project plan to an AI coding tool by giving it the project's purpose, confirmed scope, important decisions and one specific implementation task with a clear check. Ask it to inspect any existing work before changing it. Keep the plan available as files so the context is easier to revisit as the project evolves.

The goal is a useful handoff, not a single enormous prompt that attempts to produce the whole application at once.

Prepare a small set of readable project documents

Keep the material organised around the decisions a builder needs:

• Project overview: purpose, users and first useful outcome.
• Scope: the core journey, requirements and explicit exclusions.
• Technical direction: recommendations, constraints and assumptions.
• Working guidance: relevant conventions, safety rules and checks.
• Milestones: a sequence of small steps with observable completion criteria.

Avoid storing three slightly different versions of the same requirement across several files. Choose an authoritative location and link to it. Mark recommendations and unresolved choices so they do not look like approved requirements.

If you are starting from a rough idea, the project brief template helps establish this context first.

Check how your chosen tool reads instructions

Do not assume every coding tool automatically reads every document in a folder. Start by naming the files it should read, and check its current documentation for persistent project instructions.

For example, GitHub documents repository guidance through .github/copilot-instructions.md, with other instruction formats supported in particular contexts. See its repository instructions guide for applicability. Claude Code documents project guidance through CLAUDE.md in its best practices.

A document filename is not a guarantee that every tool or mode will load it. Ask the tool to summarise the important constraints it read before implementation begins. Correct misunderstandings at that point.

Ask the builder to inspect existing work

For a new empty project, inspection establishes what is available. For an existing implementation, it should identify the structure, dependencies, working behaviour and current checks before proposing changes.

Ask the implementing tool to:

1. Read the relevant project instructions and source files.
2. Identify existing functionality that should be preserved.
3. Explain which parts of the plan are already implemented.
4. Name assumptions or conflicts that affect the requested milestone.
5. Propose a bounded change before editing.

This inspection happens in the coding tool or with your developer, where the source is available. PenguinKit's planning guidance should not be treated as a diagnosis of code it has not inspected.

For an existing project, make a recoverable checkpoint before changes. A Git commit or another suitable backup gives you a way to compare and restore work. Do not overwrite unrelated changes simply to make a new plan fit.

Request one complete, checkable milestone

“Build the entire app from these documents” leaves a large amount of work to interpret at once. A bounded milestone gives you a clearer result to examine.

For a fictional reading-list app, the first milestone might be:

Add a local page that accepts a book title, saves it using the agreed storage approach and lists it after a refresh. Require a non-empty title. Do not add accounts, sharing, recommendations or external book search yet.

The completion criteria should say what must happen, not only which files should exist. In this case, the item survives a refresh, blank input is rejected, and existing saved items remain intact.

Tool vendors also encourage providing verification criteria; Claude Code's verification guidance gives examples of checks and visual evidence. No instruction removes the need to examine what was actually run.

Use this handoff prompt

Read the project overview, scope, technical decisions and
working guidance before changing anything.

First inspect the existing workspace. Explain what already
works and any conflict that affects this milestone.

Implement only this milestone:
[one useful, bounded outcome]

Preserve:
[existing behaviour, data and unrelated changes]

Do not add:
[features outside this milestone]

Completion checks:
[expected result, important boundary and invalid input]

After implementation, report what changed, which checks
actually ran, their results, and anything still unverified.
Ask before a consequential change to an agreed requirement.

Adapt the language to a script, automation or app. An automation milestone might process a sample event without sending a real message. A script milestone might preview proposed file changes without modifying the originals.

Keep the decision record current

When a choice changes, update its authoritative document and explain why. Preserve explicit user requirements unless you deliberately revise them. Do not let a new recommendation silently replace an earlier decision.

Before starting the next task, have the builder read the updated context and the previous milestone's actual result. If a check failed, keep that evidence alongside the next action instead of recording the milestone as complete.

Planning modes in coding tools can also help discuss an approach before editing. Use them when they fit your workflow; a separate project foundation is most useful when you want an organised plan you can review and carry between implementation sessions.

Review evidence before expanding the project

Ask for test output, a relevant demonstration and a list of remaining limitations. A successful build does not prove that every user journey or permission works. Use the first-milestone testing guide to choose checks that matter.

PenguinKit provides a reviewable project foundation and supporting guidance for your builder. It does not deliver a finished application or independently verify the implementation produced by a coding tool.