develop

Outcome Engineering Plugin Marketplace

A combined Codex and Claude Code plugin marketplace for Outcome Engineering — the product engineering paradigm where a durable map of your product, maintained as a Spec Tree, serves as the authoritative source of truth for all implementation.

This repository publishes two plugin surfaces from the same source tree:

• .claude-plugin packages for Claude Code plugins, commands, and agents
• .codex-plugin packages for Codex skill bundles

AGENTS.md is a symlink to CLAUDE.md, so Codex and Claude Code read the same repo-level instructions.

/bootstrap interviews you about your product, then scaffolds a spec tree — the durable map that drives all implementation.

Philosophy

1. RTFM: Follow state-of-the-art (SOTA) model prompting guidance, such as structured prompts based on XML tags
2. KILO: Keep It Local and Observable — the golden source for all specifications lives locally within the product's Git repository
3. ABC: Always Be Converging — the spec tree is the desired state; all activities are driven by it, not the other way around
4. DCI: Deterministic Context Injection — the spec tree constructs a deterministic context injection plan for the model

Quick Start

1. Install the spx CLI

npm install -g @outcomeeng/spx

The spx CLI is the developer tool for Spec Tree maintenance and validation. Required by all engineering plugins.

2. Add the marketplace

Claude Code

claude plugin marketplace add outcomeeng/plugins

Codex

codex plugin marketplace add outcomeeng/plugins

Codex registers the marketplace source in the user's ~/.codex/config.toml and reads the shared .codex-plugin bundles from it.

3. Install or use plugins

Claude Code

# Spec Tree methodology (requires spx CLI)
claude plugin install spec-tree@outcomeeng

# Language plugins (install per product, require spx CLI)
claude plugin install python@outcomeeng
claude plugin install typescript@outcomeeng

# Optional plugins
claude plugin install prose@outcomeeng
claude plugin install develop@outcomeeng

Codex

After adding the marketplace, enable only the plugins a product needs in that repo's committed .codex/config.toml:

[plugins."spec-tree@outcomeeng"]
enabled = true

[plugins."develop@outcomeeng"]
enabled = true

Add language plugins in projects that use them:

[plugins."python@outcomeeng"]
enabled = true

[plugins."typescript@outcomeeng"]
enabled = true

Add domain plugins the same way:

[plugins."frontend@outcomeeng"]
enabled = true

[plugins."visual@outcomeeng"]
enabled = true

[plugins."hdl@outcomeeng"]
enabled = true

4. Bootstrap your spec tree

> /bootstrap                       # set up a new spec tree

5. Author, implement, commit

> /author outcome for search       # author a new outcome node
> /author PDR for auth policy      # author a product decision
> /author ADR for caching strategy # author an architecture decision
> /apply                         # start the TDD flow
> /commit                          # commit with Conventional Commits

See the full tutorial for the complete workflow — from bootstrapping to handoffs.

Updating plugins

Claude Code

claude plugin marketplace update outcomeeng

Codex

codex plugin marketplace upgrade outcomeeng

From this checkout, just push-marketplace wraps the Codex upgrade with cache path preservation so active sessions with stale skill paths keep resolving for seven days.

Bumping plugin versions on a branch

When working on the marketplace itself, every branch that changes a plugin's distribution surface bumps that plugin's version exactly once. The just bump recipe automates this — it detects which plugins changed under src/plugins/<name>/** since origin/main, classifies each plugin's change pattern into a semver segment, and updates the version field in every manifest each plugin owns (.claude-plugin/plugin.json and, when present, .codex-plugin/plugin.json) in lockstep:

just bump                          # auto-detect segment per plugin vs origin/main
just bump-dry                      # preview without writing
just bump-check                    # CI gate: exit non-zero if any changed plugin needs a bump
just bump origin/main minor        # force minor for every changed plugin (warns on disagreements)
just bump main major               # major bump vs local main (must be explicit)