Cohestra · Engineering collaboration skill
From requirements to acceptance, one stage at a time.
Define the goal, organize implementation, and check the result for one engineering task. Start from its current state. Each invocation handles one stage and records conclusions, evidence, and what comes next.
Continue from where the work stands.
If the idea is still unclear, define the goal, scope, and acceptance criteria first.
If the requirements are settled, prepare the approach, implementation steps, and validation methods.
If an implementation already exists, start with review, fixes, or acceptance validation.
You can start at any stage. Existing materials remain valid; missing prerequisites are identified in the current call.
What should this stage deliver?
| Stage | Work | Main deliverable |
|---|---|---|
Requirements need | Investigate the current state; clarify goals, scope, and acceptance criteria | Requirements, valid decisions, and open questions |
Design design | Compare approaches; plan implementation and validation | Design, execution plan, and validation methods |
Implementation code | Implement clear requirements or a valid design | Implementation candidate, change summary, and validation record |
Review review | Inspect a fixed candidate; identify issues and impact | Findings, evidence, and recommendations |
Fix fix | Assess review findings and make the necessary corrections | Fix results and follow-up review needs |
Validation validate | Check acceptance criteria and gather missing evidence | Acceptance conclusion, evidence, and remaining gaps |
Choose stages to suit the task. A call stops after delivering its current stage.
Three supporting entries are also available:
- Initialize
init: establish or reuse project collaboration context. - Drift check
verify: check whether a stage's output diverges from its upstream basis. - Project overview
report: inspect task status, outstanding work, and anomalies without writing files.
Bring the goal and the decisions already made.
Identify the target project, the problem to solve, and the changes allowed in this call.
Attach existing requirements, designs, or stage handoffs. For review and validation, also provide a fixed implementation candidate and its acceptance basis.
State constraints such as preserving behavior, planning without implementation, or reviewing without changes.
Work out the approach first.
After installation, enter this in an agent chat that supports skills:
$cohestra design
Project: <absolute path to your project>
Requirement: Add search history with up to 20 entries, individual deletion, and clear all.
Constraints: Preserve existing search behavior. This call is for planning only.Cohestra uses the project's current state and rules to produce a design with implementation steps, validation methods, and open questions.
It stops after the handoff. To continue, attach that handoff or the original task directory and invoke the next stage.
This is an agent-chat example. Replace <…> with actual values.
Keep the result and its basis together.
Each stage handoff records its inputs, decisions that remain valid, results, evidence, limitations, and materials needed next.
Reference the original task directory or stage handoff when continuing, so later work can use the established context.
Requirements, designs, or acceptance notes that need long-term sharing go into the project's formal documentation, following its rules.
State exactly what has been completed.
Implementation completion, review completion, and acceptance are separate states. Validation conclusions apply to the candidate, environment, and scope actually checked. Unverified areas remain explicit gaps.
Review follows applicable risks through actual callers, assembly, state changes, and lifecycle paths. Bind evidence to a fixed candidate, including necessary unchanged dependencies. Fill coverage gaps within existing authorization first; report blocked if required paths cannot be verified. Zero findings do not prove coverage is complete. Validation checks coverage against the final candidate and returns to review or records a blocker when required re-review is missing.
Under Cadra, the worker handles code/fix/validate and an independent reviewer handles review. Implementation and fixes both require independent review or re-review. The stage executor records its actual identity and orchestration source, publishes the stage handoff and index, then stops for Cadra to dispatch the next stage. Standalone Cohestra defaults to one agent and does not automatically delegate to other agents.
The risk coverage table and optional orchestration source do not change Cohestra contract 0.8. Their absence from old handoffs does not make the contract invalid. Verify required review through actual evidence and fill gaps in a new round, without rewriting old handoffs or inventing identities.
You define where each call ends. Product decisions that need your input are listed. A stage handoff does not automatically trigger a commit or release.
Start with the stage you need now.
Clarify requirements first, or review an existing implementation directly. Bring the project and inputs, and ask Cohestra to handle the stage you specify.
Several tasks need to move forward in sequence?