開発のスキル

設計上の重要な決定をADRとして記録し、決定後の現行アーキテクチャの基準も確認するスキルです。作成・更新の要否や記録先を整理できます。

• 設計判断をADRに残すべきか判断したいとき
• 既存ADRを改訂・置き換えたいとき
• 設計変更後の現行構成を同期したいとき

要件や設計が曖昧な機能・UI・アーキテクチャ変更について、質問と選択肢を通じて判断事項を整理し、合意できる設計案にまとめます。計画や設計への反証的な検討にも対応します。

• 曖昧な機能要件を整理したいとき
• 設計案の利点とリスクを比べたいとき
• UIやAPIの変更を実装前に検討したいとき

ブランチ切り替えと作業中の変更がぶつかる場合などに、Git worktree が必要かを判断し、安全な作成・引き継ぎ・片付けまで整理します。

• 別ブランチを並行して作業したいとき
• 未コミット変更を保ってブランチを切り替えたいとき
• リポジトリ指定の worktree を用意したいとき

プロジェクト内で用語の意味が揺れたり、名称変更や廃止が生じたりしたときに、根拠を確かめて共有用語集の`CONTEXT.md`を更新するスキルです。

• 決定した用語を共有用語集に記録したいとき
• 用語集とコードの名称のずれを調べたいとき
• 承認済みの名称変更を反映したいとき

複数セッションにまたがる実装計画やレビュー地点のある計画を確認し、各作業を順に実行して検証と進捗記録を行うスキルです。

• 複数セッションにまたがる実装計画を進めたいとき
• レビュー地点のある計画を順に実行したいとき
• 進捗や計画との差分を記録しておきたいとき

検証済みの作業ブランチを、根拠と所有範囲を確認しながらマージ・保持・整理するスキルです。Gitの状態を読み戻し、統合や削除の結果も記録します。

• 検証済みブランチを統合したいとき
• ブランチを保持して一時worktreeを片付けたいとき
• 作業ブランチのPRを作成したいとき

承認済みの仕様や要件を、担当範囲・作業手順・検証方法が分かる実行可能な計画書にまとめるスキルです。

• 承認済み仕様から実装計画を作りたいとき
• 複数段階の作業を実行単位に分けたいとき
• 互換性と検証方法を計画に含めたいとき

複数の独立した実装タスクを同じセッションで進め、各タスクの仕様適合とコード品質を順にレビューしながら、計画全体を調整するスキルです。

• 実装計画の独立タスクを同じセッションで進めたいとき
• 委任した作業を仕様と品質の両面で確認したいとき
• タスクごとの進捗や計画との差分を管理したいとき

コードレビューの指摘を実装する前に、曖昧さや既存コードへの影響を確かめ、必要なら質問や技術的な根拠を添えて対応方針を決めるスキルです。

• 曖昧なレビュー指摘を確認したいとき
• 修正による影響を調べたいとき
• 技術的な理由を添えて提案に返答したいとき

古い処理や重複した担当箇所、不要なフォールバックを安全に整理するスキルです。外部互換性や永続データへの影響を分類し、削除時の確認と検証を促します。

• 古い内部処理やフォールバックを整理したいとき
• 重複した情報源を統合したいとき
• スキーマや永続化の移行を計画したいとき

バグやテスト失敗の原因を証拠に沿って調べ、責任を持つ箇所を特定してから修正と検証を進めるスキルです。局所的な対症療法を避けるための判断も支援します。

• バグの再現手順と原因を調べたいとき
• テスト失敗の原因を修正前に確認したいとき
• 共有処理の修正箇所を見極めたいとき

Codexでコードの実装・修正・調査を進める際、依頼の範囲を守り、原因に沿った保守しやすい変更と根拠のある完了確認を促します。

• 依頼範囲を守って機能を実装したいとき
• 不具合の根本原因を調べたいとき
• コードレビューの根拠を明確にしたいとき

PRやMRに寄せられたGreptileの指摘を確認し、対象を絞った修正と再レビューを繰り返して、現行リビジョンの評価と未対応事項を整理します。

• PRのGreptile指摘を修正したいとき
• MRのレビューを再依頼して確認したいとき
• Perforceの変更をレビューしたいとき

Webページや画像の変更前後を同じ条件で撮影し、画面の差を比べるためのスクリーンショットと、必要に応じて共有用Markdownを作成します。

• UI変更の前後を比較したいとき
• PR用の画面比較資料を作りたいとき
• 特定のページ要素だけ撮影したいとき

通常のトリガーで大きなPRを処理できない場合に、`greploop` のワークフローを `@greptile-apps` トリガーで実行する互換用エントリーポイントです。

• 大きなPRをGreptile Appsで処理したいとき
• 通常のトリガーで扱えないPRをレビューしたいとき
• 既存のgreploopワークフローを指定トリガーで実行

複数の機能で重複する処理を整理し、業務ルールを担うアクションと再利用できる処理を担うサービスの分け方や移行手順を示します。

• 重複した処理を共通化すべきか判断したいとき
• 業務ルールと共通処理の置き場所を整理したいとき
• 複数の呼び出し元を段階的にリファクタリングしたいとき

機能追加や修正に着手する前に、作業ごとのGit worktreeとブランチを用意し、既存の担当作業や変更範囲を確認して安全に編集を進めます。

• 機能追加を専用ブランチで始めたいとき
• 共有チェックアウトを保って修正したいとき
• 既存PRとの変更範囲を確認したいとき

トークン数を基準に大きすぎるソースファイルを見つけ、概念ごとに分割し、今後の肥大化を防ぐコミット前チェックを整えるスキルです。

• 上限超過のソースファイルを見つけたいとき
• 大きなファイルを概念ごとに分けたいとき
• コミット前にファイルサイズを確認したいとき

TypeGPU/WebGPUの描画処理を変更するときに、パスやGPUリソースの所有者をそろえ、画面に映る範囲に応じた負荷と実機画像での検証を保つ指針です。

• 描画パスを追加・変更したいとき
• シェーダーやフレーム処理を調整したいとき
• GPUリソースの寿命を見直したいとき

コーディングセッションの記録を振り返り、ファイルの探しやすさ、自動チェック、規約、ツール利用などから次回に向けた改善案を整理します。

• コーディング作業を振り返りたいとき
• 自動チェックの不足を見つけたいとき
• 開発環境の改善候補を整理したいとき

ローカルのCodex CLIを独立した確認役として使い、まとまった変更のレビューを依頼します。実装の委任は利用者が明示した場合に限り、依頼文や結果確認の進め方も扱います。

• 大きな変更を別の視点でレビューしたいとき
• 明示した作業をCodexに委任したいとき
• Codexへの依頼文を整理したいとき

変更したコードの命名や古い記述、複雑さ、コメント、テストの観点を確認し、問題をファイルと行番号付きで整理します。

• コミット前に差分を確認したいとき
• リファクタリング後の古い記述を探したいとき
• テストやコメントを監査したいとき

実装が完了した仕様書を `specs/done/` に移し、計画を設計理由や守るべき原則、実装コードへの案内を残す記録に整えるスキルです。

• 完了した仕様書をアーカイブしたいとき
• 設計判断や不変条件を記録したいとき
• 計画と実装の差分を残したいとき

大規模な機能開発を、個別に実装・検証・レビューできる段階へ分け、画面確認や調査も含む仕様書にまとめます。

• 大規模機能を検証可能な段階に分けたいとき
• 開発前に要件やリスクを整理したいとき
• 画面確認を含む実装計画を作りたいとき