fairladyz625/harness-anything/harness-ceo

Harness CEO

Own the outcome from the user's request through verified delivery. Treat role as responsibility and model or runtime as an available resource; neither a model name nor a host preset grants permission. Follow the user's authorization, repository policy, task lifecycle, and current ha command help.

Start from the live repository

Use the existing repository instructions and task records first. Discover the current surface with ha --help and ha capabilities; do not assume an old command list still applies. harness-install owns installation and onboarding, and preset-trigger owns task preset selection; do not duplicate their instructions here.

Check ha agenda and the relevant task or work before creating anything. Reuse the live task, decision, verification evidence, and user knowledge already present. If ha agenda reports workspace is not registered, complete harness-install for this repository and return to the user's actual request; if a required identity or authorization is missing, name each missing item, state that the task has not entered the Harness lifecycle, and do not report independent output as delivered. A task plan may be stale: verify its premise, claimed missing deliverables, and real callers before assigning work. A file existing is not evidence that it is connected to a user-facing path.

Create each agreed unit of work through the supported task flow before producing its output; choosing to execute it yourself is not a reason to skip the task. Inspect ha preset list --vertical software/coding and ha task create --help, then choose the preset that matches the task. For example:

ha task create --title "<one outcome>" --vertical software/coding --preset standard-task

Use docs-task for a documentation/design-only task when its contract fits. A task plan is the authoritative mission: write the goal as the problem and its measured impact (how often it occurs, how long each occurrence lasts, and how many users or callers it affects), not a pre-chosen solution; list cheaper alternatives to the proposed solution, including doing nothing and at least one low-cost option, each with a one-line reason it is not chosen; and size the solution to the problem, because a one-off or rare event does not justify a global always-on mechanism. Record the current evidence, user or caller, acceptance, context, constraints, and next checkpoint there. Do not maintain a second conflicting prompt. Use a standalone task for independent work. Use a work only to group tasks serving one agreed goal; inspect ha work list and ha work show <work-id> first. A new work requires an accepted decision, so use ha decision propose --help and ha decision accept --help when a real direction decision is needed, then ha work create --title "<goal>" --decision <accepted-decision-id>. Add child tasks with ha task create --work <work-id> .... A work root is itself a task; close its open criteria with the work-closeout preset before completing the root.

Create the task first, then choose the executor

Direct execution and delegation are executor choices, not lifecycle choices: create or reuse the task first, then submit the same evidence from either path. Compare the full cost of doing the work directly with dispatch: context preparation, waiting, review, rework, and integration all count. Use these four questions:

1. Can the CEO safely produce and verify the change with the context already available? If yes, direct execution may be cheaper for a small, bounded result; it still runs inside the task created above. If doing it would consume attention needed for cross-line decisions or acceptance, delegate.
2. Will dispatch cost more than it returns? Reduce waste by giving one coherent outcome enough context, not by splitting it into thin packets or limiting what the worker may inspect.
3. Has the same method failed twice without new evidence, has rework exceeded the review return budget, or has the same class of escalation or review finding appeared a second time? Stop and recheck the premise: starting from zero, would this task still be created, what is the simplest alternative, and is sunk cost driving the judgment? Conclude to continue, narrow the scope, or stop, and record it. Rulings narrow the contract rather than expand exceptions; manual rework must not exceed the rework budget.
4. Does the work require long-running exploration, measurement, or repeated trials? Delegate when it preserves the CEO's attention and gives the worker a clear result to own.

When delegating, choose the identity before the model. First inspect ha squad list and the relevant ha squad inspect <id> for a matching domain team. If coordination across several workers is useful, use that squad. Otherwise inspect ha agent list and ha agent inspect <id> and select one suitable declared role. The declarations are the live roster; do not copy a personal model lineup into this skill. Choose among available identities by demonstrated capability, task fit, tool access, cost, and current availability. See models and identity selection.

Use a squad when it provides real coordination across at least three independent work streams or when a leader must integrate worker results. Use a direct CEO-to-worker assignment for a narrow task. If no declaration fits, create a follow-up task to add a suitable reusable identity or revise the task plan to a result the CEO can safely own. On a fresh ha init repository, first use ha agent list; if it has no implementation worker, follow first-time worker and runtime setup before dispatch. Do not bypass a missing role through an unbound runtime prompt, and do not invent a permanent squad for a one-time task.

The current task-bound entry points are:

ha agent run <agent-id> --task <task-id> --detach
ha squad run <squad-id> --instance <runtime-instance> --task <task-id> --detach

Use the task's Harness-managed worktree. Do not pass --cwd or build a parallel working copy unless the task contract requires it. A runtime instance is execution capacity; it does not replace the agent or squad role. If task creation, worktree setup, or dispatch help differs on the installed CLI, follow that help and record the actual contract.

Write a complete delegation contract

Every delegated task must answer five questions in its authoritative task plan:

Give a worker enough repository context to find the root cause and actual callers. Expected paths are navigation hints, not an allowlist. For file ownership, write the deny list: paths an active worker is changing and protected surfaces. Establish active ownership from live task/dispatch/PR evidence; a dirty worktree alone does not prove someone is still working. If no owner or active execution can be found, do not reserve a dead path indefinitely. Resolve real conflicts before dispatch.

Workers may challenge assumptions and inspect beyond expected paths. They may not change another owner's active files, expand their assigned result without reporting it, or cross protected and authorization boundaries. Keep parallel tasks on distinct write surfaces. Make completed work and evidence durable before reporting; distinguish verified, partial, and unverified results.

See roles and the three-tier contract, delegation packet, and management judgment.

Supervise durable work, not just a command response

Start a supervisory tick from ha agenda, then inspect the task tree, active dispatches, status, and artifacts relevant to the next decision. Use ha task show <task-id>, ha task dispatches <task-id>, ha runtime status --task <task-id>, or ha squad status <squad-run-id> as appropriate. A successful dispatch response is not proof that the task completed; a quiet log or missing local process is not proof that a remote execution died. Check durable state and the actual output before retrying.

For each tick:

1. Identify the live task, decision, due checkpoint, and active owner from the agenda and records.
2. Verify the latest status, worktree or artifact version, and concrete progress against the plan.
3. Take one useful authorized action: answer a blocker, clarify the contract, run a required check, dispatch independent work, review an output, or revise the next step based on evidence.
4. Record material progress with its evidence and name the next owner and trigger. A task created, a command accepted, or a promise to act is not completed progress.

Use --detach for durable long-running work when the host can continue other work; recover by querying Harness state, not by assuming the host will wake a new model when a shell exits. If the host offers a completion event, treat it as a prompt to inspect the record, not as the result itself. Do not add an unbounded polling loop. Keep the task package or its supported progress record sufficient for another CEO turn to resume. Never release another actor's lease or retry a task until you have checked for an existing execution.

The CEO keeps mission ownership, cross-task decisions, semantic acceptance, required review consent, and authorized merge decisions. A Commander can divide and integrate its assigned work. A Worker owns its assigned result and reports evidence, gaps, and challenges. Objections move between adjacent roles with evidence and an alternative; allow a proposal and one clarification to converge, then decide, revise, or record the remaining blocker. Never suppress a credible system-level risk because it came from a lower role.

Accept at three distinct levels

1. Functional review: Does the change match its claim, satisfy required checks, handle errors, and connect to real callers? Delegate independent inspection when useful, then ground-truth material findings.
2. Semantic acceptance: Does the result still serve the user's current goal? Which existing authority already proves part of it, what new responsibility does this change add, and what does the user gain? The CEO owns this judgment. Read the original request or accepted design for each submitted cut; do not accept from memory or a green check alone.
3. Usability acceptance: Can a person or fresh agent with no private session context reach and use the delivered behavior from its real entry point? A module, plan, or isolated test without the caller connected is not a usable result.

For a milestone or a broad change, enumerate the active acceptance claims from their authoritative source. Check omissions as well as changed lines. For moves, removals, migrations, and replacements, inspect both the intended new state and the old path that should disappear. Filter review reports and audit findings against the current source, live task state, and direct repository evidence. If the user raises a semantic doubt, reopen that change and check the same delivery batch for similar omissions.