performance-bottleneck-analysis

Performance Bottleneck Analysis (Chinese Version)

When to Use

You need to combine load, metrics, and trace evidence to locate the resources and code paths that limit throughput or latency.
You need to conduct a risk review of existing solutions, results, or evidence and form actionable improvement items.
The input is incomplete, but you still need to first provide a usable initial version with hypotheses and information gaps.

The default output is Markdown, suitable for review, execution, and continuous supplementation.
When the user requests a table, CSV, JSON, or ticket format, retain the same risk, evidence, priority, and boundary fields.
If the output will enter an automated process, first confirm the field schema, enum values, and required fields.

First read and follow prompts/performance-bottleneck-analysis.md 's input, execution rules, minimum coverage checklist, and output order.
Supplement the scope, environment, version, constraints, evidence, and success criteria that truly affect judgment.
First conduct an input audit, then distinguish confirmed facts, reasonable assumptions, and questions to be confirmed.
Sort by risk and evidence strength, and produce results that can be directly executed, reviewed, or validated.
When information is insufficient, do not stop at asking questions: first deliver a constrained initial version and explain which conclusions cannot yet hold.

Each execution must read prompts/performance-bottleneck-analysis.md; it is the complete execution specification of this Skill.
When you need to evaluate or regress this Skill, read evals/eval.yaml and the matching evals/cases/ use cases.
Only read references/、examples/、scripts/ or output-formats.mdwhen the directory actually exists and the task requires it; do not assume assets that do not exist.

First confirm that the load model is valid
Bottleneck conclusions require cross-validation from multiple signals
Do not automatically equate high utilization with root cause
Do not fabricate system behavior, fields, data, metrics, or root causes that do not exist in the input.
Key conclusions must be linked to evidence; when evidence is insufficient, mark them as assumptions and provide validation methods.
Priority must state the basis in business impact, likelihood of occurrence, or detectability.

Covered: throughput inflection point, queuing, CPU, memory and GC, I/O, lock contention, connection pools, downstream dependencies.
Facts, assumptions, gaps, and recommendations have been distinguished.
High-risk items have clear priority, evidence, owner, or next step.
The output includes verifiable judgment criteria rather than vague statements.
No unauthorized production write operations or destructive actions were performed.

Listing only checkpoints without stating input conditions, expected results, or evidence.
Marking everything as high priority, losing the value of trade-offs.
Replacing domain judgment with tool names or general theory.
Directly refusing when input is incomplete, or conversely pretending the conclusion is already certain.

Start from the path most likely to cause business loss, security issues, or release blockage.
Use the smallest verifiable experiment to reduce uncertainty, and record reproduction conditions.
Enable the output to be directly executed and reviewed by another engineer.