A curated, provider-neutral OpenCode workflow: plan → build → review, with research and review subagents, project setup, git discipline, and data/geo/frontend guidance. It is a standalone snapshot of a larger private configuration — intentionally smaller, self-contained, and not kept in sync automatically.
This repository is a skill case and portfolio snapshot, not an actively maintained product. It demonstrates workflow and skill design. There is no roadmap and no active feature development beyond deliberate snapshot updates.
Only OpenCode is supported. Claude Code, Codex, and other agents are out of scope.
- Plan + Build primary agents with a strict plan-lock and stop-authority execution model.
- Seven subagents: deep planning, research, external research, plan checking, contract review, integration review, and public-web research — each with a read-only evidence-probe permission contract.
- Core controls: evidence-first research protocol, review protocol with a severity model, behavioral test-quality checks.
- Project delivery:
/git(conventional commits, profiles, secrets scan) and/setup(workflow configuration, project bootstrap, optional compact project contract). - Domain packs:
data-work(source/purpose/grain, schema invariants, reproducible transforms, independent validation) andgeospatial(CRS, units, geometry/raster validity, Nodata, alignment, provenance). - Frontend guidance: a reduced
frontend-designskill with anti-pattern constraints, accessibility, and visual QA.
- Not a provider or model bundle. No provider names, model IDs, credentials, or API configuration ship in this repository. You configure your own provider once via OpenCode's
/connect. - Not a personal setup. No planning-service bindings, session databases, personal paths, or private workflow references.
- Not continuously updated. This is an independent snapshot. It does not auto-sync and no upstream feeds it.
opencode-workflow-kit/
├── AGENTS.md # runtime agent rules
├── opencode.json # provider-neutral agent wiring (no models, no providers)
├── prompts/
│ ├── build.md # manual implementation agent prompt
│ └── plan.md # manual planning agent prompt
├── agents/ # 7 review and research subagents
├── commands/
│ ├── git.md # /git — repo-aware git workflow
│ └── setup.md # /setup — workflow config and project bootstrap
├── skills/
│ ├── research-protocol/ # evidence-first research behavior
│ ├── review-protocol/ # shared review standard (with security/simplify/thermo refs)
│ ├── test-quality/ # behavioral test review
│ ├── git-workflow/ # commit/branch/PR/release workflows (with bootstrap/release refs)
│ ├── python-devops-stack/# uv/ruff/pyright/pytest/nox toolchain reference
│ ├── setup/ # provider-neutral setup skill with embedded project file recipes
│ ├── project-contract/ # compact opt-in technical contract + structural checker
│ ├── data-work/ # data methodology contract + tool catalogs
│ ├── geospatial/ # spatial guardrails + specialized references
│ └── frontend-design/ # reduced design guidance + anti-patterns + QA checklist
├── scripts/
│ └── validate_public_config.py # config, reference, and privacy validation
├── tests/ # stdlib unit tests for validator and contract checker
├── .github/ # issue templates + validation CI
├── LICENSE # MIT
├── SECURITY.md # vulnerability reporting policy
└── install.sh # safe release installer
OpenCode with your own provider configured. This repository contains no provider or model settings; set your default model in your own opencode.json.
Download and inspect the installer, then run it:
curl -fsSL https://raw.githubusercontent.com/spignotti/opencode-workflow-kit/v1.0.2/install.sh > install.sh
less install.sh # review before executing
bash install.shThe default target is ./opencode-workflow-kit/. To install elsewhere:
bash install.sh /path/to/targetRequirements: curl and tar. The installer never overwrites an existing directory.
Copy the files into your OpenCode config directories and adapt them to your setup.
- Find your OpenCode global config directory (see opencode.ai/docs/config for the platform-specific location, e.g.
$HOME/.config/opencode/on macOS and Linux). Set it in the commands below:
export OPENCODE_CONFIG_DIR="$HOME/.config/opencode" # adjust to your platform
mkdir -p "$OPENCODE_CONFIG_DIR"- Copy the kit trees without overwriting any existing file:
cp -Rn agents commands skills prompts "$OPENCODE_CONFIG_DIR/"-
Merge
opencode.jsonandAGENTS.mdby hand. Do not copy them over your existing files — OpenCode deep-merges config from multiple sources, so:- Open your existing
$OPENCODE_CONFIG_DIR/opencode.json, add any kit sections you want (agents, permissions), and keep your own keys.{file:./prompts/...}references only resolve if the prompts live in the same directory as the config, so either copyprompts/next to it or inline the prompt text. - Open your existing
$OPENCODE_CONFIG_DIR/AGENTS.md, add the kit's rules that are missing, and keep your own sections.
- Open your existing
export PROJECT="/path/to/your/project" # adjust to your project
mkdir -p "$PROJECT/.opencode/commands" "$PROJECT/.opencode/skills"
cp -Rn agents prompts "$PROJECT/.opencode/"
cp commands/git.md commands/setup.md "$PROJECT/.opencode/commands/"
cp -Rn skills/* "$PROJECT/.opencode/skills/"Then merge AGENTS.md and opencode.json into the project root as above: keep existing content, add the kit's missing sections by hand.
- Connect a provider: run
/connectin OpenCode and authenticate your provider of choice. Credentials are stored by OpenCode; nothing here reads or writes them. - Run
/setupto configure the workflow or bootstrap a project:- Workflow mode: verifies your config layout and points you at
/connect. It never writes provider or model settings. - Project mode: detects new vs. existing repos, gathers purpose and delivery profile, previews all changes, and requires confirmation before writing a project-local
AGENTS.md. - Python route (optional): normalized bootstrap with
uv, Ruff, pytest, and profile-gated Pyright/Nox. - Project contract (opt-in): a compact, Git-versioned technical contract with a structural checker. Never automatic.
- Workflow mode: verifies your config layout and points you at
- Plan: switch to the
planagent for scoping, research, and executable plans. - Build: switch to
buildto execute approved plans with stop authority and review gates. - Review: planned work is reviewed by the review subagents; integration boundaries get an adversarial integration review.
- Git:
/git commit,/git feature <desc>,/git pr,/git shiproute through thegit-workflowskill using the project's delivery profile.
- data-work — process contract for every data task: source/purpose/grain, schema invariants, reproducible transforms, independent validation, uncertainty disclosure. Includes curated tool catalogs for engineering, science, and synthetic test data.
- geospatial — base guardrails (CRS, units, geometry/raster validity, Nodata, alignment, provenance) plus specialized references: remote sensing, spatial statistics, spatial features, spatial validation, DL on EO, spatial databases, geocoding, urban morphology, data sources, MCP servers.
- frontend-design — surface-type thinking, aesthetic direction, accessibility, anti-pattern constraints against generic UI output, and a visual QA checklist.
From the repository root:
python3 scripts/validate_public_config.py # config, reference, privacy checks
python3 -m unittest discover -s tests # unit testsCI (.github/workflows/validate.yml) runs the validator, the unit tests, and a secret scan on every push.
This repository is an independent snapshot. It is updated deliberately, not continuously. It is not an active product:
- Content is curated from a private source configuration; there is no automated sync between the two.
- Only generic, provider-neutral pieces are considered. Personal runtime, model strategy, plugins, private skills, paths, and infrastructure stay out.
- Additions follow the same review standards as any other change: validation, unit tests, and review before merge.
- MIT licensed — fork and adapt freely.
MIT. See LICENSE.