BlueprintBeginner

From AI Blueprint Project ZIP to Code

Move from ZIP extraction and a Git baseline to staged, verified implementation with a coding agent.

4 min readReviewed Sep 4, 2026Free public access
Table of contents

An AI Blueprint Project ZIP is a handoff package for implementation with a coding agent. Its exact files vary by project and generator version. Treat the manifest, implementation guide, and files actually present as the source of truth.

Example contents of an AI Blueprint Project ZIP
Example contents of an AI Blueprint Project ZIP

Step 0: Extract the ZIP

Do not code inside the compressed archive. Extract it into a normal project folder, then open that folder in your IDE. Git, build tools, and coding agents need a real filesystem where changes can be diffed and committed.

Step 1: Protect Secrets

Inspect .env.local before Git or agent access. Remove production values that are not necessary, add environment files to .gitignore, and create .env.example with empty values when useful. Never paste secrets into chat, issues, screenshots, logs, or viewers.

gitignore
.env
.env.local
.env.*.local

Step 2: Create a Git Baseline

If the folder is not already a repository:

bash
git init
git add .
git commit -m "chore: import AI Blueprint handoff"

If it is already a repository, inspect git status and make a checkpoint commit. Do not reinitialize an existing repository.

Step 3: Read Sources of Truth

Read the manifest, implementation guide, repository instructions, PRD, database schema, docs, and staged prompts in the order specified by the package. Do not assume AGENT.md and AGENTS.md have identical auto-discovery behavior across tools.

Open .md files in FileMira Markdown Viewer when you want source and rendered views side by side. Inspect .json in the JSON Viewer, .csv in the CSV Editor, YAML in the YAML Viewer, and TOML in the TOML Viewer. FileMira says processing stays in the browser, but secret files still require local private handling.

Step 4: Choose One Agent and IDE

Use one primary coding agent in one working tree. Pair it with VS Code, Google Antigravity IDE, or another editor you can inspect confidently. Parallel agents can wait until you understand Git diff, commits, recovery, file ownership, and worktrees.

Step 5: Begin with Analysis Only

text
Read the manifest, implementation guide, PRD, schema, docs,
and repository instructions. Do not edit files.
Create PLAN.md with sources of truth, conflicts, implementation stages,
target areas, dependencies, security boundaries, acceptance criteria,
verification commands, and missing information.
Do not invent new product requirements.

Resolve document conflicts before coding. A later approved decision overrides an older draft only when the authority is clear; otherwise surface the conflict for human review.

Step 6: Scaffold from the Technical Foundation

If the ZIP contains documentation but no source code, create the project skeleton using the defined framework, runtime, database, auth, and package manager. Do not replace the stack because an agent prefers another tool. Run the initial project and commit the clean scaffold.

Step 7: Pass the Design Gate

Before generating many screens, collect two or three legal references, choose a direction, write DESIGN.md, and create ASSETS.md. Implement one vertical slice first. AI coding speeds up implementation but does not replace art direction, brand assets, accessibility, or human visual review.

Step 8: Run Staged Prompts One at a Time

If the ZIP contains PROMPT_1.md through PROMPT_N.md, do not paste them all into one session. Follow the manifest and repeat:

text
READ STAGE
-> PLAN
-> IMPLEMENT
-> LINT / TYPECHECK / TEST / BUILD
-> SCREENSHOT OR FUNCTIONAL VERIFICATION
-> REVIEW DIFF
-> HUMAN REVIEW
-> COMMIT
-> NEXT STAGE

Stop after each stage until its acceptance criteria pass.

Step 9: Verify Engineering, UI, and Data

Use the commands defined by the repository. Inspect git status and git diff. For UI, test desktop, mobile, loading, empty, error, validation, long content, keyboard focus, and basic accessibility. For database and auth, inspect migrations, server-side authorization, user isolation, client secret exposure, and destructive operations.

Step 10: Commit Small Milestones

Small commits make rollback, review, handoffs, and conflict resolution easier. If a usage window ends, commit only valid finished work and write HANDOFF.md with completed work, pending work, failing checks, touched files, and the exact next step. Do not restart the project.

Step 11: Use Worktrees Only When Needed

After the baseline is stable, separate truly independent tasks with one agent and one branch per worktree. Assign file ownership, merge one branch at a time, update the remaining branch, and rerun integration tests.

Step 12: Final Acceptance

  • In-scope PRD acceptance criteria are verified.
  • No hidden scope expansion occurred.
  • Relevant lint, typecheck, tests, and build pass.
  • Auth, authorization, migrations, and data isolation were reviewed.
  • Environment files and secrets are safe.
  • UI states, responsiveness, and accessibility basics are complete.
  • Asset placeholders are identified.
  • The final diff and preview deployment were reviewed.

Official sources and references

Use these sources to confirm current commands, capabilities, prices, and limits.

Was this guide helpful?

Tell us whether the steps worked or if something needs an update.