harness: add Definition-of-Done skill routing (auto-gate work with matching check-skills)
Skill-first rule now has two halves: route the request to a doing-skill, then gate the result with the matching check-skill before 'done' -- inferred from the request, not user-named. Adds .claude/SKILL_ROUTING.md (on-demand request->doing-skill->check-skill map). Enforcement tier A+B (CORE rule + map; Stop-hook backstop deferred). Calibrate to stakes, Ollama Tier-0 for cheap passes. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
@@ -42,6 +42,16 @@ production, data-loss. Detail: EXTENDED + `.claude/OLLAMA.md`.
|
||||
the memory rules (e.g. [[feedback_syncro_billing]]) describe what the SKILL does, not a license
|
||||
to free-hand it. Reach for raw API ONLY when no skill fits or the skill genuinely cannot do it
|
||||
— and say so explicitly when you do. Mistakes here go to `errorlog.md` (`--correction`).
|
||||
- **Definition of Done — route the REQUEST to a doing-skill, then GATE the result with the
|
||||
matching check-skill(s) before calling work done — automatically, without being asked.**
|
||||
You map the request to skills from the conversation + expected end result; the user should not
|
||||
have to name skill A/B/C. Standing gates (run the check-skill BEFORE declaring done): code edits
|
||||
→ `/code-review` + `/simplify` (+ `/security-review` if it touches auth/creds/security); anything
|
||||
outbound/client-facing → `impeccable` / `stop-slop`; Syncro/vendor work → its skill's own
|
||||
preview+verify gate; wiki/memory writes → their lint (`wiki-lint`/`memory-dream`). **Calibrate to
|
||||
stakes** (a typo fix doesn't need a full review) and **use Ollama Tier-0** for the cheap
|
||||
classify/prose passes so this stays low-token. The full request→doing-skill→check-skill map is
|
||||
`.claude/SKILL_ROUTING.md` — read it on demand when a request maps to a skill or work nears done.
|
||||
- **Credentials — capture, vault, document (ALWAYS).** ANY credential that surfaces in a
|
||||
session — one the user pastes, one you create/rotate, one you discover in a log/config — you
|
||||
MUST immediately store it in the SOPS vault **via the `vault` skill** (the canonical path —
|
||||
|
||||
Reference in New Issue
Block a user