Feature request: Starter workflow templates with context management and task-phase skills
Problem
Claude Code's onboarding gives users a blank slate. The /init command generates a minimal CLAUDE.md with basic project info, but no workflow structure. Users are expected to discover best practices through trial and error.
This creates three gaps:
- No workflow structure — common failure modes (context decay in long conversations, premature "done" claims without verification, unstructured multi-file refactors) all have known mitigations that could be provided as starting points.
- No cross-session continuity — each conversation starts from zero. There's no built-in mechanism to carry task progress, accumulated learnings, or session history between conversations. Users who solve this do it by independently inventing context file systems, but most never get there.
- No task-phase discipline — the skill mechanism exists, but users don't know which skills to invoke at which phase of a task. Without structure, users skip verification, jump into implementation without planning, or never simplify their code after writing it.
Proposal
Add optional workflow templates to claude init (or a new claude init --template flag) that scaffold three things: a CLAUDE.md with structured workflows, a context directory for cross-session continuity, and task-phase skill integration. Think eslint --init — opinionated defaults the user can customize.
1. Workflow templates in CLAUDE.md
A template could include:
- Tiered task workflows — different levels of planning based on task complexity (quick fix vs. multi-file refactor vs. new module)
- Verification steps before marking tasks complete (run tests, type-check, lint)
- Git workflow rules — commit conventions, PR process, branch strategy
- Guardrails — don't refactor unrelated code, don't add dependencies without asking, etc.
Templates could vary by use case:
solo-production— strict verification, session context, structured workflowteam— PR conventions, code review process, CI/CD awarenessprototype— lighter guardrails, faster iterationlearning— educational explanations, concept definitions
2. Context management system
The highest-value pattern we've found is a context directory that creates continuity across sessions:
context/
├── todo.md # Task tracking — what's pending, in progress, done
├── lessons.md # Corrections log — mistakes the agent made and how to avoid them
├── log.md # Session activity log — what happened, when, key decisions
├── bugs.md # Bug registry — known issues, root causes, status
└── archive/ # Archived context (monthly rotation to keep files lean)
Each file has:
- Maintenance instructions at the top telling the agent how to keep it updated
- Archival rules (e.g., "when this file exceeds 300 lines, archive old entries")
- A clear purpose so the agent knows when to read vs. skip each file
The session protocol ties it together:
- On start: read todo + lessons + log → ask user what to work on
- During: update todo as tasks progress, log corrections to lessons immediately
- On end: sync all context files, check archival thresholds
This creates a feedback loop that improves over time: corrections become lessons, recurring lessons graduate to permanent rules in CLAUDE.md, context files stay lean through archival. The agent gets better with each session because it learns from documented mistakes rather than repeating them.
3. Task-phase skill integration
The skill mechanism in Claude Code is powerful but undersurfaced. Templates should map skills to specific phases of the development workflow, making it clear when each skill fires:
| Task phase | Skill purpose | When it fires |
|---|---|---|
| Before complex work | Brainstorming — explore requirements and design before writing code | When starting a new feature or multi-component task |
| Before implementation | Planning — create a concrete, step-by-step implementation plan | When a task touches 3+ files or involves non-trivial logic |
| After writing code | Simplification — review for reuse, quality, and unnecessary complexity | After every code change, non-negotiable |
| Before marking done | Verification — run tests, type-check, lint, confirm correctness | Before any "done" claim, non-negotiable |
| When stuck | Systematic debugging — structured root cause analysis before guessing fixes | When a bug or test failure resists the first fix attempt |
The key insight: making simplification and verification non-negotiable (the agent must invoke them, not skip them) solves the most common complaint about AI coding agents — claiming "done" when the code doesn't work. The template should encode these as mandatory workflow steps, not optional suggestions.
Additional ideas
- Hook presets per template — e.g., post-edit verification hooks, auto-lint on commit
- Community templates via
claude init --template <url>— power users publish, new users benefit - Sub-project awareness — for monorepos, generate root CLAUDE.md (shared rules) + sub-project CLAUDE.md (technical reference) with clear inheritance
- "Lessons graduation" mechanic — documented workflow for how repeated corrections become permanent rules
Evidence of demand
The community has already built third-party skill packages that implement workflow-phase discipline on top of Claude Code's native skill mechanism. These packages exist because users independently discovered that structured workflows dramatically improve output quality, and the built-in tools alone don't provide enough guidance on when and how to use them. This is organic demand signaling that first-party support would serve a real need.
Why this matters
The gap between "use Claude Code with no structure" and "use Claude Code with a well-designed workflow" is enormous in output quality. Users who invest in structured CLAUDE.md files with context management and task-phase skills see dramatically better results — fewer hallucinations, less context decay, cross-session continuity, and self-improving behavior. But most users never get there because they don't know the gap exists.
A good template system turns the structured workflow into the default path, not the expert path.
This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗