mstack

Mstack

該当するプレイブックを選び、その名前を簡潔に示します。プレイブックは手順を定め、原則は判断の指針となります。補足ファイルは必要な場合にのみ読み込み、相対リンクは格納先のファイルを起点に解決します。

プレイブックの完了条件をチェックリストで管理します。該当するプレイブックがない場合は、明確な成果物と終了条件を含む、そのタスク専用のチェックリストを定義します。

委任または独立したレビューを行う場合は、orchestration を読みます。

明示的な @mstack の呼び出しでこのエントリーを読み込めない場合は、別のスキルで代用せず、その旨を報告します。

プレイブック

依頼	プレイブック
新規または変更された動作	機能
報告された不具合の修正	バグ修正
動作を変えない再構成	リファクタリング
新しい提案、スケッチ、または仕様	計画
既存の提案を洗練する	仕様の洗練
仕様を実装する	仕様の実装
コードまたはアーキテクチャの読み取り専用調査	調査
プロトタイプ作成または視覚的な同等性を目指す作業	プロトタイプ
パフォーマンス測定、修正、または段階的な最適化	パフォーマンス
本番環境の症状または記録されたトレースの診断	フォレンジック
独立したレビューまたは影響範囲の分析	レビュー
アーキテクチャ、競合する設計、または分割した調査	探索
公開、書き換え、トリアージ、フィードバックの修正、チェックの確認、または監視	PR ワークフロー
PR のリベース、またはマージ済みブランチとワークツリーの整理	PR ワークフロー
明示的なスタックまたはマージ	高度なデリバリー
長時間のアクティブセッションでのタスク、またはプロジェクト規模の実行	自律実行
レビュー可能な意思決定の記録を維持または監査	意思決定の記録
以前の作業を再開する	作業の再開
作業を引き継ぐ、または一時停止する	一時停止
プロジェクトの検証スキルを作成する	作成
プロジェクトの検証スキルを保守する	保守
質問を通して提案を徹底的に検証する	質疑
ドメイン用語を明確にする、または用語集や意思決定を記録する	ドメインモデリング
図やコードの構造スケッチを使って説明する	見せて
大きなビジュアルと最小限のテキストを使い、HTML で説明する	大きな絵、小さな言葉
変更やデータモデルを共有ツアー形式で読者に案内する	ツアー
コードを変更せずに複雑さを評価する	複雑さの提示
最近の作業と現在の状態を確認する	振り返り
現在のセッションを振り返り、スキルの教訓を得る	内省
現在の会話の進捗を要約する	状況共有
対象範囲の変更箇所（コード、文章、コメント）を整理する	コードの整理
文章を改善する	文章の整理
コメントの価値をレビューする	コメント
プロジェクトのコーディング規約を見つける、適用する、または調査する	コーディング規約
プロジェクトコードに関する教訓をルールまたはチェックとして記録する	記録
mstack の使い方または依存関係を説明する	ヘルプ

調査

問いと、それによって判断する内容を明確にします。ユーザーが別途成果物または実装を依頼していない限り、読み取り専用で進めます。

• 実行時の仕組みと所有者： how を使用します。
• 設計の根拠と過去からの制約： why を使用します。
• 設計案の比較：Why ではなく、Architecture を使用します。
• タイミングの傾向、遅いテスト、ベンチマーク： performance を使用します。実装の承認が得られるまでは読み取り専用で進めます。
• 学習を目的とした対話： teach を使用します。
• 本質的な複雑さと偶発的な複雑さ： show-complexity を使用します。

重要な経路をたどり、重大な失敗事例を調べ、実際のソースを引用します。有用であれば、独立した深掘り調査を委任します。根拠のある回答が得られた時点、または判断を左右する事実が明示的に入手できないと分かった時点で終了します。次のアクションを推奨するのは、それが調査結果から導かれる場合に限ります。調査を自動的にプロトタイプ、リファクタリング、PRへ発展させてはなりません。

共通ルール

• スコープ： Mstack は呼び出されたタスクに適用されます。選択したプレイブックが作業内容と終了条件を定めます。別のファイルを読んでも、それは指針を得るためのものであり、別のワークフローを開始する権限にはなりません。明示的なユーザー指示とリポジトリのルールがタスクを規定します。無関係な作業と、選択した納品ブランチを保持します。PR がマージまたはクローズされたブランチは、もはや納品ブランチではありません。
• 承認： コード作成を伴う実験を含め、実装には承認済みのスケッチまたは仕様書が必要です。合意済みのスケッチ、仕様書、またはフィードバック対応を再利用し、新たな証拠によって結果が大きく変わる場合は、改めて承認を求めます。読み取り専用の調査、依頼された計画策定、差分の確認には実装承認は不要です。実験は、明示的に破棄可能な隔離された対象で行います。コードを書く前に、プロジェクトの標準を確認して適用します。
• 納品： 承認済みのコーディング作業は、準備済みのワークスペースで開始します。承認済みのコーディングプレイブックでは、スコープ内のコミット、プッシュ、1 件の PR 作成、および必須 CI の修復が認められます。通常の納品作業はマージ前に終了します。スタックの使用とマージには明示的な依頼が必要です。
• 完了： 完了を主張する際は、依頼された結果に照らして観測した証拠を示します。実装とレビューには検証を使用します。未達の要件と、利用できないチェックまたは未実行のチェックを報告します。作業が阻まれた場合は、目標を変更したり要件を黙って緩和したりせず、再開可能な状態を保って支援を求めます。

原則

タスクの範囲内で原則を適用する前に、関連する原則を確認してください。判断に実質的な影響を与えた原則は、それぞれ名前とリンクを示し、変更した選択について説明してください。

判断する内容	確認する原則
コアデータ、状態、シグネチャ、または所有権	ドメインをモデル化する
検証、エラー、フレームワークまたはネットワークアダプター	境界を厳守する
リファクタリング、抽象化、削除、または読み手の負担	読み手の負担を最小限にする
要件の統合、または失敗した修正の繰り返し	前提を問い直す
ユーザーに見える動作と製品上のトレードオフ	体験を最優先する
重大な不確実性を伴う新しい設計	代替案を検討する
タスクの完了を宣言する	動作を検証する
テストの設計または評価	動作をテストする
ベンチマーク、パフォーマンスの主張、または評価スコア	数値を説明する
複数手順の作業、コミット、移行、またはスタック	検証可能な単位
並行して作業するライター、または共有された可変状態	所有権を分離する
大量の証拠、調査、または引き継ぎ	コンテキストを保護する
再試行可能なコマンドと部分的な失敗	操作を冪等にする
繰り返されるミス、または繰り返し発生する手作業	教訓を仕組みに組み込む

ツール

重大な判断には、推奨案と有意義な代替案を添えて question を使用してください。利用できない場合は、会話で対応してください。ユーザーに情報の提供を求めるのではなく、事実を調べてください。

ツール名を推測せず、利用可能なカタログから遅延読み込みのツールを見つけてください。

ユーザーが成果物のレビューを依頼した場合は、利用可能な Plannotator ツールを使用してください。