roxabi-plugins

01

What it is

Every team on Claude Code reinvents the same things — a CLAUDE.md, a custom review command, a way to structure CI prompts, a doc-sync ritual. It works, but none of it travels between projects. roxabi-plugins is that disposable layer made reusable: an open-source marketplace where each plugin ships an opinionated, battle-tested bundle for one domain.

A plugin is self-contained. It carries three kinds of thing, and Claude Code discovers them on install:

Skills — trigger-phrase workflows. You describe a task in plain language; the matching skill runs. No slash command to memorize.
Agents — specialized sub-processes (a backend engineer, a security auditor) that a skill spawns to do focused work.
Hooks — guardrails that fire on every tool call: secret scanning, formatter, test-command enforcement.

Plugins are project-agnostic. Each reads your stack from .claude/stack.yml at runtime — {commands.test}, {backend.path}, {package_manager} — so the same dev-core drives a NestJS monorepo and a Django service without changing a line.

Install is two commands: claude plugin marketplace add Roxabi/roxabi-plugins, then claude plugin install dev-core.

02

dev-core at a glance

The flagship plugin. It covers the whole arc from a GitHub issue to a merged PR, and it is the one we focus on here. Everything routes through a single entry point, /dev.

33skills

9agents

3safety hooks

5workflow phases

The three hooks run on every tool call, no skill required — they are the floor under everything else.

Hook	Trigger	What it does
Security check	PreToolUse · Edit/Write	Blocks hardcoded secrets, SQL-injection and command-injection patterns
Test guard	PreToolUse · Bash	Forces `bun run test` over `bun test` — the latter uses the Bun runner and spins the CPU
Auto-format	PostToolUse · Edit/Write	Runs the formatter from `stack.yml` per file extension; silent no-op when unconfigured

03

/dev, the orchestrator

This is the heart of the plugin. /dev is not a skill that writes code — it is a state machine that scans where the work stands, decides what comes next, and delegates to the right sub-skill. One door for the whole lifecycle.

You point it at an issue. It does the rest.

Command	What it does
`/dev #42`	Resume / start from the issue
`/dev "dark mode"`	Find or create the issue, then start
`/dev #42 --from spec`	Jump to a step (warns if deps are missing)
`/dev #42 --audit`	Reasoning checkpoint before spec / plan / implement

Each invocation runs the same silent loop: scan state, find the first unfinished step, gate if a human decision is due, delegate, then re-scan in the same turn and continue.

The /dev control loop — scan on-disk state (Σ), pick the first step that is neither done nor skipped, gate when a human decision is due, run the sub-skill, then re-scan in the same turn. Repeats until every step is done or skipped.

Progress is tracked in two places, so a session can die and resume cleanly:

Artifacts on disk — frames/, analyses/, specs/, plans/. Authoritative across sessions; this is how /dev knows you already wrote the spec last week.
The task list — authoritative within a session, plus an in-memory state map for steps that leave no file (validate, review, fix).

Three rules keep it honest and out of your way:

Human gates. Approval is requested at frame, spec, and plan — never auto-advanced past a decision.
Silent transitions. No "Running /X…", no "Moving to Y" — the next skill's output is the message.
Compact pause. After /plan (on F-lite / F-full), /dev stops and recommends /compact before building — the heavy planning context is dead weight for the fresh implementation agents.

04

Three tiers

Before walking the pipeline, /dev sizes the work. The tier decides which steps run and which are skipped — a typo fix should not sit through deep analysis and a spec gate.

Tier	Criteria	Pipeline
S	≤3 files, no architecture, no risk	triage → implement → pr → validate → review → fix* → cleanup*
F-lite	Clear scope, single domain	frame → spec → plan → implement → verify → ship
F-full	New architecture, unclear reqs, >2 domains	frame → analyze → spec → plan → implement → verify → ship

* = conditional — runs only if applicable.

05

The pipeline: /dev's sub-skills

Five phases, fourteen steps. Each step is a standalone skill /dev delegates to — these are its sub-skills. They group into Frame → Shape → Build → Verify → Ship.

The five phases and their sub-skills. Amber-dotted steps (frame, spec, plan) are human gates; the arc in Verify is the review → fix loop (≤2 iterations); promote is dashed because it runs standalone, never auto-triggered.

Each step has a class: gate ⛓ asks for human approval, adv advances automatically, verdict branches on its outcome, loop iterates.

Phase	Step → skill	Class	What it does	Skipped when
Frame	`triage` → /issue-triage	adv	Labels, size, priority, dependencies	already triaged
	`recheck` → /recheck	adv	Drift-check before coding (git-drift, missing symbol, resolved dep)	never
	`frame` → /frame	gate	Frames the problem from the issue	tier S
Shape	`analyze` → /analyze	adv	Deep analysis + expert consultation	tiers S, F-lite
	`spec` → /spec	gate	Spec + acceptance criteria, smart splitting	tier S
Build	`plan` → /plan	gate	Implementation plan as micro-tasks	tier S
	`implement` → /implement	adv	Writes code + tests via domain agents	—
	`pr` → /pr	adv	Opens the PR (Conventional Commits, links the issue)	—
Verify	`ci-watch` → /ci-watch	adv	Live CI dashboard, dumps logs on failure	no PR
	`validate` → /validate	adv	Implementation vs spec, quality gates	—
	`review` → /code-review	verdict	Multi-domain review → approve or request changes	—
	`fix` → /fix	loop	Applies accepted findings (≤2 iterations, then abort)	already applied
Ship	`promote` → /promote	—	staging → production	always (standalone)
	`cleanup` → /cleanup	adv	Removes stale worktrees / branches	nothing stale

Before the first code step, /dev silently bootstraps a git worktree (/setup-worktree) under .claude/worktrees/{N}-slug on feat/{N}-slug. All tiers build in isolation — never on main or staging.

06

From issue to merged PR

Run end to end (F-full shown), the chain looks like this — amber outlines mark human gates, dashed nodes are user-triggered, and code-review is a verdict that either merges or loops back through /fix.

The full F-full chain. The amber-outlined front carries the human gates (frame, spec, plan); the dashed nodes — compact pause and /promote — are user-triggered, never automatic. code-review is a verdict: changes loop through /fix (≤2) and re-review; approved merges to staging, then cleanup.

It is fully resumable. Kill the session mid-step, run /dev #42 again — the re-scan reads the artifacts on disk and picks up exactly where it left off. Idempotent by construction.

07

The agent layer

/dev orchestrates; it does not touch code itself. Skills like implement and fix spawn the agents — the only layer that writes. Nine of them, in three tiers. Each carries a config guard (fails fast if stack.yml is missing), an escalation path, and a confidence threshold: below 70–80% certainty it stops and asks instead of guessing.

Tier	Agents	Role
Domain	`frontend-dev` · `backend-dev` · `devops`	Implementation — UI, services, infrastructure & CI
Quality	`tester` · `fixer` · `security-auditor`	Tests, accepted review fixes, OWASP audit
Strategy	`architect` · `product-lead` · `doc-writer`	ADRs, analysis & specs, documentation

Read it from the source — the orchestrator, the sub-skills, and the agents all live in the open.

The repo · github.com/Roxabi/roxabi-plugins →
dev-core · plugins/dev-core/README.md →