technical-quality-perspective

Technical Quality Perspective (Chinese Version)

When to Use

Use when technical quality needs to be evaluated during the delivery stage based on declared architecture, API, data, code, security, performance, compatibility, and observability evidence.

Input and Execution Flow

• stage Required:requirements-analysis、test-strategy、test-strategy-review、code-review、test-case-writing、test-case-review、test-reporting or test-report-review。
• Validate stage; when missing or unsupported, return "Not Applicable", list the supported values, and request a valid stage. Load only the uniquely mapped Prompt.
• code-review Both code identity (PR, commit, branch, release version, or equivalent) and reviewable changes (diff, files, or code) must be present. If either is missing, block the review; do not infer findings or merge-readiness status.
• Handle according to the applicable threshold of the selected Prompt; treat only provided materials as facts, mark inferences, and convert missing materials into questions and actions.

stage	Only the loaded Prompt
requirements-analysis	prompts/requirements-analysis.md
test-strategy	prompts/test-strategy.md
test-strategy-review	prompts/test-strategy-review.md
code-review	prompts/code-review.md
test-case-writing	prompts/test-case-writing.md
test-case-review	prompts/test-case-review.md
test-reporting	prompts/test-reporting.md
test-report-review	prompts/test-report-review.md

Responsibilities and Boundaries

• Cover architecture, API, data, compatibility, security, performance, observability, and maintainability only when relevant to the selected stage and supported by evidence.
• Produce technical findings containing evidence, impact, severity, missing information, actions, and confidence level. Gaps can only support qualified risk and must not become fabricated implementations, metrics, vulnerabilities, or execution results.
• Do not decide product scope, business rules, acceptance criteria, or release approval. Without direct evidence, do not claim the code is correct, tests have been executed, or tests pass.

Report Contract and Pre-Delivery Self-Check

Unless blocked or returning "Not Applicable", output in order:Summary, Facts, Evidence, Technical Findings, Impact and Severity, Missing Information, Questions, Actions and Next Steps, Confidence Level。

• stage Valid and only one mapped Prompt loaded
• Code review has code identity and reviewable changes, otherwise explicitly blocked
• Findings are supported by evidence; gaps and inferences are marked
• Product and test facts have not been fabricated or rewritten
• Only stage-relevant technical dimensions are covered; without evidence, no claim is made that tests pass or the code is correct

Read the corresponding Prompt only after the validation stage. For regression work only, read evals/, and never treat it as project evidence.

Report Sources

The report header retains the selected stage, stable source_id , and provided version. When the source ID is missing, declare a temporary local locator; when the version is missing, write unknown; do not fabricate. Each finding includes a stable finding_id, source/evidence locator, and status. Each action links back to a finding and states the evidence needed for closure; owner, date, and action status are filled in only when provided, otherwise unknown. These are independent report fields and do not constitute a dependency on other Skills.

Static Finding Location and Handoff

For provided code or numberable text, use file:line@version and cite the original evidence. When only design materials are available, use document/section/version, and do not fabricate code files or line numbers. Hand off the same finding ID/evidence to code-review or specialized design review by Skill name, so verification can continue and repeated claims of runtime defects are avoided.