nanostack

Nanostack — エンジニアリングワークフローのスキル

組み合わせて使えるエンジニアリングワークフローのスキルを利用できます。各スキルは、必要に応じてコンテキストを確認できる関連ファイルを含むフォルダーです。

利用可能なスキル

スキル	使用するタイミング	モード	主なファイル
/think	実装を始める前。質問を通じて大まかなアイデアを具体化し、代替案を検討し、セクションごとに設計を進めます。	—	think/references/forcing-questions.md、think/references/cognitive-patterns.md
/nano	重要な作業を始める前。範囲を定めた、実行可能な計画を作成します。	—	plan/templates/plan-template.md
/review	コードを書いた後。2段階のレビューに加え、スコープの逸脱を検出し、競合を解決します。	--quick --standard --thorough	review/checklist.md、reference/conflict-precedents.md
/qa	コードの動作を検証するとき。Playwright によるブラウザベースのテストと、根本原因のデバッグを行います。	--quick --standard --thorough	qa/bin/screenshot.sh
/security	リリース前。OWASP Top 10、STRIDE、バリアント分析、競合検出を行います。	--quick --standard --thorough	security/references/owasp-checklist.md、security/templates/security-report.md
/ship	PR の作成、マージ、デプロイ、検証を行うとき。成功時にスプリントジャーナルを生成します。	—	ship/templates/pr-template.md
/guard	本番環境、破壊的な操作、機密性の高いシステムの近くで作業するとき。	—	guard/bin/check-dangerous.sh
/feature	既存のプロジェクトに機能を追加するとき。/think を省略し、計画 → 実装 → レビュー → セキュリティ → QA → リリースへ直接進みます。	—	feature/SKILL.md
/conductor	スプリントを通じてエージェントの並列セッションを統括するとき。タスクの担当決めと成果物の引き渡しを調整します。	start claim complete status	conductor/bin/sprint.sh
/nano-run	初回セットアップ。スタック、権限、設定を会話形式で構成し、最初のスプリントを案内します。	—	start/SKILL.md
/nano-help	nanostack のすべてのコマンドと使用方法をすばやく確認できます。	—	help/SKILL.md

ワークフローの順序

デフォルトのワークフローは、/think → /nano → 実装 → /review → /security → /qa → /ship です。

/conductor を使うと、レビュー、セキュリティ、QA が並列で実行されます。いずれも実装に依存し、互いには依存しません。

think → plan → build ─┬─ review  ─┐
                      ├─ qa       ├─ ship
                      └─ security ─┘

本番環境や機密性の高いシステムの近くで作業する場合は、いつでも /guard を有効にしてください。

Zen

原則の全容は ZEN.md を参照してください。いずれかのスキルで判断に迷ったときは、こちらを確認してください。要約は次のとおりです。

• コードを書く前に、要件を問い直してください。
• 存在すべきでないものは削除してください。削除するまでは、残ったものを最適化しないでください。
• 目標はそのままに、スコープを絞ってください。
• 修正するか、質問してください。決して無視しないでください。
• セキュリティは妥協の対象ではなく、制約です。
• 求められたものよりも優れた成果を目指してください。

強度モード

/review、/security、/qa の各スキルは、強度モードに対応しています。

モード	フラグ	使用するタイミング	信頼度
Quick	--quick	軽微な変更（誤字、設定、ドキュメント）	9/10 — 明白な問題のみ
Standard	（デフォルト）	通常の変更	7/10 — 妥当な問題を検出
Thorough	--thorough	重要な変更（認証、決済、インフラ）	3/10 — 疑わしい点をすべて指摘

スキルは差分に基づいてモードを自動提案しますが、最終的に決めるのは常にユーザーです。

成果物の永続化

成果物の保存は必須です。 すべてのスキルは、完了後に成果物を保存する必要があります。

スキルは実行のたびに出力を自動的に .nanostack/ に保存します。

.nanostack/<phase>/<timestamp>.json

これにより、以下が可能になります。

• スコープの逸脱検出 — /review が計画したファイルと実際のファイルを比較します
• 競合の検出 — /review と /security が互いの所見を相互参照します
• スプリントジャーナル — /ship がすべてのフェーズの成果物からジャーナルエントリーを生成します
• 傾向の追跡 — セキュリティ上の所見は時間とともに減少していますか？

自動保存はデフォルトで有効です。ユーザーは .nanostack/config.json で auto_save: false を設定すると無効にできます。

保存前に成果物が検証されます。save-artifact.sh は、無効な JSON、必須フィールド（phase、summary）の欠落、フェーズの不一致を拒否します。

問題のあるセッションの成果物を破棄するには、bin/discard-sprint.sh を実行します（現在のプロジェクトと日付の成果物およびジャーナルエントリーを削除します）。

競合の解決

スキルが矛盾する指針を示した場合（例：/review が「エラーの詳細を増やす」と提案する一方、/security が「エラーの露出を最小限にする」と提案する場合）、競合解決フレームワークが適用されます。

1. デフォルトではセキュリティが優先されます — リスクが理論上のもの、または内部のみに関わる場合を除きます
2. 最終的な優先順位は状況によって決まります — 一般公開向けアプリ、内部ツール、スタートアップ、コンプライアンスなど
3. 競合は記録し、黙殺しません — 解決内容はすべてスキルの成果物に記録されます

既知の競合パターンと事前定義された解決策については、reference/conflict-precedents.md を参照してください。

プロジェクト設定

プロジェクトで初めて使用する際は、bin/init-config.sh --interactive を実行して .nanostack/config.json を作成します。ここには以下が保存されます。

• インストール済みエージェント — 自動検出されます（claude、codex、cursor、opencode、gemini）
• 検出されたスタック — node、go、python、docker
• 設定項目 — デフォルトの強度モード、自動保存、競合の優先順位

設定ファイルがある場合は、動作を調整するため、スキルの実行開始時に読み込みます。

bin/init-config.sh  # outputs current config or {} if none

スキルは設定を以下の目的で使用します。

• /review、/qa、/security：常に標準をデフォルトにするのではなく、preferences.default_intensity を読み込みます
• /security：スキル間の競合でどちらを優先するか判断するため、preferences.conflict_precedence を読み込みます
• /security：関連のないチェックを省くため、detected を読み込みます（Go プロジェクトでは Python の脆弱性をスキャンしません）

スキルごとの設定（security/config.json、guard/config.json）には、そのスキル固有の設定が保存され、そのスキルのみが読み込みます。

共通ルール

• 行動する前に読み込んでください。 すべてのスキルは、出力を生成する前に関連するコード、差分、設定を読み込む必要があります。確認せずに分析してはいけません。
• 湖を沸かし、海は沸かさないでください。 近道より数分多くかかるだけなら、完全に実施してください。数日かかるなら、実施しないでください。
• 成功だけでなく、失敗も記録してください。 スキルの実行中に問題（スクリプトエラー、誤ったアプローチ、予期しないプロジェクトの挙動など）が発生した場合は、記録してください。

  ~/.claude/skills/nanostack/bin/capture-failure.sh <skill> "<what went wrong>" "<what was tried>" "<what fixed it>"
  

  失敗は知識として蓄積されます。次のスプリントでは、同じ間違いを避けられます。これに /compound やリリースの成功は必要ありません。記録して先に進んでください。

積極的な提案トリガー

状況に合ったスキルを提案してください。ユーザーが思い出すのを待つ必要はありません。

トリガー	提案
ユーザーが「何を作るべきか」と尋ねる／方向性が不明確	/think
タスクが3つ以上のファイルに関わる、またはユーザーが「どう進めるべきか」と尋ねる	/nano
ユーザーが「完了した」「終わった」「レビューの準備ができた」と言う	/review
ユーザーが「これは動くか」「これをテストして」と言う、またはバグを報告する	/qa
リリース前、ユーザーが「デプロイの準備ができた」と言う、または差分が認証／環境変数／インフラに関わる	/security
ユーザーが「PRを作成して」「マージして」「リリースして」と言う	/ship
破壊的なコマンド、本番環境へのアクセス、または機密性の高い操作が検出される	/guard

使用ルール

• 新しいプロダクトに取り組む場合、または「何をするのか」が不明確な場合は、まず /think を実行してください
• 3 ファイルを超えるファイルに影響するものを作成する前に、/nano を実行してください
• 自分のコードに /review を実行してください。敵対的な観点からのチェックで、見落としを発見できます
• 本番環境にリリースする前に /security を実行することは必須です
• /guard は必要に応じて有効にしてください。常時有効のままにしないでください
• スキルは組み合わせて使用できます。/qa から /security のチェックを実行したり、/ship から /review を実行したりできます