ci-test-optimization

CI Test Pipeline Optimization (Chinese Version)

When to Use

When evidence-based analysis, design, or verification preparation is needed around pipeline stages, feedback latency, resources, variance, caching/sharding, and rollback boundaries.
When an existing plan, result, or metric needs review, and actionable improvement items need to be produced.
When inputs are incomplete, but a constrained initial version with assumptions, information gaps, and human decision boundaries still needs to be delivered.

Default output is Markdown, organized by domain risk, evidence status, priority, and boundaries.
When the user requests table, CSV, JSON, or ticket format, preserve the same finding fields, evidence, and decision boundaries.
Literal vertical bars in Markdown table cells (including inline code) must be written as \|, or the wording must be rewritten to avoid being parsed as an extra column.
Before output enters an automated process, first confirm the schema, enum values, required fields, and evidence sources.

First read and follow prompts/ci-test-optimization.md, including input audit, domain coverage, and output order.
Extract scope, environment, version, time window, constraints, success criteria, and available evidence, with emphasis on checking stage dependencies, feedback latency, resource usage, variance, caching, and sharding.
First distinguish confirmed facts, evidence-supported inferences, candidate recommendations, and Human decisions, then sort by risk and evidence strength.
Turn high-risk items into preconditions, steps, expected results or judgment criteria, required evidence, and verification methods.
When information is insufficient, deliver a constrained initial version, clarify which conclusions cannot hold, and do not write static materials as execution results.

When calibrating domain results, correct comparisons, or evidence gaps, read references/domain-decision-example.md for desensitized inputs, item-by-item expectations, and recomputation basis.
Every execution must read prompts/ci-test-optimization.md; it is the complete execution specification of this Skill.
When evaluation is needed, read evals/eval.yaml and the matching cases under evals/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.

Fix the comparison target by commit/run/runner/config/test-set ID; decompose queue, checkout/install, setup, execute, retry, and report from the event timeline, distinguishing end-to-end waiting from runner busy time.
Compute the actual critical path along the DAG; overlapping jobs are not added together; report retry counts and the original failure results, and do not hide the first failure with a green rerun.
Cache keys include project-relevant lockfile/toolchain/config identity; compare cold/warm, record hit and invalidation verification, and do not reuse mismatched caches to skip dependency validation.
Keep protection obligations, test sets, fault detection, resources, and windows comparable before/after; reject speedup candidates that delete tests or swallow failures, and propose measurable gains and rollback signals.

Only analyze pipeline stages, feedback latency, resources, variance, caching/sharding, and rollback boundaries; do not replace business owners or Human decisions on risk acceptance, exception approval, and release decisions.
Do not fabricate system behavior, fields, metrics, thresholds, data, root causes, execution records, or pass conclusions.
Static design, plans, file existence, or dry-run can only retain their original evidence status and cannot be upgraded to proof of real execution.
When evidence is insufficient, use pending confirmation, blocked, unassessed, or NOT_SCORED, and provide a minimal verification method.
When production, privacy, or security is involved, use least privilege, desensitized data, mocks, dry-run, or an isolated environment.

Stage dependencies, feedback latency, resource usage, fluctuations, caching, and sharding are covered, and the source, evidence status, and verification method are recorded for each item.
Facts, inferences, candidate recommendations, information gaps, and Human decisions are separated.
High-risk items have P0/P1/P2/P3 or equivalent priority, responsible roles, and closure conditions.
Plans, static checks, or dry-runs are not written as test execution, all passing, or release approval.
Residual risks, stop/escalation conditions, and next steps are stated.

Listing only checkpoints without explaining trigger conditions, expected focus points, responsible roles, closure conditions, and evidence.
Treating metrics or tool names from adjacent domains as the complete judgment of a CI test pipeline.
Using unexplained numbers to create false precision, or writing correlation as causation.
Directly refusing when the input is incomplete, or conversely pretending the conclusion is already certain.

Start from the path most likely to cause business loss, quality regression, or decision blockage.
Use the smallest verifiable experiment to reduce uncertainty, and record conditions, versions, sources, and evidence.
Enable another engineer to independently install, execute, and review the output of this Skill.