foyzulkarim/skills — Claude Code Plugin Marketplace

Name: skills
Author: foyzulkarim

A plugin marketplace for Claude Code with a structured 5-phase development pipeline and an optional QA gate that runs independently of review.

Why use this?

dev-pipeline turns a problem statement into a reviewed pull request through a structured 5-phase agentic workflow (with an optional QA gate that runs independently of review) — mode-appropriate verification is baked into every task.

What you get:

Verified implementation — every task ships with a verification mode (tdd, test-after, ui, or checklist) matched to its shape.
Parallel lanes — move-to-worktree lets multiple Phase 4 streams run side-by-side without stepping on each other.
Triage-first review — /review dispatches up to 17 domain checks in parallel and writes a single report.
Manual QA as a first-class gate — /plan-qa turns the specs and the diff into an executable QA specification; /execute-qa drives it against the running product (browser + shell) and writes an evidence-backed results artifact.

For solo devs and small teams who want agent-driven development to ship with the same rigor they'd want from a human reviewer.

Add this marketplace

/add-marketplace foyzulkarim/skills

Install

/install-plugin foyzulkarim/skills dev-pipeline

dev-pipeline

A complete development workflow built on a 5-phase agentic framework, with an optional QA gate that runs independently of review:

  ┌────────────────────────────────────────────────────────────┐
  │  Pre: /start-task → issue → branch + context  (opt-in)    │
  └──────────────────────────┬─────────────────────────────────┘
                             │
                             ▼
  ┌────────────────────────────────────────────────────────────┐
  │  Phase 1     /plan-requirements                            │
  │  Output: REQ-*.md                                          │
  └──────────────────────────┬─────────────────────────────────┘
                             │
                             ▼
  ┌────────────────────────────────────────────────────────────┐
  │  Phase 2     /plan-architecture                            │
  │  Output: ARCH-*.md                                         │
  └──────────────────────────┬─────────────────────────────────┘
                             │
                             ▼
  ┌────────────────────────────────────────────────────────────┐
  │  Phase 3     /generate-tasks                               │
  │  Output: TASKS-*.md                                        │
  └──────────────────────────┬─────────────────────────────────┘
                             │
                             ▼
  ┌────────────────────────────────────────────────────────────┐
  │  Phase 4     /implement                                    │
  │  Output: code + verification evidence                      │
  └──────────────┬─────────────────────────────┬───────────────┘
                 │                             │
                 ▼                             ▼
  ┌───────────────────────────┐  ┌───────────────────────────┐
  │  Phase 5   /review        │  │  QA gate (when applicable)│
  │  Output: PR + report      │  │  /plan-qa                 │
  │                           │  │    ↓                      │
  │                           │  │  /execute-qa              │
  │                           │  │  Output: QA-RESULTS-*.md  │
  └──────────────┬────────────┘  └─────────────┬─────────────┘
                 └───────────────┬─────────────┘
                                 ▼
                               merge
        (QA gate is skipped when the change has
         no running surface worth driving)

  ┌────────────────────────────────────────────────────────────┐
  │  /commit → use at any stage                                │
  └────────────────────────────────────────────────────────────┘

Skill	Phase	Description
/plan-requirements	1	Capture WHAT and WHY — Socratic interview producing `REQ-*.md`. Owner: developer.
/plan-architecture	2	Design HOW — collaborative system design producing `ARCH-*.md`.
/generate-tasks	3	Emit verification-ready task specs as `TASKS-<N>-<slug>.md` (sibling file alongside ARCH), each with a verification mode (tdd, test-after, ui, or checklist).
/implement	4	Mode-routed implementation from `TASKS-<N>-<slug>.md` (with ARCH for context); tdd, test-after, ui, or checklist per task. Collaborative or autonomous, one commit per task.
/review	5	Triage-first code review — up to 17 checks, pipeline or general mode.
/plan-qa	parallel	Interview-driven QA planning — pipeline/general/bug entry modes, environment-portable plans, plan-time parallel lanes, falsifiable expectations (`[assert]`/`[judge]`/`[judge-visual]`), guards, and operator handoffs. Runs in parallel with Phase 5.
/execute-qa	parallel	Executes a QA spec as written against any environment (`--env`/`--base`) — drives the bundled persistent Playwright daemon, runs lanes as parallel subagents, mechanical asserts plus evidence-backed judgment; writes `QA-RESULTS-*.md`.
/start-task	pre-1	One-shot branch bootstrap from a GitHub issue, Jira key, local spec, or ad-hoc brief — zero confirmation by default.
/commit	any	One-shot conventional commit — script-curated context, zero confirmation by default, `ask` mode for review/selective staging.
/sync-skills	any	Copy this repo's skills into another harness's skills directory by name — resolves the harness alias via `scripts/sync-targets.json`, with a discovery fallback for unmapped aliases.
/session-stats	any	Terminal dashboard of the current session — tokens, cache, cost, context %, tool-call histogram.
/setup-cost-tracking	any	Install per-session cost tracking by wiring logger scripts into the Claude Code statusline and hooks.
/move-to-worktree	parallel Phase 4	Park the current branch in `.worktrees/<issue#>` to open a parallel lane. Requires `.worktrees/` gitignored.
/finish-worktree	parallel Phase 4	Teardown counterpart: fast-forward default, remove worktree, delete branch after the PR squash-merges and the issue closes.
/archive-issue	post-merge	Move a closed issue's `specs/` artifacts into the GitHub wiki once the issue closes.
/release-notes	pre-release	Draft a `CHANGELOG.md` entry from commits since the last git tag.

Pipeline entry points

Greenfield → Phase 1 → 2 → 3 → 4 → 5
New feature in an existing system → Phase 2 → 3 → 4 → 5 (skip requirements; brief is enough)
Bugfix → Phase 1 (as RCA) → 3 → 4 → 5 (skip architecture)

The QA gate (/plan-qa → /execute-qa) attaches to any scenario whose change has a running surface worth driving. Review and QA are independent gates — the developer chooses whether to run them sequentially or in parallel, and in what order.

Case studies

Claude Lens V2 — 127K lines in 21 days — a 10-slide build retrospective of the entire V2 product (54 PRs, five phases, parallel agent lanes on a Saturday). Download and open in a browser for the full deck experience. Companion long-form report: merged-pr-report.md.

Prerequisites

A few system tools are required by individual skills — install before you start so nothing surprises you mid-session.

git ≥ 2.22 — move-to-worktree / finish-worktree use git branch --show-current (2.22) and git worktree remove (2.17).
GitHub CLI (gh) — required by finish-worktree, archive-issue, and start-task's GitHub path.
jq — required by scripts/sync-skills.sh's --to <harness> alias resolution and list-targets.
Node.js — only required when running /setup-cost-tracking (statusline scripts are JS).

Plugin structure

dev-pipeline/
├── .claude-plugin/
│   └── plugin.json
├── rules/                     # domain-specific review rules (api, api-test, database, database-test, service, service-test)
├── scripts/                   # file-tree.sh, search-codebase.sh — shared helpers for plan-architecture
├── skills/
│   ├── plan-requirements/
│   ├── plan-architecture/
│   ├── generate-tasks/
│   ├── implement/
│   │   └── modes/             # tdd, test-after, ui, checklist
│   ├── review/
│   │   └── sub-skills/        # 17 review check files + shared _protocol.md, dispatched by /review
│   ├── plan-qa/
│   │   ├── SKILL.md
│   │   └── artifact-template.md
│   ├── execute-qa/
│   │   ├── SKILL.md
│   │   ├── qa-browser.mjs
│   │   └── artifact-template.md
│   ├── sync-skills/
│   ├── commit/
│   ├── session-stats/
│   ├── setup-cost-tracking/
│   ├── start-task/
│   ├── move-to-worktree/
│   ├── finish-worktree/
│   ├── archive-issue/
│   └── release-notes/
└── README.md

Test locally

scripts/sync-skills.sh is a bidirectional sync helper that copies repo skills into ~/.claude/skills/ for live testing, and can pull changes back.

Each copy gets a .synced-from marker so the script only touches directories it created, never your real personal skills.

Command	What it does
`scripts/sync-skills.sh push`	Push all repo skills → `~/.claude/skills/` (creates or refreshes `.synced-from` marker)
`scripts/sync-skills.sh push <skill> …`	Push only named skills
`scripts/sync-skills.sh pull`	Pull all tracked skills back from `~/.claude/skills/` into the repo (strips marker)
`scripts/sync-skills.sh pull <skill> …`	Pull only named tracked skill(s) back
`scripts/sync-skills.sh import <skill> …`	Import a non-tracked skill from `~/.claude/skills/` into the repo (names required)
`scripts/sync-skills.sh nuke`	Remove only the `.synced-from`-managed copies from `~/.claude/skills/`
`scripts/sync-skills.sh nuke --force <skill>`	Force-remove a skill from target even if it has no marker (DANGER)
`scripts/sync-skills.sh --target <dir> push ...`	Sync to `<dir>` instead of `~/.claude/skills/` (e.g. another agent's skills directory); must precede the command
`scripts/sync-skills.sh --to <harness> push ...`	Resolve `<harness>` via `scripts/sync-targets.json` (e.g. `oh-my-pi`, `opencode`) and push there; must precede the command
`scripts/sync-skills.sh list-targets`	Print all configured harness aliases and their resolved directories
`scripts/sync-skills.sh push --force <skill>`	Overwrite even an unmanaged (unmarked) directory at the target

Harness targets: scripts/sync-targets.json maps harness aliases to skills dirs (~ is expanded). Current entries: claude → ~/.claude/skills, oh-my-pi → ~/.omp/skills, opencode → ~/.config/opencode/skills.

Prefer natural language? The /sync-skills skill wraps the script for you — say "copy commit and implement to oh-my-pi" and it handles alias resolution and discovery of new harnesses.

Typical workflow:

# Push a WIP skill to test it live
scripts/sync-skills.sh push commit
# ...edit commit in ~/.claude/skills/commit/ during a real session...
# Pull the changes back into the repo
scripts/sync-skills.sh pull commit
# Or bring in a personal skill you built locally
scripts/sync-skills.sh import my-custom-skill
# If the target already has that skill, force-nuke it first, then push
scripts/sync-skills.sh nuke --force my-custom-skill
scripts/sync-skills.sh push my-custom-skill
# Clean up target copies when done
scripts/sync-skills.sh nuke