custom-skills-plan-analyze

Plan Analyze — Plan and Report Impact Analysis

How to Use

/custom-skills-plan-analyze @path/to/document.md

Receive a document, perform systematic multi-dimensional analysis, and output a structured assessment report.

---

Analysis Process

Phase 0: Document Identification and Context Establishment

1. If the document contains YAML frontmatter and has a type field, use it directly as the document type and skip to step 2; if not, continue to step 1 to infer from the content.

2. Read the target document and identify the document type:

   • Technical debt assessment / security report
   • Feature change proposal / RFC
   • Fix plan / Hotfix plan
   • Architecture Decision Record (ADR)
   • Test plan / deployment plan
   • Other (annotate type)

3. Identify the projects and files involved in the document:

   • If the document mentions specific file paths, attempt to read them to obtain full context
   • If the document is related to other reports (e.g., REPORT-008 → REPORT-009), prompt the user whether they need to be analyzed together

Phase 1: Analyze and Assess Thoroughness

Assess the analysis quality of the document itself:

Check Item	Description
Problem Definition	Is the problem clearly defined? Are there reproduction conditions or trigger scenarios?
Scope Definition	Is the scope of impact clear? Are related modules or files missing?
Root Cause Analysis	Is the root cause traced, rather than merely describing symptoms?
Evidence Support	Are conclusions supported by code snippets, logs, or data?
Risk Quantification	Are there clear criteria for determining risk levels? Is it overly optimistic or pessimistic?
Edge Cases	Have boundary conditions, abnormal inputs, and concurrency scenarios been considered?
Omission Detection	Are there aspects that "should be analyzed but are not mentioned"?

Output format:

### 1. 分析評估完善度

| 項目 | 評級 | 說明 |
|------|------|------|
| 問題定義 | [充分/部分/不足] | ... |
| ... | ... | ... |

**遺漏項**: [列出未涵蓋但應考慮的面向]

Phase 2: Feature Design Completeness

Assess whether the proposed modification or design is complete:

Check Item	Description
Modification Scope	Have all locations that need modification been listed?
Backward Compatibility	Does the modification maintain backward compatibility of the API / data format?
Data Migration	Is a database migration needed? Is the migration plan complete?
Configuration Changes	Is it necessary to modify configuration files, environment variables, or deployment settings?
Dependency Impact	Does it affect upstream/downstream modules or third-party integrations?
Error Handling	Is the handling of exceptional scenarios complete?
Rollback Plan	If the modification fails, is there a rollback strategy?

Output format:

### 2. 功能設計完整性

| 項目 | 評級 | 說明 |
|------|------|------|
| 修改範圍 | [完整/部分/不足] | ... |
| ... | ... | ... |

**缺失項**: [列出設計中未涵蓋的必要元素]

Stage 3: Impact Assessment on Existing Processes

Analyze whether the changes break existing functionality:

1. Identify affected business processes

   • List all business processes involved in the changes (e.g., checkout process, order creation, payment confirmation)
   • Mark each process as: [No impact / Low impact / Medium impact / High impact]

2. Call chain tracing

   • If the source code is readable, trace the callers and callees of the modified functions
   • Identify whether there are implicit coupling relationships

3. State and data flow analysis

   • Do the changes alter the format, type, or flow of data?
   • Do they affect state storage such as cache, Session, Cookie, etc.?

4. Concurrency and timing impact

   • Do the changes affect concurrency handling logic?
   • Could race conditions occur?

Output format:

### 3. 既有流程影響評估

**受影響流程**:
| 流程 | 影響程度 | 說明 | 是否已處理 |
|------|----------|------|------------|
| ... | ... | ... | [是/否/不適用] |

**呼叫鏈風險**: [描述或「無額外風險」]

Stage 4: Potential Anomalies and Side Effects

Identify unexpected issues that the changes may cause:

Check aspect	Description
Performance impact	Do newly added queries, loops, or I/O affect performance?
Security	Does it introduce new attack surfaces? Does it follow the principle of least privilege?
Observability	Can anomalies in the modified behavior be detected through logs/monitoring?
Test coverage	Do the changes have corresponding tests? Do existing tests need to be updated?
Deployment risk	Is a special deployment order or downtime maintenance required?
Documentation synchronization	Do API documentation and user documentation need to be updated in sync?

Output format:

### 4. 潛在異常與副作用

| 面向 | 風險等級 | 說明 | 建議 |
|------|----------|------|------|
| ... | [無/低/中/高] | ... | ... |

Stage 5: Comprehensive Assessment and Recommendations

### 5. 綜合評估

**整體評級**: [通過 / 有條件通過 / 需修改 / 不建議執行]

**關鍵發現**:
1. ...
2. ...

**建議行動**:
| 優先級 | 行動 | 理由 |
|--------|------|------|
| P0 (阻擋) | ... | ... |
| P1 (重要) | ... | ... |
| P2 (建議) | ... | ... |

**結論**: [一段話總結]

Stage 6: Feedback and Supplements

After the analysis is complete, ask the user:

The above analysis found some items not covered by the original document. Should these new findings be added to the original plan/report?

If the user agrees:

1. Read the original document
2. Append or integrate the new findings into the document in an appropriate format (preserve the original content, adding them as a "Supplementary Analysis" section) If a standalone supplementary analysis document is produced (rather than appending to the original document), apply the filename format YYYYMMDDhh-NN-標題.md .
3. Confirm the modified content

---

Related Skill References

During the analysis, based on the types of issues found, proactively recommend that the user pair with professional Skills for in-depth analysis:

Trigger condition	Recommended Skill	When to reference
The document is a specification proposal and its structure is incomplete	/spec-driven-dev	Stage 1 — Recommend passing structural validation first before impact analysis
Requirements are vaguely described or lack acceptance criteria	/requirement-assistant	Stage 1 — Guide improvement when requirement quality is insufficient
Stage 4 identifies security risks as "Medium" or "High"	/security-scan	Stage 4 — Recommend in-depth security review
The changes involve refactoring or technical debt cleanup	/refactoring-assistant	Stage 2/3 — Recommend evaluating the refactoring strategy
Stage 4 identifies insufficient test coverage	/test-coverage-assistant	Stage 4 — Recommend evaluating test completeness
The changes have been implemented and are ready to be submitted	/code-review-assistant	Stage 5 — Recommend entering code review

Citation format (embedded in the output of the corresponding stage):

> **建議**：本分析識別到 [問題類型]，建議使用 `/skill-name` 進行深入評估。

---

Rating criteria

Overall rating determination

Rating	Condition
Pass	All aspects are "sufficient/complete", with no P0/P1 items
Conditional pass	P1 items exist but no P0; can proceed after supplementation
Requires modification	P0 items or multiple P1 items exist; the plan needs to be revised again
Execution not recommended	Fundamental design flaws or serious security risks exist

Risk level definitions

Level	Definition
High	May cause data loss, security vulnerabilities, or service interruption
Medium	May cause functional abnormalities or performance degradation, but there are mitigation paths
Low	Limited impact; can be handled in subsequent iterations
None	No identifiable risk

---

Notes

• If the source code mentioned in the document cannot be read, mark it in the assessment as [未驗證：無法存取原始碼], make inferences based on the document description, and clearly indicate the basis for the inference
• If the document references other reports, prompt the user whether to provide the related documents to improve analysis accuracy
• The analysis should remain objective and avoid relaxing technical review standards just because the document is well written
• Every conclusion must have corresponding evidence or a chain of reasoning; do not make unsupported assertions