chore: add development conventions and model-routing config
Documents TDD/BDD/DDD methodology and Conventional Commits in CLAUDE.md, and adds Claude Code model-switching setup (haiku/opus subagents, sonnet default).
This commit is contained in:
@@ -0,0 +1,8 @@
|
|||||||
|
---
|
||||||
|
name: architect
|
||||||
|
description: Use for complex, non-trivial work — designing an implementation approach, weighing architectural tradeoffs, planning a multi-step feature or refactor. Read-only: it proposes a plan, it does not implement. Not for simple/mechanical tasks or for writing the actual code.
|
||||||
|
model: opus
|
||||||
|
tools: Read, Grep, Glob, Bash
|
||||||
|
---
|
||||||
|
|
||||||
|
Investigate the relevant code and produce a clear implementation plan or design recommendation with tradeoffs. Do not write or edit files — hand the plan back for implementation.
|
||||||
@@ -0,0 +1,8 @@
|
|||||||
|
---
|
||||||
|
name: quick-task
|
||||||
|
description: Use for simple, mechanical, low-stakes work — running a CLI command, writing and running a small bash/shell script, checking the output of a command, one-off file listing or grep. Do NOT use for anything involving design decisions, multi-file code changes, or debugging non-trivial logic.
|
||||||
|
model: haiku
|
||||||
|
tools: Bash, Read, Grep, Glob, Write
|
||||||
|
---
|
||||||
|
|
||||||
|
Execute the requested command or script directly and report the result. Keep scripts short and mechanical — if the task turns out to need design decisions or touches multiple files, say so instead of improvising.
|
||||||
@@ -0,0 +1 @@
|
|||||||
|
{"sessionId":"242e77f6-a2f0-4051-97fa-f360cc57a6ce","pid":386013,"procStart":"7345046","acquiredAt":1785426330459}
|
||||||
@@ -0,0 +1,3 @@
|
|||||||
|
{
|
||||||
|
"model": "sonnet"
|
||||||
|
}
|
||||||
@@ -0,0 +1,13 @@
|
|||||||
|
# CLAUDE.md
|
||||||
|
|
||||||
|
## Development methodology
|
||||||
|
Apply these as much as the task reasonably allows; skip only for changes too trivial to warrant them (e.g. a one-line config tweak).
|
||||||
|
|
||||||
|
- **TDD** — write a failing test before the implementation code for any new behavior; keep red-green-refactor tight.
|
||||||
|
- **BDD** — state acceptance criteria as Given/When/Then before implementing a feature; use an executable BDD framework where the stack has one, otherwise plain test names/comments.
|
||||||
|
- **DDD** — model code around the domain's real concepts and language (entities, value objects, aggregates, bounded contexts), not around technical/CRUD structure. Keep domain logic isolated from infrastructure/framework code.
|
||||||
|
|
||||||
|
## Git
|
||||||
|
- Use [Conventional Commits](https://www.conventionalcommits.org/) for every commit: `<type>(<scope>): <description>`.
|
||||||
|
- Types: `feat`, `fix`, `docs`, `style`, `refactor`, `test`, `chore`, `build`, `ci`, `perf`.
|
||||||
|
- One logical change per commit.
|
||||||
Reference in New Issue
Block a user