| name | geode-workflow |
| description | GEODE evidence-first development workflow. Use for feature work, provider/model changes, GUI/computer-use work, PDF/document ingestion, observability/schema/event/state changes, verification planning, GitFlow merge prep, and requests to "follow the workflow" or "scaffold the process". |
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, and is followed by a CI-gated
main -> develop sync.
- 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
