Delivering on time by sacrificing verification, operability, or usability does not remove risk; it postpones it until after release. Delivery quality must consider scope, pace, evidence, and consequences together.
The Project Delivery Perspective Skill makes trade-offs explicit, connecting milestones to readiness signals rather than treating a date as proof of success.
The membership-upgrade v3 example connects scope, a payment-sandbox dependency, QA windows, rollback rehearsal, owners, and delivery options.
Awesome QA Skills organizes Skills by language and testing stage. The series overview covers repository structure and shared installation options; this guide stays with Project Delivery Perspective.
Read the source Skill first
The main prompt covers Required inputs, Delivery work, Source and quality boundary, Inputs, Workflow. Those headings are navigation; the project artifacts still provide the facts.
This Skill has no separate examples directory. The sample below is derived from its entry point, main prompt, and eval constraints.
Related Skills
Project Delivery Perspective brings commitments, dependencies, and owners into one delivery assessment. After a change, the workflow can continue through these Skills:
| Skill | When to use it | What it adds |
|---|---|---|
| Change Impact Analysis | Requirements, code, or dependencies change | Identifies affected systems, roles, evidence, and deliverables |
| Regression Scope Analysis | Impact is known and verification must be planned | Maps risk to required, sampled, and deferrable regression scope |
| Production Verification | A release is live and needs real-environment verification | Checks critical paths and stop conditions with observable, reversible checks |
| Multi-Role Quality Synthesis | Product, QA, Engineering, and UX reports exist for the same stage | Preserves agreement, disagreement, and sources for delivery follow-up |
| Technical Quality Perspective | Dependencies, stability, or recovery evidence affects a commitment | Supplies runtime consequences, technical gaps, and recovery evidence |
What Delivery Perspective handles across the workflow
Delivery Perspective does not re-review all eight development stages. It organizes scope, dependencies, milestones, owners, and action status only in the stages it supports. Other stage outputs must first come from the relevant role Skill and then become inputs to delivery planning.
| Development stage | Delivery Perspective handling | What to hand off or record |
|---|---|---|
| Requirements analysis | Does not perform the analysis; receives confirmed scope, exclusions, and acceptance prerequisites | Product, QA, Technical, or UX facts plus registered dependencies |
| Test strategy | Supported stage; records target dates, capacity, environments, dependencies, milestones, and owners | Project constraints, action tracking, and information gaps |
| Test strategy review | Supported stage; checks whether trade-offs have a due time, owner, and escalation path | Executable delivery options without rewriting quality facts |
| Code review | Does not review code; records dependency or rework impact raised by review | Findings and evidence from Technical Quality Perspective |
| Test case writing | Does not design cases; records how case volume, data, and environment affect the window | Verification effort and gaps from QA Quality Perspective |
| Test case review | Does not decide whether QA cases pass; tracks whether review actions affect milestones | Action owner, due time, and status |
| Test reporting | Does not generate a report for the executor; waits for run identity, results, and failure evidence | Quality facts from QA or Test Reporting Skills |
| Test report review | Supported stage; separates quality facts, project constraints, and open actions | Review date, dependency blockers, actions, and coordination issues |
Across this set of articles, Technical Quality Perspective asks what happens when a dependency fails; Multi-Role Quality Synthesis asks where role evidence agrees or conflicts; Project Delivery Perspective asks how scope and dates should change under current conditions.
Put commitments and prerequisites in the same release plan
Start with schedule, dependencies, and owners to organize the scope, verification, and accountability required for release review. This Skill does not make a Go/No-Go decision by itself.
| Delivery condition | Current evidence | Action if it fails |
|---|---|---|
| Scope | Frozen requirements, exclusions, and acceptance criteria | Record impact and re-estimate the date |
| External dependency | Commitment time for interface, environment, data, or approval | Name a fallback and latest escalation time |
| Verification window | Time needed for regression, canary, and rollback | Reduce scope or delay release |
| Owner | Every deliverable and risk has an owner | Do not mark an item complete without one |
Each condition needs a source, due time, and failure action before the plan can drive delivery.
Membership upgrade v3 delivery tracker
These project inputs are hypothetical. In a real report, dates, owners, and statuses are facts only when the supplied material supports them; otherwise list a gap.
| Milestone | Prerequisite on record | Owner | Due | Action if it fails |
|---|---|---|---|---|
| Scope freeze | PRD-42 lists the primary membership-upgrade path and exclusions | Product lead | Wednesday 12:00 | Re-estimate scope; do not include unconfirmed requirements in the on-time commitment |
| Sandbox callback | Payment provider committed to timeout and duplicate-callback samples | Payment service lead | Thursday 12:00 | Record a dependency blocker; if only a mock service is available, do not report real-callback verification as complete |
| Regression window | QA reserved time for checkout, benefits, and reconciliation | QA lead | Friday 10:00–14:00 | Reduce scope or delay; do not rewrite execution status as passed because time ran short |
| Rollback rehearsal | Candidate-version rollback and data checks are scheduled | Release lead | Friday 14:00–15:00 | Raise a coordination issue and wait for the authorized owner to adjust the plan |
| QA execution status | QA-42 records that timeout callback testing has not run | QA lead | Before Friday 14:00 | Run the test and update the quality fact; do not mark it passed |
If the payment provider misses Thursday’s delivery, Delivery Perspective can present three options: wait and move the date, narrow scope to paths with evidence, or split the candidate version into two releases. It cannot call a mock result a real dependency pass or mark unrun regression as passed.
A handoff record could look like this:
stage: test-report-review
milestone: Membership upgrade v3 release review
scope: [primary path, benefits delivery, payment callback]
dependencies:
- name: Payment sandbox callback
source_id: DELIVERY-42
due: Thursday 12:00
status: pending
validation_window:
owner: QA lead
window: Friday 10:00–14:00
source_id: QA-PLAN-42
retained_quality_facts:
- source_id: QA-42
statement: Timeout callback has not run
status: not_run
decision: pending
next_action: Confirm dependency delivery; if late, submit reduced-scope or delay options
owner: Release leadThe decision remains pending. A delivery record makes people, dates, and fallback paths visible; it does not make the release lead’s Go/No-Go decision.
Turn delivery findings into executable choices
“Release on schedule” is not the only option. State the conditions for proceeding, reducing scope, delaying, or splitting the release.
| Option | When it applies | Evidence to retain |
|---|---|---|
| Release as planned | Scope is frozen; dependencies and verification window are ready | Release checklist, regression results, rollback rehearsal |
| Reduce scope | Core paths are ready but lower-risk features lack evidence | Exclusions, user impact, and a date for follow-up |
| Delay release | A critical dependency or rollback condition is unmet | Blocker, escalation path, and new date |
Every option needs an approver and a latest confirmation time. The Skill organizes conditions and evidence; it does not make commitments for the project owner.
Adaptable prompt
Replace the bracketed fields with project material.
Use the project-delivery-perspective Skill.
Stage: test report review (test-report-review)
Task: Assess whether the membership-upgrade release plan has workable scope, dependencies, milestones, and owners
Version and environment: [requirement / build / environment]
Inputs: [plan, dependency commitments, QA records, rollback evidence]
Scope: [included and excluded work]
Constraints: [dates, capacity, environment, approvals]
Separate quality facts from project constraints. For each milestone, record its source, owner, due time, failure action, and current status. Present options with evidence and open decisions. Do not make a Go/No-Go decision.Keep delivery constraints distinct from quality conclusions
A concise delivery summary still needs project constraints, action tracking, retained quality facts, information gaps, and the next delivery action. Project Delivery Perspective does not produce a quality verdict or release approval.
Who should use this Skill
Project and release leads can use it to make schedule and dependency trade-offs explicit. QA, Product, Engineering, and Operations can use the shared record to see which owner must resolve each delivery condition.
Review a delivery record before handoff
| Review item | What to retain | If missing |
|---|---|---|
| Scope and commitment | Included work, exclusions, dates, and source versions | Reconfirm scope before treating the date as a commitment |
| Dependencies | Provider, promised artifact, due time, and fallback | Keep the dependency open and record its escalation path |
| Verification window | Regression, canary, rollback, and recovery time | Reduce scope or delay the decision |
| Ownership | Owner and approver for each action | Do not mark ownerless risks as closed |
| Quality facts | Verified, not_run, and blocked states from source reports | Preserve them; do not rewrite them as delivery status |
| Decision | Options, approver, and latest confirmation time | Leave the release decision pending |
Install and invoke
Install the individual Skill. The series overview carries the longer installation explanation.
npx skills add https://github.com/naodeng/awesome-qa-skills/tree/main/skills/en/testing-workflows/project-delivery-perspective -gInvoke it with “Use the project-delivery-perspective Skill,” then attach the real artifacts.
Common questions
Why reassess when the date has not changed?
Dependencies, scope, and verification windows may have changed. The date is a commitment; prerequisites are delivery evidence.
What if an external dependency is late?
Record impact, fallback, and the latest escalation time, then consider splitting scope or changing the release plan.
How can I tell whether a risk has an owner?
Each risk needs an owner, decision-maker, due time, and verifiable closure condition.
Can this Skill decide Go/No-Go?
No. It provides options, conditions, and evidence. An authorized person makes the release decision.
Run Delivery Perspective against a plan with dates, owners, and dependency sources, then retain inputs, output, and review notes. The example gives structure; project evidence must come from the project.
References
- Awesome QA Skills project:https://github.com/naodeng/awesome-qa-skills
- Awesome QA Skills series overview:https://inaodeng.com/en/blog/ai-testing/introduction_of_awesome_qa_skills/
- Awesome QA Skills: Project Delivery Perspective Skill source:https://github.com/naodeng/awesome-qa-skills/tree/main/skills/en/testing-workflows/project-delivery-perspective
- Project Delivery Perspective Skill details:https://inaodeng.com/en/qaskills/project-delivery-perspective/