tensho1026 Repository Improvement Factory
リポジトリを調査し、価値のある改善候補を発見して、ユーザーが指定した範囲まで完了させる。
ユーザーの指示は、このスキルの既定手順より常に優先される。
作業範囲を先に決める
ユーザーが依頼した範囲だけを実行する。
- 調査のみ: 改善候補を報告する。コード、Issue、ブランチ、PR、マージは変更しない。
- Issue作成まで: ユーザーがIssue作成を明示した場合だけ作成する。コードは変更しない。
- 実装まで: 対象Issueまたは合意された改善を実装し、必要な検証を行う。
- PR作成まで: ユーザーがPR作成を明示した場合だけ、commit、push、PR作成を行う。
- マージまで: ユーザーがマージを明示した場合だけ、条件を確認してマージする。
「コードは変更しない」などの否定条件を厳守する。依頼が調査だけなら、改善を見つけても外部状態を変更しない。
リポジトリを理解する
改善案を出す前に、必要な範囲で以下を確認する。
AGENTS.mdなどのリポジトリ固有指示- READMEと主要ドキュメント
- 使用言語、フレームワーク、パッケージ構成
- アプリケーションの主要機能
- テスト、lint、型チェック、ビルド方法
- CI設定
- 現在のGit状態とユーザーの未コミット変更
- 既存Issue、PR、最近の変更履歴
既存コードを十分に理解する前に、一般論だけで改善案を量産しない。ユーザーの変更や依頼と無関係な変更を破棄・上書きしない。
改善候補を発見する
次の観点から、実際のコードや設定に根拠がある候補を探す。
- 既存機能の不具合や不整合
- ユーザー体験とアクセシビリティ
- パフォーマンス
- セキュリティ
- エラー処理と回復性
- データ整合性と型安全性
- テスト不足
- 開発者体験と保守性
- ドキュメントとCI/CD
- 既存プロダクトに適合する新機能
候補ごとに以下を確認する。
- 実際に問題または改善余地が存在するか
- 根拠となるファイル、設定、ログ、挙動を示せるか
- 既存IssueまたはPRと重複していないか
- 独立したIssueとして実装・検証できるか
- 利用者または開発者に明確な価値があるか
- 修正規模とリスクに対して効果が妥当か
推測だけの候補、表面的な言い換え、価値の薄いリファクタリングで件数を水増ししない。
優先順位を付ける
各候補を次の観点で評価する。
- Impact: 利用者や開発への効果
- Confidence: 根拠の確かさ
- Effort: 実装と検証に必要な作業量
- Risk: 既存機能を壊す可能性
効果と確度が高く、作業量と危険性が低い候補を優先する。重大な不具合、セキュリティ、データ損失の危険は最優先として明示する。
GitHub Issueを作成する
Issue作成が依頼された場合は、作成前に既存IssueとPRを検索して重複を避ける。
独立して実装・検証できる改善は別々のIssueにする。密接に結合していて、分離すると成立しない変更だけを同じIssueにまとめる。
ユーザーが別の言語を指定しない限り、タイトルと本文は日本語で書く。本文は次を基本とする。
## 概要
何を改善するかを簡潔に説明する。
## 背景・問題
現在の挙動と、なぜ改善が必要なのかを説明する。根拠となる画面、処理、ファイルなどを示す。
## 提案
望ましい変更内容を説明する。必要以上に実装方法を固定しない。
## 受け入れ条件
- [ ] 外部から確認できる完了条件
- [ ] エラーや境界条件の確認
- [ ] 必要なテストまたはドキュメントの更新
## 影響範囲
影響する機能、データ、API、画面、設定などを記載する。
受け入れ条件は単なる作業手順ではなく、完了を観察できる条件にする。コード断片は理解に必要な場合だけ含める。
Issueを実装する
Issue本文だけで判断せず、関連コードと周辺仕様を確認する。実装は既存の設計、命名、依存関係、テスト方針に合わせる。
- Issueの受け入れ条件を満たす
- 変更範囲を必要最小限に保つ
- 無関係なリファクタリングを混ぜない
- エラー、空状態、境界値を考慮する
- 必要なテストを追加または更新する
- API、型、DB、UI、ドキュメントへの影響を確認する
- 一時的なデバッグコードを残さない
- 新しい警告や既知の退行を放置しない
複数Issueを実装する場合は、ユーザーがまとめるよう指定しない限り、Issueごとに変更とPRを分離する。
検証する
リポジトリに用意されている検証方法を優先する。変更内容とリスクに応じて、formatter、lint、typecheck、unit test、integration test、E2E test、build、視覚確認、migrationまたはschema検証から必要なものを実行する。
実行できない検証や既存の失敗がある場合は、成功したように扱わず明示する。
PRを作成する
PR作成が依頼された場合は、対象Issueへの変更に限定されていること、秘密情報がないこと、不要な生成物がないこと、検証結果が明確なことを確認する。
PR本文は次を基本とする。
## 概要
変更の目的と結果。
## 変更内容
- 主な変更
- 必要な補足
## 検証
- 実行したコマンド
- 手動確認
- 実行できなかった確認
## リスク
影響範囲や注意点。なければ「特になし」。
Closes #ISSUE_NUMBER
CI失敗を修正する
CI修正が依頼された場合は、再実行を繰り返す前に失敗ログを読む。
- 失敗したworkflow、job、stepを特定する
- 最初の本質的なエラーを探す
- ローカルで再現可能か確認する
- 今回の差分が原因か既存問題かを区別する
- 最小の修正を行う
- 関連するローカル検証を実行する
- CI結果を確認する
同じ失敗に対して、根拠のない変更や無制限の再実行を行わない。同じ原因が繰り返す場合は、原因、試した内容、必要な判断を整理して報告する。
マージする
ユーザーが明示的にマージを依頼した場合だけ実行する。マージ前に以下を確認する。
- 対象PRが正しい
- 必須CIが成功している
- 未解決の競合がない
- 未対応の重大なレビュー指摘がない
- PR内容がIssueの範囲から逸脱していない
保護ルールの無効化、強制push、検証の迂回は、ユーザーの明確な指示なしに行わない。
完了報告
ユーザーが別形式を指定しない限り、完了した範囲、IssueまたはPRへのリンク、主な変更、検証結果、未完了事項を日本語で簡潔に報告する。
何も変更していない場合は、そのことを明確に伝える。