diff --git a/get-shit-done/templates/codebase/architecture.md b/get-shit-done/templates/codebase/architecture.md
new file mode 100644
index 000000000..184409170
--- /dev/null
+++ b/get-shit-done/templates/codebase/architecture.md
@@ -0,0 +1,249 @@
+# Architecture Template
+
+Template for `.planning/codebase/ARCHITECTURE.md` - captures conceptual code organization.
+
+**Purpose:** Document how the code is organized at a conceptual level. Complements STRUCTURE.md (which shows physical file locations).
+
+---
+
+## File Template
+
+```markdown
+# Architecture
+
+**Analysis Date:** [YYYY-MM-DD]
+
+## Pattern Overview
+
+**Overall:** [Pattern name: e.g., "Monolithic CLI", "Serverless API", "Full-stack MVC"]
+
+**Key Characteristics:**
+- [Characteristic 1: e.g., "Single executable"]
+- [Characteristic 2: e.g., "Stateless request handling"]
+- [Characteristic 3: e.g., "Event-driven"]
+
+## Layers
+
+[Describe the conceptual layers and their responsibilities]
+
+**[Layer Name]:**
+- Purpose: [What this layer does]
+- Contains: [Types of code: e.g., "route handlers", "business logic"]
+- Depends on: [What it uses: e.g., "data layer only"]
+- Used by: [What uses it: e.g., "API routes"]
+
+**[Layer Name]:**
+- Purpose: [What this layer does]
+- Contains: [Types of code]
+- Depends on: [What it uses]
+- Used by: [What uses it]
+
+## Data Flow
+
+[Describe the typical request/execution lifecycle]
+
+**[Flow Name] (e.g., "HTTP Request", "CLI Command", "Event Processing"):**
+
+1. [Entry point: e.g., "User runs command"]
+2. [Processing step: e.g., "Router matches path"]
+3. [Processing step: e.g., "Controller validates input"]
+4. [Processing step: e.g., "Service executes logic"]
+5. [Output: e.g., "Response returned"]
+
+**State Management:**
+- [How state is handled: e.g., "Stateless - no persistent state", "Database per request", "In-memory cache"]
+
+## Key Abstractions
+
+[Core concepts/patterns used throughout the codebase]
+
+**[Abstraction Name]:**
+- Purpose: [What it represents]
+- Examples: [e.g., "UserService, ProjectService"]
+- Pattern: [e.g., "Singleton", "Factory", "Repository"]
+
+**[Abstraction Name]:**
+- Purpose: [What it represents]
+- Examples: [Concrete examples]
+- Pattern: [Pattern used]
+
+## Entry Points
+
+[Where execution begins]
+
+**[Entry Point]:**
+- Location: [Brief: e.g., "src/index.ts", "API Gateway triggers"]
+- Triggers: [What invokes it: e.g., "CLI invocation", "HTTP request"]
+- Responsibilities: [What it does: e.g., "Parse args, route to command"]
+
+## Error Handling
+
+**Strategy:** [How errors are handled: e.g., "Exception bubbling to top-level handler", "Per-route error middleware"]
+
+**Patterns:**
+- [Pattern: e.g., "try/catch at controller level"]
+- [Pattern: e.g., "Error codes returned to user"]
+
+## Cross-Cutting Concerns
+
+[Aspects that affect multiple layers]
+
+**Logging:**
+- [Approach: e.g., "Winston logger, injected per-request"]
+
+**Validation:**
+- [Approach: e.g., "Zod schemas at API boundary"]
+
+**Authentication:**
+- [Approach: e.g., "JWT middleware on protected routes"]
+
+---
+
+*Architecture analysis: [date]*
+*Update when major patterns change*
+```
+
+<good_examples>
+```markdown
+# Architecture
+
+**Analysis Date:** 2025-01-20
+
+## Pattern Overview
+
+**Overall:** CLI Application with Plugin System
+
+**Key Characteristics:**
+- Single executable with subcommands
+- Plugin-based extensibility
+- File-based state (no database)
+- Synchronous execution model
+
+## Layers
+
+**Command Layer:**
+- Purpose: Parse user input and route to appropriate handler
+- Contains: Command definitions, argument parsing, help text
+- Depends on: Service layer for business logic
+- Used by: CLI entry point (src/index.ts)
+
+**Service Layer:**
+- Purpose: Core business logic
+- Contains: FileService, TemplateService, InstallService
+- Depends on: File system utilities, external tools
+- Used by: Command handlers
+
+**Utility Layer:**
+- Purpose: Shared helpers and abstractions
+- Contains: File I/O wrappers, path resolution, string formatting
+- Depends on: Node.js built-ins only
+- Used by: Service layer
+
+## Data Flow
+
+**CLI Command Execution:**
+
+1. User runs: `gsd new-project`
+2. Commander parses args and flags
+3. Command handler invoked (commands/new-project.ts)
+4. Handler calls service methods (e.g., ProjectService.create())
+5. Service reads templates, processes files, writes output
+6. Results logged to console
+7. Process exits with status code
+
+**State Management:**
+- File-based: All state lives in `.planning/` directory
+- No persistent in-memory state
+- Each command execution is independent
+
+## Key Abstractions
+
+**Service:**
+- Purpose: Encapsulate business logic for a domain
+- Examples: FileService, TemplateService, ProjectService
+- Pattern: Singleton-like (imported as modules, not instantiated)
+
+**Command:**
+- Purpose: CLI command definition
+- Examples: new-project, plan-phase, execute-plan
+- Pattern: Commander.js command registration
+
+**Template:**
+- Purpose: Reusable document structures
+- Examples: PROJECT.md, PLAN.md templates
+- Pattern: Markdown files with substitution variables
+
+## Entry Points
+
+**CLI Entry:**
+- Location: src/index.ts
+- Triggers: User runs `gsd <command>`
+- Responsibilities: Register commands, parse args, display help
+
+**Commands:**
+- Location: src/commands/*.ts
+- Triggers: Matched command from CLI
+- Responsibilities: Validate input, call services, format output
+
+## Error Handling
+
+**Strategy:** Throw exceptions, catch at command level, log and exit
+
+**Patterns:**
+- Services throw Error with descriptive messages
+- Command handlers catch, log error to stderr, exit(1)
+- Validation errors shown before execution (fail fast)
+
+## Cross-Cutting Concerns
+
+**Logging:**
+- Console.log for normal output
+- Console.error for errors
+- Chalk for colored output
+
+**Validation:**
+- Zod schemas for config file parsing
+- Manual validation in command handlers
+- Fail fast on invalid input
+
+**File Operations:**
+- FileService abstraction over fs-extra
+- All paths validated before operations
+- Atomic writes (temp file + rename)
+
+---
+
+*Architecture analysis: 2025-01-20*
+*Update when major patterns change*
+```
+</good_examples>
+
+<guidelines>
+**What belongs in ARCHITECTURE.md:**
+- Overall architectural pattern (monolith, microservices, layered, etc.)
+- Conceptual layers and their relationships
+- Data flow / request lifecycle
+- Key abstractions and patterns
+- Entry points
+- Error handling strategy
+- Cross-cutting concerns (logging, auth, validation)
+
+**What does NOT belong here:**
+- Specific file paths (that's STRUCTURE.md)
+- Technology choices (that's STACK.md)
+- Line-by-line code walkthrough (defer to code reading)
+- Implementation details of specific features
+
+**When filling this template:**
+- Read main entry points (index, server, main)
+- Identify layers by reading imports/dependencies
+- Trace a typical request/command execution
+- Note recurring patterns (services, controllers, repositories)
+- Keep descriptions conceptual, not mechanical
+
+**Useful for phase planning when:**
+- Adding new features (where does it fit in the layers?)
+- Refactoring (understanding current patterns)
+- Identifying where to add code (which layer handles X?)
+- Understanding dependencies between components
+</guidelines>
diff --git a/get-shit-done/templates/codebase/stack.md b/get-shit-done/templates/codebase/stack.md
new file mode 100644
index 000000000..a686cbb1e
--- /dev/null
+++ b/get-shit-done/templates/codebase/stack.md
@@ -0,0 +1,187 @@
+# Technology Stack Template
+
+Template for `.planning/codebase/STACK.md` - captures the technology foundation.
+
+**Purpose:** Document what technologies run this codebase. Focused on "what executes when you run the code."
+
+---
+
+## File Template
+
+```markdown
+# Technology Stack
+
+**Analysis Date:** [YYYY-MM-DD]
+
+## Languages
+
+**Primary:**
+- [Language] [Version] - [Where used: e.g., "all application code"]
+
+**Secondary:**
+- [Language] [Version] - [Where used: e.g., "build scripts, tooling"]
+
+## Runtime
+
+**Environment:**
+- [Runtime] [Version] - [e.g., "Node.js 20.x"]
+- [Additional requirements if any]
+
+**Package Manager:**
+- [Manager] [Version] - [e.g., "npm 10.x"]
+- Lockfile: [e.g., "package-lock.json present"]
+
+## Frameworks
+
+**Core:**
+- [Framework] [Version] - [Purpose: e.g., "web server", "UI framework"]
+
+**Testing:**
+- [Framework] [Version] - [e.g., "Jest for unit tests"]
+- [Framework] [Version] - [e.g., "Playwright for E2E"]
+
+**Build/Dev:**
+- [Tool] [Version] - [e.g., "Vite for bundling"]
+- [Tool] [Version] - [e.g., "TypeScript compiler"]
+
+## Key Dependencies
+
+[Only include dependencies critical to understanding the stack - limit to 5-10 most important]
+
+**Critical:**
+- [Package] [Version] - [Why it matters: e.g., "authentication", "database access"]
+- [Package] [Version] - [Why it matters]
+
+**Infrastructure:**
+- [Package] [Version] - [e.g., "Express for HTTP routing"]
+- [Package] [Version] - [e.g., "PostgreSQL client"]
+
+## Configuration
+
+**Environment:**
+- [How configured: e.g., ".env files", "environment variables"]
+- [Key configs: e.g., "DATABASE_URL, API_KEY required"]
+
+**Build:**
+- [Build config files: e.g., "vite.config.ts, tsconfig.json"]
+
+## Platform Requirements
+
+**Development:**
+- [OS requirements or "any platform"]
+- [Additional tooling: e.g., "Docker for local DB"]
+
+**Production:**
+- [Deployment target: e.g., "Vercel", "AWS Lambda", "Docker container"]
+- [Version requirements]
+
+---
+
+*Stack analysis: [date]*
+*Update after major dependency changes*
+```
+
+<good_examples>
+```markdown
+# Technology Stack
+
+**Analysis Date:** 2025-01-20
+
+## Languages
+
+**Primary:**
+- TypeScript 5.3 - All application code
+
+**Secondary:**
+- JavaScript - Build scripts, config files
+
+## Runtime
+
+**Environment:**
+- Node.js 20.x (LTS)
+- No browser runtime (CLI tool only)
+
+**Package Manager:**
+- npm 10.x
+- Lockfile: package-lock.json present
+
+## Frameworks
+
+**Core:**
+- None (vanilla Node.js CLI)
+
+**Testing:**
+- Vitest 1.0 - Unit tests
+- tsx - TypeScript execution without build step
+
+**Build/Dev:**
+- TypeScript 5.3 - Compilation to JavaScript
+- esbuild - Used by Vitest for fast transforms
+
+## Key Dependencies
+
+**Critical:**
+- commander 11.x - CLI argument parsing and command structure
+- chalk 5.x - Terminal output styling
+- fs-extra 11.x - Extended file system operations
+
+**Infrastructure:**
+- Node.js built-ins - fs, path, child_process for file operations
+
+## Configuration
+
+**Environment:**
+- No environment variables required
+- Configuration via CLI flags only
+
+**Build:**
+- tsconfig.json - TypeScript compiler options
+- vitest.config.ts - Test runner configuration
+
+## Platform Requirements
+
+**Development:**
+- macOS/Linux/Windows (any platform with Node.js)
+- No external dependencies
+
+**Production:**
+- Distributed as npm package
+- Installed globally via npm install -g
+- Runs on user's Node.js installation
+
+---
+
+*Stack analysis: 2025-01-20*
+*Update after major dependency changes*
+```
+</good_examples>
+
+<guidelines>
+**What belongs in STACK.md:**
+- Languages and versions
+- Runtime requirements (Node, Bun, Deno, browser)
+- Package manager and lockfile
+- Framework choices
+- Critical dependencies (limit to 5-10 most important)
+- Build tooling
+- Platform/deployment requirements
+
+**What does NOT belong here:**
+- File structure (that's STRUCTURE.md)
+- Architectural patterns (that's ARCHITECTURE.md)
+- Every dependency in package.json (only critical ones)
+- Implementation details (defer to code)
+
+**When filling this template:**
+- Check package.json for dependencies
+- Note runtime version from .nvmrc or package.json engines
+- Include only dependencies that affect understanding (not every utility)
+- Specify versions only when version matters (breaking changes, compatibility)
+- Keep under ~100 lines total
+
+**Useful for phase planning when:**
+- Adding new dependencies (check compatibility)
+- Upgrading frameworks (know what's in use)
+- Choosing implementation approach (must work with existing stack)
+- Understanding build requirements
+</guidelines>
diff --git a/get-shit-done/templates/codebase/structure.md b/get-shit-done/templates/codebase/structure.md
new file mode 100644
index 000000000..33e3e22ff
--- /dev/null
+++ b/get-shit-done/templates/codebase/structure.md
@@ -0,0 +1,285 @@
+# Structure Template
+
+Template for `.planning/codebase/STRUCTURE.md` - captures physical file organization.
+
+**Purpose:** Document where things physically live in the codebase. Answers "where do I put X?"
+
+---
+
+## File Template
+
+```markdown
+# Codebase Structure
+
+**Analysis Date:** [YYYY-MM-DD]
+
+## Directory Layout
+
+[ASCII tree of top-level directories with purpose]
+
+```
+[project-root]/
+├── [dir]/          # [Purpose]
+├── [dir]/          # [Purpose]
+├── [dir]/          # [Purpose]
+└── [file]          # [Purpose]
+```
+
+## Directory Purposes
+
+**[Directory Name]:**
+- Purpose: [What lives here]
+- Contains: [Types of files: e.g., "*.ts source files", "component directories"]
+- Key files: [Important files in this directory]
+- Subdirectories: [If nested, describe structure]
+
+**[Directory Name]:**
+- Purpose: [What lives here]
+- Contains: [Types of files]
+- Key files: [Important files]
+- Subdirectories: [Structure]
+
+## Key File Locations
+
+**Entry Points:**
+- [Path]: [Purpose: e.g., "CLI entry point"]
+- [Path]: [Purpose: e.g., "Server startup"]
+
+**Configuration:**
+- [Path]: [Purpose: e.g., "TypeScript config"]
+- [Path]: [Purpose: e.g., "Build configuration"]
+- [Path]: [Purpose: e.g., "Environment variables"]
+
+**Core Logic:**
+- [Path]: [Purpose: e.g., "Business services"]
+- [Path]: [Purpose: e.g., "Database models"]
+- [Path]: [Purpose: e.g., "API routes"]
+
+**Testing:**
+- [Path]: [Purpose: e.g., "Unit tests"]
+- [Path]: [Purpose: e.g., "Test fixtures"]
+
+**Documentation:**
+- [Path]: [Purpose: e.g., "User-facing docs"]
+- [Path]: [Purpose: e.g., "Developer guide"]
+
+## Naming Conventions
+
+**Files:**
+- [Pattern]: [Example: e.g., "kebab-case.ts for modules"]
+- [Pattern]: [Example: e.g., "PascalCase.tsx for React components"]
+- [Pattern]: [Example: e.g., "*.test.ts for test files"]
+
+**Directories:**
+- [Pattern]: [Example: e.g., "kebab-case for feature directories"]
+- [Pattern]: [Example: e.g., "plural names for collections"]
+
+**Special Patterns:**
+- [Pattern]: [Example: e.g., "index.ts for directory exports"]
+- [Pattern]: [Example: e.g., "__tests__ for test directories"]
+
+## Where to Add New Code
+
+**New Feature:**
+- Primary code: [Directory path]
+- Tests: [Directory path]
+- Config if needed: [Directory path]
+
+**New Component/Module:**
+- Implementation: [Directory path]
+- Types: [Directory path]
+- Tests: [Directory path]
+
+**New Route/Command:**
+- Definition: [Directory path]
+- Handler: [Directory path]
+- Tests: [Directory path]
+
+**Utilities:**
+- Shared helpers: [Directory path]
+- Type definitions: [Directory path]
+
+## Special Directories
+
+[Any directories with special meaning or generation]
+
+**[Directory]:**
+- Purpose: [e.g., "Generated code", "Build output"]
+- Source: [e.g., "Auto-generated by X", "Build artifacts"]
+- Committed: [Yes/No - in .gitignore?]
+
+---
+
+*Structure analysis: [date]*
+*Update when directory structure changes*
+```
+
+<good_examples>
+```markdown
+# Codebase Structure
+
+**Analysis Date:** 2025-01-20
+
+## Directory Layout
+
+```
+get-shit-done/
+├── bin/                # Executable entry points
+├── commands/           # Slash command definitions
+│   └── gsd/           # GSD-specific commands
+├── get-shit-done/     # Skill resources
+│   ├── references/    # Principle documents
+│   ├── templates/     # File templates
+│   └── workflows/     # Multi-step procedures
+├── src/               # Source code (if applicable)
+├── tests/             # Test files
+├── package.json       # Project manifest
+└── README.md          # User documentation
+```
+
+## Directory Purposes
+
+**bin/**
+- Purpose: CLI entry points
+- Contains: install.js (installer script)
+- Key files: install.js - handles npx installation
+- Subdirectories: None
+
+**commands/gsd/**
+- Purpose: Slash command definitions for Claude Code
+- Contains: *.md files (one per command)
+- Key files: new-project.md, plan-phase.md, execute-plan.md
+- Subdirectories: None (flat structure)
+
+**get-shit-done/references/**
+- Purpose: Core philosophy and guidance documents
+- Contains: principles.md, questioning.md, plan-format.md
+- Key files: principles.md - system philosophy
+- Subdirectories: None
+
+**get-shit-done/templates/**
+- Purpose: Document templates for .planning/ files
+- Contains: Template definitions with frontmatter
+- Key files: project.md, roadmap.md, plan.md, summary.md
+- Subdirectories: codebase/ (new - for stack/architecture/structure templates)
+
+**get-shit-done/workflows/**
+- Purpose: Reusable multi-step procedures
+- Contains: Workflow definitions called by commands
+- Key files: execute-phase.md, research-phase.md
+- Subdirectories: None
+
+## Key File Locations
+
+**Entry Points:**
+- bin/install.js: Installation script (npx entry)
+
+**Configuration:**
+- package.json: Project metadata, dependencies, bin entry
+- .gitignore: Excluded files
+
+**Core Logic:**
+- bin/install.js: All installation logic (file copying, path replacement)
+
+**Testing:**
+- tests/: Test files (if present)
+
+**Documentation:**
+- README.md: User-facing installation and usage guide
+- CLAUDE.md: Instructions for Claude Code when working in this repo
+
+## Naming Conventions
+
+**Files:**
+- kebab-case.md: Markdown documents
+- kebab-case.js: JavaScript source files
+- UPPERCASE.md: Important project files (README, CLAUDE, CHANGELOG)
+
+**Directories:**
+- kebab-case: All directories
+- Plural for collections: templates/, commands/, workflows/
+
+**Special Patterns:**
+- {command-name}.md: Slash command definition
+- *-template.md: Could be used but templates/ directory preferred
+
+## Where to Add New Code
+
+**New Slash Command:**
+- Primary code: commands/gsd/{command-name}.md
+- Tests: tests/commands/{command-name}.test.js (if testing implemented)
+- Documentation: Update README.md with new command
+
+**New Template:**
+- Implementation: get-shit-done/templates/{name}.md
+- Documentation: Template is self-documenting (includes guidelines)
+
+**New Workflow:**
+- Implementation: get-shit-done/workflows/{name}.md
+- Usage: Reference from command with @~/.claude/get-shit-done/workflows/{name}.md
+
+**New Reference Document:**
+- Implementation: get-shit-done/references/{name}.md
+- Usage: Reference from commands/workflows as needed
+
+**Utilities:**
+- No utilities yet (install.js is monolithic)
+- If extracted: src/utils/
+
+## Special Directories
+
+**get-shit-done/**
+- Purpose: Resources installed to ~/.claude/
+- Source: Copied by bin/install.js during installation
+- Committed: Yes (source of truth)
+
+**commands/**
+- Purpose: Slash commands installed to ~/.claude/commands/
+- Source: Copied by bin/install.js during installation
+- Committed: Yes (source of truth)
+
+---
+
+*Structure analysis: 2025-01-20*
+*Update when directory structure changes*
+```
+</good_examples>
+
+<guidelines>
+**What belongs in STRUCTURE.md:**
+- Directory layout (ASCII tree)
+- Purpose of each directory
+- Key file locations (entry points, configs, core logic)
+- Naming conventions
+- Where to add new code (by type)
+- Special/generated directories
+
+**What does NOT belong here:**
+- Conceptual architecture (that's ARCHITECTURE.md)
+- Technology stack (that's STACK.md)
+- Code implementation details (defer to code reading)
+- Every single file (focus on directories and key files)
+
+**When filling this template:**
+- Use `tree -L 2` or similar to visualize structure
+- Identify top-level directories and their purposes
+- Note naming patterns by observing existing files
+- Locate entry points, configs, and main logic areas
+- Keep directory tree concise (max 2-3 levels)
+
+**ASCII tree format:**
+```
+root/
+├── dir1/           # Purpose
+│   ├── subdir/    # Purpose
+│   └── file.ts    # Purpose
+├── dir2/          # Purpose
+└── file.ts        # Purpose
+```
+
+**Useful for phase planning when:**
+- Adding new features (where should files go?)
+- Understanding project organization
+- Finding where specific logic lives
+- Following existing conventions
+</guidelines>