doctrine
Use when grounding work in this fixture project's recorded knowledge — purpose and scope, design contracts, required behavior, topology, or the engineering bar. Routes to one pillar navigator.
- License 许可
- MIT
- 最近更新
- 2026-11-10
- Stars
- ★ 0
- Forks
- 0
01 前言 Front Matter
- name
- doctrine
- description
- Use when grounding work in this fixture project's recorded knowledge — purpose and scope, design contracts, required behavior, topology, or the engineering bar. Routes to one pillar navigator.
03 SKILL.md 正文
Project Doctrine Router
Five pillars, one router. Load at most one subskill per question.
| The question is... | Load |
|---|---|
| WHY — purpose, scope, refusals | subskills/heart-and-soul/SKILL.md |
| HOW — wire-level contracts | subskills/legends-and-lore/SKILL.md |
| WHAT — normative requirements | subskills/spec-and-spine/SKILL.md |
| WHERE — components and boundaries | subskills/lay-and-land/SKILL.md |
| WHO WE ARE WHEN WE BUILD — quality bar | subskills/craft-and-care/SKILL.md |
No pillar fits: answer from this router or say the project has not recorded it.
04 同仓库更多 Skills
user-run
Use when a step needs privileges this session lacks (docker, sudo, another user's checkout or secrets, host access) and the owner must run it as tze. Writes a reviewable /home/orca/.tmp/<slug>/run.sh that impersonates tze (USER_TO_IMPERSONATE overrides), tees timestamped logs plus latest.log and collects artifacts there; Claude presents it with a risk and time brief, then continues from the logs. Triggers: "I'll run it for you", "permission denied on docker.sock", "needs sudo", "sudo: a password is required", "run as tze", "/user-run".
requesting-code-review
Use when completing tasks, implementing major features, or before merging to verify work meets requirements
receiving-code-review
Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation
finishing-a-development-branch
Use when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanup
executing-plans
Use when you have a written implementation plan to execute in a separate session with review checkpoints
dispatching-parallel-agents
Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies