skill-factory について
skill-factoryはCodex CLI向けのスキルで、自然言語仕様に照らした多段階の検証を進めます。シナリオ生成、ホールドアウト評価、満足度スコアリング、レポート確認を行います。
主な機能
- 018段階のファクトリー実行手順
- 02NLSpecの検証ゲート
- 03シナリオカバレッジのレビュー
- 04ホールドアウトテストと採点
- 05ファクトリーレポートの確認
活用シーン
- 01NLSpecに照らした実装評価
- 02エッジケースのシナリオ網羅性確認
- 03ホールドアウト結果と満足度スコアの確認
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ nyldn/ claude-octopus --skill skill-factoryインストール後、Claude Code で/skill-factoryを入力して読み込まれたか確認します。
同梱ファイルagents/openai.yaml
詳細
ホスト:Codex CLI — このスキルは Claude Code 向けに設計され、Codex 用に調整されています。 相互参照コマンドでは、
/octo:*スラッシュコマンドではなく、Codex にインストールされたスキル名を使用します。 現在の Codex シェルとサブエージェントのツールを使用してください。現在のセッションで利用可能であることが確認されるまでは、プロバイダー、モデル、またはホストのサブエージェントが利用可能だと断言しないでください。 ホストツールに相当する機能については、skills/blocks/codex-host-adapter.mdを参照してください。
停止 - スキルはすでに読み込まれています
Skill() を再度呼び出さないでください。直接実行してください。
実行手順(必須 — 8 ステップの手順、スキップ不可)
ステップ 1:確認の質問(必須)
ほかのアクションを実行する前に、AskUserQuestion を使って質問してください。
- 仕様の場所 — NLSpec ファイルのパス、または内容の貼り付け
- 満足度の目標値の上書き — 仕様のデフォルトを使用/カスタム値 0.80-0.99
- 費用の承認 — 約 20~30 回のエージェント呼び出しで約 0.50-2.00 USD(承認/--ci を承認/拒否)
コマンド内に仕様のパスが指定されている場合はそれを使用しますが、残りの質問は引き続き尋ねてください。 ユーザーが「skip」と言った場合は、デフォルトを使用して続行してください。 回答を得るまで、ステップ 2 に進まないでください。
ステップ 2:視覚的なインジケーターを表示(必須 — ブロック条件)
プロバイダーを確認します。
command -v codex &> /dev/null && codex_status="Available" || codex_status="Not installed"
command -v agy &> /dev/null && agy_status="Available" || agy_status="Not installed"
バナーを表示します。
🐙 CLAUDE OCTOPUS ACTIVATED - Dark Factory Mode
Pipeline: Parse → Scenarios → Embrace → Holdout → Score → Report
Providers:
Codex CLI - <status> — Scenario generation + holdout evaluation
Antigravity CLI - <status> — Additional external-model challenge
Claude - Orchestration + satisfaction scoring
Spec: <path>
Estimated: 0.50-2.00 USD / 15-45 min
検証:すべての外部プロバイダーが利用できない場合は、Claude のみで続行します(多様性が低下することをユーザーに警告してください)。少なくとも 1 つ利用可能な場合は、通常どおり進めます。
ステップ 3:仕様ファイルを検証(必須 — 検証ゲート)
if [[ ! -f "<spec_path>" ]]; then
echo "ERROR: Spec file not found at <spec_path>"
exit 1
fi
# Check minimum content
word_count=$(wc -w < "<spec_path>")
if [[ $word_count -lt 20 ]]; then
echo "WARNING: Spec is very thin ($word_count words). Results may be limited."
fi
仕様ファイルが見つからない場合は停止し、正しいパスをユーザーに尋ねてください。 仕様の内容が乏しい場合(50 語未満)は警告してから続行してください。 ファイルが存在しない場合、このゲートを通過して先に進んではいけません。
ステップ 4:以前の状態を読み込む(任意)
"${HOME}/.claude-octopus/plugin/scripts/state-manager.sh" init_state 2>/dev/null || true
"${HOME}/.claude-octopus/plugin/scripts/state-manager.sh" set_current_workflow "factory" "factory" 2>/dev/null || true
失敗した場合は、状態なしで続行し、ユーザーに警告してください。
ステップ 4.5:敵対的シナリオの網羅性ゲート(推奨)
コストのかかる embrace フェーズ(約 0.50-2.00 USD)を開始する前に、生成されたシナリオが仕様のエッジケースを実際に網羅していることを確認してください。 ここでプロバイダー間の簡易レビューを行えば、シナリオの網羅性が不十分なままファクトリー全体を実行する無駄を防げます。
orchestrate.sh が仕様を解析した後(フェーズ 1~2)、embrace の実行前(フェーズ 4)に、シナリオ網羅性レビューを実行してください。
2 つ目のプロバイダーが利用可能な場合は、Octopus のルーティングを通じてレビューを依頼します。
# Read the spec to extract behaviors and constraints
SPEC_CONTENT=$(<"<spec_path>")
review_provider=""
command -v codex >/dev/null 2>&1 && review_provider="codex"
[[ -z "$review_provider" ]] && command -v agy >/dev/null 2>&1 && review_provider="agy"
if [[ -n "$review_provider" ]]; then
"${HOME}/.claude-octopus/plugin/scripts/orchestrate.sh" spawn "$review_provider" \
"You are a QA adversary. Given this specification and generated scenarios, identify coverage gaps.
SPECIFICATION:
${SPEC_CONTENT}
Answer:
1. Which spec BEHAVIORS have no scenario testing them?
2. Which EDGE CASES from the spec constraints are untested?
3. Which FAILURE MODES are not covered (network failures, invalid input, concurrent access)?
4. Rate overall coverage: SUFFICIENT / GAPS-FOUND / CRITICAL-GAPS
Be specific — cite the behavior or constraint ID that lacks coverage." 2>/dev/null || true
fi
レビュー結果を受け取った後:
- CRITICAL-GAPS が見つかった場合:ユーザーに警告し、続行する前に
/octo:specで仕様を見直すよう提案してください - GAPS-FOUND の場合:不足点を伝えたうえで続行してください — ホールドアウトフェーズ(フェーズ 5)で一部を検出できます
- SUFFICIENT の場合:確信を持って続行してください
この簡易ゲートの追加所要時間は約 30 秒ですが、シナリオ網羅性の低い仕様で 2.00 USD のファクトリー実行を無駄にするのを防げます。
--fast を指定した場合、またはユーザーが徹底性より速度を明示的に優先した場合はスキップしてください。
ステップ 5:orchestrate.sh ファクトリーを実行(必須 — Bash ツール)
${HOME}/.claude-octopus/plugin/scripts/orchestrate.sh factory --spec "<spec_path>"
ステップ 1 の回答に応じて、以下のオプションフラグを付けます。
- カスタム比率が指定された場合は
--holdout-ratio <value> - カスタムの再試行回数が指定された場合は
--max-retries <value> - ユーザーが非対話モードを承認した場合は
--ci
ステップ 6:ファクトリーレポートを検証(必須 — 検証ゲート)
REPORT_FILE=$(find .octo/factory -name "factory-report.md" -mmin -60 2>/dev/null | sort -r | head -1)
if [[ -z "$REPORT_FILE" ]]; then
echo "ERROR: Factory report not found"
exit 1
fi
cat "$REPORT_FILE"
検証に失敗した場合は、エラーを報告し、~/.claude-octopus/logs/ のログを表示してください。先に進んだり、代替手段を使用したりしてはいけません。
ステップ 7:スコアを読み取り、結果を提示(必須)
SCORES_FILE=$(find .octo/factory -name "satisfaction-scores.json" -mmin -60 2>/dev/null | sort -r | head -1)
if [[ -n "$SCORES_FILE" ]]; then
cat "$SCORES_FILE"
fi
ユーザーに以下を提示します。
- 絵文字付きの判定(PASS/WARN/FAIL)
- 総合スコアと満足度の目標値との比較
- 項目別の内訳(動作、制約、ホールドアウト、品質)
- ホールドアウトの主な結果 — どのブラインドシナリオが合格/不合格だったか
- 詳細レビュー用の成果物ディレクトリのパス
STEP 8: 状態の更新と次のステップ(必須)
"${HOME}/.claude-octopus/plugin/scripts/state-manager.sh" record_decision "factory" "Factory run completed: <verdict> (<score>/<target>)" 2>/dev/null || true
判定に基づいて、次のステップを提案してください。
- PASS: 実装は仕様を満たしています。成果物を確認し、手動テストを実行して、リリースしてください。
- WARN: 目標に近い状態です。ホールドアウトの失敗を確認し、対象を絞った修正を検討してください。
- FAIL: 目標を下回っています。具体的な失敗については
holdout-results.mdを確認してください。以下を検討してください。/octo:specで NLSpec を改善する- 手動で修正し、
--max-retries 2で再実行する - 仕様を、より小さく明確な部分に分割する
帰属表示のフッターを含めてください。
Dark Factory Mode powered by Claude Octopus v8.25.0
Pipeline: Spec → Scenarios → Embrace → Holdout → Score → Report
Providers: Codex | Antigravity | Claude
エラー処理(ステップ別)
- Step 1(質問): ユーザーがすべて辞退した場合は、デフォルト設定で続行する
- Step 2(プロバイダー): 外部プロバイダーが両方とも利用できない場合は、Claude のみのモードで続行する(警告)
- Step 3(仕様): ファイルがない場合は停止する。仕様が簡素な場合は警告して続行する
- Step 4(状態): 失敗した場合は、状態を使用せずに続行する
- Step 5(orchestrate.sh): bash のエラーを表示し、ログを確認する — 代替処理は行わない
- Step 6(レポート): 見つからない場合はログを表示し、続行しない
- Step 7(スコア): JSON が見つからない場合は、レポートの Markdown から抽出する
- Step 8(状態): 失敗した場合は状態の更新をスキップし、結果は提示する
禁止事項
- orchestrate.sh によるファクトリー実行をスキップしてはならない
- ファクトリーのパイプラインをシミュレートまたは偽装してはならない
- 複数プロバイダーによるスコアリングの代わりに、Claude による直接分析を使用してはならない
- 仕様の検証ゲートをスキップしてはならない
- 検証ゲートに失敗した後、先へ進んではならない
- プラグインディレクトリ内に作業ファイルや進捗ファイルを作成してはならない