Resolves conflicts against the harness build-on-demand refactor (#321),
the develop/main deploy split (#317), and the flowmark reformat (#315/#316):
- harnesses/index.ts: register the two OpenCode harnesses inside
buildHarnesses() and drop their module-level constants, matching the
single-construction-path refactor
- deploy-plugins.yml: keep main's develop/main branch semantics with the
job counts updated for six plugin repos
- AGENTS.md / READMEs: fold the OpenCode V1/V2 mentions into main's
reflowed prose
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The plugins had no releases to speak of: one hand-edited version copied
across four manifests, no tags in any distribution repo, and every merge
rewriting each repo's main. Nothing separated "merged" from "shipped",
and no ref named a version anyone could pin or roll back to.
src/plugins/version.json is now the one version, stamped over the 0.0.0
placeholder in each manifest at build time, so the four plugins move in
lockstep from a single bump.
Deploys land on develop instead, leaving main to advance only when the
Release plugins workflow cuts a version -- which tags this repo
plugin/v<version> and each distribution repo v<version>. Consumers all
resolve main today, so this is what makes shipping deliberate rather
than a side effect of merging.
Develop builds carry their distance from the last tag
(1.2.1-dev.14.gdeadbee). The patch bump is load-bearing: semver ranks a
prerelease below its release, so 1.2.0-dev.14 would compare older than
the 1.2.0 it is fourteen commits ahead of, and build metadata is ignored
in comparisons entirely.
Relocate all buildable source -- skills/, references/, plugin-src/, and
SKILL_TREE.md -- under a single src/ tree so the repo root cleanly separates
source from the frozen skills-legacy/ wizards, the installer package, assets,
and docs. plugin-src/ becomes src/plugins/.
The per-agent build scripts now resolve their content root at $REPO_ROOT/src,
build-skill-tree.sh scans src/skills and writes src/SKILL_TREE.md, and the
deploy and skill-drift workflows point at the new paths. references.yml
manifests are unchanged -- their paths are relative to the references root the
build passes in.
The /seer command only wrapped what users can already do by asking the agent
natural-language questions directly against the Sentry MCP server, so it earned
its own maintenance surface (a command file, build wiring, and docs) for no real
capability. Remove the command along with the commands/ build plumbing
(copy_commands, per-agent build.sh calls, the deploy-plugins path trigger) and
every /seer reference across the READMEs, AGENTS.md, TELEMETRY.md, plugin
manifests, and concept docs.
This repository is the single source of truth for skills and routing metadata,
but it is not itself an installable plugin, and each assistant (Claude Code,
Cursor, Codex, Grok) expects the plugin in a different on-disk shape. No plugin
ecosystem can consume a zip or release asset; all install from a git ref. So a
GitHub Actions workflow builds each agent's distribution from this repository
and deploys it to a dedicated repository whose root is exactly that agent's
plugin, which a marketplace points at as getsentry/plugin-<agent>.
Each agent has a `plugin-src/<agent>/` dir with its manifests, README, and a
`build.sh` that assembles the dist tree from shared repo content. Claude, Cursor,
and Grok consume the plugin at the repo root; Codex requires it under
`plugins/sentry/` and rejects the `disable-model-invocation` field the skill
tree relies on, so its build strips that field and emits a per-skill
`agents/openai.yaml` (see `hide-skills.py`). MCP config is built from the repo's
`mcp.json` source of truth: inline in Claude's manifest, and a file for the
others.
Cross-repo writes use a short-lived token from a dedicated GitHub App scoped to
contents:write on the plugin repos; the default GITHUB_TOKEN cannot push to
other repositories.
The root `.claude-plugin/`, `.cursor-plugin/`, and `.mcp.json` are retained so
existing installs that consumed the plugin from this repo's root keep working;
their READMEs announce removal on or after 2026-07-11.
Sergiy Dybskiy