Odai Task Governance
Help AI agents plan and finish work from evidence while respecting authorization and risk boundaries.
- Source repo
- orziz/odai
- Stars
- ★ 119
- Last updated
- 1d ago
- License
- MIT
- Primary language
- JavaScript
- FA score
- 49/100 · Major gaps
At a glance
- How it runs
- Works with
- Universal · cross-platformCodexClaude Code (Partial support)
- Cost
- Free, no paid service needed
- Setup effort
- Low · running in minutes
- You'll need
- Typical use
- A developer changing code in a repository who wants project conventions and acceptance conditions checked first.
- Not a fit if
- Teams that need framework-guaranteed model routing across hosts
- Users who require automatic migration of historical DSH sessions
- Source review
- 49/100 · Major gaps
What does this agent do, and when should you use it?
Odai is a general task execution and governance framework invoked with /odai and distributed primarily as an installable skill. It uses the user's goal, files, and project context to choose an appropriate level of handling, from direct action to optional specialist routing. During execution it acts, checks results against evidence and acceptance needs, and continues until it has a deliverable. Optional DSH Plugin and Agent packages add DSH integration and a Chinese Control Center, while the skill can be installed on its own. Routing and hooks are optional; the documentation says skill text alone cannot mechanically guarantee host model switching or delegation.
After installing the odai skill, a user starts work with /odai and a natural language task; clients without slash commands can mention odai in plain language. The framework evaluates the goal, facts, gaps, authorization, risk, and acceptance conditions, and acts directly when work is clear and low-risk. It can read files and project context, use host tools, project rules, or specialist skills as needed, and preserve resumable state for complex work. When host routing is supported and configured, it can obtain a bounded specialist contribution. It then integrates evidence, verifies the deliverable, and reports the result. Optional hooks can enforce project-declared read-only paths or run declared acceptance commands from .odai/hooks.json.
- A developer changing code in a repository who wants project conventions and acceptance conditions checked first.
- A maintainer who wants a current diff reviewed and findings reported without modifying files.
- A product team updating README or onboarding copy that wants proposed wording and risks before behavior changes.
- A project team configuring Codex, Claude Code, or GitHub Copilot CLI capability routing once for a supported host.
- A DeepSeek Harness user who wants governance through the standalone Plugin or Agent preset.
How do you install or deploy this agent?
Install the standalone core skill:
npx skills add https://github.com/orziz/odai --skill odaiOptional DSH integrations:
dsh plugin --profile web add odai-dsh-plugin
npx odai-dsh-agent installThe README does not specify a separate API key requirement for the core skill; model and runtime needs depend on the host. The DSH Plugin command requires pnpm on PATH. The current DSH package source candidate uses DSH 0.2.1-rc.2 as its baseline; the Plugin and Agent packages can be installed independently.
How do you use this agent?
After installation, invoke it in a client that exposes skills as slash commands:
/odai update the onboarding flow copy.
Goal: make it clearer for first-time users.
Materials: current app files and README.
Constraints: do not change behavior yet; give me the proposed copy and risks first.If the client has no slash commands, mention odai in a natural-language task. To set up managed capability routing on a supported host, ask:
/odai install and verify capability routing for this project.Routing setup asks for confirmation and configures roles from the host's capability catalog. If the host cannot verify model switching or delegation, Odai uses one controller to continue safely achievable work and does not claim that routing ran.
What are this agent's strengths and limitations?
- Handling depth adapts to task complexity, clarity, risk, and domain; clear, low-risk work can be direct.
- It directs the agent to verify available evidence in files, commands, logs, tests, and project context before asking the user.
- It separates the skill, optional host routing, and project hooks; hooks can check declared read-only paths and acceptance commands.
- The core skill installs independently, with separate DSH Plugin and Agent integration options.
- Actual model routing depends on host capabilities; skill text alone cannot guarantee switching or delegation.
- The DSH Plugin command requires
pnpm, and the current DSH package source candidate uses DSH0.2.1-rc.2or a compatible later version. - DSH refuses historical v0 session logs containing unknown Odai events; automatic migration is not documented.
- Project hooks check structured write tools and declared commands, not ordinary shell writes, and do not replace host permissions or sandboxing.
How does this agent compare with similar options?
Compared with making every task follow a fixed, full process, Odai adjusts handling depth to the evidence and task. It can also be used without optional host routing. The README describes SDD, TDD, BDD, agents, consensus, and formal plans as optional methods rather than mandatory workflows.
Key facts side by side with the most closely related agents.
| Agent | Source review | Form / cost | Stars | Updated | Language | Full support on |
|---|---|---|---|---|---|---|
| Odai Task Governance This agent | 49 · Major gaps | Agent plugin / skillFree | ★ 119 | 1d ago | JavaScript | Codex |
| Coven | 79 · Good | CLIFree | ★ 73 | today | Rust | Codex · Claude Code |
| Spec Kit Skills for Coding Runtimes | 51 · Major gaps | Agent plugin / skill | ★ 151 | 1d ago | Shell | Codex · Claude Code |
| Gas Town — Multi-Agent Workspace Manager | 49 · Major gaps | CLIFree + model costs | ★ 18k | 2d ago | Go | Codex · Claude Code |
How does FollowAgents rate this agent?
Why each dimension lost points
README states read-only-by-default references, authorization before change, confirmation on install/uninstall, manifest-scoped uninstall with exact restoration, and hooks disabled by default, so least_privilege, user_confirmation, external_effects, rollback score 2. Data-flow transparency is asserted in prose only with no concrete flow or logging; sensitive-data handling (local human-safety record) is described but not shown in code; dependency security shows only devDependencies and npm ci with no audit or lock policy; source attribution names skills.sh and MIT but publisher identity is unverified, so these are deducted to 1.
README clearly describes routing failure handling, that auth/quota/network failures affect only the current fallback, and that odai must not pretend routing occurred, giving self_consistency 2. Dependency availability rests on stated DSH baseline and open peers with no lock or fallback strategy; failure-message form has no code evidence, so each is deducted to 1.
Audience and scenarios (light tasks direct, complex tasks escalated, multiple hosts) are well covered at 2; capability boundaries (read-only references, authorization limits, no false verification) are clear at 2. Trigger precision relies on /odai or plain-language naming without mechanically checkable rules; environment fit covers only some hosts and admits skill text cannot guarantee routing, so each is deducted to 1.
Information architecture (Internal Map table, layered references) and install notes (multiple npx installs, DSH packages, pets) are adequate at 2; examples and known limitations (historical v0 logs not migrated, old layout for migration only) are explicit at 2; MIT license is complete at 2. Naming stability is deducted to 1 for coexisting odai/odai-orchestration/odai-cli/odai-dsh-plugin/odai-dsh-agent plus mini/old branches; versioning is deducted to 1 since only a CHANGELOG link is given with no history in the body; maintenance responsibility is deducted to 1 as it points to MAINTAINING.md with an unverified publisher.
Output usability scores 2 with concrete prompt examples and a delivery/acceptance orientation. Marginal value is mostly governance philosophy and process constraints without quantified comparison or benchmark evidence; cost-benefit mentions economy mode and a token ceiling but with no measured data, so each is deducted to 1.
claim_traceability is deducted to 1 because many README assertions (isolated install verification, coexistence verification) point only to dsh/README.md and script names without results in the provided files; cross_source_corroboration is deducted to 1 since only the CI workflow and package.json script names partially correspond, with no test output; fact_inference_separation scores 2 as README distinguishes supported from uncertified claims (e.g., other hosts must not claim equivalent routing evidence).
- Publisher identity is unverified; verify source and signatures before installing.
- README assertions about isolated install and coexistence verification point only to other docs and script names, with no result evidence in the provided files.
- Dependency security and data-flow transparency are prose commitments without audit, lock, or logging evidence.
- Triggering relies on /odai or plain-language naming with no mechanically checkable rules, and host compatibility is limited.