菜单
Generate or regenerate the master architecture document (specs/MASTER_BLUEPRINT.md) — the single source of truth for tech stack, data model, API patterns, auth, UI conventions, and module relationships. Use when starting architecture, changing stack decisions, or after significant research that affects the technical approach.
Implement a fully-specced module via dual-harness execution — Claude orchestrates, Codex CLI executes inside a live tmux pane in your attached session. Use when ready to write code for a module that has approved SPEC.md and CLAUDE.md files. Triggers on phrases like 'execute the X module via codex', 'dual-harness build', or '/project-execute X'.
Initialise a new software project with full spec-first workflow — research, architecture, module specs, and roadmap. Use this whenever someone says 'build me a...', 'I want to create...', 'new project', 'start a project', or describes a product idea. Also use for major new feature areas within an existing project.
Implement a module that already has an approved spec — reads all specs, enters plan mode, then builds incrementally with tests and commits. Use when ready to write code for a specific module, or when someone says 'build the X module', 'implement X', or 'start coding X'. The module MUST have a spec before implementation begins.
Conduct deep, structured research on any domain, technology, competitor, regulation, or technical topic for this project. Use whenever the team needs to understand something before making architectural or product decisions — market landscapes, compliance requirements, API capabilities, framework comparisons, or user workflows.
End-of-session review — captures what was done, learnings, mistakes, and patterns, then updates LEARNINGS.md and CLAUDE.md. Run this after completing any task, at the end of a working session, or when switching to a different area of the project. This is what makes the system compound and get smarter over time.
| name | project-blueprint |
| description | Generate or regenerate the master architecture document (specs/MASTER_BLUEPRINT.md) — the single source of truth for tech stack, data model, API patterns, auth, UI conventions, and module relationships. Use when starting architecture, changing stack decisions, or after significant research that affects the technical approach. |
| effort | high |
This skill creates or updates the Master Architecture Blueprint, the foundational architecture document for your project. Use it when:
The skill reads existing project context, verifies technology versions, finds production examples, and generates a comprehensive blueprint.
Before generating the blueprint, gather existing project context:
Read existing specs:
specs/PROJECT_BRIEF.md (if exists) — project vision and constraintsspecs/RESEARCH.md (if exists) — technology recommendationsspecs/MODULES.md (if exists) — module decompositionCLAUDE.md (if exists) — project coding patternsIdentify decision blockers:
Determine research needs:
If the technology stack is not yet defined, answer these 4 core questions to guide choices:
Options to Research:
React
ref_search_documentationVue
ref_search_documentationSvelte
ref_search_documentationSolid or Astro (for content-heavy sites)
web_search_exaDecision Criteria:
JavaScript/Node.js Options:
ref_search_documentationweb_search_exaref_search_documentationPython Options:
ref_search_documentationref_search_documentationOther Runtimes:
web_search_exaweb_search_exaDecision Criteria:
Relational (SQL):
ref_search_documentationDocument (NoSQL):
ref_search_documentationGraph:
ref_search_documentationVector (for AI/ML):
web_search_exaCache/Sessions:
ref_search_documentationDecision Criteria:
Serverless/Edge:
ref_search_documentationContainer-Based:
Traditional Servers:
Decision Criteria:
Once stack options are identified or decided, verify current versions and best practices:
Find Official Documentation:
ref_search_documentation with query: "{{framework}} official documentation"Verify Production Patterns:
get_code_context_exa with query: "{{framework}} {{pattern}} production example"Check Version Compatibility:
Document Rationale:
Collect the following before filling the blueprint:
From Project Brief:
From Research:
From Stack Detection:
From Tech Verification:
Use the template at ../project-init/blueprint-template.md.
Fill each section systematically:
Define the core entities that represent your domain:
Example: E-commerce
interface User {
id: string;
email: string;
passwordHash: string;
role: "customer" | "admin";
createdAt: Date;
updatedAt: Date;
}
interface Product {
id: string;
name: string;
description: string;
price: number;
inventory: number;
categoryId: string;
createdAt: Date;
updatedAt: Date;
}
interface Order {
id: string;
userId: string;
items: OrderItem[];
status: "pending" | "processing" | "shipped" | "delivered";
totalPrice: number;
createdAt: Date;
updatedAt: Date;
}
Create a 1-page summary covering:
Key Technology Decisions:
Architectural Highlights:
Known Constraints & Trade-offs:
Open Questions Requiring Decision:
Before finalizing, confirm:
Once approved:
specs/MASTER_BLUEPRINT.mdWhen to Use: Startup MVP, single team, simple domain
Frontend (React) → Backend (Next.js) → Database (PostgreSQL)
↓
Cache (Redis)
When to Use: Web apps with tight frontend-backend coupling
Next.js (frontend + backend) → Postgres + Redis
↓
Vercel (deploy)
When to Use: Scale, multiple teams, independent deployments
Frontend (React) → API Gateway → Service 1 (Node.js) → DB1
→ Service 2 (Python) → DB2
→ Service 3 (Go) → DB3
When to Use: Long-running jobs, background processing
Frontend → Backend API → Queue (Redis/Bull) → Workers
↓
Database
Choose the pattern that matches your scale, team size, and complexity.
If circumstances change during development:
Always maintain the blueprint as current source of truth.
../project-init/blueprint-template.mddocs/examples/ref_search_documentation to find official guidesget_code_context_exa for real-world implementationsAfter blueprint approval:
../project-init/module-spec-template.md