SDLC Marketplace for Claude Code

Multi-stack AI-assisted SDLC pipelines built on the Stack Provider Pattern: a single core orchestrator runs the pipeline, framework plugins register themselves via declarative stack.md profiles. No core overrides, no slot registries, no copy-paste between stacks.

v1.3.0 — 27 marketplace entries: 24 local (1 core + 5 shared libs + 7 JS/TS stacks + 4 PHP/Laravel/Symfony stacks + 3 Java/.NET stacks + 4 Python stacks) plus 3 optional external. Cost-optimized: model tiering + effort per-subagent, two-tier development phase (Opus plans, Sonnet implements), enforced workflow cost caps, file-scoped format hooks, shared architect conventions (~1,600 lines of boilerplate deduped), per-aspect QA fan-out on full-stack runs. See MODEL-ROUTING.md for the routing audit behind this release.

Quickstart

# 1. Add the marketplace
/plugin marketplace add AratKruglik/claude-sdlc

# 2. Install the stack plugin you need (sdlc core is installed automatically as a dependency)
/plugin install laravel-plugin@sdlc-marketplace
# or for JS/TS projects:
/plugin install nodejs-plugin@sdlc-marketplace   # Express/Fastify/Koa
/plugin install nestjs-plugin@sdlc-marketplace   # NestJS
/plugin install nextjs-plugin@sdlc-marketplace   # Next.js (full-stack)
/plugin install react-plugin@sdlc-marketplace    # React SPA
/plugin install vue-plugin@sdlc-marketplace      # Vue 3 SPA
/plugin install angular-plugin@sdlc-marketplace  # Angular 18-21
/plugin install react-native-plugin@sdlc-marketplace  # React Native / Expo
# or for Python projects:
/plugin install django-plugin@sdlc-marketplace   # Django + DRF
/plugin install fastapi-plugin@sdlc-marketplace  # FastAPI + SQLAlchemy 2.0
/plugin install flask-plugin@sdlc-marketplace    # Flask + Flask-Migrate
/plugin install python-plugin@sdlc-marketplace   # Plain Python (CLI/library/scripts)

# 3. Install optional plugins
/plugin marketplace add mattpocock/skills
/plugin install mattpocock-skills@skills # Enhances BA phase with interactive grilling

# 4. Verify
/sdlc:doctor
/sdlc:list-stacks

# 4. Run
/sdlc:start "Add subscription billing with Stripe"

Execution model: /sdlc:start runs synchronously in your current Claude Code session, not as a detached background job. You stay engaged through dependency/stack-detection checks and phase boundaries — including an interactive approve/request-changes/abort gate before the development phase writes any code. The final phase autonomously opens a Pull Request via gh pr create. See Pipeline Phases below.

How It Works: Stack Provider Pattern

┌─────────────────────────────────────────────────────────────┐
│                    sdlc (core)                               │
│  ┌──────────────────────────────────────────────────────┐  │
│  │  pipeline-orchestrator (skill) — NEVER CHANGES        │  │
│  │                                                       │  │
│  │  Phase 1: BA          → core's business-analyst       │  │
│  │  Phase 2: Dev         → ⚡ DISPATCH to stack provider │  │
│  │  Phase X: extra       → ⚡ stack-specific phases      │  │
│  │  Phase N-2: QA        → core's qa-engineer            │  │
│  │  Phase N-1: Security  → core's security-analyst       │  │
│  │  Phase N: Docs/PR     → core's document-writer        │  │
│  └──────────────────────────────────────────────────────┘  │
│                            ▲                                │
│                            │ reads stack.md profiles        │
└────────────────────────────┼────────────────────────────────┘
                             │
    ┌────────────────────────┼───────────────────────────┐
    │            │           │             │             │
┌───▼───┐  ┌────▼────┐ ┌────▼────┐  ┌────▼────┐  ┌────▼────┐
│laravel│  │ nodejs  │ │  nestjs │  │ nextjs  │  │  react  │
│plugin │  │ plugin  │ │  plugin │  │ plugin  │  │  plugin │
│stack.md│ │ stack.md│ │stack.md │  │stack.md │  │stack.md │
└───────┘  └─────────┘ └─────────┘  └─────────┘  └─────────┘

Key principles:

1. Core never changes. Pipeline logic lives exclusively in pipeline-orchestrator/SKILL.md.
2. Plugins register themselves via stack.md frontmatter — they declare auto-detection rules, priority, agents per phase, and convention skills.
3. Per-aspect dispatch. A project can have multiple aspects (backend + frontend + database). Each aspect gets its own specialist.
4. Priority wins. When multiple profiles match, the highest priority takes over.

How Stack Selection Works

When /sdlc:start runs, the orchestrator needs to decide which agent handles development. The priority system is how it picks.

Each plugin has a stack.md file where it describes itself: "I handle projects that have X, and my priority is Y." The orchestrator scans all installed plugins, runs their detection rules against the current project, and picks the highest-priority match.

Step by step:

1. Scan ~/.claude/plugins/cache/**/stack.md — collect all registered profiles.
2. Each profile checks its detect rules: is there a package.json? Does it contain react? Is there a manage.py? And so on.
3. From those that matched — the profile with the highest priority number wins.

Example — Laravel + React (Inertia.js) project:

Result: backend → laravel-architect, frontend → inertia-react-architect (beats plain react at 175 vs 150).

Why numbers, not "first match"?

Some technologies are supersets of others. Next.js is React + a server. NestJS is Node.js + a DI framework. When multiple plugins recognize the same project, the more specialized one should win — not whichever was installed first. The numbers encode that specialization:

0   → vanilla fallback (always matches, always loses)
100 → base stacks (laravel, django, java, python...)
150 → more specific (spring-boot, react SPA, vue...)
175 → super-stacks (inertia = laravel + react combined)
200 → even more specific (nestjs, angular...)
250 → full-stack (nextjs = backend + frontend in one)
300 → mobile (react-native — its own ecosystem)

Aspects let one project run multiple specialist agents in parallel. laravel-plugin covers backend + database aspects; inertia-react-plugin covers frontend. So a Laravel + Inertia project gets three agents — laravel-architect, artisan-specialist, and inertia-react-architect — each focused on its own slice, dispatched in canonical order: database → backend → frontend.

Stack Priority Table

Pipeline Phases

Standard 5-phase pipeline

Phase 1: BA → business-analyst (opus/high)
          ↓ output: docs/plans/{slug}/01-business-analysis.md
Phase 2: Dev → [stack agent] (sonnet/medium)
          ↓ output: docs/plans/{slug}/02-development.md
Phase 3: QA → qa-engineer (sonnet/medium, max 3 attempts)
          ↓ output: docs/plans/{slug}/03-qa.md
Phase 4: Security → security-analyst (opus/high)
          ↓ output: docs/plans/{slug}/04-security.md
Phase 5: Docs → document-writer (haiku/low)
          ↓ output: PR on GitHub

Example: Laravel (6 phases)

Phase 1: BA → business-analyst
Phase 2: Dev/backend  → laravel-architect    (aspect=backend)
Phase 3: Dev/database → artisan-specialist   (extra phase after backend)
Phase 4: QA → qa-engineer
Phase 5: Security → security-analyst
Phase 6: Docs → document-writer

Per-aspect dispatch (multi-framework projects)

For a project with a Node.js backend and a React frontend:

• Phase 2/backend → node-architect
• Phase 2/frontend → react-architect (separate run)

Aspects are dispatched in canonical order: database → backend → frontend → testing.

Commands

Dynamic Workflow Recipes

A workflow recipe is a YAML file that declares which pipeline phases to run. Instead of always running all 5 phases, the orchestrator selects the right recipe automatically — or you can pick one explicitly.

Built-in recipes

Using a specific recipe

/sdlc:start --workflow=hotfix "Fix null pointer in payment handler"
/sdlc:start --workflow=docs-only "Update README for new auth flow"

Auto-selection

If no --workflow flag is given, the orchestrator checks each recipe's match rules against your $ARGUMENTS in priority order. First match wins; default always matches as the fallback.

Custom recipes

Place a YAML file at ~/.claude/plugins/cache/sdlc/workflows/my-recipe.yaml:

name: my-recipe
description: Internal audit workflow — skip BA, security required.
phases:
  - development
  - qa
  - security
caps:
  max_total_cost_usd: 1.00

/sdlc:start --workflow=my-recipe "Audit user permissions module"

Recipe files are validated against schemas/workflow.schema.json on load. Invalid recipes halt with an error listing each violation.

Model Enforcement

Every agent in the SDLC pipeline declares its model: tier in frontmatter. The pipeline enforces that tier on dispatch, so a session running on an expensive default model does not drag every phase up with it.

Two enforcement layers:

1. Orchestrator (Layer 1) — Step 3b-3 in the pipeline explicitly reads the agent's .md frontmatter and passes the tier alias in the Agent() dispatch call.

2. PreToolUse hook (Layer 2) — plugins/sdlc/hooks/enforce-agent-model.sh intercepts every Agent tool call at the harness level. It reads the agent's declared tier, compares it with the requested model, and corrects it via updatedInput if they differ. This fires even if the orchestrator misses the step.

The hook is registered in plugins/sdlc/hooks/hooks.json and activates automatically when the plugin is installed via the marketplace — no manual settings.json changes needed.

Model tiers: both layers pass the short alias (opus / sonnet / haiku / fable) as-is — the Agent tool's model parameter accepts only these aliases, and a full pinned model ID would fail validation and silently fall back to the session model. (Agent frontmatter is more permissive and does accept full IDs and inherit; the dispatch parameter does not.) Which concrete model each alias resolves to is decided by the harness, so the marketplace never goes stale on model releases.

Two-tier development phase: the development phase runs a planning pass and an implementation pass either side of a human approval gate, and they resolve different tiers. The planning pass reads model_plan: (Opus by default), the implementation pass reads model: (Sonnet). The orchestrator marks the pass in the Agent() description field so the hook enforces the matching one — see MODEL-ROUTING.md §4.1.

⚠️ Enforcement is not absolute. Claude Code resolves a subagent's model in the order CLAUDE_CODE_SUBAGENT_MODEL → per-invocation parameter → frontmatter. That environment variable overrides both layers above, and every phase silently runs on whatever it names. An organization availableModels allowlist can likewise skip a value in favour of the inherited model. Run /sdlc:doctor to see whether either is in play — while an override is active, none of the cost figures below apply.

Cost Optimization: model + effort

Why model + effort instead of temperature

Claude Code subagent frontmatter supports:

• model — opus / sonnet / haiku / fable / full model ID / inherit
• effort — low / medium / high / xhigh / max — overrides the session-level reasoning budget

temperature is not configurable per-subagent in Claude Code. We control cost exclusively through model + effort.

Note the asymmetry between the two levers: model can be overridden per dispatch (the Agent tool takes a model parameter), but effort cannot — it is read from frontmatter only. An agent invoked twice in one phase therefore shares one effort value across both invocations, which is why the development phase varies model between its passes but not effort. See MODEL-ROUTING.md §6.

model_plan is this marketplace's own optional field, not a Claude Code one — the orchestrator resolves it for the development planning pass and falls back to model when absent.

model+effort table for all agents

Development-phase agents carry a second tier in model_plan — resolved for the planning pass only, with model used for implementation.

High effort on Opus is the most expensive combination, so only the two leverage agents use it — BA and Security, where reasoning quality propagates into every later phase. Security sits one rung higher (xhigh) because its failures are the only ones the pipeline cannot detect on its own.

Estimated cost for a medium feature

Assumes a medium feature, split roughly by phase workload below. Sonnet pricing includes an introductory discount through 2026-08-31 ($2/$10 per MTok in/out vs. the $3/$15 standard rate) — both are shown since most runs during the discount window will land closer to the lower figure.

Per-MTok list prices used above: opus $5 in / $0.50 cached / $25 out; sonnet $3 / $0.30 / $15; haiku $1 / $0.10 / $5.

Two rows carry real uncertainty. The Dev plan pass has no measured token volume yet — 80K/4K is an assumption. Security at xhigh bills thinking tokens at the output rate, and how much xhigh adds has not been measured here; the row assumes output roughly doubles. Both are replaced by real numbers once docs/cost-baseline.md is populated.

This is roughly 30% above the previous single-tier estimate, and the trade is deliberate: the argument is cost per completed task, not per run. A development pass that starts from a weak plan gets redone and drags QA and security with it, which costs more than the delta. To opt out on any agent, set model_plan: sonnet or drop the field — that agent reverts to single-tier behaviour with no other changes.

Actual cost varies with codebase size, diff scope, and QA retry count — treat this as an order-of-magnitude estimate, not a quote. It also excludes the orchestrator's own token use; see docs/cost-baseline.md.

Additional cost levers

• Skip-rules: typo-fix, whitespace-only, config-only, lightweight-no-db — skip unnecessary phases automatically.
• QA hard cap: max 3 attempts to fix failing tests, then STOP.
• Compact handoffs: each agent returns a ≤2–3K-token summary.
• Prompt caching: stable system prompts (no timestamps, slugs, or dynamic content) → ~60% cache hit rate on Sonnet.
• Workflow cost caps: caps.max_total_cost_usd in a recipe halts the run (with confirmation) once the running total crosses it. Set as a runaway guard, not a routine blocker.
• Fewer spawns beat cheaper spawns. The dominant cost driver is the per-phase subagent spawn, so removing an unnecessary phase saves more than re-tiering one. Skip-rules are the strongest lever here; adding a cheap agent to feed an expensive one usually loses.

Available Plugins

Optional external dependencies

Stack Composition Examples

Local Overrides

A .claude/sdlc.local.yaml file at the project root (not inside the plugin) lets you adapt the pipeline without modifying any plugin:

post_pipeline_checks:
  - "composer test"
  - "php artisan route:list --json"

phase_command_overrides:
  qa: "php artisan test --coverage --min=80"

convention_skills_extra:
  - "local:custom-coding-standards"

skip_phases:
  - security  # for internal hotfix branches

extra_phase_prompts:
  development: "Follow our internal-styleguide.md"

Adding a New Stack Plugin

Contract for a new framework provider:

plugins/your-framework-plugin/
├── .claude-plugin/
│   └── plugin.json          # { "name": "...", "dependencies": ["sdlc"] }
├── stack.md                 # YAML frontmatter: stack, priority, aspects, detect
├── agents/
│   └── your-architect.md    # frontmatter: name, model, effort, color, tools
├── skills/
│   └── your-conventions/
│       └── SKILL.md
└── README.md

stack.md example

---
stack: django
priority: 150
aspects: [backend, database]
detect:
  any:
    - file_exists: manage.py
    - file_contains:
        path: pyproject.toml
        pattern: "[Dd]jango"
    - file_contains:
        path: requirements.txt
        pattern: "[Dd]jango"
---
# Django Stack Profile

## Agents per phase
# business_analysis: business-analyst
# development.backend: django-architect
# database: django-migrations-specialist
# qa: qa-engineer / security: security-analyst / documentation: document-writer

## Convention skills to apply
# python-foundation:python-conventions
# python-foundation:python-tooling
# python-foundation:pytest-testing
# django-plugin:django-conventions
# django-plugin:django-orm-patterns

Schema validation

# Validate plugin.json
npx check-jsonschema --schemafile schemas/plugin.schema.json .claude-plugin/plugin.json

# Validate stack.md frontmatter
npx check-jsonschema --schemafile schemas/stack.schema.json <(yq '.frontmatter' stack.md)

Installation (step-by-step)

1. Add the marketplace

/plugin marketplace add AratKruglik/claude-sdlc
# or for local development:
/plugin marketplace add /path/to/claude-sdlc

2. Install core + required plugins

# Core is installed automatically as a dependency
/plugin install nodejs-plugin@sdlc-marketplace     # Node.js backend
/plugin install js-foundation@sdlc-marketplace     # required for JS/TS plugins

3. Optional external dependencies

/plugin marketplace add mattpocock/skills
/plugin install mattpocock-skills@skills
/plugin marketplace add obra/superpowers
/plugin install superpowers@superpowers-marketplace

/plugin marketplace add anthropics/claude-plugins-official
/plugin install security-guidance@claude-plugins-official

4. Verify

/sdlc:doctor
# → Stack profiles detected: vanilla(0), nodejs(100), react(150), ...
# → superpowers: ✅ installed
# → security-guidance: ⚠️ not found (pipeline will run in degraded mode)

/sdlc:list-stacks
# → Shows all matched stack profiles for current project

5. Run

/sdlc:start "Add user authentication with JWT"
# → Auto-detects stack, runs 5 phases in-session (with a dev-phase approval gate), creates PR

Requirements

• Claude Code (latest)
• API Tier 2+ or Claude Max — a medium feature uses ~445K input tokens; Pro plan rate limits will throttle the pipeline.
• A Git repository for document-writer (PR creation).

License

MIT — see LICENSE.