Start with the loaded copy and the actual records.

Check the actual path returned by the installer and any skipped or failed steps. Confirm the installation scope and target host, then refresh the skill list as the host requires.

If it is still missing, check the host's configuration and supported skill discovery method.

Check each copy's location, source, and version, then explicitly establish which one is loaded for this invocation.

Hosts can have different precedence rules. Do not infer the actual source from project-level or user-level labels alone, or delete a copy before confirming its purpose.

Check that the update targeted the correct skill and scope, then read release.json in the copy actually loaded.

Handle local-path and manually installed copies through their original installation method. Reinstall from the original source and scope if necessary, then verify the complete package. See Installation and updates.

Copy the complete skill directory. The entry may reference rules, templates, scripts, and assets. Missing files can affect execution.

Enter it in an agent chat that supports skills, such as $cohestra design, with the project, goal, and constraints.

npx skills … is an installer command for a terminal. $skill-name … expresses a skill invocation in chat. Other hosts use their own supported invocation methods.

Installation only places skill packages.

Cohestra stage calls and Cadra write entries minimally establish required context when appropriate. If you are continuing a task whose records are missing, resolve that gap rather than replacing recovery with empty initialization.

$cohestra init can establish or reuse context separately. The installer's npx skills init creates a new skill and means something different.

Each invocation handles one stage and stops after delivery.

To continue, attach the stage handoff or original task directory and explicitly invoke the next stage. Use Cadra when several engineering stages should advance automatically within a run.

add only registers a task. ready checks execution conditions. run establishes and executes a new run.

Check requirements, acceptance, completed dependencies, human decisions, the Git workspace, Cohestra contract and role dispatch support, and Python/POSIX file locks. The host must also support child agents with clean context, verified identities, stage dispatch, and execution and tool status queries. Missing capabilities block preflight; the controller cannot substitute its own implementation or self-review.

The new default is implementation. It rejects full / feature / small-change and stage lists containing need/design. If the project has an unfinished run, check its protocol and executor state first. Use append for admitted new tasks at the end of a running Run, without opening a parallel Run.

First check the Run protocol and the original executor, all bound child agents, and their tools. Take over under resume authorization only when all are confirmed stopped. Preserve the state while any are active or their liveness is unknown; elapsed time or a stopped parent agent does not prove child agents stopped. Reconcile the original call and handoffs without redispatching completed stages or resetting budgets.

If the original run has ended, resolve the blocking or failure causes, then explicitly specify task IDs and recovery scope to establish a new run. Edit changed definitions and check readiness again first.

Preserve the original records and confirm the loaded version and project protocol. Cadra 0.8 treats historical 0.6/0.7 Tasks and Runs as read-only; continue unfinished old Runs with a matching older version. Only with no unfinished Run and explicit authorization to upgrade a specified Task may add back it up and upgrade it, followed by a new ready check. Do not migrate old Runs or historical results. A protocol upgrade does not reopen completed tasks; tasks selected for execution must pass admission again.

Do not manually change version fields to make old records appear compatible with a new protocol.

A recommendation explains tradeoffs. Adoption requires an exact candidate version or explicit authorization to choose.

Within an established candidate context, saying “use B” records the selection and proceeds to handoff. To record only the choice, say “do not prepare the handoff yet.” Resolve required decisions and handoff materials before engineering that depends on the design.

Images express and compare static visuals. Interaction, responsive layout, runtime behavior, and accessibility need validation after engineering implementation.

Coverage depends on readable sources and complete evidence. Cloud records, deleted records, and records on other machines may be absent. Vistra artifacts also need references and evidence checks.

Reports retain coverage gaps. Missing time or tokens remain unknown.

Inspect each task's actual outcome and acceptance state.

A completed run has ended, but can include blocked, failed, or unexecuted tasks. Completing a review-only task does not establish engineering acceptance either.