タスク仕様書ドメイン用L1 rubricを参照したいとき、Phase 1-13/SRP/ユビキタス言語の評価基準を確認したいときに使う。
インストール方法を見るインストールする前に、エージェントに与えられる指示の中身を確認できます。
設計書29 §3 の3層階層モデル (L0 共通 / L1 ドメイン / L2 プロジェクト) における L1 (タスク仕様書ドメイン特化) rubric。L0 (ref-skill-design-rubric) を upstream に継承し、タスク仕様書ドメイン固有のルール (Phase 1-13 整合、SRP、ユビキタス言語) のみを追加する。L2 (各 evaluator) からは upstream として参照される中間層。
入力: なし (参照型 Skill)
出力: references/rubric.json (L1 rubric 実体)
完了条件: 派生 evaluator が upstream チェーンを通じて本 rubric を解決できること。
upstream: ["plugins/harness-creator/skills/ref-skill-design-rubric/references/rubric.json"]plugins/skill-governance-config/config/rubric-registry.json の rubrics[] に登録L2 evaluator は references/rubric.json の upstream に本ファイル (plugins/harness-creator/skills/ref-domain-task-spec-rubric/references/rubric.json) を指定する。compose-rubrics.py が deep-merge を解決する。
Phase 1-13 整合、SRP 分解粒度、ユビキタス言語整合などタスク仕様書固有の評価軸のみを追加する。汎用 rule は L0 に置く。
compute-rubric-hash.py でハッシュを再生成し、registry に記録された値と一致することを確認する。
まだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
アプリ・Webサービス・業務ツールの制作を、証拠分析→確定的な初稿→要件定義→体験設計→機能分解→実装→品質ゲート→リリース判定の手順ゲート制で進めるスキル。質問で要件を埋めるのではなく、依頼文・既存コード・資料・ログから最有力案を選び、動く成果物を先に出して差分で改善する。ユーザーが「アプリを作りたい」「ツールを作って」「〜を自動化したい」「システム化したい」「要件定義」「仕様を決めたい」「UI/UXを設計して」「体験を良くしたい」「機能を洗い出して」「MVPを決めたい」「品質チェック」「リリースしていいか判断して」などと言ったら必ず使用する。外部データの取込・マスタ・締め処理を伴う業務システムでは references/data-lifecycle.md も併用する。新規・既存を問わずアプリの制作・改善・リニューアルで使用する。
Webアプリの準備→要件定義→設計→実装→公開→品質ゲートを実行する内部オーケストレーター。Claude Codeの /build-app /improve-app、Codexの $build-app / $improve-app から明示的に委譲された場合、custom agent起動時、または利用者が $app-orchestrator を明示した場合だけ使用する。一般のアプリ相談から暗黙起動しない。
run-extract-blueprint が生成した章別ブループリントの忠実性を独立 context で評価したいとき、事実/推測区別と粒度と被覆を検証し draft_hash に束縛した PASS/FAIL verdict をローカル品質ゲート (C01 の周回内の受入判定・差し戻し) へ渡したいときに使う。
確認点で利用者が見る深さを選んだあと打ち合わせ資料を作り手とは別の目で確かめたいとき、正確さ・言葉・見た目・シンプルさの指摘を資料の編集なしで受け取りたいときに使う。
生成した handout 資料が初心者に伝わるか読みやすさレビューを依頼したいとき、独立 context のレビュアーから指摘と根拠つきの verdict を回収したいときに使う。
Notion ページを描画する直前に粒度を検証したいとき、info-collector-agent ページと同等の section 充足度を section_canonical_map 基準で機械検証したいときに使う。