Cadra · Task orchestration skill
Prepare the tasks. Then move them forward in order.
Organize several engineering tasks, check their execution conditions, then call Cohestra serially. Keep a record of each result, interruption point, and outstanding action.
Move prepared tasks forward, one by one.
When several tasks need implementation, define each goal, scope, acceptance criteria, and execution flow first.
Once tasks are ready, establish an execution batch, or run. Cadra calls Cohestra in priority order to advance the permitted engineering stages. Tasks with the same priority are ordered by task ID.
If execution is interrupted, check the existing records before resuming or closing the unfinished run.
From task preparation to run completion.
| Entry | Work | Main deliverable |
|---|---|---|
Add add | Create or revise the goal, scope, acceptance criteria, and flow | Task definition and task ID |
Ready ready | Check inputs, dependencies, decisions, and execution prerequisites | Readiness result and missing inputs |
List list | Inspect tasks, the queue, and runs without making changes | Current status overview |
Run run | Establish a new run and call Cohestra serially | Execution records and results |
Append append | Add an admitted batch of tasks to the end of an active run | Append record and updated queue |
Resume resume | Check the working state, then resume or close an unfinished run | Recovery result and remaining work |
Report report | Generate a run summary and register its link without changing execution results | Run summary and outstanding human actions |
Cadra manages tasks and execution state. Cohestra handles the engineering stages themselves.
For the current protocol, report writes a summary file and registers its link while preserving execution results. Reports for historical 0.6/0.7 Runs are read-only output in chat, with no new files or links.
Give every task a clear definition of done.
Provide the target project, task goal, allowed scope, and acceptance criteria. Attach any existing plan, assets, or implementation candidate.
The default flow, implementation, initially starts at code. Use bugfix for a located defect with established remediation evidence, or review-only to inspect a fixed candidate. Explicit stage lists accept only code, review, fix, and validate. The first item sets the start; the remaining items define allowed scope, not execution order, and the last item does not declare an endpoint. Continuation, recovery, and revisions determine the first action from the legal contract and admission rules.
Prepare requirements, product decisions, and any necessary engineering design outside Cadra through $cohestra need / $cohestra design with human participation. Existing decisions remain valid; small tasks need no fabricated earlier handoffs. A return to need/design during execution blocks the task for preparation with human input.
Execution requires a safely writable project Git workspace, Cohestra supporting the required contract and role dispatch, Python, and POSIX file locks. The host must support child agents with clean context, verified identities, stage dispatch, and execution and tool status queries; missing capabilities block preflight. Complete dependencies and necessary decisions first. An unfinished dependency and its downstream task cannot pass readiness together.
Register one task first.
After installation, enter this in an agent chat that supports skills:
$cadra add
Project: <absolute path to your project>
Task: Search history
Goal: Add search history with up to 20 entries, individual deletion, and clear all.
Input: <absolute paths to confirmed requirements and any necessary engineering design>
Acceptance: History survives restart; deletion and clear all work; existing search behavior is preserved.
Flow: implementationThis call registers the task and returns a stable task ID (slug). If Cohestra already has a task for the same goal, provide its original ID and directory and explicitly continue that task.
After receiving the task ID, use ready to check execution conditions. When they pass, use run and explicitly select the tasks for the new run. These are separate invocations.
implementation starts at code and advances through independent review, necessary fixes and re-review, then validation as actual results require. Explicit stage lists cannot bypass required independent review. Mandatory fixes block review-only rather than expand its scope.
This is an agent-chat example. Replace <…> with actual values.
Inspect each task and the run as a whole.
Task records preserve requirements, acceptance criteria, and readiness results. Run records show each task's actual progress, the deliverables used, and outstanding work.
Run summaries distinguish completed, blocked, failed, and unexecuted tasks, and list necessary human actions. Follow the corresponding Cohestra stage handoffs for engineering details.
Leave a recoverable state when something is missing.
When a human decision or prerequisite is missing, the current task records the blocking reason. The run's stopping policy determines whether the remaining tasks continue or execution ends.
Use resume to take over and reconcile an unfinished run only when its protocol matches and the original executor, all bound child agents, and their tools are confirmed stopped. Preserve the state while any are active or their liveness is unknown; elapsed time does not prove they stopped. Reconcile a fully delivered stage under its original call without dispatching it again or resetting budgets.
For blocked or failed tasks in a completed run, resolve the gaps, explicitly select the tasks and recovery scope, and establish a new run. If definitions change, edit and check readiness again first.
A project can have at most one unfinished run. The controller creates a worker and independent reviewer as each task needs them: the worker handles code/fix/validate, and the reviewer handles review. Prefer reusing each role within its task, never across tasks. Tasks and stages remain serial. Review-only creates no worker; reconciliation without stage calls creates no agents. Cadra has no timer or independent background service.
To add tasks during execution, complete add and ready separately, then append to the specified run:
$cadra append
Run: <running run-id>
Tasks: <ready slug list>Append accepts or rejects the entire batch. New tasks are sorted by priority and slug within that batch and placed at the end. The existing queue stays in order; append does not take over or wake the executor. Resume an interrupted run first; finished runs cannot accept appended tasks.
The current Cadra protocol is 0.8. Historical 0.6/0.7 Tasks and Runs are read-only; continue unfinished old Runs with a matching older installation. Only explicit authorization to upgrade a specified Task, with no unfinished Run in the project, permits add to back up and upgrade that Task, followed by a new ready check. Preserve old Runs and results. Old flow names do not automatically become aliases for new ones. A protocol upgrade does not reopen completed tasks; tasks selected for execution must pass admission again.
After a run ends, inspect every task's result and acceptance state.
Start with one well-prepared task.
Write down the goal and completion conditions, register the task, then check whether it can execute. For batch execution, place ready tasks in the same run.
Requirements still need clarification?