Preamble
echo "🚀 上线执行方案制定工具已启动"
Write-time boundaries
When only discussing, do not write files; startup checks do not create directories. When the user asks to save artifacts, first confirm the current product, the exact output path, and the overwrite/append choice for existing files; after confirmationonly immediately before the actual Writecreate the parent directory of that output file. For complete installation, see skills/_shared/artifact-policy.md, and installing this skill alone also follows this paragraph.
Cross-Agent interaction rules
When the process requires interaction with the user:
- If the current environment supports AskUserQuestion, use AskUserQuestion (best experience).
- If the current environment does not support AskUserQuestion, you must ask the same question using a normal chat message.
- Ask only one question at a time.
- After asking, you must stop the current turn and wait for the user to answer (STOP and WAIT).
- Do not generate documents or write to docs before the user answers.
- Existing docs files cannot replace the user's answer in this round.
Execution process
Step 1: Determine the go-live strategy
Use AskUserQuestion:
📦 Go-live strategy selection
Choose the method for this go-live:
A) Full release (release to all users at once) B) Gradual release (gradually open up the user percentage) C) Blue-green deployment (old and new versions in parallel) D) Canary release (small-traffic validation)
Continue asking:
🌍 Environment deployment strategy
Which environments need deployment?
A) Production environment only B) Test environment → Production environment C) Development environment → Test environment → Staging environment → Production environment D) Custom environment process
Step 2: Create the go-live checklist
Use AskUserQuestion:
✅ Go-live check items
Which items must be checked? (multiple selections allowed)
A) Functional testing (core function verification) B) Performance testing (stress testing, capacity verification) C) Security testing (vulnerability scanning, permission verification) D) Compatibility testing (multiple platforms, multiple browsers) E) Data backup (database, configuration files) F) Monitoring and alerting (logs, metrics, alert rules) G) Complete documentation (user manual, operations documentation) H) All checks
Step 3: Plan the release time
Use AskUserQuestion:
⏰ Release time window
Choose an appropriate release time:
A) Weekday daytime (convenient for quickly responding to issues) B) Weekday nighttime (fewer users, smaller impact) C) Weekend nighttime (lowest peak period) D) Flexibly choose based on business characteristics
Continue asking:
📅 Release cadence
What is the release frequency?
A) Single release (completed in one go) B) Phased release (multiple versions rolled out gradually) C) Continuous release (multiple iterations, continuous optimization)
Step 4: Design the rollback plan
Use AskUserQuestion:
🔙 Rollback trigger conditions
Under what circumstances is a rollback needed?
A) A severe bug causes functions to be unavailable B) Severe performance degradation (response time, error rate) C) A surge in user complaints D) Data anomalies (key metrics plummet) E) All of the above
Continue asking:
⏱️ Rollback time requirements
From deciding to roll back to completing the rollback, the maximum acceptable time:
A) Within 5 minutes (fast rollback) B) Within 15 minutes (standard rollback) C) Within 30 minutes (slow rollback) D) Within 1 hour (acceptable)
Step 5: Plan the notification mechanism
Use AskUserQuestion:
📢 Launch notification recipients
Who needs to be notified? (multiple selections allowed)
A) Internal team (product, R&D, testing, operations) B) Management (project sponsor, department head) C) External users (release announcement, changelog) D) Partners (third-party services, channel partners) E) Customer service team (prepare FAQ in advance)
Step 6: Generate the launch execution plan
Use the Write tool to generate docs/04-风控管理/上线执行方案.md。
Subagent parallel acceleration (new in v2.0.0)
Use the Agent tool to execute independent subtasks in parallel, greatly shortening the total execution time.
Parallelizable subtasks
After the user information collection in steps 1-3 is complete, the following two tasks can be executed in parallel:
| Subtask | Description |
|---|---|
| Checklist orchestration | Automatically generate a complete launch checklist based on the launch strategy and check items |
| Rollback plan design | Output rollback operation steps based on rollback trigger conditions and time requirements |
Trigger method
Before generating the document in step 6, use the Agent tool to activate parallel execution of subtasks.
V1 vs V2 comparison
| Dimension | V1.1.0 (serial) | V2.0.0 (Subagent parallel) | Savings |
|---|---|---|---|
| Checklist | User confirms check items one by one | Agent generates the complete checklist in parallel | About 3 rounds of interaction |
| Rollback plan | Ask about rollback details sequentially | Agent automatically outputs rollback steps | About 2 rounds of interaction |
| Notification mechanism design | Ask about notification recipients one by one | Agent orchestrates the notification plan in parallel | About 2 rounds of interaction |
| Total interaction rounds | About 12-15 rounds | About 6-8 rounds | Reduced by 50%+ |
| Time estimate | 12-18 minutes | 6-9 minutes | Saves about 8 minutes |
Output file
Launch execution plan → docs/04-风控管理/上线执行方案.md
Output document template
# 上线执行方案
## 一、上线概况
- **上线策略**: [从步骤1提取]
- **环境部署**: [从步骤1提取]
- **发布时间**: [从步骤3提取]
- **回滚要求**: [从步骤4提取]
- **生成时间**: [当前时间]
---
## 二、上线策略
### 2.1 发布方式
**策略**: [从步骤1提取]
**选择理由**:
- [说明为什么选择此策略]
- [适用的场景]
### 2.2 灰度发布计划（如适用）
**阶段划分**:
- **阶段1**: 1% 用户（内部用户、白名单）
- **阶段2**: 10% 用户（观察期：24小时）
- **阶段3**: 50% 用户（观察期：12小时）
- **阶段4**: 100% 用户（全量发布）
**观察指标**:
- 错误率 < 1%
- 平均响应时间 < 500ms
- 用户投诉数 < 5起/小时
### 2.3 蓝绿部署方案（如适用）
**环境准备**:
- Blue环境：当前生产版本
- Green环境：新版本
**切换流程**:
1. 部署Green环境
2. 健康检查通过
3. 切换流量到Green
4. Blue环境待命（可快速回滚）
---
## 三、上线检查清单
### 3.1 功能测试
| 检查项 | 验收标准 | 负责人 | 状态 |
|--------|---------|--------|------|
| 核心功能验证 | 所有P0功能正常 | 测试负责人 | ⏳ 待测试 |
| 边界条件测试 | 异常情况处理正确 | 测试负责人 | ⏳ 待测试 |
| 兼容性测试 | 主流浏览器、设备正常 | 测试负责人 | ⏳ 待测试 |
| 回归测试 | 无严重Bug | 测试负责人 | ⏳ 待测试 |
### 3.2 性能测试
| 检查项 | 验收标准 | 负责人 | 状态 |
|--------|---------|--------|------|
| 压力测试 | 支持[XX]并发用户 | 性能工程师 | ⏳ 待测试 |
| 容量验证 | CPU < 70%，内存 < 80% | 运维工程师 | ⏳ 待验证 |
| 响应时间 | 平均 < 500ms，P99 < 2s | 性能工程师 | ⏳ 待测试 |
| 数据库性能 | 慢查询 < 1% | DBA | ⏳ 待验证 |
### 3.3 安全检查
| 检查项 | 验收标准 | 负责人 | 状态 |
|--------|---------|--------|------|
| 漏洞扫描 | 无高危漏洞 | 安全工程师 | ⏳ 待扫描 |
| 权限验证 | 越权访问测试通过 | 安全工程师 | ⏳ 待验证 |
| 数据加密 | 敏感数据加密存储 | 研发负责人 | ⏳ 待确认 |
| 日志脱敏 | 日志中无明文敏感信息 | 研发负责人 | ⏳ 待确认 |
### 3.4 数据备份
| 检查项 | 验收标准 | 负责人 | 状态 |
|--------|---------|--------|------|
| 数据库备份 | 全量备份完成 | DBA | ⏳ 待备份 |
| 配置文件备份 | 配置已备份到Git | 运维工程师 | ⏳ 待备份 |
| 回滚脚本准备 | 回滚脚本验证通过 | 研发负责人 | ⏳ 待准备 |
### 3.5 监控告警
| 检查项 | 验收标准 | 负责人 | 状态 |
|--------|---------|--------|------|
| 日志监控 | 日志正常输出 | 运维工程师 | ⏳ 待验证 |
| 指标监控 | Grafana面板配置完成 | 运维工程师 | ⏳ 待配置 |
| 告警规则 | 关键指标告警配置完成 | 运维工程师 | ⏳ 待配置 |
| 值班人员 | 上线期间有人值班 | 项目经理 | ⏳ 待安排 |
### 3.6 文档完备
| 检查项 | 验收标准 | 负责人 | 状态 |
|--------|---------|--------|------|
| 用户手册 | 更新用户操作文档 | 产品负责人 | ⏳ 待完成 |
| 运维文档 | 更新部署、配置文档 | 运维工程师 | ⏳ 待完成 |
| API文档 | 更新接口文档 | 研发负责人 | ⏳ 待完成 |
| 更新日志 | CHANGELOG已更新 | 产品负责人 | ⏳ 待完成 |
---
## 四、发布时间规划
### 4.1 发布时间窗口
**发布日期**: [YYYY-MM-DD]
**发布时间**: [HH:MM]
**预计时长**: [XX]小时
**选择理由**:
- [为什么选择这个时间]
- [用户访问低峰期/业务低峰期]
### 4.2 发布时间线
| 时间 | 任务 | 负责人 | 预计时长 |
|------|------|--------|---------|
| T-2h | 最终检查清单确认 | 项目经理 | 30分钟 |
| T-1h | 团队就位，最后一次同步 | 项目经理 | 15分钟 |
| T-0 | 开始上线 | 运维工程师 | - |
| T+0.5h | 环境部署、配置更新 | 运维工程师 | 30分钟 |
| T+1h | 功能验证（冒烟测试） | 测试负责人 | 30分钟 |
| T+1.5h | 监控指标观察 | 运维工程师 | 30分钟 |
| T+2h | 发布通知 | 产品负责人 | 15分钟 |
| T+4h | 灰度放开至10%（如适用） | 运维工程师 | - |
| T+24h | 全量发布完成 | 项目经理 | - |
---
## 五、回滚方案
### 5.1 回滚触发条件
**立即回滚**（红色预警）:
- ✅ 严重Bug导致核心功能不可用
- ✅ 错误率 > 5%
- ✅ 响应时间 > 5s
- ✅ 数据丢失或损坏
**评估后回滚**（黄色预警）:
- ⚠️ 性能下降明显（响应时间 > 1s）
- ⚠️ 用户投诉 > 10起/小时
- ⚠️ 关键指标下降 > 20%
### 5.2 回滚流程
Discover issue → Assess severity → Decide whether to roll back ↓ Notify relevant personnel (project manager, technical lead) ↓ Execute rollback operation ↓ Verify rollback success ↓ Post-mortem analysis
### 5.3 回滚操作步骤
#### 方式1：代码回滚
```bash
# 1. 切换到稳定版本分支
git checkout [稳定版本tag]
# 2. 重新构建
npm run build
# 3. 部署
kubectl set image deployment/app app=[新镜像]
# 4. 验证
curl -I https://app.example.com/health
Method 2: Database rollback
# 1. 停止应用写入
kubectl scale deployment/app --replicas=0
# 2. 恢复数据库
mysql -u root -p < /backup/backup_YYYYMMDD.sql
# 3. 验证数据完整性
mysql -u root -p -e "SELECT COUNT(*) FROM users;"
# 4. 重启应用
kubectl scale deployment/app --replicas=3
Method 3: Configuration rollback
# 1. 恢复配置文件
kubectl rollout undo deployment/app
# 2. 验证配置
kubectl get configmap app-config -o yaml
# 3. 重启应用
kubectl rollout restart deployment/app
5.4 Rollback time requirements
Target: [Extracted from step 4]
Fast rollback checklist:
- Rollback script prepared and verified
- Database backup can be quickly restored
- Configuration files under version control
- Rollback drill has been conducted
VI. Notification mechanism
6.1 Pre-launch notification
Notification time: [XX] hours before launch
Notification recipients: [Extracted from Step 5]
Notification Content:
【上线通知】
项目：[项目名称]
版本：[版本号]
时间：[YYYY-MM-DD HH:MM]
变更内容：[简要说明]
影响范围：[用户/功能]
联系人：[姓名+电话]
6.2 In-Release Notifications
Notification Nodes:
- Release Start
- Key Steps Completed
- Issues Encountered
- Release Complete
Notification Channels:
- Project Group (Real-time Sync)
- Email (Important Nodes)
- SMS (Emergency Situations)
6.3 Post-Release Notifications
Notification Time: Within [XX] hours after release completion
Notification Targets:
- Internal Team (Project Group)
- Management (Email)
- External Users (Announcements, Push Notifications)
- Customer Service Team (FAQ Document)
Notification Content:
【上线成功通知】
项目：[项目名称]
版本：[版本号]
上线时间：[YYYY-MM-DD HH:MM]
新增功能：[功能列表]
优化改进：[改进点]
问题修复：[修复内容]
已知问题：[如有]
反馈渠道：[联系方式]
VII. Monitoring and Alerting
7.1 Monitoring Metrics
Application Layer:
- Request Volume (QPS)
- Error Rate (5xx ratio)
- Response Time (P50, P95, P99)
- Concurrency
System Layer:
- CPU Usage
- Memory Usage
- Disk I/O
- Network Traffic
Business Layer:
- Active Users
- Core Feature Usage Rate
- Conversion Rate
- Average Order Value
7.2 Alerting Rules
| Metric | Threshold | Level | Notification Method |
|---|---|---|---|
| Error Rate | > 1% | Yellow | Project Group |
| Error Rate | > 5% | Red | Phone + Project Group |
| Response Time | > 2s | Yellow | Project Group |
| CPU Usage | > 80% | Yellow | Project Group |
| Memory Usage | > 90% | Red | Phone + Project Group |
7.3 Monitoring Dashboards
Monitoring Tools: Grafana / Alibaba Cloud Monitoring / Self-built Monitoring
Monitoring Dashboards:
- Real-time Traffic Dashboard
- Error Monitoring Dashboard
- Performance Monitoring Dashboard
- Business Metrics Dashboard
VIII. Emergency Response
8.1 Emergency Contacts
| Role | Name | Phone | Responsibilities |
|---|---|---|---|
| Project Manager | [Name] | [Phone] | Overall Coordination |
| Technical Lead | [Name] | [Phone] | Technical Decisions |
| Operations Lead | [Name] | [Phone] | System Operations |
| Test Lead | [Name] | [Phone] | Quality Assurance |
| Product Lead | [Name] | [Phone] | Business Decisions |
8.2 Emergency Response Process
发现问题 → 初步评估（5分钟内）
↓
通知相关人员 → 问题定位（15分钟内）
↓
制定方案 → 方案执行（30分钟内）
↓
验证结果 → 问题解决
↓
复盘总结
8.3 Issue Severity Levels
P0 - Critical Issue:
- Core functionality unavailable
- Data loss
- Security vulnerability
Response: Handle immediately, everyone stops current work
P1 - Critical issue:
- Major functionality failure
- Severe performance degradation
- Affects a large number of users
Response: Handle within 1 hour, assign a dedicated person
P2 - General issue:
- Minor functionality failure
- Affects a small number of users
Response: Handle within 24 hours, schedule into the iteration plan
IX. Post-launch Retrospective
9.1 Retrospective Timing
Retrospective meeting: Within [XX] days after launch
Participants:
- Project manager
- Technical lead
- Test lead
- Product lead
- Operations lead
9.2 Retrospective Content
Process review:
- Was the launch process smooth
- Was the checklist complete
- Was collaboration efficient
Problem analysis:
- What problems were encountered
- Root cause analysis of the problems
- How to avoid similar problems
Improvement measures:
- Process optimization suggestions
- Tool improvement suggestions
- Documentation improvement suggestions
9.3 Retrospective Output
Retrospective report:
- Launch overview
- Issue list
- Improvement measures
- Lessons learned
X. Next-step Recommendations
Recommended actions:
- /pm-change (establish a change management mechanism)
- /pm-retro (conduct an iteration retrospective)
- /pm-roadmap (update the product roadmap)
Output Quality Comparison
✅ Good example：
- 有数据引用：「根据 Q4 数据，留存率从 35% 降至 28%」
- 有验证来源：「数据来源：Google Analytics, 2025-12-01」
- 有明确建议：「建议将新手引导步骤从 5 步减少至 3 步」
❌ Bad example：
- 模糊结论：「数据表明留存率有所下降」
- 无来源：「根据经验，这个功能很重要」
- 没有行动建议：「留存是个问题」
Common Pitfalls / Red Flags — STOP
Stop immediately and backtrack if any of the following occurs:
| Pitfall | Correct approach |
|---|---|
| Drawing conclusions using "should", "probably", "seems" | Must be based on actual data and verification |
| Claiming completion without running checks | Verify first, then state |
| Skipping key steps due to time pressure | No exceptions; the tighter the time, the stricter you must be |
| The thought "this time it should be fine" | Re-verify every time |
Output Quality Check / Verification Checklist
- Prerequisites are met (input documents/data have been collected)
- All core steps have been executed
- Output document has been generated to
docs/directory - Every judgment is supported by data/evidence
- 2-3 follow-up skills have been recommended
⚠️ If any item fails → complete it before marking as done.
Project status: Launch execution plan has been formulated Generation time: [timestamp] Generation tool: super-pm
---
## 推荐下一步
执行完成后，输出：
✅ 上线执行方案已生成！
🎯 建议下一步：
1. /pm-change（建立变更管理机制）
2. /pm-retro（进行迭代复盘）
3. /pm-roadmap（更新产品路线图）