Greenfield Baseline

Greenfield Baseline

Overview

Start right, stay right. A greenfield project is a rare opportunity to establish excellent foundations without legacy constraints. This skill ensures new projects begin with proper baseline infrastructure: quality gates, repository structure, CI/CD pipeline, and development standards that prevent technical debt from day one.

REQUIRED: superpowers:verification-before-completion, superpowers:test-driven-development

Bootstrapping Skills Decision Matrix

Use this matrix to select the appropriate bootstrapping skill:

Skill Scope Comparison

Invocation Order for New Projects

1. greenfield-baseline         (establish project structure)
   ├── automated-standards-enforcement (quality tooling - auto-triggered)
   └── repo-best-practices-bootstrap   (security config - invoke after)
2. walking-skeleton-delivery   (E2E validation - invoke after baseline)

Do NOT Use This Skill When

• Project has existing code or structure (this is brownfield - use automated-standards-enforcement with brownfield strategy)
• Only need to add quality tooling (use automated-standards-enforcement directly)
• Only need security/compliance audit (use repo-best-practices-bootstrap directly)

When to Use

• Creating a brand new project or repository
• Starting from scratch with no existing codebase
• User mentions "new project", "greenfield", or "starting fresh"
• Team has opportunity to "do it right from the start"
• Setting up a new microservice in an existing ecosystem

Detection and Deference

Before creating new baseline structure, check for existing work:

# Check for existing project structure
ls *.sln *.csproj package.json pyproject.toml Cargo.toml go.mod 2>/dev/null

# Check for existing quality tooling
ls .editorconfig .prettierrc .eslintrc* ruff.toml .github/workflows/*.yml 2>/dev/null

# Check for existing documentation
ls README.md CONTRIBUTING.md docs/ 2>/dev/null

If existing structure found:

• This is NOT greenfield - use brownfield approach instead
• Apply automated-standards-enforcement with brownfield strategy
• Incrementally improve existing structure

If truly greenfield:

• Apply full baseline establishment
• Document architecture decisions in ADRs
• Set up quality gates from day one

Skill Interaction

This skill integrates with and triggers other skills:

Execution order: greenfield-baseline first, then walking-skeleton-delivery for E2E validation.

Core Workflow

1. Verify truly greenfield (no existing code/structure)
2. Define project scope and technology stack
3. Establish repository structure:
   • Source code directories (src/, tests/, docs/)
   • Configuration files (.editorconfig, .gitignore)
   • Documentation skeleton (README.md, CONTRIBUTING.md)
4. Set up quality gates:
   • Linting and formatting (language-appropriate)
   • Spelling checks (cspell or similar)
   • Pre-commit hooks
   • CI pipeline with quality checks
5. Establish development standards:
   • Coding conventions documented
   • Testing strategy defined
   • Branching strategy configured
6. Document architecture decisions (ADR for key choices)
7. Verify baseline works (run all quality checks)
8. Hand off to walking-skeleton for E2E validation

Baseline Checklist

A proper greenfield baseline includes:

Repository Structure

• Clear directory organisation (src/, tests/, docs/)
• .gitignore appropriate for technology stack
• .editorconfig for consistent formatting
• README.md with project overview and setup instructions
• CONTRIBUTING.md with contribution guidelines

Quality Gates

• Linting configured and passing
• Formatting configured and enforced
• Spelling check configured
• Pre-commit hooks installed
• CI pipeline running all checks
• Zero warnings policy established

Development Standards

• Coding conventions documented or referenced
• Testing strategy defined (unit, integration, E2E)
• Branching strategy documented
• Commit message conventions defined

Documentation

• Architecture Decision Records (ADRs) directory created
• Initial ADR documenting technology choices
• Getting started guide for new developers

Technology-Specific Templates

.NET Projects

# Solution structure
dotnet new sln -n ProjectName
dotnet new classlib -n ProjectName.Domain -o src/ProjectName.Domain
dotnet new classlib -n ProjectName.Application -o src/ProjectName.Application
dotnet new webapi -n ProjectName.Api -o src/ProjectName.Api
dotnet new xunit -n ProjectName.Tests -o tests/ProjectName.Tests

# Add projects to solution
dotnet sln add src/**/*.csproj tests/**/*.csproj

# Quality tooling
dotnet new editorconfig
dotnet new tool-manifest
dotnet tool install dotnet-format

Node.js Projects

# Initialize project
npm init -y

# Quality tooling
npm install --save-dev eslint prettier husky lint-staged cspell

# Initialize ESLint
npx eslint --init

# Set up pre-commit hooks
npx husky install
npx husky add .husky/pre-commit "npx lint-staged"

Python Projects

# Initialize with pyproject.toml
mkdir src tests docs

# Create pyproject.toml with ruff, pytest configuration
# Quality tooling
pip install ruff pytest pre-commit

# Set up pre-commit
pre-commit install

Red Flags - STOP

• "We'll add quality checks later"
• "MVP doesn't need this overhead"
• "Let's just get something working first"
• "Documentation can wait"
• "CI/CD is overkill for now"

All mean: Apply greenfield-baseline NOW. Technical debt starts at day one without proper foundation.

Anti-Patterns to Avoid

Verification Assertions

Before declaring baseline complete:

• All quality checks pass (npm run lint or equivalent)
• Pre-commit hooks work (test with a dummy commit)
• CI pipeline runs successfully
• README explains how to set up and run the project
• New developer can clone and run checks in under 5 minutes
• Zero warnings from all tooling

Completion Evidence

When baseline is established, provide:

## Greenfield Baseline Complete

**Repository structure:**

- [x] src/, tests/, docs/ directories created
- [x] .editorconfig configured
- [x] .gitignore appropriate for stack

**Quality gates:**

- [x] Linting: [tool name] configured
- [x] Formatting: [tool name] configured
- [x] Pre-commit hooks: installed and tested
- [x] CI pipeline: [link to workflow]

**Documentation:**

- [x] README.md with setup instructions
- [x] ADR-0001: Technology choices

**Verification:**

- All quality checks pass: [output/link]
- CI pipeline green: [link]

**Next step:** Apply walking-skeleton-delivery for E2E validation

Stack-Agnostic Baseline Path

For projects where technology stack is not yet decided:

Minimum Viable Baseline (Any Stack)

# 1. Repository essentials
mkdir -p src tests docs/adr
touch README.md CONTRIBUTING.md .gitignore .editorconfig

# 2. Basic .editorconfig (universal)
cat > .editorconfig << 'EOF'
root = true

[*]
indent_style = space
indent_size = 4
end_of_line = lf
charset = utf-8
trim_trailing_whitespace = true
insert_final_newline = true
EOF

# 3. Minimal .gitignore
cat > .gitignore << 'EOF'
# IDE
.idea/
.vscode/
*.swp

# Build outputs
/dist/
/build/
/out/

# Dependencies
node_modules/
.venv/
vendor/

# Environment
.env
.env.local
EOF

# 4. README template
cat > README.md << 'EOF'
# Project Name

## Overview
[Brief description]

## Getting Started
[Setup instructions - to be completed when stack is chosen]

## Development
[Development workflow - to be completed]

## License
[License information]
EOF

Stack Selection ADR Template

# ADR-0001: Technology Stack Selection

## Status

Proposed

## Context

Starting new project with requirements: [list requirements]

## Decision

We will use [stack] because:

- [Reason 1]
- [Reason 2]

## Consequences

- [Positive consequence]
- [Trade-off to manage]

Minimal Baseline for Prototypes

For rapid prototyping where full baseline is overhead:

Prototype Baseline (< 1 week projects)

Prototype Checklist

• README.md with project purpose
• .gitignore for IDE and build artifacts
• Single-command run capability
• One smoke test proving core functionality
• Time-boxed: Max 30 minutes on baseline

Promotion Path: Prototype → Production

When prototype proves valuable:

1. Apply full greenfield-baseline retroactively
2. Add quality gates before any additional features
3. Document learnings from prototype phase
4. Treat as brownfield from this point