Pm AI Workflow To Evidence

PM AI Workflow to Evidence

Use this skill when a PM or workflow owner has scattered material about one AI workflow and needs to state what the evidence actually supports. It creates a traceable packet with an artifact index, evidence ladder, claim ledger, contribution boundary, missing receipts, and one bounded next route. It is an evidence organizer, not a case-study certifier, analytics connector, or scale decision.

When to use

Use it when:

• notes, a PRD, prompt or skill, test cases, screenshots, metrics, adoption observations, or stakeholder feedback need to become one reviewable record;
• a PM needs to explain what was built, how it operated in real work, and what the supplied evidence does and does not support;
• a workflow has some exposure or real-use material but the team is unsure whether it can support a stronger behavior, outcome, value, or next-step claim;
• a contributor needs to separate personal work from collaborators' work and keep dates, versions, sources, and limitations attached;
• an internal reviewer needs the smallest next evidence to capture before piloting, extending, investing, or sharing a workflow.

Use pm-proof-to-share when the main job is public or channel-specific copy for a verified release. Use pm-ai-workflow-to-adoption for a team-introduction and real-use plan. Use pm-ai-adoption-to-diagnosis to explain a stalled behavior. Use pm-ai-value-to-investment for cost/value scenarios and an investment route. Use pm-ai-outcome-to-improvement for a verified proposal- to-outcome finding. Use pm-ai-evaluation-plan for formal quality or safety test design.

Do not use

Do not use this skill to:

• generate a public post, release announcement, social message, or channel schedule;
• collect private telemetry, inspect a customer system, query analytics, verify a screenshot, or call a model/provider automatically;
• certify a case study, badge, adoption result, business value, ROI, causal impact, quality, safety, or production readiness claim;
• manufacture a denominator, baseline, source, user story, quote, metric, contribution, market size, or stakeholder approval;
• rank a portfolio, choose a pre-test workflow, diagnose an adoption blocker, design an evaluation, or decide post-pilot scale;
• expose customer data, employee identifiers, raw traces, private URLs, credentials, tokens, proprietary prompts, or confidential roadmap material.

Write Not provided, Not verified, Not run, Not measured, Unknown, Need evidence, and Not covered when the material does not support a stronger claim.

Evidence boundary

The packet is only as strong as the source and layer attached to each claim. Use the highest layer the evidence actually supports, not the strongest story the owner wants to tell.

Tests, screenshots, release tags, traffic, downloads, quotes, and usage counts are evidence at different layers. Never let one receipt silently promote itself.

Claim statuses

Use one status per material claim:

Workflow

1. Frame the packet

Write:

For [user/group] completing [job] with [workflow/version], assemble the supplied evidence to decide [internal decision] under [claim, privacy, contribution, and operating boundary].

Capture:

If the workflow or decision is missing, keep the packet at Hold or Capture next; do not reverse-engineer a purpose from the artifacts.

2. Inventory every supplied artifact

Record an index before writing a narrative:

Do not use a screenshot, quote, or generated summary as authority when the underlying source is missing. Keep stale and current versions in separate rows.

3. Map the evidence ladder

For each material statement, ask:

1. Is this a problem/design statement, or did the workflow operate?
2. Is there exposure, first use, repeat use, changed work, accepted outcome, value, or causal evidence?
3. What is the unit and denominator? Which eligible cases, people, periods, retries, abstentions, or exclusions are missing?
4. What is the strongest claim this artifact can support, and what stronger claim must be blocked?

If artifacts stop at design or exposure, do not write a real-use or adoption narrative. If an accepted outcome exists without a baseline, preserve the outcome and block an improvement claim.

4. Build the claim ledger

Write literal claims, not slogans. For each claim record:

Keep the claim, evidence, interpretation, decision, and next action in separate rows. A positive observation can coexist with Unknown value or adoption.

5. Check contribution, authority, and conflict

Before a packet is shared internally:

• distinguish the author's work, collaborator work, inherited assets, and provider or platform capability;
• mark whether the source is first-hand, second-hand, generated, or inferred;
• preserve conflicting notes, reviewer disagreement, stale versions, and unknown ownership rather than choosing the convenient one;
• verify that each source is allowed for the intended audience and redact personal, customer, security, legal, and proprietary details;
• do not claim a workflow caused an outcome because the owner built it or because the result followed it chronologically.

6. Choose one bounded route

Proceed bounded does not mean publish, scale, or approve. It means a human owner has a reviewable next action within the declared boundary.

7. Write the smallest evidence capture plan

For Capture next, define one receipt:

• unit and eligible slice;
• source, owner, timestamp/timezone, version, and freshness;
• positive, negative, ambiguous, abstain, or exception cases where relevant;
• baseline or comparison if an outcome/improvement claim is being considered;
• contribution/reviewer record and privacy/redaction boundary;
• expected claim it could support, claim it cannot support, and stop condition;
• writeback location and review date.

Do not ask for every possible metric. Ask for the smallest receipt that changes the next decision.

8. Handoff without publishing or execution

Give the owner the evidence packet, blocked claims, one next action, source and privacy checks, fallback, and downstream skill. This skill is tool-free: it does not read private artifacts, collect telemetry, send a message, publish a case, or change an external system.

Output contract

Return these sections in order and preserve missingness.

Decision on the desk

State the workflow/version, user/job, owner, intended reader/decision, evidence window, contribution boundary, privacy boundary, and what could change the route.

Artifact index

List every supplied artifact with ID/type, source/authority, date, version, scope, sensitivity/redaction, evidence layer, and limitation.

Evidence ladder

Map the strongest supported layer for problem/design, operation, exposure, first use, repeat use, changed work, accepted outcome, value, and causality. Mark unavailable layers Not provided, Not run, or Unknown.

Claim ledger

Use a table with literal claim, status, scope/unit, source IDs, method or denominator, date/version, contribution, limitation, and next receipt.

Contribution, authority, and conflict

State who did what, which source is authoritative, what is first-hand or reported, which versions conflict, what is redacted, and what remains unclear.

Evidence-supported account

Write the shortest plain-language account the packet supports. Separate what was designed, what operated, what people did, what outcome was accepted, and what remains unmeasured. Do not turn a gap into a smooth narrative.

Route

Choose exactly one of Capture next, Proceed bounded, Hold, or Do not claim. State the decisive evidence, blocked interpretation, owner, boundary, and next receipt.

Smallest next evidence

Define the unit, eligible slice, source, owner, date/version, method, privacy boundary, expected claim, non-claim, stop condition, and writeback location.

Implementation handoff

Name the authorized owner, smallest action, affected artifacts/surfaces, source and privacy review, acceptance/evidence receipt, fallback, and follow-on skill. Do not imply the action ran.

Not covered

List unsupported prevalence, demand, adoption, retention, value, ROI, causality, quality, safety, privacy, security, accessibility, localization, cost, latency, reliability, production readiness, rollout, customer outcome, or GitHub traffic, stars, and organic growth claims.

Review ask

Ask the reviewer to choose exactly one route: Capture next, Proceed bounded, Hold, or Do not claim. Name the one material claim or source boundary that needs correction.

Edge cases

• Only a polished narrative: discard unsupported sentences, build an artifact index, and route to Capture next or Do not claim.
• Only a metric: preserve the number with its unit/window if supplied; do not invent baseline, causality, adoption, or value.
• Only a screenshot or quote: label it Reported or Observed at the narrow scope; request source, date, and context.
• Usage without denominator: keep it as exposure/activity and route to Capture next or Do not claim.
• Real use without outcome: write the behavior and route to a smallest outcome receipt; do not claim business value.
• Outcome without baseline: preserve accepted outcome and block improvement or causal language.
• Conflicting versions or sources: keep both rows, identify authority, and use Hold until a reviewer reconciles them.
• Contribution unclear: use Hold or Capture next; never inflate the named author's role.
• Fictional or synthetic material: label the packet fictional fixture; it can exercise the format but cannot support a real workflow story, adoption, value, or growth claim.
• High-impact or irreversible claim: use Hold or Do not claim until privacy, authority, human review, and the required evidence are explicit.
• Question asks for stars or traffic impact: keep GitHub signals in their own evidence layer and mark attribution Not measured or Not covered.

Final check

Before handoff, confirm:

• one workflow, user/job, owner, intended decision, window, and privacy boundary are explicit;
• every artifact has source, date/version, scope, sensitivity, and limitation;
• evidence layers are not upgraded beyond what the source supports;
• every material claim has status, source IDs, scope/unit, method/denominator, contribution, limitation, and next receipt;
• conflicts, stale versions, and unknown ownership are visible;
• problem/design, operation, exposure, first use, repeat use, changed work, outcome, value, and causality are separate;
• exactly one of the four routes is selected;
• the next evidence action has owner, scope, privacy, stop condition, and writeback;
• no fictional, usage, screenshot, quote, or test evidence is written as adoption, value, safety, or causality proof;
• unsupported claims are listed under Not covered.

Source notes

This skill's evidence framing is informed by the official OpenAI Academy materials on the Workflow evidence coach, Gather appropriate evidence of value, Capture and share use cases and impact, and the Workflow adoption planner. These sources shape the packet; they do not certify a particular workflow's evidence, adoption, value, safety, or production readiness.