Godmode

One plugin for Claude Code and Codex: nine coding workflow skills and ten no-auth MCP servers, written once and emitted for both engines by a single build that CI checks byte for byte.

Browser captures of the page at 1280x800 and 390x844. GitHub shows the light or the dark one to match your theme; the site itself follows your system setting and has a toggle.

Try it

Live site with the full catalog: https://patrickking67.github.io/godmode/

# Claude Code
claude plugin marketplace add patrickking67/godmode
claude plugin install godmode@godmode

# Codex
codex plugin marketplace add patrickking67/godmode
codex plugin add godmode@godmode

In Claude Code, run a workflow as /godmode:revelation. In Codex, name it in your prompt: godmode:revelation. Inside either app the same install is /plugin marketplace add patrickking67/godmode then /plugin install godmode@godmode.

What is technically interesting here

• One source, three outputs. Workflows, subagents, hooks and servers are defined once in src/plugin/_sources/. scripts/build-plugin.ts emits the Claude Code manifest, the Codex manifest, the shared skills and the site's catalog from them. Golden-output tests pin each emitter: tests/plugin/emitters.test.ts.
• Generated output is committed and proven current. Both engines install plugin/ straight from the repository, so it has to be in git. CI rebuilds and fails on any diff, and tests/plugin/packaging.test.ts does the same comparison locally, as bytes, including the icons.
• Engine differences live in the emitter, not in the workflows. A source marked invocation: manual becomes disable-model-invocation: true for Claude Code and an agents/openai.yaml policy file for Codex. The commit workflow uses it so neither engine commits on its own initiative.
• Skills are linted like code. tests/plugin/skills.test.ts requires a trigger in every description, four fixed sections, numbered steps, and no reference to a workflow, subagent or server that does not ship. It also rejects a skill that pre-approves a bare shell or edit tool.
• Names are treated as untrusted input. A workflow name becomes a path, a TOML key and a shell word. The build rejects anything that is not kebab-case before writing a file, and shell-quotes arguments in the generated Codex script: see validateSourceNames and shQuote.
• Claims are tested. tests/catalog.test.ts fails if the README, the docs, the site or a manifest lists a different server or states a different count than the sources produce. scripts/check-claims.mjs does the same for the test count in the badge above.

Architecture

flowchart LR
  subgraph SRC["src/plugin/_sources (edited by hand)"]
    C["commands/*.md<br/>9 workflows"]
    A["agents/*.md, hooks/<br/>5 subagents, 3 hooks"]
    M["mcps.ts<br/>10 servers"]
    I["manifest.ts, assets/"]
  end
  B{{"build-plugin.ts<br/>name and schema checks"}}
  C --> B
  A --> B
  M --> B
  I --> B
  B -->|"Claude manifest"| CL[".claude-plugin/plugin.json"]
  B -->|"Codex manifest"| CX[".codex-plugin/plugin.json"]
  B -->|"one shared copy"| SK["skills/, .mcp.json"]
  B -->|"catalog"| SD["site/data/godmode.json"]
  CL --> CC(["Claude Code"])
  SK --> CC
  SK --> CO(["Codex"])
  CX --> CO
  SD --> PG(["Pages site"])
  CI["CI: rebuild, git diff, tests"] -.->|"fails on drift"| B

Both engines scan skills/, and both also read a plugin's commands/ folder, so a workflow emitted to both would register twice. The build writes each workflow once. Deeper diagrams, including the build's validation order and the manual-invocation fan-out, are in docs/architecture.md.

What ships

Surface	Count	Engines	Generated at
Workflow skills	9	Claude Code, Codex	plugin/skills/<name>/SKILL.md
MCP servers	10	Claude Code, Codex	plugin/.mcp.json
Subagents	5	Claude Code	plugin/agents/<name>.md
Hooks	3	Claude Code	plugin/hooks/hooks.json + scripts

Workflows

Each skill has the same shape: when to use it, a numbered procedure, stop conditions, and a verification step.

This is the beginning of the README. Read the rest at the original. Read the full README ↗