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:
eho
2026-07-30 17:49:14 +02:00
commit 09b27173a7
5 changed files with 33 additions and 0 deletions
+8
View File
@@ -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.
+8
View File
@@ -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.
+1
View File
@@ -0,0 +1 @@
{"sessionId":"242e77f6-a2f0-4051-97fa-f360cc57a6ce","pid":386013,"procStart":"7345046","acquiredAt":1785426330459}
+3
View File
@@ -0,0 +1,3 @@
{
"model": "sonnet"
}
+13
View File
@@ -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.