# Adopt planning, parallel sessions and headless workflows

Read the [complete reference](https://hamedtaheri.com/playbook/v0.1.0/reference/workflows.md) before using these patterns. The scripts described there belong to the author's implementation and are not shipped in this kit; the person can request a copy from the author (see [start.md](https://hamedtaheri.com/playbook/v0.1.0/agent/start.md)). Do not invent an installed command or silently launch a paid run.

## Assess and prepare

1. Inspect actual project instructions, accepted goal, current source, permissions, available tools and provider login. Confirm whether this is planning, setup or execution.
2. Use design/planning skills where available to resolve the specification before implementation. Produce a spec with behavior, exact interfaces, non-goals, invariants and acceptance; then an [implementation plan](https://hamedtaheri.com/playbook/v0.1.0/templates/implementation-plan.md) with files, dependencies, verification and review points.
3. Select coherent deliverables. Isolate checkouts and test resources. Order shared-schema and interface changes; do not equate several tiny commits with several shipped features.

## Choose execution

- Interactive lanes: suitable for discovery and changing constraints. Assign one task and owner per session, explicit worktree, revision and stop rules. Send [focused messages](https://hamedtaheri.com/playbook/v0.1.0/templates/session-message.md) only when authorized, then retain accepted state in tasks/decisions/handoffs.
- Scripted lanes: suitable for ready bounded tasks. Inspect installed runner source, CLI version, configuration and the command's actual side effects. Produce a dry-run plan first. Encode approved constraints in the worker card/brief before reducing context discovery.

## Run and review

Verify the spec's current-content gate, environment and ownership. Use a versioned claim if the backend offers one (Personize supports `expectedVersion`); the reference queue's write/wait/re-read does not prove exclusivity across coordinators, so run one coordinator at a time with it. Budget preparation, worker, coordinator, internal/external reviews and repairs. Cap checks between stages and timeouts are not live spending guarantees.

Record provider, harness, auth mode, model, attempt, revision, token counters and pricing source/date. Keep actual charges, API-equivalent valuation and subscription quota separate. Codex can resume at the product level, but this ephemeral runner adapter does not implement recovery resume.

Validate acceptance with real commands and relevant environments. Review the exact head revision. Do not interpret `MERGE`, `ready_for_gate` or a clean external review as release authority. Escalate missing specs, environments, unknown spend and unresolved decisions. Use bounded fixes; repeated findings in the same area may need a new design.

## Close or hand off

Retain revision, acceptance, failed and passed checks, reports, cost completeness, owner, human question and exact resume step. Report a failed board write as NOT saved. Keep raw transcripts, keys and private identifiers out of public contributions. Offer only an explicitly requested, redacted learning report through the contribution process.