mkdir ~/Documents/my-project-name
cd ~/Documents/my-project-name

git init

claude

PROMPT: Project Scaffold (Team Standard v8) - Part A: Structure, Core Files, and Rules
You are setting up a new project. Create the following structure and files. Do not ask questions -- just create everything listed below.

################################################################################################

1. Create the folder structure:

/docs/                          (all project documentation lives here)
/docs/idea/                     (Idea Pack goes here)
/docs/prd/                      (PRD and acceptance criteria go here)
/docs/adr/                      (Architecture Decision Records go here)
/docs/adr/template.md           (ADR template)
/docs/agents/                   (Agent specifications -- SEO, copywriter, etc.)
/src/                           (source code)
/tests/                         (test files)
/.claude/                       (Claude Code config)
/.claude/rules/                 (modular rules files)
/.claude/commands/               (custom slash commands)
/.claude/agents/                 (custom subagent and team definitions)
/.claude/hooks/                  (lifecycle hooks for agent teams)

################################################################################################

2. Create CLAUDE.md at the project root with this content:

# Project: [PROJECT_NAME]

## Overview
[To be filled during Idea Pack phase]

## Tech Stack
[To be filled during Architecture phase]

## Commands
- Dev server: [To be filled during Architecture phase]
- Run tests: [To be filled during Architecture phase]
- Build: [To be filled during Architecture phase]

## Current Phase
[Update as work progresses]

## Key Documents
- Idea Pack: /docs/idea/idea-pack.md
- PRD: /docs/prd/prd.md
- Acceptance checklist: /docs/prd/acceptance-checklist.md
- ADRs: /docs/adr/README.md
- Implementation plan: /docs/implementation-plan.md
- Interfaces: /docs/interfaces.md
- Agent coordination: AGENTS.md (read this before any team work)
- Design system: /docs/design-system/MASTER.md

## Rules
- Never commit secrets, API keys, or .env files
- Run tests after every code change
- One phase at a time -- never build the whole app in one go
- Use Context7 for any library/framework documentation lookups
- Track multi-step work in Beads
- Stay below 60% context utilisation -- /clear between phases
- Never work directly on main -- always use feature branches

## Agent Team Quick Reference
Teammates auto-load CLAUDE.md but do NOT inherit the lead's conversation history.
For full team coordination rules, file ownership, code standards, and patterns: read AGENTS.md.
For API contracts and integration points: read /docs/interfaces.md.

## Testing
- Framework: [To be decided in Architecture phase]
- Run command: [To be decided]
- Coverage target: 80%+

################################################################################################

3. Create AGENTS.md at the project root with this content:

# AGENTS.md -- Contract-First Team Coordination

This file is the single source of truth for how agents (solo, sub-agents, and teams) work on this project.
Every teammate reads this independently, so it must be explicit. No assumptions.

## Architecture Rules
[To be filled during Architecture phase. Examples:]
- All API routes use the handler pattern in /src/handlers/
- Database queries go through /src/db/queries/ -- never inline SQL
- Every public function has doc comments with params and returns
- All public-facing pages must be server-side rendered (SSR or SSG) for SEO
- Every public page must include meta tags, OpenGraph data, and JSON-LD structured data

## File Ownership (Critical for Teams)
Two teammates editing the same file creates merge conflicts that waste tokens.
Each teammate owns specific directories. Respect boundaries.

| Directory | Owner | Notes |
|-----------|-------|-------|
| /src/api/ | API teammate | REST endpoints, middleware |
| /src/db/ | Database teammate | Migrations, queries, models |
| /src/components/ | Frontend teammate | UI components, pages |
| /tests/ | Test teammate | All test files |
| /docs/agents/seo-specialist.md | SEO / Frontend teammate | Audit spec, meta tags, structured data |

[Update this table to match actual project structure]

## Code Standards
[To be filled during Architecture phase. Examples:]
- TypeScript strict mode, no `any` types
- Error handling: use Result<T, E> pattern or equivalent
- Imports: absolute paths via @/ alias

## SEO Standards (All Public Pages)
**[DELETE THIS ENTIRE SECTION if you skipped the optional SEO scaffold items during project kickoff.]**
- Single H1 per page, logical H2-H6 hierarchy
- Unique title tag (50-60 chars) and meta description (150-160 chars)
- OpenGraph and Twitter Card meta tags
- JSON-LD structured data appropriate to page type
- Images: descriptive alt text, WebP, lazy-loaded, explicit width/height
- No client-side-only content on crawlable pages
- Canonical URLs set, included in sitemap.xml
- Auth and admin pages must have noindex tags
- Run SEO audit agent before every deployment (see /docs/agents/seo-specialist.md)

## Team Coordination Rules
- Before modifying a shared file, message the file owner
- Integration points documented in /docs/interfaces.md
- All teammates run the test suite before reporting task complete
- Always clean up: lead calls TeamDelete when work is complete
- Orphaned teammate sessions keep running and burning tokens

## When to Use Teams vs Sub-Agents

**Use Sub-Agents when:**
- Focused task, no collaboration needed (single bug fix, translations, one-off generation)
- Workers just need to do work and report back
- No inter-worker communication required

**Use Agent Teams when:**
- Cross-layer coordination needed (API + DB + tests touching multiple areas)
- Teammates need to share discoveries and challenge each other
- Complex refactors across many files with conflict avoidance
- Research/debate where competing approaches should argue it out

Key question: Do workers need to talk to each other? If yes, Agent Teams. If not, sub-agents are faster and cheaper.

## Team Patterns

### Pattern 1: Feature Squad
Lead spawns 3 teammates:
- API Teammate: builds endpoints
- DB Teammate: creates migrations + queries
- Test Teammate: writes integration tests as API + DB work completes

Test teammate watches messages from the others and tests against the interfaces they define.

### Pattern 2: Research Debate
Lead spawns 2-3 teammates:
- Advocate A: argues for approach X with evidence
- Advocate B: argues for approach Y with evidence
- (Optional) Critic: tries to break both approaches

Use this for architectural decisions where there's no obvious right answer.

### Pattern 3: Parallel Processor
Lead spawns N workers, each owns a distinct file range.
No communication needed between workers -- lead distributes and collects.
Use for codebase-wide refactors or bulk file processing.

## Lead Mode Selection

**Plan Mode (default):** Lead plans AND participates in execution.
- Good for small teams (2-3 teammates)
- Good for quick prototyping where strict delegation adds overhead
- Risk: lead gets distracted by implementation instead of coordinating

**Delegate Mode (Shift+Tab):** Lead locked to coordination only. Cannot touch code.
- Good for larger teams (4+ teammates)
- Good for complex cross-layer refactors
- Good for production workflows needing clean planning/execution separation
- Start here for any team of 4+

################################################################################################

4. Create /.claude/rules/security.md:

---
description: Security rules for all code
---
- Never read, write, or commit .env files
- Never hardcode API keys, passwords, or secrets
- Always use environment variables for sensitive configuration
- Deny access to any file matching: .env, .env.*, secrets.*, credentials.*
- When running shell commands, always show the command and wait for approval

################################################################################################

5. Create /.claude/rules/testing.md:

---
description: Testing rules for all code
---
- Run the full test suite after every code change
- Write tests for every new function, component, or endpoint
- Minimum 80% code coverage target
- Test both happy path and error cases
- Never mark a phase as complete until all tests pass

################################################################################################

6. Create /.claude/rules/context-management.md:

---
description: Context window management rules
---
- Monitor context usage regularly with /context
- Never exceed 60% context utilisation before clearing
- Use /clear between build phases
- Use /compact with a focus instruction when context grows large
- When compacting, specify what to preserve: "compact, preserving [current phase] progress and test results"
- Break large tasks into phases -- never try to build everything at once

################################################################################################

7. Create /.claude/rules/git.md:

---
description: Git workflow rules
---
- Never commit directly to main
- Always work on a feature branch: feature/[description] or fix/[description]
- Commit after each successful build phase with a descriptive message
- Before committing, run the test suite
- Write commit messages that describe WHAT changed and WHY

################################################################################################

8. Create /.claude/rules/agent-teams.md:

---
description: Rules for agent team coordination
---
## When to use Agent Teams vs Solo/Sub-agents
Agent Teams use ~5x more tokens than a single session. Use this decision gate:
- The phase touches 3+ distinct feature areas (e.g. API + DB + frontend) AND
- The phase creates or modifies 8+ files AND
- Teammates need to build against shared interfaces or coordinate discoveries
If ANY of these conditions is false, use Solo or Sub-agents instead.
Track per-phase token cost: run /cost at phase start and end, record both in the Beads issue comment.

## Coordination rules
- Read AGENTS.md before starting any team work -- it is the coordination contract
- Respect file ownership boundaries -- never edit files outside your assigned scope
- Before modifying a shared file, message the file owner first
- All teammates must run the test suite before reporting a task complete
- The lead must call TeamDelete when work is complete -- orphaned sessions burn tokens
- Teammates do NOT inherit the lead's conversation history -- put all needed context in the spawn prompt
- Be explicit about scope: include file paths, constraints, and what "done" looks like in every spawn prompt
- Start with 2-3 teammates -- scale up only when coordination overhead is justified
- Use delegate mode (Shift+Tab) for teams of 4+ teammates
- For teams of 2-3 where the lead's direct contributions matter, plan mode is fine
- Each teammate is a separate Claude instance -- token usage scales with teammate count
- Never have two teammates editing the same file -- structure work so each owns different files
- If teammates must touch the same file, sequence the tasks with dependencies

################################################################################################

OPTIONAL: SEO SCAFFOLD
Include item 9 only if building a public-facing product where search engine
discoverability matters. Skip for internal tools, admin panels, APIs, or early MVPs.
This can be added later by re-running this item from the scaffold.

9. Create /.claude/rules/seo.md:

---
description: SEO rules for all public-facing pages
---
- Every public page must be server-side rendered (SSR or SSG) -- no client-only content on crawlable pages
- Every public page must have a unique <title> (50-60 chars) and <meta description> (150-160 chars)
- Single H1 per page, logical H2-H6 hierarchy, no skipped levels
- All images must have descriptive alt text, WebP format, lazy loading, and explicit width/height
- OpenGraph and Twitter Card meta tags on every public page
- JSON-LD structured data appropriate to page type (Article, HowTo, Product, Organization, FAQ)
- sitemap.xml auto-generated from published content, robots.txt blocks non-public routes
- Canonical URLs on every page -- no duplicate content
- Core Web Vitals targets: LCP < 2.5s, FID < 100ms, CLS < 0.1
- Lighthouse performance score > 90 on all public pages
- Run the SEO specialist agent audit before every deployment (see /docs/agents/seo-specialist.md)
- Auth, admin, and app pages must have noindex tags
- No render-blocking resources on public pages
- No orphan pages -- every public page must have at least one internal link pointing to it
- Breadcrumb markup (JSON-LD) for content with hierarchy

################################################################################################

After creating everything above, show me the full directory tree so I can verify
the structure before we continue with Part B.

PROMPT: Project Scaffold (Team Standard v8) - Part B: Templates, Config, and Commands
This is a continuation of the project scaffold. Part A has already been completed.
Read CLAUDE.md and verify the folder structure exists before proceeding.
Do not ask questions -- just create everything listed below.

################################################################################################

10. Create /docs/adr/template.md:

# ADR-[NUMBER]: [Title]

**Status:** Proposed | Accepted | Deprecated | Superseded
**Date:** YYYY-MM-DD
**Decision makers:** [names]

## Context
What is the issue or question that needs a decision?

## Decision
What is the decision that was made?

## Consequences
What are the positive, negative, and neutral consequences of this decision?

## Alternatives considered
What other options were evaluated and why were they rejected?

################################################################################################

11. Create /.claude/settings.json:

{
  "env": {
    "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
  },
  "permissions": {
    "deny": [
      "Read(.env*)",
      "Read(secrets.*)",
      "Read(credentials.*)",
      "Write(.env*)"
    ]
  }
}

################################################################################################

12. Create .gitignore:

node_modules/
.env
.env.*
.DS_Store
dist/
build/
coverage/
*.log
.claude/settings.local.json
.serena/

################################################################################################

13. Create .env.example at the project root:

# Environment variables for this project
# Copy this file to .env and fill in actual values
# NEVER commit .env -- only .env.example
DATABASE_URL=
API_KEY=
NODE_ENV=development

################################################################################################

14. Create /.claude/commands/create-adr.md:

---
description: Create a new Architecture Decision Record
allowed-tools: Write, Read
---
Create a new ADR in /docs/adr/ using the template in /docs/adr/template.md.
Number it sequentially based on existing ADRs.
Ask me for: the title, context, and the decision to record.

################################################################################################

15. Create /.claude/commands/spawn-team.md:

---
description: Spawn an agent team for the current task
allowed-tools: TeamCreate, TaskCreate, SendMessage, Read
---
Before spawning a team:
1. Read AGENTS.md to understand file ownership and coordination rules
2. Read CLAUDE.md for current project phase and architecture context
3. Determine the right team pattern (Feature Squad, Research Debate, or Parallel Processor)
4. Choose lead mode: delegate mode for 4+ teammates, plan mode for 2-3

When spawning teammates, include in each spawn prompt:
- Their specific role and file ownership scope
- The current project phase and relevant architecture context
- What "done" looks like for their tasks
- Any API contracts or interfaces they need to work against
- Instruction to read AGENTS.md and CLAUDE.md

After team completes work:
- Ensure all teammates have run the test suite
- Synthesize results
- Call TeamDelete to clean up -- do not leave orphaned sessions

################################################################################################

OPTIONAL: SEO SCAFFOLD
Include item 16 only if you included item 9 in Part A.

16. Create /.claude/commands/seo-audit.md:

---
description: Run an SEO audit on all public-facing pages
allowed-tools: Read, Bash, Write
---
Run the SEO specialist agent checklist against all public-facing pages.

1. Read /docs/agents/seo-specialist.md for the full audit checklist
2. Read /.claude/rules/seo.md for the project SEO rules
3. Identify all public-facing pages (landing page, ungated content, changelog, etc.)
4. For each page, audit against the checklist:
   - Meta tags (title, description, OG, Twitter)
   - Content structure (H1, heading hierarchy, alt text)
   - Technical SEO (SSR, page speed, Core Web Vitals, canonical URLs)
   - Structured data (JSON-LD schema, validation)
   - Indexing (robots.txt, sitemap.xml, noindex flags)
5. Output the report to /docs/seo-audit-[date].md

Report format per page:
- Critical issues (fix before deployment)
- Warnings (should fix)
- Passed checks
- Meta tag suggestions (title, description)

################################################################################################

After creating everything above, show me the full directory tree so I can verify
before we continue with Part C.

PROMPT: Project Scaffold (Team Standard v8) - Part C: Hooks, Agents, and Initialization
This is the final part of the project scaffold. Parts A and B have already been completed.
Read CLAUDE.md and verify the folder structure and config files exist before proceeding.
Do not ask questions -- just create everything listed below.

################################################################################################

17. Create /.claude/hooks/teammate-idle.sh:

#!/bin/bash
# Hook: TeammateIdle
# Runs when a teammate is about to go idle.
# Exit code 2 = send feedback and keep the teammate working.
# Exit code 0 = allow teammate to go idle.

# Default: allow idle. Customise per project.
exit 0

################################################################################################

18. Create /.claude/hooks/task-completed.sh:

#!/bin/bash
# Hook: TaskCompleted
# Runs when a task is being marked complete.
# Exit code 2 = prevent completion and send feedback.
# Exit code 0 = allow completion.

# Default: allow completion. Customise to enforce quality gates.
exit 0

################################################################################################

19. Create /.claude/hooks/stop-sync.sh:

#!/bin/bash
# Hook: Stop
# Runs after Claude finishes its final response in a turn.
# Syncs Beads so no work is lost if the session ends unexpectedly.

bd sync --quiet 2>/dev/null || true

################################################################################################

20. Create /.claude/hooks/context-warning.sh:

#!/bin/bash
# Hook: Notification
# Fires when Claude Code emits a notification (including context threshold warnings).
# Checks context usage and warns if approaching the 60% team ceiling.

MESSAGE="$1"

if echo "$MESSAGE" | grep -qi "context.*threshold\|context.*limit\|context.*capacity\|context.*warning"; then
  echo "⚠️  CONTEXT WARNING: You are approaching the 60% context ceiling."
  echo "Action required: Run /compact with a focus instruction, or /clear if between phases."
  echo "See Part 10: Context Management for the full protocol."
fi

################################################################################################

OPTIONAL: SEO SCAFFOLD
Include item 21 only if you included items 9 and 16 in Parts A and B.

21. Create /docs/agents/seo-specialist.md:

---
name: SEO Specialist
role: Search engine optimization, meta tags, structured data, and organic discoverability
when_to_invoke: New pages, landing page changes, before launches, content updates, or periodic SEO audits
output_style: SEO audit report with issues, severity, and specific fixes
---

# SEO Specialist Agent

## Purpose

Ensure all public-facing pages are optimized for search engine discovery and ranking. Focus on technical SEO, on-page optimization, and content discoverability.

## Responsibilities

- Audit pages for SEO compliance
- Ensure proper meta tags (title, description, og:*, twitter:*)
- Verify structured data (JSON-LD schema markup)
- Check heading hierarchy (single H1, logical H2-H6 structure)
- Validate image optimization (alt text, file sizes, lazy loading)
- Ensure mobile-friendliness and Core Web Vitals alignment
- Check canonical URLs and avoid duplicate content
- Verify sitemap.xml and robots.txt configuration
- Monitor page indexability

## SEO Audit Checklist

For every public page, verify:

### Meta Tags

- [ ] Unique, descriptive `<title>` (50-60 characters)
- [ ] Compelling `<meta name="description">` (150-160 characters)
- [ ] `og:title`, `og:description`, `og:image` for social sharing
- [ ] `twitter:card`, `twitter:title`, `twitter:description`
- [ ] Canonical URL set correctly
- [ ] Language attribute on `<html>`

### Content Structure

- [ ] Single `<h1>` per page (matches topic)
- [ ] Logical heading hierarchy (H1 > H2 > H3, no skips)
- [ ] Descriptive anchor text for internal links
- [ ] Keywords naturally integrated (no stuffing)
- [ ] Content length appropriate for intent

### Technical SEO

- [ ] Page loads in < 3 seconds
- [ ] Mobile-responsive design
- [ ] No broken links (internal or external)
- [ ] Images have descriptive `alt` attributes
- [ ] Images are optimized (WebP, compressed, lazy-loaded)
- [ ] No render-blocking resources
- [ ] HTTPS enforced

### Structured Data

- [ ] JSON-LD schema for page type (Organization, Product, FAQ, HowTo, Article)
- [ ] Schema validates in Google Rich Results Test
- [ ] Breadcrumbs markup if applicable

### Indexing

- [ ] Page is not blocked by robots.txt
- [ ] No errant `noindex` tags
- [ ] Included in sitemap.xml
- [ ] Internal linking from other pages

## Page-Specific Requirements

### Landing Page (/)

- Schema: `Organization` + `Product`
- Focus keywords: [Fill from Idea Pack keyword strategy]
- Must have: value proposition in H1, trust signals, clear CTA
- og:image: compelling social preview

### Public Content Pages (ungated)

- Schema: `Article` + `HowTo`
- Focus keywords: [Fill from Idea Pack keyword strategy]
- Must have: comprehensive content, internal links to gated teasers

### Gated Content Pages

- Schema: `Article`
- Teaser content (title, intro, headings) must be crawlable
- Full content behind auth -- not indexed
- Each page links to next/previous in sequence

### Auth Pages (/auth/*)

- Should be `noindex` (no SEO value)
- Canonical to main site

### Admin Pages (/admin/*)

- Should be `noindex` (private content)
- No structured data needed

### Changelog / What's New

- Schema: `Article`
- Fully indexed -- provides fresh content signals
- Internal links to updated content

## Output Format

When auditing a page:

    SEO Audit: [Page Name]
    URL: /path

    Critical Issues (fix immediately)
    - Issue description > Fix: specific action

    Warnings (should fix)
    - Issue description > Fix: specific action

    Passed Checks
    - Check that passed

    Recommendations
    - Opportunity for improvement

    Meta Tag Suggestions
    Title: "Suggested title here"
    Description: "Suggested description here"

## Integration with Other Agents

- **Copywriter**: Collaborate on meta descriptions, titles, heading copy
- **Designer**: Coordinate on image optimization, page structure
- **Implementer**: Technical fixes (schema markup, meta tags in framework)
- **Optimizer**: Align on Core Web Vitals, page speed

## Framework-Specific Patterns

### Metadata API (App Router -- Next.js example)

    // In page.tsx or layout.tsx
    export const metadata: Metadata = {
      title: 'Page Title | Brand',
      description: 'Compelling description under 160 chars',
      openGraph: {
        title: 'Page Title',
        description: 'Description for social',
        images: ['/og-image.png'],
      },
      twitter: {
        card: 'summary_large_image',
        title: 'Page Title',
        description: 'Description for Twitter',
      },
    };

### JSON-LD Schema

    // In page.tsx
    export default function Page() {
      const jsonLd = {
        '@context': 'https://schema.org',
        '@type': 'Article',
        name: 'Article Title',
        description: '...',
      };

      return (
        <>
          <script
            type="application/ld+json"
            dangerouslySetInnerHTML={{ __html: JSON.stringify(jsonLd) }}
          />
          {/* Page content */}
        </>
      );
    }

## Tools for Verification

- Google Search Console (indexing, coverage)
- Google Rich Results Test (structured data)
- PageSpeed Insights (Core Web Vitals)
- Lighthouse (comprehensive audit)
- Screaming Frog (crawl analysis)

## Anti-Patterns

- Keyword stuffing in titles or content
- Duplicate meta descriptions across pages
- Missing alt text on decorative images (use `alt=""` for decorative)
- Blocking CSS/JS in robots.txt
- Orphan pages with no internal links
- Thin content pages (< 300 words for main pages)
- Multiple H1 tags per page
- Client-side-only rendering of content that needs indexing

## When to Invoke

- After creating any new public page
- Before launching landing page changes
- When content is updated or published
- Monthly audit of all public pages
- After any metadata or schema changes
- When adding new images to public pages
- Before every deployment to production

################################################################################################

22. Create /.claude/agents/security-auditor.md:

---
name: Security Auditor
role: Security vulnerability detection and remediation
when_to_invoke: After each build phase, before deployments, and during code review
output_style: Ranked findings with file references and specific fixes
---

# Security Auditor Agent

## Purpose

Audit all source code for security vulnerabilities, misconfigurations, and unsafe patterns.

## Setup

Before running, read:
- /.claude/rules/security.md for project security rules
- The non-functional requirements section of /docs/prd/prd.md
- AGENTS.md for code standards

## Audit Scope

Scan all source code in /src/ for issues including but not limited to:

- Hardcoded secrets, API keys, or passwords
- Unvalidated or unsanitised user inputs
- SQL injection, XSS, and CSRF vulnerabilities
- Missing authentication/authorisation checks
- Error messages leaking internal details (stack traces, DB schemas, file paths)
- Insecure dependencies or outdated packages with known CVEs
- Improper session handling or token storage
- Missing rate limiting on public endpoints
- Overly permissive CORS configuration
- Sensitive data in logs

## Output Format

Rank all findings by severity: Critical, High, Medium, Low.

For each finding:

### [SEVERITY]: [Short title]
**File:** [path:line]
**Issue:** [description]
**Fix:** [recommended remediation]

################################################################################################

23. Create /.claude/agents/infrastructure-auditor.md:

---
name: Infrastructure Auditor
role: Infrastructure, configuration, and operational readiness review
when_to_invoke: After each build phase, before deployments, and during code review
output_style: Ranked findings with file references and specific fixes
---

# Infrastructure Auditor Agent

## Purpose

Audit the project for infrastructure, configuration, and operational readiness issues.

## Setup

Before running, read:
- The ADRs in /docs/adr/ for hosting and deployment decisions
- The non-functional requirements section of /docs/prd/prd.md

## Audit Scope

Check the full project for issues including but not limited to:

- Missing or incomplete environment variable documentation
- No .env.example file or equivalent
- Missing health check endpoints
- No graceful shutdown handling
- Missing or misconfigured build/bundler settings
- Dependency versions unpinned or wildcard
- No Docker/deployment config (if applicable per ADRs)
- Missing CI/CD pipeline config
- No database migration strategy or rollback plan
- Performance issues: N+1 queries, missing indexes, unbounded queries
- Missing caching where appropriate
- No logging/monitoring setup

## Output Format

Rank all findings by severity: Critical, High, Medium, Low.

For each finding:

### [SEVERITY]: [Short title]
**File:** [path:line]
**Issue:** [description]
**Fix:** [recommended remediation]

################################################################################################

24. Initialise Beads for this project:

Run: bd init

25. Make all hook scripts executable:

Run: chmod +x .claude/hooks/*.sh

################################################################################################

After creating everything above, show me the full directory tree including all files
created across Parts A, B, and C so I can do a final verification of the complete scaffold.

Create a .mcp.json file at the project root that documents which MCP servers this project uses. 

Content: 
  { 
    "mcpServers": 
    { 
      "context7": 
      { 
        "type": "http", "url": "https://mcp.context7.com/mcp" 
      } 
    }
}

This ensures anyone cloning this project knows which MCP servers are expected.

⚠️ IMPORTANT: MCP server configuration MUST go in `.mcp.json` at the project root. Do NOT put MCP server definitions in `.claude/settings.json` — they will be silently ignored. `.claude/settings.json` is for permissions, environment variables, and hooks only. If an MCP server is not connecting, the first thing to check is whether it was accidentally added to the wrong file.

claude mcp add serena -- uvx --from git+https://github.com/oraios/serena \ serena start-mcp-server --context claude-code --project "$(pwd)"

Please update the .mcp.json to include provisions for Serena MCP

{
  "mcpServers": {
    "context7": {
      "type": "http",
      "url": "https://mcp.context7.com/mcp"
    },
    "serena": {
      "command": "uvx",
      "args": [
        "--from", "git+https://github.com/oraios/serena",
        "serena", "start-mcp-server",
        "--context", "claude-code",
        "--project", "."
      ]
    }
  }
}

Please include the following directory in .gitignore: .serena/

sudo npm install -g uipro-cli

then...

cd ~/Documents/my-project-name
uipro init --ai claude

Create a feature branch called "setup/initial-scaffold", stage all files, and commit with message: "chore: initial project scaffold with Claude Code config, rules, and documentation structure"