# Project Bootstrapper

> Universal meta-skill that bootstraps ANY software project regardless of programming language. Auto-generates 15-30+ hyper-detailed, project-specific coding skills BEFORE writing code. Language-agnostic: works with TypeScript, Python, Go, Rust, Java, C#, Swift, Kotlin, PHP, Ruby, and polyglot projects. AGGRESSIVE version enforcement: EVERY technology version MUST be verified via real-time lookup — never use memorized versions. Generates skills for architecture, security, performance, privacy, testing, error handling, accessibility, observability, data modeling, API design, DevOps. Each skill enforces zero-bug standards with concrete code examples, anti-patterns, and measurable budgets. Triggers on: "bootstrap", "new project", "start project", "create project", "set up", "generate skills" — use BEFORE any code exists.

- Skill: `ersinkoc/project-bootstrapper` (Agent Skill, multi-file: 5 files)
- Install (CLI): `npx skillmds@latest add ersinkoc/project-bootstrapper`
- Raw SKILL.md: https://api.skillmd.com/api/skills/ersinkoc/project-bootstrapper/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Web & Frontend
- Author: ersinkoc (https://skillmd.com/u/ersinkoc)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/ersinkoc/project-bootstrapper

---


# Project Bootstrapper

> **Philosophy**: Define how code must be written before writing any code. Bugs are prevented at design time, not discovered at runtime.

This is a **meta-skill** — it does not write application code. It generates the **rules, patterns, guardrails, and quality standards** that govern all code written afterward, by any developer or AI assistant.

## How It Works

```
[Idea] → [Interview] → [Tech Stack] → [Skill Map] → [Generate Skills] → [Validate] → [Code]
```

## Activation

This skill activates when:
- User describes a new software project idea
- User says "bootstrap", "new project", "start from scratch", "set up project"
- User wants to generate a skill suite for an existing codebase
- User asks for coding standards, project scaffolding, or development guardrails
- Any context where skills should be created before development begins

## Important: Read References First

Before generating ANY skills, you MUST read these reference files in order:
1. `references/skill-catalog.md` — Full catalog of 40+ skill domains
2. `references/skill-template.md` — Universal template every skill must follow
3. `references/generation-guide.md` — Domain-specific generation instructions with code
4. `references/quality-standards.md` — Quality checklist for generated skills
5. `references/cross-cutting-concerns.md` — Rules that span all skills

---

## Phase 1: Project Intelligence Gathering

### 1.1 — Understand the Idea

Extract or ask about:

**What** (Product):
- What does this project do? (one sentence)
- What type is it? (web app, mobile app, desktop app, CLI, library/SDK, API service, browser extension, IoT, embedded, game, data pipeline, ML platform, monorepo with multiple products)
- Who is the end user? (developers, consumers, enterprise, internal team)
- What is the revenue model? (open-source, freemium, SaaS subscription, one-time purchase, marketplace, ad-supported, enterprise license)

**How Big** (Scale):
- Expected users at launch? At 12 months?
- Data volume? (records, files, events/sec, storage)
- Geographic scope? (single region, continental, global)
- Availability requirement? (99.9%, 99.95%, 99.99%)

**How** (Constraints):
- Required technologies? (must use React, must deploy on AWS, etc.)
- Existing codebase? (greenfield vs brownfield)
- Team size? (solo, small team 2-5, medium 5-15, large 15+)
- Timeline? (hackathon/weekend, MVP in weeks, production in months)
- Budget constraints? (free tier only, moderate, enterprise)
- Compliance requirements? (GDPR, HIPAA, SOC2, PCI-DSS, COPPA, CCPA)

**If the user already provided details**, extract answers from their message instead of asking. Only ask what's missing and genuinely needed to make tech stack decisions.

### 1.2 — Determine Tech Stack

Based on the answers, recommend a complete tech stack.

#### 🔍 MANDATORY: Version Research (Latest Stable) — ZERO TOLERANCE

**This is NON-NEGOTIABLE. Before proposing ANY technology, you MUST verify its latest stable version via real-time lookup.**

⚠️ **CRITICAL**: AI models have knowledge cutoffs. Package ecosystems evolve daily. A skill generated with outdated versions will produce vulnerable, deprecated code.

**Research Protocol** (execute for EVERY technology):
1. **Use available tools** (in priority order):
   - `WebSearch`: `"{package} latest stable version {current_year}"`
   - `WebFetch`: Official docs site (e.g., `nextjs.org`, `python.org`, `go.dev`)
   - Context7: `resolve-library-id` → `query-docs` for changelog
   - Package registry: npmjs.com, pypi.org, crates.io, pkg.go.dev, maven.apache.org

2. **Extract exact version**:
   - Format: `Major.Minor.Patch` (e.g., `Next.js 16.1.0`)
   - Verify it's STABLE (not alpha, beta, RC, canary, nightly)
   - Note release date — reject if >6 months old without updates

3. **Document verification**:
   ```
   Technology: Next.js
   Version: 16.1.0
   Verified via: nextjs.org/blog
   Verification date: 2026-03-09
   Release date: 2026-02-15
   Node requirement: >= 22.0.0
   ```

**HARDCORE RULES**:
- ✅ **MUST**: Verify EVERY dependency, not just frameworks
- ✅ **MUST**: Pin exact versions in all configs (`package.json`, `requirements.txt`, `Cargo.toml`, etc.)
- ✅ **MUST**: Use latest APIs/syntax from verified version in ALL code examples
- ❌ **NEVER**: Use memorized versions under ANY circumstance
- ❌ **NEVER**: Skip verification even for "well-known" packages
- ❌ **NEVER**: Use deprecated APIs from older versions
- ⚠️ **WARN**: If verification fails, mark clearly: `⚠️ VERSION UNVERIFIED — MUST CONFIRM`

**Abandonment Detection**:
- Last commit/release >12 months = investigate alternatives
- No maintainer response to issues >6 months = red flag
- Security advisories unpatched >30 days = DO NOT USE

**Example research queries**:
- `"next.js latest version"` → nextjs.org or npm
- `"postgresql latest stable release"` → postgresql.org
- `"tailwind css latest version"` → tailwindcss.com or npm
- Context7: resolve library ID → query docs for version/changelog

#### Tech Stack Decision Table

Organize as a layered decision table:

```
┌──────────────────────────────────────────────────────────────────────┐
│  TECH STACK PROPOSAL (versions verified: {date})                     │
├────────────────┬─────────────────────────────────┬───────────────────┤
│ Category       │ Choice                          │ Rationale         │
├────────────────┼─────────────────────────────────┼───────────────────┤
│ Language       │ {name} {verified latest version} │                   │
│ Runtime        │ {name} {verified latest version} │                   │
│ Framework      │ {name} {verified latest version} │                   │
│ Database       │ {name} {verified latest version} │                   │
│ ORM/Query      │ {name} {verified latest version} │                   │
│ Cache          │ {name} {verified latest version} │                   │
│ Auth           │ {name} {verified latest version} │                   │
│ UI Library     │ {name} {verified latest version} │                   │
│ CSS/Styling    │ {name} {verified latest version} │                   │
│ State Mgmt     │ {name} {verified latest version} │                   │
│ API Style      │ {name} {verified latest version} │                   │
│ Validation     │ {name} {verified latest version} │                   │
│ Testing        │ {name} {verified latest version} │                   │
│ CI/CD          │ {name} {verified latest version} │                   │
│ Hosting        │ {name}                           │                   │
│ Monitoring     │ {name} {verified latest version} │                   │
│ Email          │ {name} {verified latest version} │                   │
│ File Storage   │ {name}                           │                   │
│ Search         │ {name} {verified latest version} │                   │
│ Queue/Jobs     │ {name} {verified latest version} │                   │
│ Analytics      │ {name} {verified latest version} │                   │
└────────────────┴─────────────────────────────────┴───────────────────┘
```

Only include rows relevant to the project. Each choice gets a one-line rationale.

**Wait for user confirmation before proceeding.** The tech stack determines everything that follows.

#### Language-Agnostic Version Verification Matrix

For EVERY language, verify these tool versions:

```
┌─────────────────────────────────────────────────────────────────────────┐
│ LANGUAGE     │ CORE VERSION │ PACKAGE MANAGER │ LINTER     │ TESTER      │
├─────────────────────────────────────────────────────────────────────────┤
│ TypeScript   │ Latest Node  │ npm/pnpm 10+    │ ESLint 9+  │ Vitest 3+   │
│ Python       │ 3.12+        │ pip/uv          │ Ruff 0.9+  │ pytest 8+   │
│ Go           │ 1.24+        │ go modules      │ golangci   │ go test     │
│ Rust         │ Latest       │ cargo           │ clippy     │ cargo test  │
│ Java         │ 21 LTS       │ Maven/Gradle    │ checkstyle │ JUnit 5     │
│ Kotlin       │ 2.1+         │ Gradle          │ ktlint     │ Kotest      │
│ C#           │ .NET 9+      │ NuGet           │ analyzers  │ xUnit       │
│ Swift        │ 6.0+         │ SwiftPM         │ swiftlint  │ XCTest      │
│ PHP          │ 8.4+         │ Composer 2+     │ PHPStan 2+ │ PHPUnit 11+ │
│ Ruby         │ 3.4+         │ Bundler         │ RuboCop    │ RSpec       │
└─────────────────────────────────────────────────────────────────────────┘
```

**Polyglot Projects**: Generate separate `{language}-standards` skills for each language.

### 1.3 — Generate Skill Map

Based on confirmed tech stack, produce a skill map — the complete list of skills to generate. Read `references/skill-catalog.md` for the full domain catalog.

**Mandatory skills** (generated for every project):
1. `project-architecture` — folder structure, module boundaries, naming
2. `{language}-standards` — language-level coding rules
3. `security-hardening` — defense in depth, input/output, secrets, deps
4. `error-handling` — error hierarchy, propagation, recovery
5. `data-validation` — schema validation, sanitization, boundaries
6. `testing-strategy` — test types, coverage, mocking, fixtures
7. `performance-optimization` — budgets, profiling, caching, lazy loading
8. `git-workflow` — branches, commits, PRs, releases
9. `documentation-standards` — code docs, API docs, READMs, ADRs
10. `privacy-compliance` — PII handling, data lifecycle, consent, GDPR/CCPA
11. `dependency-management` — versioning, auditing, update policy, lockfiles

**Conditional skills** (generated when the project needs them):
- `{framework}-patterns` — framework-specific conventions
- `database-design` — schema, migrations, indexing, queries
- `api-design` — endpoints, versioning, pagination, rate limiting
- `ui-engineering` — components, styling, responsive, a11y
- `state-management` — client/server/URL/form state patterns
- `auth-patterns` — authn, authz, sessions, tokens, MFA
- `devops-pipeline` — CI/CD, environments, deployment, rollback
- `observability` — logging, metrics, tracing, alerting
- `accessibility-standards` — WCAG compliance, ARIA, keyboard nav
- `internationalization` — i18n, l10n, RTL, pluralization
- `payment-integration` — billing, subscriptions, webhooks, PCI
- `file-handling` — uploads, storage, processing, CDN
- `realtime-system` — WebSocket, SSE, pub/sub, presence
- `email-system` — transactional, templates, queue, compliance
- `search-implementation` — engine, indexing, relevance, autocomplete
- `background-jobs` — queues, scheduling, retry, dead letter
- `mobile-patterns` — navigation, offline, push, deep links
- `desktop-patterns` — window mgmt, tray, IPC, auto-update
- `cli-design` — commands, args, output, config, shell completion
- `monorepo-management` — workspaces, boundaries, versioning
- `ai-integration` — LLM calls, prompts, streaming, cost, safety
- `caching-strategy` — layers, invalidation, CDN, stale-while-revalidate
- `rate-limiting` — algorithms, tiers, headers, distributed limiting
- `feature-flags` — rollout, targeting, kill switches, cleanup
- `migration-strategy` — zero-downtime, data migrations, backward compat
- `container-orchestration` — Docker, K8s, health checks, resources
- `infrastructure-as-code` — Terraform/Pulumi, state, modules
- `event-driven-architecture` — event sourcing, CQRS, sagas
- `graphql-patterns` — schema design, resolvers, N+1, batching
- `websocket-patterns` — connection management, rooms, reconnection
- `microservice-patterns` — service boundaries, communication, discovery

Present the skill map organized by generation layer. **Wait for user confirmation.**

---

## Phase 2: Skill Generation Engine

### 2.1 — Generation Order (Dependency Layers)

Generate skills in strict dependency order — later skills can reference earlier ones:

```
Layer 0: project-architecture
         (defines folder structure, module boundaries, naming — everything else references this)

Layer 1: {language}-standards, git-workflow, documentation-standards
         (foundational coding and process standards)

Layer 2: security-hardening, error-handling, data-validation, privacy-compliance,
         dependency-management
         (cross-cutting safety and quality concerns)

Layer 3: database-design, api-design, auth-patterns, caching-strategy
         (data and communication layer)

Layer 4: {framework}-patterns, ui-engineering, state-management,
         accessibility-standards
         (presentation and interaction layer)

Layer 5: testing-strategy, performance-optimization
         (quality assurance — needs all other skills to exist first)

Layer 6: devops-pipeline, observability, container-orchestration,
         infrastructure-as-code
         (operations layer)

Layer 7: Domain-specific skills (payments, i18n, email, search, realtime,
         background-jobs, feature-flags, AI, etc.)
         (only relevant domains)
```

### 2.2 — Skill File Structure

Every generated skill MUST produce this file tree:

```
{skill-name}/
├── SKILL.md              # Main instructions (< 500 lines)
├── references/
│   ├── patterns.md       # Approved patterns with full code examples
│   ├── anti-patterns.md  # Forbidden patterns with severity + explanation
│   └── checklist.md      # Pre-commit/pre-merge verification checklist
└── templates/            # (optional) Code templates, configs
    └── *.template.*
```

### 2.3 — Content Requirements

Read `references/skill-template.md` for the exact skeleton. Read `references/generation-guide.md` for domain-specific content requirements.

Every generated skill MUST contain:

1. **YAML frontmatter** — name + aggressive description for reliable triggering
2. **Activation conditions** — exact triggers (file types, directories, user phrases)
3. **Project context** — references to actual project tech, paths, decisions
4. **Numbered core rules** (15-40 per skill) — each with rationale + code examples
5. **Approved patterns** — copy-pasteable code showing the right way
6. **Anti-patterns with severity** (🔴 CRITICAL / 🟠 HIGH / 🟡 MEDIUM / 🟢 LOW)
7. **Performance budgets** — concrete measurable numbers, not vague goals
8. **Security checklist** — domain-specific security verification items
9. **Error scenarios table** — what fails, how to detect, how to recover
10. **Edge cases** — documented with handling instructions
11. **Integration points** — how this skill connects to other generated skills
12. **Pre-commit checklist** — verification items before code can be committed

### 2.4 — Writing Principles

- **Explain the WHY**: Claude and developers are smart — reasoning > rigid commands
- **Concrete over abstract**: Real code examples > descriptions of code
- **Project-specific**: Reference actual tech choices, paths, and decisions — never generic
- **Opinionated**: Pick one best approach and enforce it, don't offer menus
- **Testable**: Every rule must be verifiable (lint rule, test, code review check)
- **Examples compile**: All code examples must work if copy-pasted, no pseudocode
- **Both sides**: Show correct AND incorrect for every critical rule

### 2.5 — Cross-Skill Consistency

After generating all skills, verify:
- [ ] No contradictions between skills
- [ ] Shared terminology is consistent across all skills
- [ ] Import paths reference actual project structure
- [ ] Tech versions match across all skills
- [ ] Error handling patterns are uniform
- [ ] Logging format is identical everywhere
- [ ] Validation approach is the same everywhere
- [ ] Security rules don't conflict

---

## Phase 3: Output

### 3.1 — Directory Layout

```
{project-root}/
├── .claude/
│   └── skills/
│       ├── project-architecture/
│       │   ├── SKILL.md
│       │   └── references/
│       ├── {language}-standards/
│       │   ├── SKILL.md
│       │   ├── references/
│       │   └── templates/
│       ├── security-hardening/
│       │   ├── SKILL.md
│       │   └── references/
│       ├── ... (all generated skills)
│       └── _bootstrap-manifest.json
├── .gitignore
└── ... (application code comes AFTER bootstrap)
```

### 3.2 — Bootstrap Manifest

Generate `_bootstrap-manifest.json`:

```json
{
  "project": "{name}",
  "bootstrapped_at": "{ISO-8601}",
  "tech_stack": {},
  "skills_generated": [
    {
      "name": "{skill-name}",
      "path": ".claude/skills/{skill-name}/",
      "layer": 0,
      "depends_on": [],
      "domains_covered": ["architecture", "folder-structure", "naming"]
    }
  ],
  "total_skills": 0,
  "total_rules": 0,
  "total_anti_patterns": 0,
  "coverage": {
    "security": true,
    "performance": true,
    "privacy": true,
    "testing": true,
    "accessibility": true,
    "error_handling": true,
    "documentation": true,
    "observability": true
  }
}
```

---

## Phase 4: Validation

Before declaring bootstrap complete, run validation using **both JavaScript and Python validators**:

### Validation Checklist

1. **Completeness** — Every tech stack component is covered by at least one skill
2. **Contradictions** — No two skills give conflicting advice
3. **Dependencies** — Every skill's `depends_on` targets exist
4. **Coverage** — Security, performance, privacy, testing, error handling all covered
5. **Specificity** — Skills reference actual project names, paths, versions
6. **Quality** — Run validators against the generated skills

### Running Validators

**JavaScript/Node.js (default):**
```bash
# Validate all skills
node scripts/validate_bootstrap.js .claude/skills/

# Check version consistency
node scripts/version_checker.js .claude/skills/

# Check compliance (if you have source code)
node scripts/check_skill_compliance.js src/
```

**Python (alternative):**
```bash
# Validate all skills
python scripts/validate_bootstrap.py .claude/skills/

# Check version consistency
python scripts/version_checker.py .claude/skills/

# Check compliance
python scripts/check_skill_compliance.py src/
```

### Validation Output

Present a summary table:

```
╔═══════════════════════════════════════════════════╗
║  BOOTSTRAP COMPLETE                               ║
╠═══════════════════════════════════════════════════╣
║  Project: {name}                                  ║
║  Skills Generated: {N}                            ║
║  Total Rules: {N}                                 ║
║  Total Anti-Patterns: {N}                         ║
║  Security Rules: {N}                              ║
║  Performance Budgets: {N}                         ║
║  Privacy Controls: {N}                            ║
║  Test Requirements: {N}                           ║
╠═══════════════════════════════════════════════════╣
║  ✅ No contradictions found                       ║
║  ✅ All dependencies resolved                     ║
║  ✅ Full coverage verified                        ║
║  ✅ Validators passed                             ║
║  ✅ Ready to code                                 ║
╚═══════════════════════════════════════════════════╝
```

---

## Phase 5: Continuous Compliance (project-manager skill)

**CRITICAL:** After bootstrap, the `project-manager` skill ensures ongoing compliance:

### What project-manager Does

- **Monitors** all code changes in real-time
- **Validates** every modification against active skills
- **Blocks** commits with skill violations
- **Reports** compliance metrics weekly
- **Guides** developers back to skill compliance
- **Detects** skill drift automatically

### Tools Available

**JavaScript:**
```bash
# Check code compliance
node scripts/check_skill_compliance.js src/

# Analyze skill coverage
node scripts/analyze_skill_coverage.js src/

# Generate weekly report
node scripts/generate_compliance_report.js --week
```

**Python:**
```bash
# Check code compliance
python scripts/check_skill_compliance.py src/

# Analyze skill coverage
python scripts/analyze_skill_coverage.py src/

# Generate weekly report
python scripts/generate_compliance_report.py --week
```

### Pre-Commit Hooks

Set up automated compliance checking:

```bash
# Install pre-commit hook
cp scripts/pre-commit.example .git/hooks/pre-commit
chmod +x .git/hooks/pre-commit
```

**Result:** Skills become **active guardrails**, not just documentation.

---

## Phase 6: Handoff

After bootstrap and validation:

1. **Confirm** all skills are generated in `.claude/skills/`
2. **Explain** the `project-manager` skill will monitor compliance
3. **Show** how to run validators (both JS and Python options)
4. **Demonstrate** compliance checking commands
5. **Transition** to actual development

Every file created or edited will be governed by the relevant skills automatically, enforced by the project-manager skill.

---

## Rules for This Skill

### Core Principles

- This skill generates OTHER skills — it never generates application code
- Generated skills must be project-specific, not generic boilerplate
- When in doubt, generate MORE skills rather than fewer
- If the user's project needs a domain not in the catalog, invent a new skill for it
- Follow the user's language preference (English by default)
- The tech stack is tech-agnostic: works for TypeScript, Python, Go, Rust, Java, C#, Swift, Kotlin, PHP, Ruby, or any combination
- For polyglot projects, generate per-language skills
- Read ALL reference files before generating ANY skills

### Validation Requirements

**ALWAYS run validators after generation:**

```bash
# Option 1: JavaScript/Node.js (recommended, no Python needed)
node scripts/validate_bootstrap.js .claude/skills/

# Option 2: Python (if available)
python scripts/validate_bootstrap.py .claude/skills/
```

**Validation must pass before declaring bootstrap complete.**

### Required Skills

**ALWAYS generate the `project-manager` skill** alongside other skills. It:
- Monitors compliance throughout development
- Validates code against skills in real-time
- Generates compliance reports
- Prevents skill drift

### Version Verification

**CRITICAL:** Every technology version MUST be verified via real-time lookup:
- Use `WebSearch`, `WebFetch`, or Context7
- Document verification source and date
- Never use memorized versions
- Verify ALL dependencies, not just frameworks

### Post-Generation Checklist

Before handoff:
- [ ] All skills generated in `.claude/skills/`
- [ ] `project-manager` skill included
- [ ] Validation passed (JS or Python)
- [ ] Version checker run
- [ ] `_bootstrap-manifest.json` created
- [ ] Compliance tools explained to user
- [ ] Pre-commit hooks mentioned

