oscaner-skills

English | 中文

A cdd-first methodology: continuously-discovered development as the core discipline, AI coding skills as the distribution vehicle.

This repository is the home of that methodology and the vehicle that distributes it. The core discipline — cdd, continuously-discovered development — is encoded as skills and released as installable plugins, consumable across multiple AI coding harnesses (verified on Claude Code and Cursor Agent). First-party plugins are built here under packages/ and published to npm under the @oscaner-skills/* scope; the cdd engine drives the whole flow.

The cdd philosophy

cdd (continuously-discovered development) is a development discipline that treats planning as an ongoing discovery process instead of a front-loaded artifact. Requirements are discovered by working in small, verifiable increments: each task is planned against the plan, executed against a task brief by the host harness CLI, and reviewed against shared convergence rules — so the next increment is always planned from what the previous one actually learned.

Instead of writing the plan once and hoping it survives contact with reality, cdd keeps planning live across the whole development process and makes every step provable ("did it converge?") rather than assumed ("it should be fine").

Why cdd is designed this way

• Discover, don't predict. Requirements are discovered through implementation and review, not guessed up front. Every round's review findings become the input to the next round's brief — no requirement is taken on faith.
• Small, verifiable increments. Each task is scoped by a plan, carried by a brief, and concluded by an explicit status. The process stays legible and every change is provable.
• Single sources, derived products. Facts live once — in the plan, the schema, or the manifest — and everything that ships is derived from them, so paper and practice cannot drift apart.
• Deterministic execution. The cdd engine drives the chain as commands: same plan, same brief, same commands, same outcome. The human and the harness follow the same contract.

The three-mode chain

The core loop is a chain of three modes:

The chain is a closure: implement → review → fix, then the next group's implement. A review that blocks routes back through fix and is re-reviewed until it passes; a review that passes converges and the loop advances. When all groups have converged, a final branch review closes the change and hands it off to finishing. The cdd engine runs the whole chain deterministically — dispatching each phase to the host harness and writing the handoff artifacts.

Convergence discipline

Reviews are structured, not impressionistic. Every finding carries a severity — blocker, warn, or nit — and a lens, and a round only concludes when its findings converge:

• blocker findings route the round back to fix and a re-review, until none remain;
• warn / nit findings are applied by a fix round that converges and completes without a re-review, with the findings recorded;
• zero findings close the review outright.

Review Convergence is the shared closure rule behind all of this — a review never passes silently, and a fix round never re-opens settled decisions. The same rule closes task reviews, branch reviews, spec reviews, and plan reviews alike, so the whole methodology converges under one discipline instead of a pile of ad hoc checklists.

What this is

A marketplace that packages personal AI coding skills as installable plugins consumed by multiple AI coding harnesses. First-party plugins live in this repository under packages/ and are published by us to npm under the @oscaner-skills/* scope; upstream plugins are not packaged here — they install from their own publishers, and osuperpowers orchestrators read them through /-prefixed plugin:skill references (e.g. /superpowers:brainstorming).

Plugins

Upstream plugin versions follow their own release schedules and are not tracked in this marketplace — always install them from their own publishers (see Installation).

Installation

From the marketplace (recommended)

# Claude Code
/plugin marketplace add oscaner/skills
/plugin install osuperpowers@oscaner-skills

From npm

npm install @oscaner-skills/osuperpowers

Upstream plugins

Upstream plugins (superpowers / mattpocock-skills / impeccable) are not packaged here — install each from its own publisher via its official command (marked Upstream in the Plugins table, linked to their GitHub home repos).

Per-harness install

osuperpowers installs through each harness's own plugin marketplace; neither Claude Code nor Cursor Agent needs a per-harness config file.

Quick start

1. Install the plugins from the marketplace or npm (see Installation).
2. Make sure the cdd engine CLI is on PATH (command -v cdd); if it is missing, run npm i -g @oscaner-skills/cdd-engine. cli-driven-development's detect-engine node re-checks this at dispatch.
3. Invoke the superpowers workflow as you normally would — osuperpowers skills intercept upstream triggers and route to the matching target automatically.

Architecture

Package layout

packages/
├── osuperpowers/   # first-party plugin: osuperpowers orchestration + cli-* family + CDD engine skills
└── cdd-engine/     # @oscaner-skills/cdd-engine — the CDD engine CLI package (dependency of osuperpowers)

Package-as-source, one emit chain

The marketplace is package-as-source — metadata lives in each first-party package.json's oscaner-plugin field. The build step pnpm run emit derives everything from that:

package.json#oscaner-plugin --> emit --> marketplace/source.json
                                     --> .claude-plugin/marketplace.json
                                     --> .cursor-plugin/marketplace.json
                                     --> per-plugin .claude-plugin/plugin.json

No hand-registration is needed for first-party plugins — pnpm run emit auto-discovers them.

Full architecture: CLAUDE.md.

Per-package docs

• packages/osuperpowers/ — the plugin's own guide: skill inventory, install, quick start, the cdd CLI harness table
• packages/cdd-engine/ — the CDD engine package source (maintained from this repo)
• docs/maintainers/ — maintainer-only documentation index for this repository's developers

Development

Common operations

# After editing any plugin manifest or skills
pnpm run emit && pnpm run validate

Adding a new first-party plugin

1. Create packages/<name>/package.json with the oscaner-plugin field.
2. Run pnpm run emit — it auto-discovers the plugin and regenerates all manifests.
3. Add a changeset naming it — it is released as @oscaner-skills/<name>.

No hand registration needed. See CLAUDE.md for full details.

Branch flow

develop is the integration branch — day-to-day PRs merge there. Production releases go through develop --> main. Version PRs, git tags, and GitHub Releases run on main only.

Release process: .changeset/README.md.

License

First-party code (osuperpowers, marketplace tooling): MIT.