# Repo Improvement Factory > Analyze a software repository for meaningful improvements and, when explicitly requested, turn them into separate Japanese GitHub Issues, implement selected issues, create PRs, repair CI failures, and merge them. Use for repository-wide improvement discovery or an explicitly requested issue-to-merge workflow. Do not use for ordinary single-feature implementation, generic code explanation, or code review without improvement discovery. - Skill: `tensho1026/repo-improvement-factory` (Agent Skill) - Install (CLI): `npx skillmds@latest add tensho1026/repo-improvement-factory` - Raw SKILL.md: https://api.skillmd.com/api/skills/tensho1026/repo-improvement-factory/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Product & Planning - Author: tensho1026 (https://skillmd.com/u/tensho1026) - Updated: 2026-09-22 - Page: https://skillmd.com/skills/tensho1026/repo-improvement-factory --- # Repository Improvement Factory リポジトリを調査し、価値のある改善候補を発見して、ユーザーが指定した範囲まで完了させる。 ユーザーの指示は、このスキルの既定手順より常に優先される。 ## 作業範囲を先に決める ユーザーが依頼した範囲だけを実行する。 - 調査のみ: 改善候補を報告する。コード、Issue、ブランチ、PR、マージは変更しない。 - Issue作成まで: ユーザーがIssue作成を明示した場合だけ作成する。コードは変更しない。 - 実装まで: 対象Issueまたは合意された改善を実装し、必要な検証を行う。 - PR作成まで: ユーザーがPR作成を明示した場合だけ、commit、push、PR作成を行う。 - マージまで: ユーザーがマージを明示した場合だけ、条件を確認してマージする。 「コードは変更しない」などの否定条件を厳守する。依頼が調査だけなら、改善を見つけても外部状態を変更しない。 ## リポジトリを理解する 改善案を出す前に、必要な範囲で以下を確認する。 - `AGENTS.md`などのリポジトリ固有指示 - READMEと主要ドキュメント - 使用言語、フレームワーク、パッケージ構成 - アプリケーションの主要機能 - テスト、lint、型チェック、ビルド方法 - CI設定 - 現在のGit状態とユーザーの未コミット変更 - 既存Issue、PR、最近の変更履歴 既存コードを十分に理解する前に、一般論だけで改善案を量産しない。ユーザーの変更や依頼と無関係な変更を破棄・上書きしない。 ## 改善候補を発見する 次の観点から、実際のコードや設定に根拠がある候補を探す。 - 既存機能の不具合や不整合 - ユーザー体験とアクセシビリティ - パフォーマンス - セキュリティ - エラー処理と回復性 - データ整合性と型安全性 - テスト不足 - 開発者体験と保守性 - ドキュメントとCI/CD - 既存プロダクトに適合する新機能 候補ごとに以下を確認する。 1. 実際に問題または改善余地が存在するか 2. 根拠となるファイル、設定、ログ、挙動を示せるか 3. 既存IssueまたはPRと重複していないか 4. 独立したIssueとして実装・検証できるか 5. 利用者または開発者に明確な価値があるか 6. 修正規模とリスクに対して効果が妥当か 推測だけの候補、表面的な言い換え、価値の薄いリファクタリングで件数を水増ししない。 ## 優先順位を付ける 各候補を次の観点で評価する。 - Impact: 利用者や開発への効果 - Confidence: 根拠の確かさ - Effort: 実装と検証に必要な作業量 - Risk: 既存機能を壊す可能性 効果と確度が高く、作業量と危険性が低い候補を優先する。重大な不具合、セキュリティ、データ損失の危険は最優先として明示する。 ## GitHub Issueを作成する Issue作成が依頼された場合は、作成前に既存IssueとPRを検索して重複を避ける。 独立して実装・検証できる改善は別々のIssueにする。密接に結合していて、分離すると成立しない変更だけを同じIssueにまとめる。 ユーザーが別の言語を指定しない限り、タイトルと本文は日本語で書く。本文は次を基本とする。 ```markdown ## 概要 何を改善するかを簡潔に説明する。 ## 背景・問題 現在の挙動と、なぜ改善が必要なのかを説明する。根拠となる画面、処理、ファイルなどを示す。 ## 提案 望ましい変更内容を説明する。必要以上に実装方法を固定しない。 ## 受け入れ条件 - [ ] 外部から確認できる完了条件 - [ ] エラーや境界条件の確認 - [ ] 必要なテストまたはドキュメントの更新 ## 影響範囲 影響する機能、データ、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本文は次を基本とする。 ```markdown ## 概要 変更の目的と結果。 ## 変更内容 - 主な変更 - 必要な補足 ## 検証 - 実行したコマンド - 手動確認 - 実行できなかった確認 ## リスク 影響範囲や注意点。なければ「特になし」。 Closes #ISSUE_NUMBER ``` ## CI失敗を修正する CI修正が依頼された場合は、再実行を繰り返す前に失敗ログを読む。 1. 失敗したworkflow、job、stepを特定する 2. 最初の本質的なエラーを探す 3. ローカルで再現可能か確認する 4. 今回の差分が原因か既存問題かを区別する 5. 最小の修正を行う 6. 関連するローカル検証を実行する 7. CI結果を確認する 同じ失敗に対して、根拠のない変更や無制限の再実行を行わない。同じ原因が繰り返す場合は、原因、試した内容、必要な判断を整理して報告する。 ## マージする ユーザーが明示的にマージを依頼した場合だけ実行する。マージ前に以下を確認する。 - 対象PRが正しい - 必須CIが成功している - 未解決の競合がない - 未対応の重大なレビュー指摘がない - PR内容がIssueの範囲から逸脱していない 保護ルールの無効化、強制push、検証の迂回は、ユーザーの明確な指示なしに行わない。 ## 完了報告 ユーザーが別形式を指定しない限り、完了した範囲、IssueまたはPRへのリンク、主な変更、検証結果、未完了事項を日本語で簡潔に報告する。 何も変更していない場合は、そのことを明確に伝える。