odai

English · 中文

odai

odai is a governance-powered general task-execution framework for AI agents.

It embeds governance into execution: align the real objective, facts, assumptions, authorization, risks, and acceptance; then choose the shortest sufficient path, combine the right capabilities, act, verify, and keep moving until the task is genuinely deliverable. It does not replace the model's judgment with a rigid workflow.

The short version: call /odai; governance stays nearly invisible on simple work, while ambiguity, complexity, risk, and domain needs automatically increase or reduce the depth of handling.

Why Use It

odai is for people who want agents to move with autonomy, but not with false confidence.

It helps an agent:

• ask only when the missing answer would change the goal, scope, authorization, acceptance, risk, or stop line
• verify what it can verify from files, commands, logs, tests, or project context before asking you
• keep lightweight tasks lightweight instead of turning every request into ceremony
• avoid claiming that something was tested, delegated, reviewed, or verified when it was not
• combine specialist skills and domain guidance only when the task needs them, instead of stuffing every rule into every turn
• reuse existing host or project memory, persisting only durable information with provenance, scope, and invalidation conditions
• respond early and humanely to persistent low mood or self-harm/suicide inclination without diagnosing, labeling, waiting for a plan, or causing secondary harm

The Dao of odai

The user defines the task; evidence determines the route; methods adapt to circumstances; verification determines completion; boundaries determine where to stop—get the task done, without acting presumptuously.

This is not a collage of philosophical schools. It is one decision rule:

• Get the task done: advance the user's task to a verified, deliverable result, while surfacing counterexamples, risks, and a better route when they would change the outcome.
• Do not act presumptuously: do not bend facts, user decisions, or hard boundaries; do not conclude without evidence, exceed authorization, invent work, or treat a discovery as permission to implement it.

The person and the model work as partners toward a shared result, not through a one-way command chain. The person contributes intent, context, value judgments, and unacceptable outcomes; the model contributes judgment, evidence, creation, and execution, challenges doubtful premises, and proposes better routes. Both calibrate understanding and trust through real progress, candid uncertainty, and feedback. The person owns goal-level tradeoffs; the model chooses professional implementation details within the agreed boundary. Authorization is not blind obedience, and challenge is not a takeover.

odai is neither an echo of the user nor a reciter of rules. It takes the person's purpose as its direction and facts and boundaries as its constraints, forms its own judgment and recommendation, holds a justified disagreement when necessary, and changes its mind when the evidence changes. Truth outranks pleasing, effectiveness outranks ceremony, reliable results outrank superficial shortcuts, and long-term trust outranks one-turn performance.

The model's initiative is judged by net value. Speed, quality, stability, cost, breadth, and practicality are outcomes to balance against the user's goal and the evidence—not a flat list of slogans, and never substitutes for a real result.

Operating Standard

See clearly, hold steadily, strike accurately, land real results, defend what matters, and build for the long run.

Understand the real objective, facts, and gaps; hold authorization, boundaries, and risk steady; choose the narrowest sufficient path; produce a verifiable deliverable; protect user decisions, system safety, and truth; and leave a result that survives use, maintenance, and change.

Product Goal

Make agents faster, more accurate, better, steadier, cheaper, lighter, broader, more adaptive, more useful, and more practical. These are not independent process targets. They are product outcomes balanced around the task's net value; process, file count, tokens, and benchmark scores never substitute for getting the real task done.

30-Second Start

Install standalone governance:

npx skills add https://github.com/orziz/odai --skill odai

The source candidate separates optional orchestration into an installable sibling skill:

npx skills add https://github.com/orziz/odai --skill odai-orchestration

odai-orchestration depends on odai and adds responsibility presets and host routing adapters. Installing the skill does not change host settings. The candidate DSH packages bundle both; governance works without enabling orchestration. For an unpublished local checkout, replace the repository URL with its local path.

Then invoke it with /odai. That is the normal form in clients that expose 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 slash commands are not available in your client, naming odai in plain language works too.

You do not need to know the internal structure or choose a methodology. odai infers the required depth, capability, domain knowledge, and verification from the task and project evidence.

DeepSeek Harness packages

DSH users can install either integration independently:

# Apply Odai to every agent preset in one profile
dsh plugin --profile web add odai-dsh-plugin

# Install a selectable, session-scoped Odai Agent preset
npx odai-dsh-agent install

The current 0.2.56 source candidate uses DSH 0.2.1-rc.2 as its minimum supported baseline. The Agent admits >=0.2.1-rc.2, including later prereleases, and both npm peers remain open (*). Later releases still need compatible host APIs and are not certified without testing. Earlier DSH versions are outside current support; published releases retain their historical compatibility entries. Odai owns its preset and preserves its capabilities without copying Standard or automatically adding its new tools. Control Center uses the Web transport while headless governance remains independent of it.

Normal lifecycle and runtime paths do not inspect or rewrite old session logs. DSH refuses historical v0 logs containing unknown Odai events even when marked ignorable; the old flag-only legacy-session-repair entry is retired and does not modify files. New SDK support does not claim those historical sessions have been migrated.

The Plugin command requires pnpm on PATH. Each package already includes the canonical Odai skill, shared DSH runtime, and the same Chinese Control Center; there is no third package. Plugin exposes Control Center automatically. Interactive Agent install describes the existing profile source/version and asks at [Y/n]; Enter, y, or yes confirms, while EOF, n, no, or other text leaves the Web profile unchanged. Non-interactive install changes the profile only with explicit --with-control-center. Plugin and Agent may be installed independently or together: when both are present, Plugin owns the single Control Center surface while the runtimes share and deduplicate governance, routing, and evidence state. The existing provider-neutral odai-cli remains a separate product.

Both DSH packages default output to soft concise. Users can explicitly select normal output or the optional economy mode, which combines concise presentation with a user-adjustable provider output ceiling: it defaults to 500 when economy is requested without another value. The ceiling never changes child-agent, compaction, checkpoint, or internal context budgets and may be exceeded or ignored by the provider. See dsh/README.md for the complete three-mode contract.

A complete independently installed Odai skill can update faster than either DSH package without changing the default. The user must explicitly ask Odai to switch the skill source to auto or user; auto can select compatible project .dsh/.agents bundles and newer user installs, while user ignores project roots. An explicit deployment path remains highest priority. Plugin and Agent deliberately installed together share one per-agent/per-turn snapshot, so prompt governance and routing role contracts cannot select different bundles.

Neither DSH package chooses responsibility models or dispatch overrides. Tell Odai naturally, for example, use provider/model for planning with high reasoning and dispatch planning as child; the runtime persists only those explicit choices for both surfaces. Researcher, planner, reviewer, and frontend can each use same-turn or child; optional creative supports only read-only child dispatch on API and local CLI routes, returning writing candidates, tradeoffs, or review findings. The controller owns integration, validation, and final delivery. DSH children remain read-only and can return unapplied patches when explicitly assigned patch preparation; research, planning, and review retain their narrower contracts. Later requests stay ordinary: role words are not commands, task state selects direct, inline, same-turn, or child dispatch; read-only same-turn responsibilities return only to the controller, an identical planner/controller model is not called twice, and the controller continues an already-authorized implementation after planning. If a needed responsibility is still unconfigured, Odai names it and asks for the model instead of claiming that route ran. Persisted routes are formally resolved before provider I/O: deterministic invalid mappings are backed up and removed by exact match, while authentication, quota, rate-limit, or network failures affect only the current fallback.

DSH human-safety continuity is separate from generic semantic memory. Only an explicit direct-user request can save user-authored care preferences, signals to notice, effective support, or safety-plan steps in the independent local record; the user can inspect, export, correct, remove, or physically clear it, and entries persist until one of those deletion controls is used. New sessions treat it as historical care preference, never as present-risk evidence, diagnosis, or a hidden score, and child agents never receive it.

See dsh/README.md for package boundaries, source precedence, natural-language configuration, and the isolated real-install coexistence verification.

Host Capability Routing

The user identifies who should own each responsibility once, or lets odai recommend a mapping from the host's real capability catalog. After confirmation and installation, the project persists that mapping. Every later conversation and action still starts with /odai or an ordinary task request; the user never repeats models, roles, planning modes, or routing commands and does not need to watch internal handoffs. When models change, update the mapping once in place.

The controller is the persistent task thread that owns the goal, global state, correction loop, and final delivery, not another role launched on every turn. Judgment and acceptance are optional internal responsibilities rather than a user workflow; implementation remains with the controller. One sufficient capability completes the task in one pass; when another mapped responsibility can materially change the result, the host obtains that bounded contribution and returns it to the current conversation. Reliable no-tool answers stay direct, and follow-ups inherit recent deliveries and unresolved items without making the user restate them.

This routing is constrained by the host; skill text alone cannot mechanically guarantee it. If the host cannot verify model switching or delegation, odai uses one sufficient controller and continues the safely achievable work without pretending that routing occurred. The router is not a prerequisite for ordinary use and is installed only when the user requests managed capability routing.

Managed capability routing and the project guardrail hooks described below are separate mechanisms. Routing registers host roles and does not install a task runner or hidden per-turn hook. Project guardrails only enforce project-declared read-only paths and acceptance commands and do not route models.

Users on a supported host who want managed role routing do not need to find paths, enter model IDs, or merge configuration by hand. After installing the skill, say:

/odai install and verify capability routing for this project.

odai configures one controller plus planner and reviewer from the host's actual capability catalog, with optional researcher, frontend, and creative mappings, explains the persistent effect, asks for one confirmation, and installs them with conflict checks. The default auto policy only registers capabilities: one controller owns complete delivery and may delegate bounded production within host permissions; optional responsibilities run only when independent work can change the result. It adds no hidden per-turn preflight or stage runner. Reliable direct answers and read-only lookups never invoke another role merely to demonstrate routing.

To remove it, ask odai to uninstall capability routing for the current project. The installer merges with existing host settings, records the original Codex controller configuration for exact restoration, deletes only unchanged files listed in its managed manifest, and preserves unrelated settings. Installation, update, or an actual uninstall requires a new session; project scope is the default. It can generate managed role configuration for Codex, Claude Code, and GitHub Copilot CLI. Codex additionally supports native role verification; the other two hosts must not claim equivalent runtime routing evidence until comparable verification exists.

How It Decides

odai continuously evaluates four dimensions:

• Complexity: direct action, a small amount of structure, staged execution, or durable task state and trusted memory.
• Clarity: enough evidence to act, safe exploration first, or a decision that only the user can make.
• Risk: lightweight verification for reversible work; stronger authorization and evidence for external or hard-to-reverse work.
• Domain: internal craft knowledge, repository conventions, or a specialist host skill for code, documents, spreadsheets, slides, browsers, images, games, and other deliverables.

Before loading any playbook, it applies a silent light-task gate. If the outcome, action, path, authorization, and verification are already clear and low-risk, it acts directly. A suspicious premise, conflicting request, material ambiguity, cross-layer tradeoff, high-risk side effect, or long dependency is what makes it expand.

Depth is not fixed at the start. A task can be upgraded when its impact expands or downgraded when inspection reveals a small local change. SDD, TDD, BDD, agents, consensus, and formal plans are optional methods, not mandatory modes.

Objects supplied only to inform, compare, explain, or verify the target are read-only by default. A request whose result is understanding, judgment, advice, or a plan is not silently upgraded into authorization to modify existing objects; even change requests write only to the identified target.

The point is not to slow the agent down. The point is to make sure it is fast in the places where speed is safe, and careful in the places where guessing would cost you.

Architecture Logic

user task
                            |
                            v
       +---------------------------------------------+
       | /odai -> lightweight adaptive kernel       |
       | understand -> choose next valuable action  |
       +---------------------+-----------------------+
                             |
       +---------------------+-----------------------+
       |                     |                       |
       v                     v                       v
  direct action       internal capability      host skill / tool
                     + domain knowledge         + project rules
       |                     |                       |
       +---------------------+-----------------------+
                             v
                    act -> verify -> deliver
                             |
                  new evidence updates the path

Add support for an actual gap, then remove it when stable;
persist state for resumption and delegate for a distinct contribution.

The framework owns the task from understanding through delivery. Eight on-demand references own boundaries, planning, craft, verification, state and memory, external capabilities, everyday care, and crisis safety. Each addresses only the current gap.

odai's complete capability is not just its entry text. It combines the core, built-in baseline craft, project context, and professional capabilities that are worth using. A clearly matching installed capability may be used directly; a general capability gap warrants an installation recommendation only when the net gain is real; stable, repeated, project-specific craft may be encoded as a project skill. Whatever route is used, odai still owns evidence integration, acceptance, and final delivery. Merely finding, recommending, creating, or invoking a capability is not completion.

Internal Map

The internal structure is organized by responsibility, not by mandatory stages:

Layer · Purpose Kernel · Core principle, rules organized by outcome, facts, approach, completion, and boundaries, delivery, and gap-based loading care.md · Non-crisis everyday support, reduced action burden, and user-controlled response styles human-safety.md · Early recognition, humane crisis intervention, prevention of secondary harm, and explicitly authorized safety continuity dao.md · Goal ownership, factual correction, authorization, read-only references, and high-impact boundaries craft.md · Implementation and troubleshooting, design, UI and real-time interaction, writing, and review for an agreed result planning.md · Executable engineering plans, requirement coverage, work-package dependencies, durable handoffs, and recovery order verification.md · Acceptance, evidence strength, and completion memory.md · Long-term information, the project overlay, and codifying project rules or skills; planning owns resumable task state leverage.md · Tool, resource, and skill selection; external capability discovery, net-benefit decisions, installation, creation, and composition

Domain depth is inferred from the task instead of selected as a package. Game, UI, documentation, and software work use the built-in craft baseline, then borrow project material, host tools, or professional skills only for a named gap. An optional host responsibility such as frontend is a model-routing adapter for a verified production gap inside the current task, not a selectable domain package or a precedent for enumerating database, security, or other domain roles. Without an external skill or responsibility mapping, odai still completes what the current model can do reliably.

Content work preserves evidence, existing templates, stale responsibilities, and publication boundaries. Complex or long-running work writes decisions, state, and acceptance evidence back to one existing maintenance location only when that materially improves recovery. Code, tests, or the requested artifact remain sufficient when they already carry the complete result.

Good Prompts

Use the level of detail you actually have:

/odai handle this. Decide the route and ask only if a boundary or acceptance point is missing.

/odai review the current diff. Report findings first and do not modify files.

/odai refresh this repository README. Remove outdated screenshots and keep the install path clear.

/odai this task is user-facing. Do not change behavior without approval; verify the proposed route first.

Install Options

Most users only need the unified entry point:

npx skills add https://github.com/orziz/odai --skill odai

Other supported installs:

# Install every skill in this repository
npx skills add https://github.com/orziz/odai --all

# Install the slimmer branch
npx skills add https://github.com/orziz/odai#mini

# Install the older "one skill per ability" layout
npx skills add https://github.com/orziz/odai#old

Use old only if you still depend on the previous standalone skill layout or are comparing a migration.

Canonical source lives in skills/. Distribution is handled through the skills.sh install flow; this repository no longer keeps per-platform mirror outputs. See MAINTAINING.md for the current source, validation, freeze, and release rules, and CHANGELOG.md for frozen architecture changes.