A template for LLM-assisted software development with structured planning, implementation, and review workflow.
Important
This is how my process evolved over time to plan and write code wiith CC.
What this does:
Defines processes for starting and maintaining a new product.
Uses what works for me in CC
Hopefully, helps people get started a little quicker.
What this does not:
Revolutionize anything. (Why does everyone "revolutionize". Let's be real, here.)
Implement known best practices. (Do those exist?)
Prevent you from defining your own processes or modifying these ones.
People ask how to get started and this is a resource for them. That's it. I highly encourage everyone to learn by doing. Trial and error in unavoidable.
Using CCLSP
CCLSP makes finding and reading code faster and more token efficient. It is mentioned throughout this repo. I highly recommend installing it. If you don't want to install it, then ask Claude to remove instructions on using it.
Quick Start
Copy this template to your project
Run /get-started to configure your project interactively
Start designing with /arch-design
The /get-started skill walks you through:
Defining your project identity
Choosing your core principles
Setting up initial capabilities
Configuring invariants
Or customize manually - see CUSTOMIZATION.md for detailed guidance.
Workflow
/get-started ā Configure project (run once)
/arch-design ā Design interfaces, create architecture docs
/create-sprint ā Plan implementation phases
/eval-sprint ā Evaluate sprint spec before implementation
/implement-sprint ā Execute the plan
/review-sprint ā QA and verify
/verify-sprint ā Final verification of sprint deliverables
/audit-docs ā Keep documentation accurate
Directory Structure
project/
āāā CLAUDE.md # Principles, invariants, navigation
āāā docs/
ā āāā CAPABILITIES.md # What the system does (status tracking)
ā āāā SCRATCHPAD.md # Temporary context used during or between sessions.
ā āāā architecture/
ā ā āāā README.md # Index, reading order
ā ā āāā PROCESS.md # Development process
ā ā āāā {feature}.md # Design docs per subsystem
ā āāā sprints/
ā āāā sprint-{N}.md # Sprint specifications
āāā .claude/
ā āāā agents/ # Worker definitions (architect, implementer)
ā āāā skills/ # Process definitions (slash commands)
āāā src/ # Your source code
Agents vs Skills
| Type | Purpose | Location |
|------|---------|----------|
| Agents | Workers with specific expertise | .claude/agents/ |
| Skills | Processes that orchestrate work | .claude/skills/ |
Agents do focused work (design, implement). Skills define workflows that may use agents.
SCRATCHPAD Pattern
docs/SCRATCHPAD.md Temporary context that doesn't fit into established docs.
Create temporary in-between session context.
Write plans when not in plan mode.
**Important: ** Claude never writes to this file unless instructed. This is for the end user to manage.
Session Analysis
/session analyzes past Claude Code sessions so you can improve your skills and processes over time. Name sessions with /rename for easy lookup later.
Things you can ask:
"List my recent sessions" / "List all sessions for this project"
"Find sessions where I used /implement-sprint"
"Summarize that session ā did it follow the spec?"
"Give me a deep summary with subagent breakdown"
"How much context did that session use?"
"Show me the tool usage timeline"
"Compare these two sessions" (diff)
Why didn't that session work well. How can we improve it.
Session analysis is not as deterministic as we'd like. The analyzer handles structured queries well (list, search, summary, diff), but for nuanced questions ā "why did this go wrong?", "did it follow the spec?" ā you'll often want to ask Claude to read the JSONL directly. The ad-hoc analysis recipes in the skill guide help with this.
** We all know Claude likes to self flagellate and tell us everything it did wrong. This is not productive when improving processes. I found telling Claude that "I choose to blame processes not people or LLMs." steers the conversation in a far more productive direction.
Philosophy
Principles Are Guardrails
Without explicit principles, LLMs optimize locally and lose coherence across a project. Principles enable autonomous decision-making within bounds.
Good principles:
Are specific enough to apply ("fail fast" not "be robust")