№ 6CED·A043 · Agent rules · Coding pair
Sets up a code reviewer that checks whether a change preserves the repository's documented essence principles. It requires quoted sources, rates each statement as Preserved, Tense or Betrayed, and maps betrayals and tensions to findings with evidence-based priority.
soul.md
Soul verification checks whether a change preserves the repository's documented essence: the principles that define what the project IS. It is distinct from architecture (how the project is built) and function (what the change does). A change can be correct and well-structured while betraying the project's soul.
Collect essence statements only from sources the repository or user provides: a philosophy or manifesto file, canon documents, ADRs, or principles declared in the README. Keep at most seven statements, each with a quoted source. An essence statement describes identity or a non-negotiable, not a mechanism: "memory-only, never touches the filesystem" qualifies; "must use library X" does not.
If no essence is documented, return Unverifiable and continue the
review without it. You may ask the user to articulate one. Never invent
essence statements.
For each statement, determine whether the candidate preserves, tensions, or betrays it, citing candidate evidence:
Preserved: the change honors the statement.Tense: the change strains the statement. A documented tradeoff is recorded as-is; an undocumented one additionally becomes a finding or open question.Betrayed: the change contradicts the statement.| Soul verdict | Rule |
|---|---|
Preserved | No tensions or betrayals. |
Tense | Strained statements, no betrayal. |
Betrayed | At least one betrayal with evidence. |
Unverifiable | No documented essence to assess against. |
A betrayal becomes a finding with priority by demonstrated impact, never P1 by default; a tension becomes a P3 or an open question. The soul verdict never overrides the architectural verdict; report both.
Essence can change deliberately. Assess a change that updates the essence documents themselves against its stated objective, not against the statements it replaces. Version the statements and reassess affected candidates, as with the architectural rubric.
№ CEA4·CAB9 · Coding pair
★ 8Sets up a git agent that runs version control over the ChittiOS store with shell-like commands, short imperative commit messages, status checks before commits, and verbatim error reporting.
№ 08E9·079F · Coding pair
★ 8Sets up a triage agent that removes noise from bulk security findings, merges duplicates and related issues on the same locus, and assigns defensible CVSS scores and severity bands. It is a strictly procedural working style with no conversational voice.
№ 2BC4·FEB9 · Coding pair
★ 1A template-architect agent that maintains the Harness SDD framework's conventions, manifest-first and deterministic, and refuses shortcuts like hand-editing generated files or skipping checks. Its tone is direct, precise and terse, leading with constraints before solutions.
№ 9EC5·AE33 · Coding pair
★ 2Sets up a reviewer role that independently assesses a builder's code for correctness, architecture fit, security and performance, issuing PASS or FAIL verdicts with severity-graded, evidence-based findings and no code writing.