GEODE Workflow

Use this skill as GEODE's default execution scaffold. It replaces the older issue-first workflow with an evidence-first loop: inspect existing code, ground external contracts, define the observable surface, implement narrowly, verify, then report honestly.

Core Loop

Follow the canonical workflow and its execution scope. Produce the requested reviewable result; load only the references relevant to the task. For abstraction, naming, type/class, schema, test, site, or version decisions, use $geode-code-conventions.

Reference Routing

Read only the reference needed for the current task:

Need	Read
Phase-by-phase checklist for ordinary code work	references/phase-checklist.md
Abstraction, naming, type/class, schema, test, site, and version conventions	$geode-code-conventions (follow its task-specific SOT routing)
Provider/model/API capability claims	references/provider-grounding.md
Schema/log/event/state/trajectory consistency	references/observability-contract.md
Usage/cache fields, estimates versus billing, incomplete accounting	Usage accounting contract
Same-task Codex–GEODE production and comparison	references/codex-geode-paired-coding.md
Test, lint, type, prompt, full-suite reporting, or failure-to-rule review	references/verification-gates.md
Branch, PR, merge, and cleanup operations	references/gitflow.md

For simple docs or trivial bug fixes, use the core loop and skip references that do not affect the task.

Non-Negotiables

• Do not switch branches inside an active worktree.
• Do not revert unrelated dirty work.
• Architecture/extensibility implementation work starts only after a roadmap-only claim PR moves the package from READY to IN_PROGRESS on canonical develop and names its owner/implementation branch. Claim and reconciliation PRs establish that prerequisite; they do not require an earlier claim. The implementation PR preserves the claimed status and never predicts IN_DEVELOP or DONE.
• Register architecture scope discovered during implementation through a separate roadmap-only GAP-registration PR. Registration may add an OPEN package without a prior claim, but does not authorize implementing it.
• Within the architecture/extensibility program, use origin/main only for a tracking-only roadmap DONE worktree after release. Its PR targets main, carries no implementation code. The next owned feature branch incorporates the resulting main history before CI and integration; no standalone sync PR.
• Do not mark unsupported provider behaviour as supported without grounding.
• Do not add ad hoc observability strings when the capability/evidence vocabulary should be extended.
• Do not log raw screenshots, base64 blobs, API keys, tokens, passwords, or secret fragments.
• Do not imply a full-suite pass if only targeted checks ran.

Output Contract

When finishing, include:

• implementation summary
• key files changed
• verification commands and results
• known failures, skipped gates, or live-test uncertainty
• GitFlow state if any branch/PR/merge action was requested