mcpField
P
pr-plan

pr-plan

github.com/boshu2開発450593 回インストール今日更新
リポジトリ

pr-plan について

pr-plan は、`$pr-research` の調査結果をオープンソースへの貢献計画にまとめるスキルです。実装前に対象、受け入れ基準、リスク、進め方を整理します。

主な機能

  1. 01調査結果を貢献計画に変換
  2. 02範囲と対象領域の定義
  3. 03受け入れ基準の設定
  4. 04リスクと実装戦略の評価
  5. 05日付付き計画ファイルの作成

活用シーン

  1. 01リポジトリ調査後の貢献計画
  2. 02実装前の変更範囲の絞り込み
  3. 03大きな貢献を段階に分割

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/boshu2/agentops --skill pr-plan

インストール後、Claude Code で/pr-planを入力して読み込まれたか確認します。

同梱ファイルscripts/validate.sh

詳細

PR Plan Skill

オープンソースへの貢献に向けた戦略的な計画です。

概要

調査と実装をつなぐ貢献計画を作成します。$pr-research の出力を受け取り、実行可能な計画を作成します。

出力先: .agents/plans/YYYY-MM-DD-pr-plan-{repo-slug}.md

使用するタイミング:

  • $pr-research の完了後
  • 貢献戦略を計画するとき
  • 実装を始める前

使用しないタイミング:

  • リポジトリをまだ調査していないとき
  • 些細な貢献(誤字の修正など)
  • 内部プロジェクトの計画($plan を使用)

ワークフロー

0.  Input Discovery     -> Find/load pr-research artifact
1.  Scope Definition    -> What exactly to contribute
2.  Target Selection    -> Which issues/areas to address
3.  Criteria Definition -> Acceptance criteria from research
4.  Risk Assessment     -> What could go wrong
5.  Strategy Formation  -> Implementation approach
6.  Output              -> Write plan artifact

フェーズ 1:スコープの定義

スコープに関する質問
質問重要な理由
具体的にどの機能を対象としますか?成果物を明確にできます
どのファイル/パッケージを対象としますか?影響範囲を限定できます
明確に対象外とするものは何ですか?スコープの肥大化を防げます
1 つの PR にまとめますか、それとも複数に分けますか?想定を明確にできます
スコープのテンプレート
## Scope

**Contribution**: [1-2 sentences describing the change]

**Affected Areas**:
- `path/to/file.go` - [what changes]

**Out of Scope**:
- [Related but excluded work]

フェーズ 3:受け入れ条件

メンテナーの視点から成功の条件を定義します。

## Acceptance Criteria

### Code Quality
- [ ] Follows project coding style
- [ ] Passes existing tests
- [ ] Adds tests for new functionality
- [ ] No linting warnings

### PR Requirements
- [ ] Title follows convention
- [ ] Body uses project template
- [ ] Size within acceptable range
- [ ] Single logical change

### Project-Specific
- [ ] [Any project-specific requirements from research]

フェーズ 4:リスク評価

リスク発生可能性影響軽減策
PR のレビューに 2 週間以上かかる中中小さく始め、迅速に対応します
レビュー中にスコープが拡大する中高事前にスコープを明確に定義します
破壊的変更が見つかる低高複数のバージョンでテストします

フェーズ 5:実装戦略

## Implementation Strategy

### Approach

1. **Setup**: Fork repo, configure dev environment
2. **Understand**: Read existing code in affected area
3. **Implement**: Make changes following project patterns
4. **Test**: Run existing tests + add new tests
5. **Document**: Update any affected documentation
6. **Submit**: Create PR following project conventions

### Pre-Implementation Checklist

- [ ] Fork created and up-to-date with upstream
- [ ] Dev environment working
- [ ] Issue claimed or comment posted
- [ ] Recent repo activity reviewed

出力テンプレート

.agents/plans/YYYY-MM-DD-pr-plan-{repo-slug}.md に書き込みます。

# PR Plan: {repo-name}

## Executive Summary
{2-3 sentences: what you're contributing, why, expected outcome}

## Scope
**Contribution**: {description}
**Affected Areas**: [list]
**Out of Scope**: [list]

## Target
**Primary Issue**: #{N} - {title}

## Acceptance Criteria
[checklist]

## Risk Assessment
[table]

## Implementation Strategy
[numbered steps]

## Next Steps
1. Claim/comment on target issue
2. Fork and set up development environment
3. Implement following strategy
4. Run `$pr-prep` when ready

ワークフローとの統合

$pr-research <repo> -> $pr-plan <research> -> implement -> $pr-prep

例

対象を絞った外部貢献を計画する

ユーザーの発言:「PR の調査成果物をもとに、貢献計画を作成してください。」

実行内容:

  1. 受け入れられている慣習と制約を抽出します。
  2. スコープの境界と受け入れ条件を定義します。
  3. リスクを含む実装戦略を作成します。
コーディング前にスコープを絞る

ユーザーの発言:「この PR 計画は 1 回の提出には大きすぎないか確認してください。」

実行内容:

  1. 提案された変更を、過去の PR の規模の傾向と比較します。
  2. 大きすぎるスコープを段階的な貢献に分割します。
  3. 修正版の計画と次のステップのチェックリストを出力します。

トラブルシューティング

問題原因解決策
計画の受け入れ条件が曖昧条件が測定可能でない条件を具体的な動作確認項目に変換します
スコープが広すぎる複数の課題が混在しているユーザーに見える変更単位、またはサブシステムの境界で分割します
リスクの項目が不十分失敗モードの分析が不足している統合、レビュー、ロールバックのリスクを明示的に追加します
計画がリポジトリの慣習に合わない調査成果物が不完全$pr-research を再実行し、制約を更新します

コメント