skills

ori — my Claude Code marketplace

Documentation →

ori is my personal Claude Code plugin marketplace (served from this repo), so my tooling is available everywhere — including Claude Code on the web/phone (cloud sessions install declared plugins at session start). It hosts two plugins:

Plugin	Install id	What it is
skills	skills@ori	13 reusable methodology skills (docs, process, QA, design).
cookbook	cookbook@ori	Recipe system: install versioned doc-based engineering-process packages into any repo, update via a lock + 3-way merge, check conformance with doctors.

Use it in a repo (and from the phone)

Add to the repo's committed .claude/settings.json:

{
  "extraKnownMarketplaces": {
    "ori": { "source": { "source": "github", "repo": "dotts-h/claude-skills" } }
  },
  "enabledPlugins": {
    "skills@ori": true,
    "cookbook@ori": true
  }
}

enabledPlugins is an object keyed by plugin-id@marketplace-id with boolean values — the array form (["skills@ori", ...]) is silently ignored by the settings schema, so the plugins never enable.

Commit + push. Any cloud session for that repo installs the plugins automatically at session start (GitHub is in the default network allowlist), provided this marketplace repo is public — the cloud container clones the marketplace source directly from github.com without credentials. Locally you can also add them interactively:

/plugin marketplace add dotts-h/claude-skills
/plugin install skills@ori
/plugin install cookbook@ori

The skills plugin

13 methodology skills, bundled:

Group	Skills
Docs	recording-decisions · registering-contracts · maintaining-conventions · logging-learnings · mapping-codebases
Process	practicing-tdd · managing-tech-debt · improving-architecture · auditing-code-quality
QA	hardening-tests · authoring-tests · exploring-quality
Design	designing-ui-ux

The cookbook plugin

Installable, versioned, doc-based engineering process packages. A recipe turns a hard-won process (a constitution, quality gates, an issue store, a dev loop, a release ritual, a contracts registry) into something you install into a repo, keep updated, and conformance-check — the way a package manager treats code.

thing	lives where	lifetime	who benefits
plugin / skill	the agent host	per-session context; leaves no trace in the repo	the agent that loaded it
recipe	the target repo (docs, scripts, CI, .recipes/lock.json)	durable state, versioned + updatable	any agent (or human) that opens the repo, on any host

Skills here are the operators; recipes are the payload. A repo that adopted recipes works with no plugin installed at all — the docs and scripts are just there, host-agnostic (both CLAUDE.md and AGENTS.md thin pointers).

Quickstart

# In the repo you want to bring under management (with cookbook@ori enabled)
/adopt-recipes

adopt-recipes inventories the repo, proposes a profile + tier + answers, confirms with you, installs in dependency order (harvesting existing docs on brownfield — never clobbering), writes .recipes/lock.json, and reports gaps. Later: /update-recipes (semantic 3-way merge to new versions, via PR) and /recipe-doctor (aggregate conformance report).

Without the plugin, everything is runnable by hand:

make evals                       # run all recipe evals (fixture repos in mktemp)
make lint                        # bash -n all scripts + secret/date scans
make doctor TARGET=/path/to/repo # aggregate doctors against a repo
plugins/cookbook/scripts/install-recipe.sh \
  --recipe plugins/cookbook/recipes/core --target /path/to/repo --tier M

Catalog

recipe	layer	what it installs
core	0	CLAUDE.md + AGENTS.md thin pointers, CONVENTIONS constitution (doctrine), CONTEXT glossary; ADR log (M+); CODEMAP/RETROS/TECH_DEBT (L)
quality	1	single-run CI (make/npm flavors) with docs-only paths-ignore skip, the self-enforcing workflow guard, coverage-floor parameter, opt-in fuzz-smoke workflow, REGRESSIONS register (M+)
loop	1	the dev loop playbook + start-fresh.sh (verified base) + next-issue.sh (dependency-aware picker)
issues	1	hybrid issue store: markdown source of truth + GitHub mirror; INDEX + frontmatter format; epics via group:
release	1	tag-driven release workflow with verified version resolution; SemVer + verify-after playbook
contracts	1	CONTRACTS registry with Provides/Consumes; fleet constellation.yaml + fleet-doctor.sh cross-check