القائمة
Compatibility umbrella skill for the UNITARES governance framework. Use this as the entrypoint when you need the overall model and route into the split governance skills.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Use when an agent needs to understand UNITARES governance concepts — EISV state vectors, basins, policy actions, coherence, calibration. Reference material for interpreting governance metrics as proprioceptive state estimation, not outcome judgment.
Use when an agent is participating in a UNITARES dialectic session — paused and needs to submit a thesis, reviewing another agent's thesis, or synthesizing conditions for resolution. Covers structured argumentation and convergence.
Use when an agent is interacting with UNITARES governance for the first time, needs to onboard, check in, or recover from a pause/reject verdict. Covers the full agent lifecycle from session start through check-ins to recovery.
Use when adding, editing, or reviewing sections on the unitares dashboard (dashboard/redesign/). Captures the redesign's conventions: the section-module pattern (window.X = { load }), the live-or-snapshot data seam, theme-aware charts via design tokens, and the app.html wiring (nav / pane / lazyLoad / RELOAD / retheme). A repo-specific reference — not general dashboard advice.
Use when setting up or operating the UNITARES Discord bridge — a standalone bot that surfaces governance events, agent presence, Lumen's state, and autonomous governance actions as a living Discord server.
Use when an agent needs to search the shared knowledge graph, contribute a discovery, or update existing entries. Covers search, tagging, discovery types, and status lifecycle.
| name | unitares-governance |
| description | Compatibility umbrella skill for the UNITARES governance framework. Use this as the entrypoint when you need the overall model and route into the split governance skills. |
| last_verified | 2026-06-29 |
| freshness_days | 14 |
| source_files | ["unitares/src/mcp_handlers/core.py","unitares/src/mcp_handlers/identity/handlers.py","unitares/skills/governance-lifecycle/SKILL.md","unitares/skills/governance-fundamentals/SKILL.md","unitares/skills/knowledge-graph/SKILL.md","unitares/skills/dialectic-reasoning/SKILL.md","unitares/skills/discord-bridge/SKILL.md"] |
This umbrella skill exists for backward compatibility and as a stable top-level entrypoint into the UNITARES framework.
UNITARES evaluates agent state with the EISV model:
E: effective energy / execution driveI: integrity / coherence of alignmentS: entropy / disorder / instabilityV: valence (signed E-I imbalance)Agents typically call start_session(force_new=true) once for a fresh process
identity, then continue that same running process with sync_state() as their
main check-in loop. A new user message is not a reason to call
start_session(force_new=true) again; that mints another process identity.
These are the primary workflow tools; raw implementation tools such as
onboard(...) and
process_agent_update(...) remain available for compatibility. The full raw
payload remains available under raw_governance.
Use start_session(force_new=true) to register a fresh process identity once.
If the process is a real handoff continuing prior work, declare that with
parent_agent_id=<prior uuid> and spawn_reason="new_session".
Use raw onboard(...) instead for older servers or raw response shape.
Use identity(agent_uuid=..., continuity_token=..., resume=true) only when
rebinding the same live owner to an existing UUID. The continuity_token is
short-lived ownership proof for anti-hijack gates, not indefinite
cross-process continuity. A bare onboard() or bare
identity(agent_uuid=..., resume=true) can rely on weak evidence or an
unsigned UUID claim; do not teach those as normal flow.
In-process tool calls thread the response's client_session_id through
subsequent invocations to maintain transport continuity within a single
process. Use that for ordinary sync_state() / check_working_state() calls.
client_session_id is in-session continuity only — weak across processes, not
identity proof on its own. Do not pass continuity_token on every call; reserve
it for explicit same-live-owner identity(..., resume=true) rebinds.
Use sync_state() after meaningful work to record progress, complexity, and
confidence, then read the returned governance verdict. Use raw
process_agent_update() when you need the raw handler response.
The governance system is coupled to the knowledge graph. Agents should search existing knowledge before duplicating work, and contribute discoveries, questions, and answers as they learn.
The old monolithic skill was split into focused skills:
skills/governance-lifecycle/SKILL.md for onboarding, check-ins, and recoveryskills/governance-fundamentals/SKILL.md for EISV, basins, coherence, and verdictsskills/knowledge-graph/SKILL.md for knowledge graph search and contributionskills/dialectic-reasoning/SKILL.md for thesis/antithesis/synthesis workflowsskills/discord-bridge/SKILL.md for the Discord governance bridgeIf you need the full mental model, start here. If you know the task shape, prefer the focused skill directly.