1️⃣ STOP - Don't create files yet
2️⃣ PLAN - Use "think hard" OR create planning document
3️⃣ ANNOUNCE - Tell user your file creation order
4️⃣ CREATE - Make files in optimal order (dependencies first)
5️⃣ VERIFY - Check all references work

User: "Create a portfolio with home, about, projects pages"

✓ Step 1: STOP [Don't immediately create index.html]
✓ Step 2: PLAN [Think: Need styles.css + 3 HTML files, CSS first]
✓ Step 3: ANNOUNCE ["I'll create: 1. styles.css, 2. index.html, 3. about.html, 4. projects.html"]
✓ Step 4: CREATE [Make them in that order]
✓ Step 5: VERIFY [Check all HTML files link to styles.css correctly]

Result: Done efficiently, no refactoring needed!

"Think hard about the architecture for this [project type]:
- What files are needed and what is their purpose?
- What are the shared dependencies (CSS, config, base classes)?
- What is the optimal creation order and why?
- What are the cross-file references?
- What could go wrong if we create files in the wrong order?"

"Think hard about the architecture for this [project]:
- What files are needed?
- What is the optimal creation order?
- What dependencies exist?"

Use bash_tool or create an artifact for the planning document:

ARCHITECTURE_PLAN.md:
- Files needed: [list]
- Creation order: [numbered list]
- Dependencies: [diagram/list]
- Potential issues: [list]

cat > ARCHITECTURE_PLAN.md << 'EOF'

**Benefit of planning document:** You can reference it throughout the project, and it serves as documentation.

---## 💰 WHY THIS MATTERS: Token Savings

**Without planning:**
- Create files → Realize structure is wrong → Refactor → More explanations
- **Cost: ~8,000 tokens** (redundant work + explanations + fixes)

**With planning (this skill):**
- Think first → Create files in optimal order → Done correctly first time
- **Cost: ~3,000 tokens** (efficient creation only)

**💡 Savings: ~5,000 tokens (62% reduction) per multi-file project**

Over a long session with multiple projects, this compounds significantly.

Without planning: ~6,000 tokens
  - Create HTML → Add inline styles → Extract CSS → Update refs
With planning: ~2,500 tokens
  - Plan → Create CSS → Create HTML with refs
💰 Savings: ~3,500 tokens (58%)

Without planning: ~12,000 tokens
  - Create pages → Realize shared components → Refactor → Fix imports
With planning: ~4,500 tokens
  - Plan → Create shared → Create pages → No refactoring
💰 Savings: ~7,500 tokens (63%)

Without planning: ~35,000 tokens
  - Create files randomly → Multiple refactoring cycles → Fix dependencies
With planning: ~12,000 tokens
  - Plan architecture → Create in optimal order → Minimal fixes
💰 Savings: ~23,000 tokens (66%)

1. Did you plan before creating files? [Yes/No]
   
2. How many files did you create? [Number]

3. Did you have to refactor or fix file references? [Yes/No]
   
4. If you planned first:
   - Estimated context used: ~[2,500-4,500] tokens for [3-8] files
   
5. If you created without planning:
   - You likely used: ~[6,000-12,000] tokens
   - Potential savings missed: ~[3,500-7,500] tokens

Files created: [N]
Did planning: [Yes/No]

If Yes:
  Tokens used: ~(N × 350) + 500 for planning
  Tokens saved: ~(N × 800)
  Efficiency: ~70%

If No:
  Tokens used: ~(N × 1,150) 
  Missed savings: ~(N × 800)
  Next time: Plan first!

☐ Step 1: THINK FIRST - Use "think hard" to plan architecture
         (List all files, determine optimal order, identify dependencies)
         
☐ Step 2: ANNOUNCE THE PLAN - Tell user the file creation order
         ("I'll create files in this order: 1. CSS, 2. index.html, 3...")
         
☐ Step 3: CREATE FOUNDATION FILES - Shared dependencies first
         (CSS files, config files, base classes)
         
☐ Step 4: CREATE DEPENDENT FILES - Files that use the foundations
         (HTML pages that reference CSS, components that use base classes)
         
☐ Step 5: VERIFY - Check all references/imports work

User: "Create a portfolio with home, about, and projects pages"
You: [Creates index.html]
You: [Creates about.html]
You: [Creates projects.html]
You: [Realizes CSS should be shared, has to refactor]
Result: Wasted effort, redundant work

User: "Create a portfolio with home, about, and projects pages"
You: "Think hard about the architecture first..."
     [Plans: Need 1 CSS file + 3 HTML files, CSS should come first]
You: "I'll create files in this order: 1. styles.css, 2. index.html, 3. about.html, 4. projects.html"
You: [Creates files in that order]
Result: Efficient, no redundant work

1. Create utils.js
2. Create helpers.js
3. Create api.js
4. Create app.js (main file that imports all the above)
Problem: Had to keep going back to app.js to add imports

1. Think about module structure
2. Create app.js (with import statements planned)
3. Create utils.js (knowing what app.js needs)
4. Create helpers.js (knowing what app.js needs)
5. Create api.js (knowing what app.js needs)
Benefit: App.js structured correctly from the start

1. Create index.html with inline styles
2. Create about.html with inline styles
3. Realize styles are duplicated
4. Extract to styles.css
5. Update all HTML files to reference it
Problem: Redundant work, had to edit multiple files

1. Think: These pages will share styling
2. Create styles.css first
3. Create HTML files that reference styles.css
Benefit: No duplication, no refactoring needed

1. Create UserProfile.jsx component
2. Create UserList.jsx component
3. Realize data structure is unclear
4. Go back and modify components to match data
Problem: Components built on assumptions

1. Think about data structure first
2. Create types.js or schema.js
3. Create components that use defined data structure
Benefit: Components built correctly from the start

1. Create home.html with full layout
2. Create about.html with full layout
3. Realize layout should be shared
4. Extract to layout component/template
5. Refactor all pages
Problem: Major refactoring required

1. Think: Pages will share layout
2. Create layout.html or Layout component
3. Create pages that use the layout
Benefit: DRY from the start

1. Create multiple files with hardcoded values
2. Realize config should be centralized
3. Create config.js
4. Update all files to use config
Problem: Config scattered, hard to change

1. Think: What values will be used across files?
2. Create config.js first
3. Create other files that import config
Benefit: Centralized configuration from start

Phase 1: "think about the architecture for this app"
[Review architecture plan]

Phase 2: "Create the database schema"
[Review schema]

Phase 3: "Build the authentication system"
[Continue phase by phase]

"Think hard about the architecture for this [project]:
- What files are needed and their purpose?
- What are shared dependencies?
- What is optimal creation order?
- What are cross-file references?
- What could go wrong?"

Create ARCHITECTURE_PLAN.md (via bash_tool or artifact):
- Files needed with purposes
- Shared dependencies
- Numbered creation order with reasoning
- Cross-file reference map
- Potential issues to avoid

ARCHITECTURE PLAN TEMPLATE:

□ FILES NEEDED:
  - [filename]: [purpose]
  - [filename]: [purpose]
  - [filename]: [purpose]

□ SHARED DEPENDENCIES (must be created first):
  - [dependency]: [what files need this]

□ CREATION ORDER (numbered with reasoning):
  1. [file] - Reason: [why this first]
  2. [file] - Reason: [why this second]
  3. [file] - Reason: [why this third]

□ CROSS-FILE REFERENCES:
  - [file A] references [file B] via [method]
  - [file C] imports [file D] via [method]

□ POTENTIAL ISSUES TO AVOID:
  - [what could go wrong]
  - [common mistake]

ARCHITECTURE PLAN:

□ FILES NEEDED:
  - styles.css: Shared styling for all pages
  - index.html: Home page with navigation
  - about.html: About page
  - projects.html: Portfolio showcase
  - contact.html: Contact form

□ SHARED DEPENDENCIES:
  - styles.css: All HTML files need this for consistent styling

□ CREATION ORDER:
  1. styles.css - Reason: Shared dependency, all HTML files will reference it
  2. index.html - Reason: Main entry point, establishes structure
  3. about.html - Reason: References styles.css which now exists
  4. projects.html - Reason: References styles.css which now exists
  5. contact.html - Reason: References styles.css which now exists

□ CROSS-FILE REFERENCES:
  - All HTML files link to styles.css via <link rel="stylesheet">
  - All HTML pages link to each other via <a href="...">

□ POTENTIAL ISSUES TO AVOID:
  - Creating HTML before CSS → Would require going back to add links
  - Inline styles in HTML → Would require extraction later
  - Inconsistent navigation → Hard to maintain across files

1. styles.css (shared styling)
2. index.html (home page - references styles.css)
3. about.html (references styles.css)
4. projects.html (references styles.css)
5. contact.html (references styles.css)
6. script.js (if needed)

1. package.json (dependencies)
2. App.js (main component)
3. components/Header.js (layout components)
4. components/Footer.js
5. pages/Home.js (page components)
6. pages/About.js
7. styles/main.css

1. config.js (configuration)
2. database.js (DB connection)
3. models/User.js (data models)
4. routes/auth.js (route handlers)
5. routes/api.js
6. server.js (entry point)

□ Check all file paths are correct
  - CSS links: <link href="styles.css"> (not "style.css" or "css/styles.css")
  - JS scripts: <script src="script.js"> 
  - Images: <img src="image.png">
  - Relative paths match actual file structure

□ Ensure CSS/JS references load properly
  - HTML files can find the CSS file
  - JavaScript imports resolve correctly
  - No 404 errors for missing files
  - Correct syntax in link/script tags

□ Test navigation between pages
  - All navigation links point to correct files
  - Links use correct relative paths
  - No broken navigation (links to non-existent pages)
  - Back/forward navigation works logically

□ Validate cross-file dependencies work
  - Components import correctly
  - Modules can access exported functions
  - Shared utilities are accessible
  - API calls reference correct endpoints

□ Check consistency across files
  - Naming conventions are consistent
  - Styling is uniform (if using shared CSS)
  - Code structure follows same patterns
  - Documentation style matches across files

After creating styles.css, index.html, about.html, projects.html, contact.html:

✓ Verification checklist:
  [✓] All HTML files have <link rel="stylesheet" href="styles.css">
  [✓] styles.css exists and has content
  [✓] Navigation links: 
      - index.html links to about.html, projects.html, contact.html ✓
      - All other pages link back to index.html ✓
  [✓] All pages use consistent styling from styles.css ✓
  [✓] No broken links or missing file references ✓

Result: Project structure verified, ready to use!

Main Session (Orchestrator)
├─ Stays high-level and focused
├─ Makes decisions based on summaries
└─ Delegates complex analysis

        ↓ delegates with thinking triggers ↓

Analysis Layer (Agents/Artifacts)
├─ Extended thinking happens HERE (5K+ tokens)
├─ Deep reasoning happens HERE
├─ Context-heavy work happens HERE
└─ Returns concise summaries UP (~200 tokens)

        ↑ returns actionable conclusions ↑

Main Session
└─ Receives well-reasoned recommendations
└─ Context stays clean for sustained work

undefined

**Usage:**

**Context saved:** ~4,800 tokens per analysis

User: "Analyze the best database for this use case"

Claude: "I'll create a deep analysis artifact where I can think 
through this thoroughly."

[Creates artifact: "database-analysis.md"]
[Inside artifact:
  - Extended thinking block (collapsed in UI)
  - Detailed analysis
  - Comparison tables
  - Final recommendation
]

Main conversation: "Based on the analysis artifact, I recommend 
PostgreSQL because [2-sentence summary]. See artifact for complete 
reasoning including performance comparisons and scaling considerations."

User: "What state management should I use?"
Claude: [5K tokens of thinking in main context]
Claude: [Another 2K tokens explaining recommendation]
Total: ~7K tokens consumed

User: "What state management should I use for a large e-commerce app?"

Claude Code:
"This warrants deep analysis. Let me delegate to a deep analyzer."
/agent architecture-advisor "Think deeply about state management 
options (Redux, Zustand, Jotai, Context) for large-scale e-commerce 
with real-time inventory"

[Subagent uses ultrathink in isolated context - 5K tokens]
[Returns summary - 200 tokens]

Main context: "The advisor recommends Zustand for these reasons..."
Total in main: ~300 tokens

Step 1: Research phase
"Search for [topic] and gather key information"

Step 2: Analysis phase  
"think hard about the best approach based on those findings"

Step 3: Implementation phase
"Now implement [specific task] using the approach we decided"

1. "Create a [file type] artifact with [functionality]"
2. Test/review the artifact
3. "Update the artifact to add [feature]"
4. Iterate within the artifact

1. "think about the plan for this project"
2. "Create a markdown artifact with the plan"
3. Reference the plan artifact as you work
4. Update the plan artifact as decisions change

1. "Research aspect A of [topic]"
2. "Create a summary artifact"
3. [New conversation or context reset]
4. "Research aspect B of [topic]" 
5. "Create a summary artifact"
6. "Synthesize findings from both research phases"

"I need to build a REST API. Let me break this into phases:

Phase 1: ultrathink about the API design and architecture
[Review thinking output]

Phase 2: Create an artifact with the OpenAPI specification
[Review spec]

Phase 3: Implement the authentication endpoints
[Continue implementation]

python scripts/generate_claude_md.py --type [TYPE] --output ./CLAUDE.md

python scripts/create_subagent.py [NAME] --type [TYPE]

✓ STEP 1: STOP AND THINK (DO THIS FIRST, ALWAYS)
   Output: "Think hard about the architecture for this [project]..."
   [Extended thinking plans: files needed, creation order, dependencies]

✓ STEP 2: ANNOUNCE THE PLAN
   Output: "I'll create these files in this order:
            1. styles.css (shared styling)
            2. index.html (home page)
            3. about.html
            4. projects.html
            5. contact.html"

✓ STEP 3: CREATE FOUNDATION FILES FIRST
   Create: styles.css
   
✓ STEP 4: CREATE DEPENDENT FILES
   Create: index.html (references styles.css)
   Create: about.html (references styles.css)
   Create: projects.html (references styles.css)
   Create: contact.html (references styles.css)

✓ STEP 5: VERIFY
   Check: All HTML files reference styles.css correctly

User: "Create a portfolio website with home, about, projects, and contact pages"

🛑 BEFORE YOU CREATE ANY FILES, YOU MUST OUTPUT:

"Let me think hard about the architecture first..."

[Extended thinking output should plan:
 - Files needed: index.html, about.html, projects.html, contact.html, styles.css
 - Optimal order: styles.css FIRST (it's a shared dependency), then HTML pages
 - Dependencies: All HTML files will reference styles.css
 - Structure: Simple multi-page site with shared stylesheet]

THEN announce the plan:

"I'll create the files in this order:

1. styles.css - Shared styling for all pages
2. index.html - Home page (will reference styles.css)
3. about.html - About page (will reference styles.css)
4. projects.html - Projects page (will reference styles.css)
5. contact.html - Contact page (will reference styles.css)

This order ensures all dependencies are in place before files that need them."

THEN create files in that exact order.

User: "Create a portfolio website with home, about, projects, and contact pages"

[Immediately creates index.html without thinking]
[Creates about.html]
[Creates projects.html]
[Realizes CSS should be shared, has to go back and add it]

This wastes effort and context!

User: "Create a portfolio website with home, about, projects, and contact pages"

"Think hard about architecture..." [Plans first]
"I'll create in this order: CSS first, then HTML pages" [Announces plan]
[Creates styles.css]
[Creates HTML pages that reference styles.css]

Efficient! No redundant work!

User: "Should we use microservices or monolith?"

1. /agent deep-analyzer "Ultrathink about architecture choice 
   for 10M user e-commerce platform, 8 dev team"
2. [Receives well-reasoned recommendation in main context]
3. Make decision based on analysis
4. Proceed with implementation

User: "Should we use microservices or monolith?"

1. "Create a deep-analysis.md artifact and ultrathink about this"
2. [Artifact contains extended thinking + conclusion]
3. Main conversation: "Based on analysis, recommend monolith because..."
4. Proceed with implementation

Phase 1: Architecture Analysis
Claude Code: /agent deep-analyzer "Think deeply about architecture for [feature]"
Web/API: "Create architecture-analysis artifact with deep thinking"
[Isolated thinking → summary to main]

Phase 2: Design Planning
"Based on that analysis, create implementation plan artifact"
[Main context references analysis conclusions]

Phase 3: Implementation
"Implement component A based on the plan"
[Create code artifact]

Phase 4: Testing
Claude Code: /agent test-runner "Run tests and analyze failures"
Web/API: "Run tests" [test output in separate space]

Phase 5: Integration
"Integrate based on architecture plan"

Phase 1: Deep Research
Claude Code: /agent pattern-researcher "Research and think hard about 
  authentication approaches, analyze tradeoffs"
Web/API: "Create research-findings artifact and think through options"

Phase 2: Synthesis
[Receives summary of findings]
"Create comparison table artifact"

Phase 3: Recommendation
Claude Code: /agent deep-analyzer "Based on research, recommend approach"
Web/API: "Based on research artifact, ultrathink and recommend"

Phase 4: Implementation
"Implement recommended approach"

1. "Create a [language] script that [functionality]"
   → Artifact created

2. "Add [feature] to the script"
   → Artifact updated

3. "Optimize the [specific part]"
   → Targeted update

4. "Add error handling"
   → Incremental improvement

1. /agent analyzer "Think hard about refactoring approach 
   for legacy auth system"
2. [Receives analysis in main: strategy, risks, order]
3. "Create REFACTOR.md plan based on analysis"
4. /clear
5. For each module:
   - Refactor according to plan
   - /agent test-runner "verify changes"
   - Commit
   - /clear before next

1. "Create refactoring-analysis artifact, think deeply about approach"
2. [Artifact has thinking + strategy]
3. "Create refactoring-plan artifact based on analysis"
4. Implement module by module
5. Reference plan artifact as you work

✅ /agent deep-analyzer "Ultrathink about [complex decision]"
❌ "Think about [complex decision]" [happens in main context]

✅ "Create analysis artifact and ultrathink about [decision]"
❌ "Ultrathink about [decision]" [thinking stays in conversation]

"think hard about the approach for [task]"

✅ "Create a Python script artifact that [functionality]"
❌ "Show me the Python code for [functionality]"

"Phase 1 complete. Moving to Phase 2: [description]"

Phase 1: /agent deep-analyzer "analyze approaches"
Phase 2: Implement based on analysis

"Create a decisions.md artifact tracking our key choices"

✅ "First, analyze the requirements"
    "Now, design the data model"
    "Now, implement the core logic"

❌ "Analyze requirements, design data model, and implement everything"

"ultrathink about multiple approaches and recommend the best one"

"Setting aside the previous approach, let's try a different angle..."

1. "Create initial version of [artifact]"
2. Review
3. "Improve [specific aspect]"
4. Review
5. "Add [feature]"
6. Continue iterating

1. "Create architecture.md artifact"
2. "Create database-schema.sql artifact"
3. "Create api-spec.yaml artifact"
4. "Now implement based on these artifacts"

1. "ultrathink about [complex problem]"
2. "Document the decision in a plan artifact"
3. "Execute phase 1 of the plan"
4. Reference plan artifact as you continue

1. "Create outline artifact"
2. "Write introduction (add to artifact)"
3. "Write section 1 (add to artifact)"
4. Continue section by section

python scripts/generate_claude_md.py --type [TYPE] --output ./CLAUDE.md

python scripts/create_subagent.py [NAME] --type [TYPE] --output [DIR]

/agent [NAME] [task description]

1. /clear (start fresh)
2. /agent deep-analyzer "Ultrathink about [complex decision]"
3. [Receives well-reasoned analysis in ~200 tokens]
4. Make decision and implement
5. Main context stayed clean throughout

1. /agent pattern-researcher "Research [topic] and think hard about implications"
2. [Subagent searches + thinks in isolation]
3. Review findings in main context
4. Proceed with informed decision

1. Write test in main context
2. /agent test-runner "Run test and think hard if it fails"
3. [Subagent analyzes root cause in isolation]
4. Implement fix based on analysis
5. /agent test-runner "verify"
6. If passing: commit and /clear

1. /agent analyzer "Think deeply about current architecture issues"
2. [Receives analysis: bottlenecks, technical debt, opportunities]
3. /agent deep-analyzer "Recommend evolution strategy"
4. Create EVOLUTION.md plan
5. /clear
6. Execute plan phase by phase

1. /agent analyzer "Think hard about refactoring scope and risks"
2. [Receives risk assessment + strategy]
3. Create REFACTOR.md plan
4. /clear
5. For each file:
   - Load and refactor
   - /agent test-runner "analyze test results"
   - /clear before next

python scripts/generate_claude_md.py --type TYPE --output PATH

python scripts/create_subagent.py NAME --type TYPE --output DIR