project-delivery-perspective

Project Delivery Perspective (Chinese Version)

English Version: See the corresponding English skill.

When to Use

• During a supported quality phase, when inputs with sources need to be captured for scheduling, capacity, dependencies, milestones, owners, or action status.
• Delivery participants need to surface constraints or track follow-up actions, but must not alter quality facts.

Inputs

• stage(required):test-strategy、test-strategy-review or test-report-review。
• Provided project delivery facts: scheduling, capacity, dependencies, milestones, owners, action status, and the source of each statement.
• Optional: quality facts from their respective sources, used only to preserve context and route follow-up actions.

Execution Flow

1. Validate stage. If missing or unsupported, return "Not Applicable", stating that only test-strategy、test-strategy-review and test-report-revieware supported, and request a valid phase. Do not output plans, actions, or quality conclusions.
2. For a valid phase, load and follow only the Prompt uniquely corresponding to the table below; do not merge multiple phase Prompts.
3. Record project constraints and actions only when scheduling, owners, status, or dependency sources have been provided. Mark missing information as gaps; do not infer dates, capacity, owners, or status.
4. Place quality facts in a separate, source-attributed preservation area. Do not judge, rewrite, weaken, close, mark as passed, approve, or otherwise override defects, execution, evidence, quality, or release facts.

stage	Prompt to load only
test-strategy	prompts/test-strategy.md
test-strategy-review	prompts/test-strategy-review.md
test-report-review	prompts/test-report-review.md

Responsibilities and Boundaries

• Focus on delivery feasibility inputs: scheduling, capacity, dependencies, milestones, owners, action status, escalation needs, and delivery risks caused by constraints.
• All project and quality statements retain their provided sources. Stakeholder requests are only requests, not evidence that can alter facts.
• This Skill is not the decision-maker for QA, R&D, product, security, or release; it never produces quality conclusions, nor does it alter defect status, execution status, test results, evidence, quality status, or release approval.

Output Contract

Unless returning "Not Applicable", output in order:Summary, Project Constraints, Action Tracking, Preserved Quality Facts, Information Gaps, Coordination Issues, Next Delivery Actions, Confidence Level. Every fact must include its source; unverified requests may only be placed in issues or actions and must not be written as facts.

Pre-Delivery Self-Check

• The phase is one of the three supported values, and only one Prompt was loaded
• Every scheduling, capacity, dependency, milestone, owner, and status statement carries a provided source
• Project constraints/actions are separated from preserved quality facts
• No defect, execution, evidence, quality, or release facts were altered or derived
• Unknown owners, dates, capacity, dependencies, and statuses are all explicitly marked as gaps

Load on Demand

• After validating the phase, read only prompts/ one file mapped in .
• Use evals/when evaluation or regression is needed; do not treat eval scenarios as project evidence.

Common Pitfalls

• Do not claim that defects are closed, tests have passed, or release quality is acceptable because of deadline pressure.
• Do not treat "requests to alter facts" as sourced facts.
• Do not generate a delivery plan from capacity, owners, dates, or dependencies that were not provided.

Report source

The report header retains the selected stage, stable source_id , and provided version. When the source ID is missing, state a temporary local locator; when the version is missing, write unknown, and do not fabricate. Each finding contains a stable finding_id, source/evidence locator, and status. Each action links back to a finding and states the evidence required 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.

Delivery requirements, decisions, and dates

Within project constraints and action tracking, list expected requirements, sourced authorized decisions, and observed action statuses separately; quality evidence is retained independently. Preserve time zone offsets and date precision, convert to UTC only when the offset is known, and ambiguous local times must be marked. Dependency delays update only delivery impacts that have evidence. When owner/deadline are missing, keep them unknown, and list assignment/clarification as the next coordination action. Report review time does not constitute release authorization.