Skip to content

nisavid/tricritical

v1.0.0MIT

Tricritical: independently planned intent, runtime, and structure critics, adjudication, authority-gated revision, and one fixed-point loop.

Tricritical plugin

Tricritical is an Agent Plugins review package with native Claude agent aliases. It separates independent observation from adjudication, authorized revision, and repetition.

Public skills

SkillPersonaRoleMutates directlyCan cause mutationRequires original mutation authorityRepeatsCalls
reviewcoordinatornonononointent, runtime, structure
intentOathfindercriticnononono
runtimeFaultwalkercriticnononono
structureKnotcuttercriticnononono
adjudicateClaimweigheradjudicatornononono
reviseFormwrightreviseryesyesyesno
loopFathomkeeperloopnoyesyesyesreview, adjudicate, revise

Adapter boundary

Root plugin.json and skills/ are the canonical Agent Plugins package. The package-level references/ files and topology.json are the authored shared sources. Each public skill loads generated byte-identical projections beneath its own references/ directory, so a client that installs one skill root can resolve every shared runtime resource without package-parent access. Run the Tricritical content-lock writer after changing an authored shared source; it refreshes the required per-skill projections before locking them. Claude Code has no standard agent component, so its native adapter auto-discovers root agents/*.md; each file is an exact minimal forwarder to one public skill. Codex consumes skills/ and each skill's agents/openai.yaml, but not root Claude agents. A Codex named-agent projection belongs to a local harness configuration and must call the public skill rather than copy its policy.

Semantic skill-to-skill edges use literal public identities linked to sibling SKILL.md files and remain relative and unqualified. Claude adapters, the Codex extension, and agents/openai.yaml prompts use $tricritical:<skill> targets. Ordinary review consumes a live model-selection record per execution and a separate Rolecasting frozen invocation plan. The same leader verifies distinct worker contexts, unchanged inputs, completed reports, and declared verification. The resulting hand-back reports review status and its assurance limits; it does not attest the effective model or product-enforced permissions.

Explicitly witnessed review adds separate authenticated model-selection and invocation-topology receipts through conditional_requires.witnessed. Missing issuance or a consumer minimum above the route's capability blocks that mode. Neither mode changes original authority, closed dispatch membership, review completeness, or freshness. A changed candidate or evidence dependency requires fresh affected review before a downstream action. See the shared invocation boundary.

topology.json is the sole machine-readable authority and dependency declaration. The table above and sibling skill links are validated projections of that file. Its schema_version versions Tricritical's topology shape; it is not a repository-wide interchange-schema version.

The raw evaluation corpus and its isolation protocol are documented in evals/README.md. Run uv run --with PyYAML python scripts/validate_tricritical.py from the repository root after changes. That validator proves structural and corpus declarations only; it does not enforce an external evaluation runner or prove LLM behavior. It validates a private immutable byte snapshot and reports that snapshot's identity. Run it only while no concurrent writer can modify the checkout; live-tree drift detection remains an additional operational gate, not the identity of the validated snapshot.

Terminal evidence owner

The closed owner contract is documented in skills/loop/references/review-evidence.md. Task Witness may register the Tricritical terminal-evidence validator, but this package intentionally registers no producer or issuer. The v2 projection preserves Rolecasting's target, topology, authority, execution result, and assurance evidence as final_dispatch; Tricritical does not promote weaker evidence. Authenticated Rolecasting execution is not available in the installed integration, so validation is limited to retained evidence and fixture/bootstrap bundles. This is not a new-publication producer chain and does not establish canonical end-to-end reachability.