openspec plugins

by Joe Stump

Spec-Driven Development: ADRs, specifications, sprint planning, parallel implementation, code review, and documentation generation.

by Paul Ingram

Spec-to-production multi-agent coding pipeline. Takes a requirements folder (OpenSpec / Superpowers / plain markdown), drives it through a 100%-coverage planning loop, spawns parallel agent teams for backend/frontend, enforces review gates, reconciles parallel work, and verifies with live dev-API + Playwright user-flow tests.

by TanglmChris

Keel OpenSpec execution discipline: stateless continuity, task capsules, deterministic gates, and expectation alignment for Codex and Claude Code.

by TanglmChris

Keel OpenSpec execution discipline: stateless continuity, task capsules, deterministic gates, and expectation alignment for Codex and Claude Code.

by Rob Sherman

A lightweight project-management layer that sits above OpenSpec and Superpowers. Tracks active proposals as epics, maintains an explicit detour stack, and enforces a reconcile gate so nothing is lost when development pivots or context is compacted.

by reqstool

OpenSpec integration for reqstool — conventions for referencing reqstool IDs in OpenSpec files, plus an openspecui hook that enriches all OpenSpec documents with reqstool requirement/SVC titles and descriptions at read time.

by Kido

Company-wide engineering harness: core standards, risk-based workflows, project packs, and verified skills.

by Oratta

この開発ハーネスでの標準開発ワークフローを集めるプラグイン。develop: コード・スキル・コマンド・規範文書を変えるときは入口（issue 番号/URL/自然文・会話・cron・エピックの子）を問わず必ず通すワークフロー。本体はオーケストレータ専任（Edit でコードを書かず、レビューを代行しない）で、作業者 W（dev-workflow:worker）・仕様レビュアー R1・ゲート実行者 G（dev-workflow:gate-runner） を model 明示で spawn し 1 ループ（入口 0 で記録先＝issue または Draft PR を確定 → W が `仕様化判断: する|しない` を記録先に記録し change 分割と openspec new change → R1 が別コンテキストで仕様レビュー（2 周キャップ・結果を `仕様レビュー: APPROVE|REQUEST_CHANGES` で記録）→ W が (3a) TDD 実装・verify まで行って return し、本体が計測してから (3b) archive・PR・仕様宣言 → G が pr-review-gate 手順 1〜5）を回す。issue が無ければ issue を切らず、空 commit → Draft PR を記録先にする（issue を切るのは追跡・キュー・議論が要るときだけ）。エピックの条件・作り方・回し方・完了条件も規定。役割のモデルは pre-classification.md の事前分類（4 分類のいずれでも W は 1 周目から opus 止まりで、W の上限は opus。それ以外の W は sonnet 既定。G は sonnet 固定で判定は needs-reviewer のレビュアーが担う。abundant はどの役割も押し上げない）と、Fable を渡せる唯一の種別 agents/decider.md（dev-workflow:decider。model: fable・tools は Read/Grep/Glob の読み取り専用で、読んで判断する役はこの種別で spawn する。scripts/agent-model-guard.sh が PreToolUse で他種別への model: fable を deny する）と残量モード（FABLE_BUDGET_MODE。reserve は自動実行のみ・exhausted は全経路で opus 上限）と共有枠モード（SHARED_BUDGET_MODE。全モデル共通の週次枠から導出し、throttled / depleted で全役割 sonnet 起点）で決め、W / G の SendMessage 再開は毎回 scripts/subagent-context.sh でコンテキスト量を測り、DEV_WORKFLOW_CONTEXT_CAP（既定 150K tokens）超なら作業継続の SendMessage を送らない（無条件）。前回 return を渡した同じ役割の新しいエージェント（新しい W / 新しい G）への手渡しは、前任の return の 1 行目が `工程完了: <工程名>` のときだけ行う（`工程中断:` なら再開も手渡しもしない）。昇格トリップワイヤー（templates/escalation-tripwires.md）は決める役 / 実行役の分離ラダーとして残す。さらに hooks/hooks.json に配線した scripts/context-tripwire.sh が、サブエージェントの起動の途中でも PostToolUse（全ツール）/ PreToolUse（Edit|Write|NotebookEdit|Bash）で自分自身のコンテキストを測り、DEV_WORKFLOW_CONTEXT_CAP 超で締めを通知し DEV_WORKFLOW_CONTEXT_HARD_CAP 超で編集系を deny する（計測対象は agent_id から導出するので worktree 隔離のサブエージェントでも効く）。/develop（/work-issue はエイリアス）: 5 分岐で記録先を確定し、issue を切ると決めたときだけ issueify スキル（skills/issueify）で起票する。loop-dev-agent の無人サイクルでは憲法のメインが develop の本体を務める（--unmanned）。pr-review-gate: PR 作成後に必ず通す品質ゲート（別コンテキストレビュー・リスク宣言と仕様宣言の positive affirmation・動作確認証拠・agent-review:passed 付与を fail-closed で行う。仕様宣言は記録先（issue → 無ければ PR 自身）の `仕様化判断:` 記録と突き合わせ、記録なし PR は合格させない。規範パス接触の裏取りは scripts/spec-touch-check.sh。レビューの重量は変更内容から light / full に事前判定し、既定と迷ったときは full＝Codex に倒す。auto-merge workflow のリポ展開テンプレートは templates/auto-merge/）。レビュー failed からの修正は実装品質起因のときだけ昇格し、失敗の原因が判断側か実行側かで決める役（dev-workflow:decider。model は opus → fable）と実行役（sonnet → opus が上限）のどちらか一方だけを上げる（仕様曖昧・レビュアー誤検出はモデル昇格しない。フォールバック記録の正本は pr-review-gate）。上流の壁打ち（/opsx:explore）は呼ばず、issue 化前の壁打ちとは切り分ける。references/（プラグイン直下）: 複数プラグインで共有する契約 — self-verification.md（自己検証の共通原則）・pr-body-format.md（PR / issue 本文の型）・model-tiers.md（Workflow 実行のロール別ティア → opts.model エイリアス）・workflow-execution.md（1 ループに収まらない規模をネイティブ Workflow で回す型。Review → Build → Verify・Build Contract・verifier のしきい値）。旧プラグイン 3 本は 2026-08 に解散し、契約はここへ移設（CHANGELOG.md に uninstall 手順）。 usage-probe はアカウントレジストリ（`accounts.json`）の全スロットを Keychain サービス名ごとにフェッチし、snapshot を schema 2（`accounts` にスロット別の値・`active` に現在のスロット id・`five_hour` も収集）で書く。トップレベルの従来キーは active スロットのミラー。使用量の主な情報源はステータスラインのセッション記録（`.usage-sessions/`）で、probe は補助。残量モードの導出と自動選択は `scripts/usage_view.py` の実効値を使う。fail-open はスロット単位で、失敗したスロットは前回値と取得時刻を保持する（refresh_token でのトークン更新は本体との競合を避けるため意図的に非対応）。scripts/subagent-context-audit.sh は同じコンテキスト量の定義で母集団（直近 N 日の subagents/agent-*.jsonl）を集計し、初回・最終の中央値と上限超の割合を 1 行 JSON とキャッシュ（SUBAGENT_CONTEXT_AUDIT_CACHE、TTL 既定 6 時間）に出す観測専用のスクリプトで、読み方の正本は docs/usage-audit.md（強制は加えず、SessionStart にも注入しない）。 memory-refresh: メモリ索引の肥大を検知し（scripts/memory-tripwire.sh、session-tripwires.sh 経由で SessionStart ごとに閾値判定）、削除・統合・短縮・維持に分類して主の承認を得てから手で整理するスキル（/memory-refresh）。

by Job Schepers

The change lane: installs and configures the OpenSpec CLI so a change to a repository is proposed, agreed, built step by step, and archived as deltas against its devbook chapters — never a copy of OpenSpec's skills. init checks the CLI against the stamped range, runs openspec init at the repository root, writes the managed devbook schema (proposal → devbook-delta → solution → tasks) and a seeded config.yaml, removes the specs/ folder the CLI scaffolds, installs the change-folder rule with a wrapper per host, and stamps components.openspec; update runs openspec update and refreshes what it manages. Four providers an engine can bind by name: spec returns an approved change's specification unchanged, tracker keeps tasks.md as the work items with read_item, update_item, and comment, status reports steps, verdicts, and both gates, and archive checks the gates, merges every delta through devbook's delta.mjs, and lets openspec archive move the folder. onboard walks a first change through. An L1 extension over devbook.

by Travis James

Windows-native, scaled-down port of the Prometheus skill system: KBD process orchestration, adversarial review, and portable agent tooling.

by Travis James

Windows-native, scaled-down port of the Prometheus skill system: KBD process orchestration, adversarial review, and portable agent tooling.

by SpecPowers Team

六阶段 spec 驱动开发流水线编排插件：constitution→brainstorm→specify→plan→build→archive，叠加结构一致性门禁与实时卡转人工。新增无人值守 auto 模式（/specpowers-auto 以设计文档为权威输入全流程直通，自动裁决确认/门禁节点）。桥接 OpenSpec CLI + superpowers 插件 + codex-review 技能，需预装。

Frontend coding conventions plus the workflow around them. One fe-coding skill detects the stack (Next.js App/Page Router, React Native Expo/CLI, Next.js API + Prisma) and applies the _modules architecture, component hierarchy, Link-only navigation, function minimalism, visible empty states and Zod/React-Hook-Form validation. Workflow skills cover project setup, Figma-to-code, ticket workflow, BA/PO ticket writing (requirement → templated ClickUp ticket), mobile release notes, deployment checks, spec-driven (OpenSpec), and capturing corrections as rules. Each project keeps its own live, committed copy of the rules (edit it, review the diff, PR it back) and can register the other repos of its system so cross-repo contracts are read from the real files instead of guessed. Bundles the context7 and Framelink Figma MCP servers so they load on install.