npx skills add https://github.com/boshu2/agentops --skill pr-plan为开源贡献制定战略规划。
创建一个连接研究与实现的贡献计划。接收 $pr-research 的输出并生成一个可执行的计划。
输出: .agents/plans/YYYY-MM-DD-pr-plan-{repo-slug}.md
使用时机:
$pr-research 之后不应使用的情况:
$plan)0. 输入发现 -> 查找/加载 pr-research 工件
1. 范围定义 -> 具体贡献什么
2. 目标选择 -> 解决哪些问题/领域
3. 标准定义 -> 来自研究的验收标准
4. 风险评估 -> 可能出现什么问题
5. 策略制定 -> 实施方法
6. 输出 -> 编写计划工件
广告位招租
在这里展示您的产品或服务
触达数万 AI 开发者,精准高效
| 问题 | 重要性 |
|---|---|
| 具体是什么功能? | 明确交付成果 |
| 哪些文件/包? | 限制影响范围 |
| 明确排除哪些内容? | 防止范围蔓延 |
| 单个 PR 还是系列 PR? | 设定预期 |
## 范围
**贡献内容**:[1-2 句话描述变更]
**影响区域**:
- `path/to/file.go` - [具体变更内容]
**排除范围**:
- [相关但被排除的工作]
从维护者的角度定义成功标准:
## 验收标准
### 代码质量
- [ ] 遵循项目编码风格
- [ ] 通过现有测试
- [ ] 为新功能添加测试
- [ ] 无代码检查警告
### PR 要求
- [ ] 标题遵循约定
- [ ] 正文使用项目模板
- [ ] 大小在可接受范围内
- [ ] 单一逻辑变更
### 项目特定要求
- [ ] [研究中发现的任何项目特定要求]
| 风险 | 可能性 | 影响 | 缓解措施 |
|---|---|---|---|
| PR 审核时间超过 2 周 | 中等 | 中等 | 从小处着手,及时响应 |
| 审核期间范围扩大 | 中等 | 高 | 预先明确定义范围 |
| 发现破坏性变更 | 低 | 高 | 针对多个版本进行测试 |
## 实施策略
### 方法
1. **设置**:Fork 仓库,配置开发环境
2. **理解**:阅读受影响区域的现有代码
3. **实施**:按照项目模式进行更改
4. **测试**:运行现有测试 + 添加新测试
5. **文档**:更新任何受影响的文档
6. **提交**:按照项目约定创建 PR
### 实施前检查清单
- [ ] Fork 已创建并与上游保持同步
- [ ] 开发环境正常工作
- [ ] 已认领问题或已发布评论
- [ ] 已查看最近的仓库活动
写入 .agents/plans/YYYY-MM-DD-pr-plan-{repo-slug}.md
# PR 计划:{repo-name}
## 执行摘要
{2-3 句话:贡献内容、原因、预期成果}
## 范围
**贡献内容**:{描述}
**影响区域**:[列表]
**排除范围**:[列表]
## 目标
**主要问题**:#{N} - {标题}
## 验收标准
[检查清单]
## 风险评估
[表格]
## 实施策略
[编号步骤]
## 后续步骤
1. 认领/评论目标问题
2. Fork 并设置开发环境
3. 按照策略实施
4. 准备就绪后运行 `$pr-prep`
$pr-research <repo> -> $pr-plan <research> -> implement -> $pr-prep
用户说: "根据我的 PR 研究工件创建一个贡献计划。"
会发生什么:
用户说: "检查这个 PR 计划对于一个提交来说是否太大。"
会发生什么:
| 问题 | 原因 | 解决方案 |
|---|---|---|
| 计划验收标准模糊 | 标准不可衡量 | 将标准转换为具体的行为检查 |
| 范围太广 | 混合了多个关注点 | 按用户可见的变更或子系统边界拆分 |
| 风险部分薄弱 | 缺少故障模式分析 | 明确添加集成、审核和回滚风险 |
| 计划与仓库规范冲突 | 研究工件不完整 | 重新运行 $pr-research 并刷新约束 |
每周安装量
128
仓库
GitHub 星标数
197
首次出现
2026年2月18日
安全审计
安装于
opencode128
github-copilot125
codex125
kimi-cli125
gemini-cli125
amp125
Strategic planning for open source contributions.
Create a contribution plan that bridges research and implementation. Takes $pr-research output and produces an actionable plan.
Output: .agents/plans/YYYY-MM-DD-pr-plan-{repo-slug}.md
When to Use :
$pr-researchWhen NOT to Use :
$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
| Question | Why It Matters |
|---|---|
| What specific functionality? | Clear deliverable |
| Which files/packages? | Limits impact surface |
| What's explicitly out of scope? | Prevents scope creep |
| Single PR or series? | Sets expectations |
## Scope
**Contribution**: [1-2 sentences describing the change]
**Affected Areas**:
- `path/to/file.go` - [what changes]
**Out of Scope**:
- [Related but excluded work]
Define success from maintainer perspective:
## 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]
| Risk | Likelihood | Impact | Mitigation |
|---|---|---|---|
| PR review takes > 2 weeks | Medium | Medium | Start small, be responsive |
| Scope expands during review | Medium | High | Define scope clearly upfront |
| Breaking change discovered | Low | High | Test against multiple versions |
## 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
Write to .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
User says: "Create a contribution plan from my PR research artifact."
What happens:
User says: "Check if this PR plan is too large for one submission."
What happens:
| Problem | Cause | Solution |
|---|---|---|
| Plan has vague acceptance criteria | Criteria not measurable | Convert criteria to concrete behavioral checks |
| Scope too broad | Multiple concerns mixed | Split by user-visible change or subsystem boundary |
| Risk section is weak | Missing failure-mode analysis | Add integration, review, and rollback risks explicitly |
| Plan conflicts with repo norms | Research artifact incomplete | Re-run $pr-research and refresh constraints |
Weekly Installs
128
Repository
GitHub Stars
197
First Seen
Feb 18, 2026
Security Audits
Gen Agent Trust HubPassSocketFailSnykPass
Installed on
opencode128
github-copilot125
codex125
kimi-cli125
gemini-cli125
amp125
站立会议模板:敏捷开发每日站会指南与工具(含远程团队异步模板)
10,500 周安装
Docker安全指南:全面容器安全最佳实践、漏洞扫描与合规性要求
177 周安装
iOS开发专家技能:精通Swift 6、SwiftUI与原生应用开发,涵盖架构、性能与App Store合规
177 周安装
describe技能:AI驱动结构化测试用例生成,提升代码质量与评审效率
2 周安装
专业 README 生成器 | 支持 Rust/TypeScript/Python 项目,自动应用最佳实践
2 周安装
Django 6 升级指南:从 Django 5 迁移的完整步骤与重大变更解析
1 周安装
GitLab DAG与并行处理指南:needs与parallel优化CI/CD流水线速度
2 周安装