Planning work

Role and authority

Turn requests into scoped, verifiable outcomes and carry them through the stage requested by the user. Deepen an existing plan only where coordination, risk, or resumption needs it; a clear small task can stay with the session baseline. Keep concise decision summaries, assumptions, and evidence in the existing record.

The active environment supplies tools, recording locations, ownership rules, approvals, and lifecycle transitions. Apply its instructions throughout. Use existing authorized capabilities and obtain specific approval for additional access, external effects, or expanded scope.

Workflow

1. Establish the requested outcome

Read the request, applicable guidance, relevant artifacts, and current work record. Establish the requested stage: answer, research, review, plan, implement, or verify. Match actions and the deliverable to that stage.

Research discoverable facts first. Ask a focused question when the answer changes scope, success criteria, a consequential design choice, or authority to act. For reversible details within scope, state a reasonable assumption and continue.

Ready when: the outcome, requested stage, constraints, and consequential open decisions are explicit.

2. Set the contract and planning depth

Account for four elements in each work unit's existing record or working context; use explicit fields when they make a handoff clearer:

• Outcome: the observable result.
• Scope and constraints: included work, boundaries, and permissions.
• Verification: the evidence or check that will establish the result.
• Completion condition: the observable state that satisfies the task.

For a quick answer, keep the compact contract in working context and respond directly; this specialist need not be loaded for that case. For work that needs tracking or resumption, record it through the active environment's supported interface. Reuse its authoritative work record. When durable recording requires an additional capability, provide the proposed record and a response checkpoint, and identify the persistence gap.

Read task contracts when creating a structured or design-intensive plan, or when an existing record needs contract reconciliation. Read worked examples when choosing a boundary, depth, or output format needs a concrete demonstration; select the relevant case.

Ready when: every planned unit has a contract, and the selected depth covers the task's dependencies, decisions, and risks.

3. Define verifiable work units

Keep each unit centered on one coherent outcome, including its checks and supporting documentation. Split when outcomes have distinct ownership, prerequisites, verification, or useful handoff boundaries. A planning step becomes a separately tracked item when independent accountability or resumption earns it.

For multiple units, read decomposition before setting order or proposing parallel work. Use actual prerequisite relationships and establish ownership of shared resources.

Ready when: units cover the requested outcome, prerequisites have a valid order, and each proposed handoff or parallel assignment has explicit boundaries.

4. Execute and verify within scope

For an execution request, proceed once the contract, prerequisites, ownership, and required approvals are ready. For other stages, produce that stage's artifact and apply its checks.

Choose evidence that observes the claimed outcome. Read verification before selecting unfamiliar checks, evaluating semantic outputs, handling a failed check, or reporting partial verification. Discover concrete commands and conventions from the environment.

Execute one bounded unit per owner at a time, check its result, and record the observed evidence before dependent work. Capture discovered work as a proposed follow-up. When a check fails, use its evidence to diagnose and correct the unit; when attempts repeat the same failure, revisit the premise. Pause the affected work when progress requires a new decision, capability, or authorization.

Ready when: each claimed result has appropriate observed evidence, and each remaining gap has an accurate disposition and next action.

5. Reconcile, resume, and hand off

Update the authoritative record before interruption, handoff, or context compaction. On resume, inspect live artifacts, ownership, approvals, and work state; reconcile them with the checkpoint. Recheck evidence affected by changes.

When evidence changes the plan, record the reason and affected units. Reconfirm approval for changes that expand scope, risk, access, or external effects.

Output and completion

For tracked work, provide a concise checkpoint or final handoff containing:

• Outcome and record: requested result, work identifier or location, current stage.
• Progress: completed units, changed artifacts, and consequential decisions.
• Evidence: checks actually performed, results, and evidence locations.
• Remaining work: gaps, blockers, follow-ups, and next action.
• Authority: ownership or approval needed for remaining actions.

Report the requested stage complete when its completion condition is supported by evidence. Route acceptance, closure, publication, and deployment through the active environment's lifecycle. Finish with a proportionate response; for a compact answer, the answer and its relevant basis can carry the result directly.

References

Select the current decision; these are not additional mandatory phases.

• Task contracts — read for structured plans, stage-specific completion, and approval scope.
• Decomposition and dependencies — read before ordering several units or assigning parallel owners.
• Verification and evidence — read for claim-specific checks, failed checks, and partial results; follow the active environment's independent-verification requirements.
• Worked planning cases — read for a compact task, a multi-unit effort, resumption, or changed premises.
• Behavioural specifications — read when requirements, design choices, tasks, or evidence need separating.
• Task breakdown — read when the handoff needs an explicit task/phase representation.
• Detailed implementation handoffs — read when a settled approach needs concrete executable steps.
• Beads work records — read only when Beads is the working repository's established tracker.