品質戦略スキル群 (Quality Strategy Skills)
ソフトウェアの品質戦略（誰がプロジェクトにとって重要なのか、彼らが何を価値とするのか、どこに脆弱性があるのか、そしてどう対処すべきか）をインタビュー形式で生成するClaude Codeスキル群です。さらに、それをアクションに変換するテスト戦略とツーリング戦略も提供します。コードの大半があなたのプロジェクトにとって品質が何を意味するかを知らないエージェントによって書かれる現代において、明示的な戦略は、彼らが自信満々に間違った方向に進むのを防ぐ唯一の手段です。
Edmund Pringleの品質フレームワークに基づいています。品質とは重要な誰かにとっての価値であり、テストとは実際に何が真実かを調べる調査であり、リスクとは品質に対する危険です。ソロ開発者、小規模チーム、エンジニアリングリーダー、そしてエージェントがコードベースで作業するすべての人を対象としています。リポジトリは必要ありません。アイデア段階で実行することも第一級のユースケースです。
ステータス: アルファ版。 最初のテスターネットワークで共有中です。スキルは動作し、シミュレーションユーザーに対して十分にテストされていますが、実世界での使用実績は限られています。荒い部分があることを想定し、誤作動があればお知らせください（フィードバック）。また、先に既知の制限事項をお読みください。私たちはギャップを隠しません。
インストール
これはClaude Codeプラグインです：
/plugin marketplace add tollens-ai/quality-strategy-skills
/plugin install quality-strategy@tollens
その後、任意のプロジェクトで /quality-strategy から開始してください。出力はプロジェクトルートの quality/strategy.md に保存されます。（名前空間付きのスキルも利用可能です。例えば /quality-strategy:test-strategy。ベアネームが他のプラグインと衝突する場合に備えて。）
新しいバージョンは定期的にリリースされます。claude plugin update quality-strategy でアップデートを取得し、CHANGELOG.md で変更内容を確認してください。
標準的なフロー
/quality-strategy— メインイベント。構造化インタビューによりquality/strategy.mdを生成し、組み込み監査で終了します。さらに、フォローアップすべき次のステップを案内します。/test-strategy— 戦略を調査計画に変換します。何を、どの順序で、人間とエージェントの間でどのように分担して調査するかを定義します。/tooling-strategy— ドキュメントから、まだ測定・判断できない事項（これはよくあることで、失敗ではなく発見です）が明らかになった場合に、不足しているオラクルや計測器を優先的に構築するための計画を提供します。リスクマップがほとんど盲目的である場合、ステップ2と3は入れ替わります。スキルは自動的に適切な順序を推奨しますが、ユーザーが常に上書きできます。/strategy-variants(オプション) — 関係者向けの1ページ要約やクライアント向けのバージョンを生成します。/quality-artefacts(オプション) — 希望するビューを説明する（「品質の状況がわかるツイート可能なサマリー」「スタンドアップで使える決済リスクのダッシュボード」など）と、戦略からカスタムの自己完結型SVG/HTMLアーティファクトをデザインします。不明点（Unknowns）について正直に、スクリーンショットして共有できるように設計されています。実際の例はexamples/fernly/quality/artefacts/にあります。
スキル間の関係
ユーザーが開始する5つのスキル（太字）；残りはスキル実行時に呼び出されるチェックと監査です（点線の矢印 — それぞれ単独でも動作します）。スキルごとの詳細: docs/SKILLS.md。
flowchart TD
QS["<b>/quality-strategy</b><br/>7ステップのインタビュー — ここから開始"]
OA["/oracle-adequacy<br/><i>「現在地」の主張は<br/>実際に判断可能か？</i>"]
CC["/contradiction-check<br/><i>内部の一貫性、<br/>各ステップの境界</i>"]
OD["/operational-distillation<br/><i>ドキュメント冒頭の<br/>TL;DR + トリアージ基準</i>"]
QSR["/quality-strategy-review<br/><i>クロージング監査</i>"]
SDOC[/"quality/strategy.md"/]
TS["<b>/test-strategy</b><br/>調査計画"]
TA["/tooling-adequacy<br/><i>各学習ニーズに<br/>実際に答えられるか？</i>"]
TSR["/test-strategy-review<br/><i>クロージング監査</i>"]
TDOC[/"quality/test-strategy.md"/]
TOOL["<b>/tooling-strategy</b><br/>オラクル/計測器構築計画"]
ODOC[/"quality/tooling-strategy.md"/]
SV["<b>/strategy-variants</b><br/>オーディエンス向けバリアント"]
VDOC[/"1ページ要約 ·<br/>クライアント向けバージョン"/]
QA["<b>/quality-artefacts</b><br/>カスタム共有可能ビジュアル"]
ADOC[/"quality/artefacts/<br/>*.svg · *.html"/]
BUILD(["オラクル &<br/>計測器を構築"])
QS -.-> OA
QS -.-> CC
QS -.-> OD
QS -.-> QSR
QS --> SDOC
SDOC -->|"リスクマップが<br/>ほとんど回答可能"| TS
SDOC -->|"リスクマップがほとんど盲目的 —<br/>不明点 + オラクルギャップ"| TOOL
SDOC -->|"配布用の資料が必要"| SV
SDOC -->|"一目でわかる資料が必要 —<br/>見たいビューを説明"| QA
TS -.-> TA
TS -.-> TSR
TS --> TDOC
TDOC -->|"ブロックされた学習ニーズ —<br/>明確化された要求"| TOOL
TOOL --> ODOC
ODOC --> BUILD
BUILD -.->|"不明点が既知に —<br/>リスクマップを更新し、<br/>学習ニーズのブロックを解除"| SDOC
SV --> VDOC
QA --> ADOC
classDef sub fill:#f6f6f6,stroke:#aaaaaa,color:#444444
class OA,CC,OD,QSR,TA,TSR sub
classDef doc fill:#fdf6e3,stroke:#b58900,color:#333333
class SDOC,TDOC,ODOC,VDOC,ADOC doc
この構造はパックの4つの質問に従っています — 「良い状態」とは何か？どうやってそれを知るか？それが良い状態か？どうやって良い状態にするか？ — そして1つのルール: 判断できるものだけを調査できる。そのため、リスクマップの状態によって、調査計画と構築計画のどちらを先にするかが決まります。
期待できること
- インタビュー形式で進みます。 品質戦略はコードから推測できません。誰が重要か、彼らが何を価値とするか、何が非目標かはすべて誤って推測されるでしょう。スキルはリポジトリを事前に読み、情報に基づいた質問をします。重要なことはすべて、推測ではなく質問によって決定されます。
- 基準を厳格に守ります。 タスクが小さいからといって非目標をスキップしたり、厳密さを緩めたりしません。その厳格さこそが本質です。ただし、ユーザーに合わせて表現を調整し、ユーザーが行き詰まった場合には明確にラベル付けされた初期仮説を提供します。
- 生きたドキュメントを生成します。 一度書いて保存するためのものではなく、読み、更新し、意思決定の場で使用することを意図しています。
- 本当の思考を必要とします。 1〜2営業日分の認知時間を、複数のセッションに分けて計画してください。スキルは休憩を前提に設計されており、再開もシームレスです。2時間未満で完了することは、通常、回答が速すぎることを意味します。
- リポジトリは不要です。 アイデア段階では、事前読み込みは推測をスキャン結果のように見せかける代わりに、正直にインタビューから得られたものであると伝え、インタビューが常に担う役割を果たします。
既知の制限事項
- AI / 非決定性製品向けの専用次元がまだありません — 「正しさ」がドリフトするメトリクス分布であるシステム向けです。ステークホルダー/リスク/計画の仕組みは依然として役立ちますが、「良い状態とは何か、それをどうやって知るか」という中核は手作業で作成する必要があります。これは私たちの最優先研究項目です（ROADMAP.md）。
- 主にシミュレーションで検証されています。 多くの模擬ユーザーに対してストレステストされ、敵対的なレビューも受けていますが、実世界での使用実績は限られています。暫定的な判断は
OPEN-QUESTIONS.mdに記録されており、どのような情報があれば判断が変わるかも明記されています。 /tooling-strategyは最も新しいスキルであり、使用実績が最も少ないです。そのため、より荒い部分があると想定してください。- 適用範囲は一律です。 プロジェクトの規模に関わらず、すべての実行は同一の徹底的な処理を受けます。同じ厳密さをより軽量に表示することはロードマップにありますが、基準を下げることはありません。
- 単一リリースの深さ。 詳細な分析は一度に1つのリリースをカバーします。次のリリースのコンテキストが現実的になった時点で、改訂モードで再実行してください。
出自
これは Tollens からの最初のオープンソースリリースです。Tollensは、プロジェクトにとっての「良い」とは何か、そして実際にどの程度良いのかという暗黙の感覚を、人とAIエージェントの両方が推論できる明示的で生きたマップに変換するエンジニアリング管理コンサルタントです。このスキルパックは単独で動作する実用的なテイスターであり、アカウントは不要です。ただし、スタンドアロンのスキルであり、エンドツーエンドのワークフローではありません。ドキュメントをチームのプロセスに適合させるのはユーザーの責任です。完全なTollens製品（開発中）はエンドツーエンドバージョンです。すべてのステップをエージェントがサポートし、フィードバックループ、エビデンスとレポート、リリース信頼性評価を提供します。
簡単に言えば、このパックは「現在地」を示す矢印付きの地図です。Tollensはカーナビです。旅全体をターンバイターンで案内し、逸れたときに再計算し、信頼できる到着予定時刻を提供します。
ドキュメント構成
- docs/SKILLS.md — スキルごとのリファレンス（計画中のスキルを含む）。
- ROADMAP.md — 今後の予定（見出し: AI / 非決定性製品向けの品質次元）。
examples/fernly/— 架空のプロジェクトにおける完全な実例: 完全な戦略、テスト戦略、および3つの生成アーティファクト。あるプロジェクトの回答例であり、テンプレートではありません — README を参照してください。PHILOSOPHY.md— 根幹。なぜスキルがこのような動作をするのか。OPEN-QUESTIONS.md— 不確実性の下で行われた設計上の決定と、それを変える可能性のある情報。skills/— スキル自体。
フィードバック
誤作動があればお知らせください: Issueを開く。最も価値のある報告は具体的なものです。何を実行したか、何が生成されたか、何を期待していたか。特に歓迎するのは、インタビューが見逃した（または不必要に表面化した）次元、推測すべきところを推測した箇所、そして既知の制限事項が説明よりも深刻に影響しているケースです。
クレジット
品質フレームワークは Edmund Pringle によるもので、このパックが直接利用するオープンソースの**品質ブレイン**に集約されています。彼のブログシリーズは、このテーマに関する最も優れた読み物です。このフレームワークは、コンテキスト駆動型テストの伝統（Bach, Bolton, Weinberg）に基づいています。スキルの実装は Yanqing Cheng によるものです。Claude Codeで構築されました。
ライセンス
MIT (LICENSE-MIT) または Apache-2.0 (LICENSE-APACHE) のいずれかの条件の下でライセンスされています。明示的に別段の表明がない限り、Apache-2.0 ライセンスで定義されているように、あなたがこの作品に含めるために意図的に提出したすべての貢献は、追加の条項や条件なしに上記の通り二重ライセンスされます。