Auto-applying rules¶
Rules in .claude/rules/ are referenced from the workspace CLAUDE.md, so
Claude Code loads them into context on every session in this workspace.
They shape behavior without being explicitly invoked.
Task pipeline¶
task-pipeline.md -- when a message reads like a task (a description plus
requirements or an expected result), Claude suggests /create-task rather
than running the pipeline silently. The pipeline has real side effects (Jira
tickets, branches, PRs), so it is gated behind explicit slash commands. Simple
questions, single-line edits, and "explain this" do not trigger it. See the
Task-delivery pipeline.
Model routing¶
model-routing.md -- each pipeline phase is assigned the cheapest Claude tier
that still does the job well, and heavy autonomous steps are delegated to a
sub-agent on that tier. Active profile is Balanced:
| Phase | Tier |
|---|---|
| Planning / spec / AI code review | Opus |
| Implementation | Sonnet (escalate to Opus on large/high-risk specs) |
| Lint/test triage, CLI mechanics | Haiku |
| PR body / commit message | Sonnet |
Interactive Approve/Iterate gates always run on the main session model. This is Claude-only -- no cross-provider calls.
Token optimization (context cache)¶
token-optimization.md -- the workspace keeps a pre-summarized context
cache (S3-backed, mirrored at hq/cache/context/) covering past specs,
per-repo architecture, pipeline patterns, and command cheatsheets. Before
reading a large file or running broad grep/find sweeps, consult it:
hq/.venv/bin/python -m hq.context_cache search "<keyword>"
hq/.venv/bin/python -m hq.context_cache get summaries/<path>.md
Cache hits bump a use_count so the system learns which entries earn their
budget. Skip the cache for short files, when a summary is stale, or when you
need exact line numbers.
Deploy targets¶
deploy-targets.md -- a registry in the DynamoDB config table maps each repo
+ environment to its CodePipeline name, endpoint, and a per-project check
kind. Before re-hunting AWS for a pipeline name or load-balancer DNS,
consult it:
hq/.venv/bin/python -m hq.deploy get <repo> --env stage
hq/.venv/bin/python -m hq.deploy check <repo> --env stage
check probes multiple aspects independently (pipeline / endpoint / nginx /
docker / api / task); a missing component is not-found, not a failure. Missing
targets are discovered from AWS once and written back to the registry.
Bastion access¶
bastion-access.md -- deploy instances live in private subnets, reachable only
through a single bastion host. Host checks (command / docker / nginx
kinds) run over a nested SSH hop via hq.deploy, using the bastion key
(~/.ssh/bastion.pem, auto-downloaded from S3) and per-target keys held on the
bastion. HTTP targets are checked by curling the endpoint -- no SSH needed.
Dormant rules¶
bridge-mode-pipeline.md -- the render-UI "bridge mode" spawn pattern. The
active flow is terminal-only, so this rule never takes effect. It is retained on
disk for possible future revival and is not auto-loaded.
Why rules exist
Conversations here recur on the same repos, commands, and pipeline. Rules encode the shortcuts once (cheapest model, cached context, registry lookups, gated side effects) so every session behaves consistently and cheaply without being re-taught.