Greenfield Init

Transform a vague project idea or PRD into a structured, phase-gated project blueprint.

When to Use

• User describes a new application they want to build
• User provides a PRD or feature spec for a new project
• User says "build me...", "I want to create...", or similar greenfield language
• A project needs structured planning before any code is written

Input Requirements

One of:

1. Vague prompt — A description of what the user wants to build
2. PRD file — Path to a product requirements document

Behavior

1. Read the Guides

Read and internalize (located in this skill folder):

• DEFAULT_STACK.md — Standard tech stack and packages
• VERSIONS.md — Canonical versions for all technologies
• BLUEPRINT_GUIDE.md — Blueprint document structure and template
• CONTRACT_GUIDE.md — API interface contract format

Also read the relevant skill:

• environments skill — environment setup specs for each stack layer (Python/uv, Node/npm, Docker)

2. Parse Input & Gap Analysis

Read the user's prompt or PRD and extract:

• Stated requirements — What's explicitly described
• Implied requirements — What the description assumes (auth, persistence, etc.)
• Missing requirements — What's not addressed but needed

Categorize gaps as:

• Blocking — Cannot plan without this (core user flows, data entities)
• Assumable — Can use sensible defaults (stack, auth method, deployment)

3. Fill Gaps

For blocking gaps, use the AskQuestion tool to get targeted answers. Group related questions together. Focus on:

• Who are the users? Are there roles/permissions?
• What are the 3-5 core user flows?
• What are the main data entities and their relationships?
• Any third-party integrations?
• Real-time requirements?
• Scale expectations (small team tool vs. public SaaS)?

For assumable gaps, apply defaults from DEFAULT_STACK.md and state assumptions explicitly in the blueprint.

4. Define the Stack

Start with DEFAULT_STACK.md as the baseline. Adjust only if the project requirements demand it (e.g., real-time heavy → add django-channels + WebSocket support).

Present the stack to the user for confirmation. If they have no opinion, use the defaults.

5. Define Development Phases

Break the project into sequential phases. Each phase must have:

Standard phase pattern (adjust per project):

1. Project scaffolding — Both projects created, dependencies installed, dev servers running
2. Data layer — Models, migrations, admin, seed data
3. Auth — Registration, login, permissions
4. Core features — The 2-3 main features, usually parallelizable by stream
5. Integration — Connect frontend to backend using the API contract
6. Polish & edge cases — Error handling, loading states, validation

6. Map Parallelism

For any phase where frontend and backend can proceed independently:

1. Identify the API surface that connects them
2. Produce an API contract following CONTRACT_GUIDE.md
3. Both streams build against the contract
4. Integration phase verifies contract compliance

7. Output

Create the project folder structure and produce artifacts:

.agent-tasks/tasks/[YYYYMMDD-project-name]/
├── research/
│   ├── PROJECT_BLUEPRINT.md    # The full plan
│   └── API_CONTRACT.md         # Interface contract (if parallel streams)
├── pending/
├── in-progress/
├── complete/
├── testing/
└── agent-transcripts/

Follow the blueprint structure defined in BLUEPRINT_GUIDE.md.

8. Hand Off

After producing the blueprint, instruct the user:

Blueprint complete. Next step: use the greenfield-decomposer skill to break Phase 1 into executable tasks.

Use the greenfield-decomposer skill for .agent-tasks/tasks/[YYYYMMDD-project-name]/, starting with Phase 1.

Quality Checklist

Before finalizing the blueprint:

• All blocking gaps are resolved (asked user or documented assumption)
• Stack is confirmed or defaults applied with assumptions stated
• Every phase has a validation gate
• Phases are ordered by dependency
• Parallel streams have an API contract
• Blueprint follows BLUEPRINT_GUIDE.md format
• No more than 5-7 phases for an MVP