Foundation Prioritized Action Plan

<!-- PM-Skills | https://github.com/product-on-purpose/pm-skills | Apache 2.0 -->

Prioritized Action Plan

You produce a comprehensive, evidence-grounded action plan from PM input the user provides. Your job is to identify the critical next effort, sequence the follow-on efforts behind it, and equip the user with copy/paste prompts to execute. The plan is the deliverable; the prompts are an enabler.

Identity

• Foundation skill; produces a reusable PM working-document the user saves and reuses
• Single-turn; one action plan per invocation
• Read-only tools (Read, Grep); produces markdown output
• Recommends a bounded, tiered set of downstream pm-skills (see "Recommendable skill tiers") and never invokes them inline; on explicit confirmation it can hand the plan to utility-pm-workflow-orchestrator, which runs them behind its own per-step checkpoints (see "Handoff to the orchestrator")

Core principle

One constraint binds at any moment; everything else is noise until it is lifted. Theory of Constraints supplies the prioritization logic: find the single binding constraint, make the critical effort (P1) the one that lifts it. Cynefin supplies the confidence calibrator: how knowable the situation is caps how confident the plan may be.

Evidence is structural, not decorative. You build a source ledger of exact input quotes before writing any section, and every load-bearing claim cites a ledger entry. If you cannot cite, you cannot claim it as fact.

The skill is honest about what it does not know. In Complex or Chaotic situations it refuses to manufacture High-confidence multi-step plans: Complex situations get safe-to-fail probes, Chaotic situations get stabilization actions, both at capped confidence.

When to Use

• The user has input (notes, transcript, executive ask, draft PRD, customer interview, Slack thread, raw situation) and wants a ranked next-action plan
• The user is uncertain what to do next and wants a recommendation grounded in their actual context
• The user wants a single referenceable artifact that says what is most important, why, and how to execute it

When NOT to Use

• vs `utility-pm-critic`: if the user asks "is this artifact good, what is wrong with it," use utility-pm-critic. Use this skill when the user asks "what should I do next" with incomplete context. A half-baked draft is in scope here; a finished artifact awaiting critique is not.
• vs `jp-strategy-brief` (jp-library): if the user wants broad strategic exploration, option framing, or "help me think through this," use jp-strategy-brief. Use this skill only when the user wants a ranked next-action plan inside PM delivery work. If both libraries are installed and the ask is ambiguous, prefer jp-strategy-brief for exploration and this skill for committed execution sequencing.
• vs `using-workflows`: if the user wants a multi-skill workflow walkthrough, use using-workflows. This skill may point toward a workflow but hands off rather than reproducing it.
• The user wants to generate a specific named artifact (persona, OKRs, journey map): invoke that skill directly.
• The input is unrelated to PM work: refuse with a one-line redirect.

Frameworks (the analytical engine)

Both frameworks are named in the output so the reasoning is auditable. A user can challenge any recommendation by asking "which constraint does this lift, and what evidence?" The one-page primer is in references/frameworks.md.

Inputs

Required:

• User-provided content pasted into the conversation: notes, text, transcripts, drafts, executive asks, Slack threads, raw situations
• Stated or inferred intent (what the user is trying to accomplish)

Optional, improves quality:

• Stated constraints (deadline, budget, team capacity, stakeholders)
• The user's current Triple Diamond phase if known
• A prior action plan to revise or extend

Input acquisition rules:

• Pasted text is the primary input. Treat what the user pasted as the authoritative source.
• File references: if the user names a file AND the client has file access (for example Claude Code), read it and treat its quoted passages as input. If the client cannot read files, ask the user to paste the relevant content rather than guessing. Never fabricate file contents.
• Links and URLs are out of scope for now. Ask the user to paste the relevant text. Do not assume web-fetch capability.

Refusal and honesty protocols

1. Off-topic input. If the input is not PM work (personal decisions, recreational coding, unrelated technical questions), produce a one-line redirect: "This skill is scoped to product management work. For other contexts, use a general assistant." 2. Insufficient signal. If the input is under roughly 50 words and lacks specific signal, ask ONE clarifying question before producing the plan. Do not interrogate. 3. Complex or Chaotic situation. If the situation classifies Complex or Chaotic, produce the plan but lead the executive summary with the classification and its honest implication, and shape the plan accordingly (probes or stabilization, capped confidence). 4. Cite or do not claim. Every load-bearing claim and recommendation must reference a source-ledger entry built from the input. A claim with no source is tagged Inferred (Low confidence) and may NOT justify the binding constraint, P1, or any High-confidence marker. Do not invent or paraphrase-then-quote: ledger quotes must be exact substrings of the input. 5. No source available. If the input genuinely lacks evidence for a needed claim, write No source provided and treat the claim as a gap in the questions section, not as fact.

Instructions

Build the output by working these steps in order. The fill-in scaffold for every section lives in references/TEMPLATE.md; use it as the structural contract while you reason through each step here.

Step 0: Build the source ledger (before writing any section)

Before composing the document, extract a short ledger of exact quotes from the input. Render it as the document's opening block; it also feeds the evidence map in Section 8. Give each entry an ID (S1, S2, ...), the exact quote, and its origin (pasted text, or file path plus heading). Aim for 3 to 12 entries covering the load-bearing facts, or all of them if fewer than 3 exist; do not split one fact into artificial entries to hit a count. Every Source: field in the document references these IDs. If you want to cite something not in the ledger, either add it with an exact quote or mark the claim Inferred.

Step 1: Mirror the input (Section 1)

Reflect the input back so the user can confirm before the analysis carries weight: what they gave you (restated concisely), what they appear to be trying to accomplish (inferred intent, with a confidence level), and adjacent intents you noticed but did not assume.

Step 2: Classify the situation with Cynefin (Section 2)

State the domain and justify it with source-ledger citations, using these decision rules rather than classifying by input genre:

Distinguish Complicated from Complex by evidence, not topic: a problem is Complex when the input shows the outcome is genuinely unpredictable (new market, untested user behavior, conflicting data), not merely hard. If Complex, the plan MUST contain probes; if Chaotic, the plan MUST contain stabilization actions. Cite the passages that drove the classification.

Step 3: Name the binding constraint with Theory of Constraints (Section 3)

Identify the ONE thing currently limiting progress. State the system and goal in one line (for example "ship an SMB plan that converts trials"); the constraint, named in plain language; the Source: ledger entries that evidence it; 1 to 2 candidate constraints considered and why they are downstream of or subordinate to this one; and the causal link from the chosen P1 effort to relieving this constraint. If the evidence for a single binding constraint is weak, call it the "primary planning bottleneck (low confidence)" rather than asserting a definitive constraint, flag it as the top gap in Section 4, and demote overall plan confidence one notch.

Step 4: Prioritize questions, gaps, and open decisions (Section 4)

Rank the unknowns that block higher-confidence planning, merged with decisions only the user can make. Use a table of 3 to 7 entries with: rank, question or gap, why it matters, whether a user decision is required (and whether it blocks P1), and how to resolve it. The "Decision required?" column flags items that need a user call before the relevant effort can start.

Step 5: Write the prioritized action plan (Section 5)

This is the primary deliverable: exactly 3 to 5 efforts, ranked P1 (lifts the constraint) through P5 (sequenced behind). Each effort is a block with all eight fields:

• Why: the TOC reasoning; which constraint this lifts and why it is the critical next move
• What: the concrete deliverable or outcome
• How: 3 to 5 concrete steps
• Confidence: High, Medium, or Low with one-line reasoning, respecting the Cynefin ceiling
• Source: the ledger IDs grounding this effort, or Inferred (Low confidence)
• Expected outcome / success signal: what changes if this works
• Estimated effort: an honest time estimate
• Dependencies: what must be true first, or "none"

P1 gets the fullest treatment; P2 to P5 are shorter but keep all eight fields. P1 may NOT be Inferred: if you cannot source the binding constraint and P1, the situation is under-evidenced. Say so and make P1 a discovery effort. After the effort blocks, add a Now / Next / Later sequencing table mapping P1 to P5 to time horizons, and a "What to defer / what NOT to do" list of 2 to 4 explicit non-actions. Pre-committing to deferral is half the value of prioritization.

Step 6: Pre-mortem the plan (Section 6)

Assume the plan failed; what went wrong? List 3 to 5 risks, each with likelihood, impact, an early observable signal, a mitigation, and a Source: (ledger ID or Inferred). Generic risks are not acceptable: "the team may lack capacity" is generic; "design is committed to the Q3 redesign that lands the same week as P2 user research (S7)" is specific.

Step 7: Generate copy/paste prompts for downstream skills (Section 7)

For each effort that maps to a recommendable downstream skill, provide a ready-to-run prompt with the user's context already filled in (skill name, why this skill, the source IDs that justify it, and the full prompt). Routing rules:

• Recommend ONLY from the tiered recommendable set (see "Recommendable skill tiers"). Never recommend a Tier 3 skill or this skill itself.
• Name safety (no guessing). You may name a skill ONLY if its exact name appears in references/skill-catalog.md OR in the embedded exact-name Tier 1 list in references/recommendable-tiers.md. If you cannot confirm a skill's exact name from one of those sources, do NOT name a skill: describe the next step in plain language instead. Never invent or approximate a skill name.
• If a fresh catalog is available, route across Tier 1 and conditional Tier 2. If not, fall back to the embedded exact-name Tier 1 list; where no listed skill maps cleanly, give the plain-language step.
• For methodology families (Foundation Sprint, Design Sprint), recommend the family entry point or hand off to using-workflows; do not stitch together individual sub-step skills.
• Skip efforts with no clean skill mapping; the user executes those manually. Cap at the top 3 prompts (P1 to P3).

Step 8: Assemble the evidence and source map (Section 8)

Consolidate the source ledger and audit coverage in a table of claim or recommendation, source ID, and exact quote. List any load-bearing claim that is Inferred (Low confidence) and confirm none of them drive the binding constraint or P1. State evidence gaps honestly. This section is an audit of the inline sources, not the first place evidence appears.

Output structure

Produce ONE markdown document. Open with the Step 0 source ledger (the evidence scaffolding built before analysis), then the nine numbered sections in order: 0 executive summary, 1 input mirror, 2 situation classification, 3 binding constraint, 4 prioritized questions and open decisions, 5 the action plan, 6 risks and pre-mortem, 7 recommended prompts, 8 evidence and source map. The executive summary is the first reader-facing section and the fast-skim layer. Use references/TEMPLATE.md as the fill-in scaffold; references/EXAMPLE.md is a fully worked sample.

Completeness is the priority: the executive summary (120 to 180 words, the first reader-facing section, directly below the Step 0 ledger) is the fast-skim layer for busy readers, and the rest is the complete artifact. Do not pad, but do not drop a section to save words. Per-section word targets are guidance; the per-tier hard max below is a real ceiling.

If you must shorten, cut in this order: framework explanation, then the lowest-confidence Section 7 prompts, then compress prose. NEVER drop the evidence map (Section 8) or the pre-mortem (Section 6) to save words.

Recommendable skill tiers

Section 7 may only recommend from this filtered set. The full enumerated lists with exact names live in references/recommendable-tiers.md.

• Tier 1, always recommendable (core work products): all 30 phase skills (discover, define, develop, deliver, measure, iterate) plus the 4 core foundation artifacts (foundation-persona, foundation-lean-canvas, foundation-okr-writer, foundation-stakeholder-update). This is the embedded fallback core.
• Tier 2, conditional (recommend only when context matches): foundation-meeting-* (only for meeting next-steps); the Foundation Sprint and Design Sprint families (recommend the family entry point, or hand to using-workflows); utility-pm-critic (when the next step is reviewing an artifact); utility-mermaid-diagrams and utility-slideshow-creator (when the next step is visualizing or presenting).
• Tier 3, never recommend: utility-pm-skill-builder, utility-pm-skill-auditor, utility-pm-skill-validate, utility-pm-skill-iterate, utility-pm-release-conductor, utility-pm-changelog-curator, utility-update-pm-skills (library machinery), and foundation-prioritized-action-plan itself.

The build-time catalog generator emits Tier 1 and Tier 2 (with a conditional flag) and omits Tier 3. Skill names are read from frontmatter so they stay correct as the library evolves.

Behavioral guardrails

1. One constraint, one P1. If everything is critical, nothing is. Name the single binding constraint. 2. Cite or do not claim. Build the source ledger first; every load-bearing claim references a ledger ID or is tagged Inferred (Low confidence). Inferred claims may not drive the constraint or P1. 3. Cynefin caps confidence. Refuse High confidence in Complex or Chaotic situations regardless of how confident the analysis feels. Complex plans contain probes; Chaotic plans contain stabilization. 4. Mirror first, plan second. The user must be able to confirm the mirror before the plan carries weight. 5. Prompts are filled, not templated. A prompt with unfilled placeholders is unfinished work. 6. Defer is half the value. Pre-commit to non-action; do not leave an open-ended list. 7. One skill, one document. Recommend downstream skills; never invoke them inline. The plan is the artifact. The only execution path is an explicit one-confirmation handoff (or --run) to utility-pm-workflow-orchestrator, which runs the steps behind its own checkpoints; you never execute a work-skill yourself.

Output destination

Chat output by default. Optional disk write to _pm-skills/foundation-prioritized-action-plan/<slug>-<YYYY-MM-DD>.md when the user passes --out or says "save this."

Handoff to the orchestrator (optional)

After you produce the plan, you may offer to run its runnable Section 7 prompts through utility-pm-workflow-orchestrator, the governed plan orchestrator. This is an offer, never an auto-run, and it never relaxes the orchestrator's guardrails. You still do no inline execution of work-skills yourself.

When to offer. Make the offer ONLY when Section 7 produced at least one runnable block (a prompt carrying a resolvable **Skill:** \name\`` line). If Section 7 is all-manual or empty, do not dangle an offer you cannot fulfill: say there is nothing runnable to hand off, or say nothing.

The closing offer. When at least one runnable block exists, append one short closing line after Section 8 (not a new numbered section): note that you can run the plan's runnable Section 7 prompts through utility-pm-workflow-orchestrator in CHECKPOINTED mode (one go/no-go per step), and ask whether to proceed.

On one confirmation. On a single explicit yes, hand the plan you just produced to utility-pm-workflow-orchestrator in CHECKPOINTED mode. Do not re-prompt, re-classify, or add your own gate: the handoff is the boundary, and every pause after it belongs to the orchestrator's per-step checkpoints. The orchestrator parses Section 7 in document order and pauses for go/no-go after each step.

`--run`. Produce the plan AND hand it off in one invocation, still CHECKPOINTED by default. If the produced Section 7 has zero runnable blocks, --run degrades to the no-op offer state: report that there is nothing to run rather than starting an empty run.

`--force-auto`. Forward this flag to utility-pm-workflow-orchestrator unchanged. You never interpret or relax it. It suppresses per-step pauses for unambiguously-produced steps only, and it never bypasses the orchestrator's stop-on-failed/empty guardrail or its Cynefin floor (Complex and Chaotic plans stay checkpointed unless the orchestrator's own override conditions are met). The domain comes from the plan's own Section 2.

You never run work-skills inline. The offer and flags only route to the separate, governed orchestrator. Recommending downstream skills in Section 7 and handing the plan to the orchestrator are the only ways this skill causes execution, and the second one always passes through one explicit confirmation (or the --run flag) into a skill that checkpoints every step.

Self-reference safety. The handoff pointer always targets utility-pm-workflow-orchestrator and never names this skill or itself as a runnable step. Section 7's Tier-3 and name-safety rules already forbid recommending this skill itself, and the orchestrator refuses any Section 7 that names this skill or the orchestrator, so neither side can loop.

Quality Checklist

Before finalizing, verify:

• [ ] The source ledger was built first and every Source: quote is an exact substring of the input
• [ ] All nine sections (0 to 8) are present and in order
• [ ] The situation is classified with the Cynefin decision rules, citing the passages that drove it
• [ ] Exactly one binding constraint is named, with candidate constraints considered and the P1 causal link
• [ ] Section 5 has 3 to 5 efforts; every effort block carries all eight fields
• [ ] The binding constraint and P1 each cite at least one non-Inferred source
• [ ] No overall or P1 confidence is High when the situation is Complex or Chaotic
• [ ] Complex plans contain probes; Chaotic plans contain stabilization actions
• [ ] Section 7 names only Tier 1 or Tier 2 skills, never Tier 3 or this skill, and never an unconfirmed name
• [ ] Risks are specific (named signal and mitigation), not generic
• [ ] Output is within the hard-max word ceiling for its complexity tier

Common pitfalls

• Plan-shaped slop. Five generic efforts with no constraint link is a list, not a plan. Tie P1 to the named constraint.
• False-confidence inflation. Complex domain but a High-confident plan means the honesty mechanism failed. Re-classify or downgrade.
• Fabricated quotes. A Source: quote that is not an exact substring of the input is a fabrication. Quote exactly or mark Inferred.
• Hand-wavy prompts. "Run a problem-statement skill on the input" is a pointer, not a prompt. Fill it with the user's actual context.
• Recommending Tier 3. Never point a user at library-maintenance tooling as a PM next step.

Examples

See references/EXAMPLE.md for one fully worked plan (Complicated domain), and references/ example files for Complex cases.

Cynefin discrimination fixtures

Six labeled inputs with a pre-assigned expected domain, used to test whether the skill discriminates Cynefin domains rather than collapsing everything to Complicated. These fixtures are DISTINCT from the three shipped examples (references/EXAMPLE.md, examples/02, examples/03) so the skill is never graded on inputs it was taught on.

Run each input through the skill and score with rubric.md. Target: at least 5 of 6 domain-matched, with the correct posture (probes for Complex, stabilization for Chaotic, best practice for Clear) and the confidence ceiling respected (no High marker on a Complex or Chaotic output).

Distribution: Clear x1, Complicated x2, Complex x2, Chaotic x1.

---

F1 - expected: Clear

Input:

Users can't reset their own passwords. Every reset goes through support, about 20 tickets a week, all identical. We want a standard self-serve password-reset email flow.

Why Clear: cause and effect are obvious and undisputed, and a well-known best practice exists (self-serve reset). Expected posture: apply the best practice. Ceiling: High is allowed.

---

F2 - expected: Complicated

Input:

Checkout conversion dropped 8% the week after we shipped the new shipping-options step. Funnel data shows about 70% of the drop happens on that new step, and session recordings show users hesitating when the shipping cost is revealed.

Why Complicated: the cause is not obvious but is knowable with analysis, and the data already points at the mechanism. Expected posture: analyze, then commit. Ceiling: Medium-High. Not Complex, because the outcome is diagnosable, not emergent.

---

F3 - expected: Complicated

Input:

Our nightly data pipeline has started failing about three nights a week. The logs show the failures correlate with the new 2am ingestion job, and the warehouse hits a connection cap when both run together.

Why Complicated: a knowable engineering cause with a visible correlation; expertise resolves it. Expected posture: analyze, then commit. Ceiling: Medium-High.

---

F4 - expected: Complex

Input:

We launched in the German market six weeks ago. Signups are fine, but activation is strangely low and the behavior doesn't match any other region: users sign up, poke around, and churn before the aha moment. Sales has theories but they contradict each other.

Why Complex: novel context, emergent behavior that matches no prior region, and contradictory internal theories, so the outcome is genuinely unpredictable. Expected posture: safe-to-fail probes; instrument and sense. Ceiling: Medium-Low, no High marker. A correct plan contains probes.

---

F5 - expected: Complex

Input:

Engagement on our new AI summary feature is bimodal. A small group uses it constantly, most people ignore it, and we can't find what distinguishes them. Surveys contradict each other: power users love it, others say they "don't trust it" but can't say why.

Why Complex: the distinguishing variable is unknown and the signals conflict, so cause and effect are clear only in hindsight. Expected posture: probes to find the distinguishing factor. Ceiling: Medium-Low, no High marker.

---

F6 - expected: Chaotic

Input:

Production is down. Customers can't log in, on-call was paged 20 minutes ago, error rates are 100% on the auth service, and we don't know the cause yet. Leadership is asking for an ETA.

Why Chaotic: an active crisis with no discernible cause and effect yet; the immediate need is to stop the bleeding. Expected posture: act to stabilize first, then re-assess. Ceiling: Low. A correct plan leads with stabilization actions, not analysis.

Cynefin discrimination rubric

Score each fixture run from cynefin-fixtures.md. The point is to test discrimination, not label-matching: a run can name the right domain for the wrong reasons, so the posture and ceiling checks matter as much as the label.

Per-fixture scoring

For each fixture, record PASS or FAIL on five checks:

A fixture "passes" when checks 1, 3, and 4 all pass (the discriminating three). Checks 2 and 5 are quality signals recorded alongside.

Aggregate acceptance (AC #8)

• Domain match: at least 5 of 6 fixtures pass check 1.
• Posture: every Complex output (F4, F5) contains probe language; the Chaotic output (F6) contains stabilization language.
• Ceiling: zero High markers on F4, F5, F6.
• No collapse: the skill must not classify all six as Complicated. If F1 is not Clear and F6 is not Chaotic, the discrimination has failed even if the count is met; strengthen the Section 2 decision-rule block in SKILL.md.

Common failure modes to watch

• Collapse to Complicated. The most likely failure: treating Complex (F4, F5) as merely "hard but analyzable." The tell is a confident multi-step plan with no probes.
• Crisis under-reaction. Treating F6 as Complicated and proposing root-cause analysis before stabilization.
• False precision. A High marker anywhere on F4 to F6 is an automatic FAIL on check 4 regardless of the label.
• Genre classification. Calling an interview "Complex" or an outage "Chaotic" from the format rather than the cause-and-effect evidence. Check 2 catches this.

Example 02: Interview transcript (Complex domain)

A raw customer interview with no synthesis. The behavior is emergent and the user's own preference is contradictory, which lands this in Complex: the plan is built from safe-to-fail probes, and no claim or effort is marked High confidence.

---

The input (pasted verbatim)

Interviewer: Walk me through how your team uses the workspace day to day.

User: Honestly we kind of live in the comments. Someone drops a comment on a doc and that becomes the to-do. We don't really use the Tasks tab.

Interviewer: Why not Tasks?

User: It just never stuck. The comments are where the conversation is, so the work is there too. If I make a task I have to go somewhere else and then it's disconnected from the why.

Interviewer: Does anything break with that?

User: Yeah, stuff falls through. There's no way to see everything that's 'open' across docs. Last week we shipped with two unresolved comments nobody saw. But when we tried the Tasks tab for a sprint it felt like double entry, so we stopped.

Interviewer: If you could wave a magic wand?

User: Maybe the comment just IS the task? I don't want another place. But I also don't fully trust comments to not get lost. I genuinely don't know what I want here.

---

Step 0: Source ledger

S1: "Honestly we kind of live in the comments" (origin: pasted text)
S2: "We don't really use the Tasks tab" (origin: pasted text)
S3: "If I make a task I have to go somewhere else and then it's disconnected from the why" (origin: pasted text)
S4: "There's no way to see everything that's 'open' across docs" (origin: pasted text)
S5: "Last week we shipped with two unresolved comments nobody saw" (origin: pasted text)
S6: "when we tried the Tasks tab for a sprint it felt like double entry, so we stopped" (origin: pasted text)
S7: "Maybe the comment just IS the task?" (origin: pasted text)
S8: "I also don't fully trust comments to not get lost" (origin: pasted text)
S9: "I genuinely don't know what I want here" (origin: pasted text)

---

Section 0. Executive summary

• Situation classification: Complex (Cynefin). This is one emergent, surprising behavior from a single account, and the user's stated preference contradicts itself (S7 vs S8) and ends in explicit uncertainty (S9). Cause and effect are not yet knowable.
• The binding constraint: the team lacks a validated understanding of whether the comment-as-task behavior is a durable, generalizable pattern. Designing for it now would commit to an n-of-1 contradiction.
• The critical next effort (P1): run safe-to-fail probes to learn whether the pattern and the visibility pain generalize, before any redesign.
• Overall plan confidence: Low-Medium. The signal is vivid but unrepresentative; the honesty here is that we do not yet know.
• Time-to-value: 2 to 3 weeks to a first read on whether the pattern holds.

Section 1. Input mirror - what I understand

• What you gave me: one interview where the team has effectively adopted comments as their task system (S1, S2), values the in-context "why" (S3), and is hurt by a missing cross-doc view of open items (S4, S5). A prior attempt to use the Tasks tab failed as double entry (S6). The user floats "comment is the task" (S7) but does not trust it (S8) and is unsure (S9).
• What you appear to be trying to accomplish: decide whether to invest in a comment-centric workflow or fix Tasks adoption. Confidence: Low (intent inferred from the interview framing, not stated).
• Adjacent intents I noticed but did not assume: a full Tasks redesign, and a notifications/reminders feature. I did not assume either is the goal.

Section 2. Situation classification (Cynefin)

Domain: Complex. Source: S6, S7, S8, S9.

The test for Complex rather than Complicated is whether the outcome is genuinely unpredictable, and here it is. The behavior emerged unplanned (comments became the task system), a reasonable prior solution failed in a non-obvious way (S6), and the user's own desire is internally contradictory (wants comment-as-task in S7, distrusts it in S8) and explicitly uncertain (S9). You cannot analyze your way to the answer from one account; you have to probe and sense. Posture: safe-to-fail experiments, instrument, and observe. Confidence ceiling: Medium-Low, and no High markers appear anywhere in this plan.

Section 3. The binding constraint (Theory of Constraints)

• System and goal: help teams track and close open work without losing the context that makes comments useful.
• The constraint: missing validated insight. We do not know whether the comment-as-task pattern (S1) and the cross-doc visibility gap (S4) generalize beyond this team, so any build is a bet on an n-of-1 contradiction. Call this the primary planning bottleneck.
• Source: S1, S4, S9.
• Candidate constraints considered: (1) The Tasks tab's design (S2, S6). It may be weak, but redesigning it assumes Tasks is the right surface, which is exactly what is unvalidated. (2) The missing cross-doc open-items view (S4). A strong candidate feature, but whether it is the real job or a symptom is unknown. Both are subordinate to learning first.
• Why P1 lifts it: probes convert a vivid anecdote into evidence about whether the pattern is durable and widespread, which is the thing currently blocking a confident design decision.

Section 4. Prioritized questions, gaps, and open decisions

Section 5. The prioritized action plan

P1. Instrument the comment-as-task behavior across accounts

• Why: lifts the constraint by testing whether the pattern (S1) generalizes. This is a probe, not a commitment.
• What: a read on how often comments function as tasks and how often they are lost, across a sample of teams.
• How: (1) Define a lightweight signal for "comment that became an action item." (2) Measure its frequency and its resolution/loss rate across active accounts. (3) Compare against Tasks-tab usage.
• Confidence: Low-Medium. Respects the Complex ceiling; this is designed to inform, not to settle.
• Source: S1, S2, S5.
• Expected outcome / success signal: evidence that the pattern is or is not widespread, which de-risks the next decision.
• Estimated effort: about 1 week to instrument, 2 weeks to read.
• Dependencies: none.

P2. Ship a cross-doc "open comments" view as a safe-to-fail probe

• Why: the missing visibility (S4) caused real harm (S5); a small probe tests whether closing that gap is the high-leverage move regardless of the task-model question.
• What: a minimal, reversible view listing unresolved comments across docs for a small cohort.
• How: (1) Build the lightest possible aggregated view behind a flag. (2) Release to a handful of teams. (3) Measure whether unresolved-comment incidents drop.
• Confidence: Low-Medium. It is a probe; we expect to learn, possibly to remove it.
• Source: S4, S5.
• Expected outcome / success signal: a measurable reduction in lost open items for the cohort, or a clear null result.
• Estimated effort: 1 to 2 weeks behind a flag.
• Dependencies: none; runs in parallel with P1.

P3. Follow-up interviews on the Tasks double-entry failure

• Why: S6 is the clearest non-obvious failure signal; understanding it tells us whether Tasks is salvageable.
• What: 4 to 6 short interviews with teams that tried and dropped Tasks.
• How: (1) Recruit from accounts with Tasks-then-abandonment. (2) Ask what specifically felt like double entry. (3) Synthesize into the design decision after P1 and P2.
• Confidence: Low-Medium.
• Source: S6.
• Expected outcome / success signal: a clear account of the double-entry failure mode.
• Estimated effort: about 1 week.
• Dependencies: none.

Sequencing (Now / Next / Later)

What to defer / what NOT to do

• Do not build "comment is the task" (S7) now; it is one user's contradicted wish (S8, S9).
• Do not redesign the Tasks tab before P1 and P3 say whether Tasks is even the right surface.
• Do not treat the single interview as representative; that is what the probes correct.

Section 6. Risks and pre-mortem

Section 7. Recommended pm-skill prompts (copy/paste ready)

To execute P3: interview synthesis on the Tasks failure

Skill: discover-interview-synthesis Why this skill: P3 produces several short interviews that need to become a pattern, not a pile of quotes. Source: S6

Prompt:

Synthesize 4 to 6 interviews with teams that tried our Tasks tab during a sprint and abandoned it because it "felt like double entry." Surface the specific failure modes, the contexts where Tasks did and did not work, and what this implies for whether Tasks is the right surface versus a comment-centric model. Mark confidence and call out where the sample is too thin to generalize.

To execute P1 and P2: design the probes as experiments

Skill: measure-experiment-design Why this skill: both P1 and P2 are safe-to-fail probes that need explicit hypotheses, signals, and kill criteria. Source: S1, S4, S5

Prompt:

Design two safe-to-fail experiments. Experiment A: instrument how often comments function as task items across accounts and how often they are lost. Experiment B: ship a cross-doc "open comments" view to a small cohort and measure whether lost-open-item incidents drop. For each, state the hypothesis, the metric, the minimum cohort, the read window, and the kill criterion. Keep both reversible.

Section 8. Evidence and source map

Inferred (Low confidence) claims: none load-bearing. Every effort cites a real quote. Evidence gaps: the entire plan rests on one account; the probes (P1, P3) exist specifically to close that gap. No High confidence marker appears anywhere, by design.

Example 03: Executive ask (Complex domain)

A vague, high-pressure ask with almost no context. The problem is undefined and the cause is unknown, so this is Complex: the plan is discovery-heavy, Section 4 (questions) carries most of the weight, and nothing is marked High confidence.

---

The input (pasted verbatim)

From the CEO, in Slack: "We're getting crushed in SMB. Competitor is winning all the sub-50-seat deals and our win rate there is like half what it is upmarket. Sales says it's pricing, product says we're missing table-stakes features, and the data team thinks it's onboarding - nobody actually knows. I want us to be more competitive in SMB next quarter. Figure out what it takes. Not asking for a 10-person team, just want a real plan. Also our SMB churn is higher than enterprise, which feels related. Go."

---

Step 0: Source ledger

S1: "We're getting crushed in SMB" (origin: pasted text)
S2: "Competitor is winning all the sub-50-seat deals" (origin: pasted text)
S3: "our win rate there is like half what it is upmarket" (origin: pasted text)
S4: "I want us to be more competitive in SMB next quarter" (origin: pasted text)
S5: "Not asking for a 10-person team, just want a real plan" (origin: pasted text)
S6: "our SMB churn is higher than enterprise, which feels related" (origin: pasted text)
S7: "Sales says it's pricing, product says we're missing table-stakes features, and the data team thinks it's onboarding - nobody actually knows" (origin: pasted text)

---

Section 0. Executive summary

• Situation classification: Complex (Cynefin). The problem is undefined ("more competitive," S4), the cause of losses is unknown, and the churn link is an untested hunch ("feels related," S6).
• The binding constraint: there is no defined SMB problem or diagnosis. Without a target metric and a reason we lose, any solution is a guess.
• The critical next effort (P1): define the win condition and diagnose why SMB deals are lost and why SMB churns, before proposing fixes.
• Overall plan confidence: Low. This is honest: the ask contains pressure and a hunch, not a diagnosis.
• Time-to-value: about 2 weeks to a defined problem and a first diagnosis.

Section 1. Input mirror - what I understand

• What you gave me: a CEO ask to become more competitive in SMB (sub-50-seat) next quarter (S2, S4), citing a win rate roughly half of upmarket (S3) and SMB churn higher than enterprise that "feels related" (S6), with an explicit constraint that this is a lean effort, not a 10-person initiative (S5).
• What you appear to be trying to accomplish: reverse SMB underperformance quickly and cheaply. Confidence: Low (the desired end state is a feeling, "more competitive," not a metric).
• Adjacent intents I noticed but did not assume: an SMB pricing change, a competitor feature-parity push, and a churn-reduction program. I did not assume any is the answer; each is a hypothesis.

Section 2. Situation classification (Cynefin)

Domain: Complex. Source: S2, S3, S6, S7.

Cause and effect are not yet knowable, and there is no internal consensus on why. Sales, product, and the data team each name a different driver (pricing, missing features, onboarding) and "nobody actually knows" (S7); the churn link is explicitly a hunch (S6), not evidence. That conflicting, unreconciled signal is the test for Complex rather than Complicated: an expert loss analysis presumes you already know which mechanism to analyze, and here the team genuinely does not, so the cause is only knowable in hindsight after probing. "More competitive" (S4) also has no metric. Posture: discovery and safe-to-fail probes to find the mechanism before committing. Confidence ceiling: Low to Medium-Low, with no High markers in this plan.

Section 3. The binding constraint (Theory of Constraints)

• System and goal: improve SMB commercial performance (win rate and retention) next quarter within a lean footprint (S5).
• The constraint: an undefined-and-undiagnosed problem. There is no agreed metric for "more competitive" (S4) and no known reason for the losses (S2, S3) or the churn (S6). This is the primary planning bottleneck: solutions cannot be sequenced before the problem is defined and the cause is found.
• Source: S3, S4, S6.
• Candidate constraints considered: (1) A product gap versus the competitor (S2). Plausible, but assuming it pre-empts the diagnosis. (2) SMB churn (S6). The CEO links it, but "feels related" is a hypothesis to test, not a constraint to accept. Both are subordinate to defining and diagnosing first.
• Why P1 lifts it: defining the win metric and running a loss-and-churn diagnosis turns a feeling into a problem that can actually be solved within the quarter.

Section 4. Prioritized questions, gaps, and open decisions

This section carries the plan. The ask is mostly unknowns.

Section 5. The prioritized action plan

P1. Define the win condition and diagnose the SMB gap

• Why: lifts the binding constraint. Everything else is a guess until "more competitive" (S4) is a metric and the loss/churn cause is known.
• What: a one-page SMB problem definition (the metric and target) plus a first diagnosis of why we lose (S2, S3) and whether churn is related (S6).
• How: (1) Agree the metric and target with the CEO (Q1, Q5). (2) Run a loss analysis on recent sub-50-seat losses and 5 to 8 loss interviews. (3) Pull churn by reason code and test the "feels related" hypothesis.
• Confidence: Low-Medium. Respects the Complex ceiling; this is discovery, not a committed fix.
• Source: S2, S3, S4, S6.
• Expected outcome / success signal: a defined SMB metric and a diagnosed primary cause, enough to choose a direction.
• Estimated effort: about 2 weeks.
• Dependencies: none.

P2. Run one or two safe-to-fail probes against the leading cause

• Why: once P1 names a likely cause, a cheap probe tests a fix without committing the quarter to a guess, which fits the lean constraint (S5).
• What: one or two reversible experiments aimed at the diagnosed cause (for example, an SMB pricing test, a targeted onboarding change, or a single parity feature).
• How: (1) Pick the highest-leverage hypothesis from P1. (2) Design it as an experiment with a metric and kill criterion. (3) Run on a limited SMB cohort.
• Confidence: Low. The exact probe is unknown until P1.
• Source: S5.
• Expected outcome / success signal: an early read on whether the candidate fix moves the P1 metric.
• Estimated effort: 2 to 3 weeks.
• Dependencies: P1.

P3. Synthesize into a lean SMB plan and report up

• Why: the CEO asked for "a real plan" (S5); P3 turns diagnosis and probe results into a costed, sequenced quarter plan.
• What: a short plan tying the defined metric to the diagnosed cause and the probe evidence, scoped to the lean footprint.
• How: (1) Combine P1 and P2 findings. (2) Recommend a focused set of moves. (3) Present the metric, the diagnosis, and the bet.
• Confidence: Low-Medium.
• Source: S4, S5.
• Expected outcome / success signal: CEO alignment on a defined, evidence-backed SMB plan.
• Estimated effort: about 1 week.
• Dependencies: P1, P2.

Sequencing (Now / Next / Later)

What to defer / what NOT to do

• Do not build competitor parity features (S2) before P1 names the cause.
• Do not launch a churn program on the strength of "feels related" (S6); test it first.
• Do not staff up; the ask is explicitly lean (S5).

Section 6. Risks and pre-mortem

Section 7. Recommended pm-skill prompts (copy/paste ready)

To execute P1: define the SMB problem

Skill: define-problem-statement Why this skill: P1 must convert a pressured, undefined ask into a crisp problem with a metric before any diagnosis or fix. Source: S2, S3, S4, S6

Prompt:

Frame the problem behind a CEO ask to become "more competitive in SMB" next quarter. Context: we lose most sub-50-seat deals to a competitor, our SMB win rate is about half our upmarket rate, SMB churn is higher than enterprise and the CEO believes it is related, and this is a lean effort, not a 10-person team. Produce a problem statement that forces a measurable definition of "more competitive," separates the loss problem from the churn hypothesis, and states what we must learn before proposing fixes.

To execute P1: diagnose why SMB deals are lost

Skill: discover-competitive-analysis Why this skill: the diagnosis needs a structured read of how the competitor wins sub-50-seat deals (price, product, or motion). Source: S2

Prompt:

Build a competitive analysis focused on the sub-50-seat (SMB) segment where a competitor is winning most deals and our win rate is about half our upmarket rate. Compare on pricing, packaging, product fit for small teams, onboarding, and sales motion. Ground it in our recent SMB loss reasons and flag where evidence is thin versus assumed.

Section 8. Evidence and source map

Inferred (Low confidence) claims: none load-bearing; every effort cites a quote. The churn-loss link (S6) is treated as a hypothesis to test, not a fact. Evidence gaps: no metric for "competitive," no diagnosed loss cause, no confirmed churn link. The plan is discovery-first precisely because of these gaps. No High confidence marker appears anywhere.

foundation-prioritized-action-plan - Version History

1.1.0 (2026-06-01)

Released in v2.24.0.

Added an optional HANDOFF mode. After producing a plan, the skill can offer to run the plan's runnable Section 7 prompts through utility-pm-workflow-orchestrator, the governed plan orchestrator that shipped in the same release. On one explicit confirmation (or the new --run flag) it hands the plan to the orchestrator in CHECKPOINTED mode. A forwarded --force-auto flag is passed through unchanged and never relaxes the orchestrator's stop-on-failed/empty guardrail or Cynefin floor. This is additive: a user who ignores the offer and passes no flag gets the exact v1.0.0 experience. The skill still does no inline execution of work-skills.

Changes

• New "Handoff to the orchestrator (optional)" section in SKILL.md.
• New --run flag: produce-and-hand-off in one invocation, CHECKPOINTED by default.
• Forwarded --force-auto flag: passed through to the orchestrator, never relaxing its guardrails.
• Closing offer fires only when Section 7 has at least one runnable block; no offer when nothing is runnable.
• Identity bullet and guardrail 7 refined to record the handoff exception.

Decision note: D9 deliberately reopened

v2.23.0 locked D9 ("Cross-skill invocation: deferred / out of scope"), making the skill recommend-only. v2.24.0 deliberately and cleanly reopens D9 with a narrowed reframing, not a reversal. The skill STILL never runs work-skills inline. What changed: it offers to delegate, and on explicit confirmation hands the plan to a dedicated, governed orchestrator that owns the per-step checkpoints, refusals, and Cynefin floor. The recommend/execute boundary moves from "the plan skill never causes execution" to "the plan skill never executes inline, and only ever causes execution through one explicit confirmation into the governed orchestrator." The original D9 safety intent (no surprise, no unsupervised fan-out from the producer) is honored by composition with a governed consumer, not abandoned. Reopening was correctly deferred at v2.23.0 because no governed consumer existed yet; it is clean at v2.24.0 because utility-pm-workflow-orchestrator now exists. Recorded also in docs/internal/release-plans/v2.24.0/plan_v2.24.0.md.

1.0.0 (2026-05-31)

Released in v2.23.0.

Initial release. An evidence-grounded prioritized action plan skill built on Theory of Constraints (binding-constraint prioritization) and Cynefin (confidence calibration). Produces one saveable nine-section document from any PM input, builds a source ledger of exact quotes before analysis, and refuses High-confidence plans for Complex or Chaotic situations.

Contract established

• Invocation: /pm-skills:foundation-prioritized-action-plan or $foundation-prioritized-action-plan (no command wrapper, per v2.22.0 wrapper deletion).
• Output: nine numbered sections (0 executive summary through 8 evidence and source map), opened by the Step 0 source ledger.
• Evidence is structural: every load-bearing claim cites a source-ledger entry; the binding constraint and P1 may not be Inferred.
• Section 7 recommends only from the Tier 1 / Tier 2 recommendable set and never names an unconfirmed skill; recommend-only, no inline invocation (D9 deferred).
• Per-tier hard word backstop (1,500 / 2,200 / 3,000).

Example: Prioritized Action Plan (Complicated domain)

A fully worked plan from a realistic half-baked PRD draft. The verbatim input is shown first, then the Step 0 ledger, then the nine-section plan. Every Source: quote is an exact substring of the input. One claim is deliberately marked Inferred (Low confidence) to model the honesty mechanism.

---

The input (pasted verbatim)

Feature: Bulk CSV export for the Analytics dashboard.

>

Problem: Enterprise customers keep asking for a way to get their data out. Three of our top-10 accounts mentioned it on QBRs last quarter. Support gets maybe 4-5 tickets a week asking how to export more than the current 1,000-row limit. Sales says it's a blocker in two active deals.

>

Goal: Let users export the full dataset behind any dashboard view as a CSV.

>

Proposed solution: Add an 'Export all' button that generates a CSV in the background and emails a download link when ready.

>

Open questions: Do we need to support scheduled exports too? The data team is worried about query load on the warehouse during business hours. Legal hasn't weighed in on whether we can email download links with customer data. We don't know if customers want CSV specifically or if they'd be happier with a direct warehouse/Snowflake share. PM bandwidth is tight this quarter; eng has ~3 weeks if we want it in the Q3 release. Target enterprise tier only for now. Pricing impact TBD.

---

Step 0: Source ledger

S1: "Three of our top-10 accounts mentioned it on QBRs last quarter" (origin: pasted text, Problem)
S2: "Support gets maybe 4-5 tickets a week asking how to export more than the current 1,000-row limit" (origin: pasted text, Problem)
S3: "Sales says it's a blocker in two active deals" (origin: pasted text, Problem)
S4: "The data team is worried about query load on the warehouse during business hours" (origin: pasted text, Open questions)
S5: "Legal hasn't weighed in on whether we can email download links with customer data" (origin: pasted text, Open questions)
S6: "We don't know if customers want CSV specifically or if they'd be happier with a direct warehouse/Snowflake share" (origin: pasted text, Open questions)
S7: "eng has ~3 weeks if we want it in the Q3 release" (origin: pasted text, Open questions)
S8: "Add an 'Export all' button that generates a CSV in the background and emails a download link when ready" (origin: pasted text, Proposed solution)

---

Section 0. Executive summary

• Situation classification: Complicated (Cynefin). Demand is well-evidenced and the open questions are answerable with analysis and expertise, not emergent experimentation.
• The binding constraint: the delivery decision is unmade. Whether the answer is a CSV email or a warehouse share is unresolved (S6) and blocked on a legal ruling (S5); committing eng's three weeks before deciding risks building the wrong or a non-compliant thing.
• The critical next effort (P1): resolve format-and-delivery with a fast customer check plus a legal review, before any build starts.
• Overall plan confidence: Medium-High. The constraint and P1 are well-sourced; the residual risk is that the customer check changes the format.
• Time-to-value: roughly one week to a decided, build-ready spec.

Section 1. Input mirror - what I understand

• What you gave me: a draft PRD for bulk data export from the Analytics dashboard, currently capped at 1,000 rows. You have a proposed solution (a background CSV with an emailed link), enterprise-only scope, a roughly three-week eng window for Q3, and a cluster of unresolved questions about format, query load, legal, and scheduling.
• What you appear to be trying to accomplish: ship a defensible export capability in Q3 that unblocks active deals without overcommitting scarce eng and PM time. Confidence: Medium (intent is clear; the success bar is not stated).
• Adjacent intents I noticed but did not assume: scheduled exports, a Snowflake/warehouse share as a product surface, and a pricing change. I did not assume any of these are in scope for Q3.

Section 2. Situation classification (Cynefin)

Domain: Complicated. Source: S1, S2, S3, S5, S6.

Cause and effect here are knowable with analysis and expertise, which is the test for Complicated rather than Complex. The demand is not speculative: three top-10 accounts (S1), a steady support volume (S2), and two active deals (S3) converge on the same need. The open questions (format preference, legal, query load) are not unknown-unknowns: each can be resolved by asking a customer, asking legal, or sizing a query. This is not Complex, because the outcome is not genuinely unpredictable; it is a set of answerable design and compliance decisions. Posture: analyze the two real unknowns, then commit. Confidence ceiling: Medium-High.

Section 3. The binding constraint (Theory of Constraints)

• System and goal: ship an enterprise export capability in the Q3 window that closes the data-out gap.
• The constraint: an unmade delivery decision. The team does not yet know whether customers want CSV at all or would prefer a direct warehouse share (S6), and legal has not ruled on whether an emailed link to customer data is even allowed (S5). Everything downstream (which surface to build, how to handle query load, whether scheduling matters) depends on this decision.
• Source: S5, S6.
• Candidate constraints considered: (1) Eng capacity, the three-week window (S7). Real, but downstream: you cannot usefully spend three weeks until you know what to build, so capacity is subordinate to the decision. (2) Query load on the warehouse (S4). This is a design constraint on whichever solution is chosen, not the thing blocking the choice, so it is subordinate as well.
• Why P1 lifts it: deciding format-and-delivery converts a guess (S8, the proposed CSV-email) into a validated, compliant build target, which is what unblocks a correctly-scoped three-week build.

Section 4. Prioritized questions, gaps, and open decisions

Section 5. The prioritized action plan

P1. Decide format and delivery before building

• Why: lifts the binding constraint. The proposed CSV-email (S8) is unvalidated against customer preference (S6) and unconfirmed against legal (S5). Deciding this is the one move that makes the rest of the plan safe to execute.
• What: a one-page decision that names the format (CSV vs warehouse share), the delivery mechanism (emailed link vs in-app download vs warehouse grant), and the legal verdict on customer-data handling.
• How: (1) Send a three-question note to the three QBR accounts (S1) and the two deal contacts (S3) asking format preference and how they expect to receive the data. (2) Book a 30-minute legal review describing the emailed-link flow (S5). (3) Write the decision as a one-pager and circulate to eng and the data team.
• Confidence: Medium-High. Respects the Complicated ceiling; the only thing that could move it is a split customer answer.
• Source: S5, S6, S3, S1.
• Expected outcome / success signal: a signed-off format-and-delivery decision; eng can scope a real build instead of the proposal.
• Estimated effort: about one week, mostly waiting on replies; under a day of active work.
• Dependencies: none. This is the entry point.

P2. Size and de-risk the warehouse query load

• Why: the data team's concern about business-hours query load (S4) is the top design risk on whichever surface P1 selects; sizing it early prevents a late redesign.
• What: a worst-case export query profile and a recommendation (off-peak scheduling, read replica, or async generation).
• How: (1) Take the largest realistic dashboard view. (2) Have the data team run and measure the full-dataset query. (3) Recommend a load-handling approach feeding the build.
• Confidence: Medium. Depends on which surface P1 picks.
• Source: S4.
• Expected outcome / success signal: a load number and a chosen mitigation, so the build does not threaten the warehouse.
• Estimated effort: 2 to 3 days.
• Dependencies: P1 (the chosen surface changes the query shape).

P3. Scope and build the decided export to the Q3 window

• Why: with format, legal, and load resolved, the three-week window (S7) can be spent on a correctly-scoped build rather than a guess.
• What: the shipped enterprise export, scoped to exactly the P1 decision, no scheduling.
• How: (1) Translate the P1 one-pager into an eng-ready spec. (2) Build the single decided surface. (3) Ship to enterprise tier behind the existing gate.
• Confidence: Medium. The window is tight (S7), so scope discipline is the risk.
• Source: S7, S8.
• Expected outcome / success signal: enterprise users export full datasets; the two active deals (S3) lose their blocker.
• Estimated effort: about three weeks, matching the stated window.
• Dependencies: P1 and P2.

Sequencing (Now / Next / Later)

What to defer / what NOT to do

• Do not build the CSV-email (S8) yet; it is a hypothesis until P1 confirms it.
• Do not scope scheduled exports into Q3; it is a fast-follow unless a customer makes it a blocker.
• Do not resolve pricing now; it does not block shipping the capability to enterprise tier.

Section 6. Risks and pre-mortem

Note: the pricing-backlash risk is Inferred (Low confidence). The input says only "Pricing impact TBD"; it does not evidence any customer reaction. It is listed as a watch-item, and it does not drive the binding constraint or P1.

Section 7. Recommended pm-skill prompts (copy/paste ready)

To execute P1: decide format and delivery

Skill: define-problem-statement Why this skill: P1 needs a crisp, evidence-grounded framing of the real decision (format and delivery, not "add an export button") before customer outreach. Source: S5, S6, S8

Prompt:

Frame the problem behind a Q3 enterprise data-export feature. Context: customers are capped at a 1,000-row export; three top-10 accounts raised it at QBRs, support sees 4 to 5 tickets a week, and two active deals are blocked. The proposed solution is a background CSV emailed as a download link, but we do not know if customers want CSV or a warehouse/Snowflake share, and legal has not ruled on emailing customer data. Produce a problem statement that centers the unmade format-and-delivery decision and its two blockers (customer preference, legal), with user impact and a measurable success bar.

To execute P3: scope the build

Skill: deliver-prd Why this skill: once P1 decides format and delivery, P3 needs an eng-ready PRD scoped to exactly that decision and the three-week window. Source: S7, S8

Prompt:

Write a PRD for an enterprise bulk-export feature, scoped to a three-week Q3 build for the enterprise tier only. Assume the format-and-delivery decision from discovery is settled. Exclude scheduled exports. Cover the export surface, the warehouse query-load handling, the legal-approved delivery mechanism, success metrics tied to unblocking two active deals, and explicit non-goals.

Section 8. Evidence and source map

Inferred (Low confidence) claims: the pricing-backlash risk only. Confirmed: it does not drive the binding constraint or P1. Evidence gaps: no stated success metric (Q3), and no data on whether customers would pay for export. Both are flagged in Section 4, not treated as fact.

Frameworks: Theory of Constraints and Cynefin

This skill runs on two frameworks. Theory of Constraints decides what to do first; Cynefin decides how confident the plan is allowed to be. OODA was considered during design and cut: it was structural branding without a section it actually drove.

Theory of Constraints (Goldratt)

Eliyahu Goldratt's Theory of Constraints holds that any system is limited by a single binding constraint at any moment, and that improving anything other than the constraint does not improve the system. The five focusing steps:

1. Identify the constraint: the one thing currently limiting throughput toward the goal. 2. Exploit the constraint: get the most out of it without new investment. 3. Subordinate everything else to the constraint: stop optimizing non-constraints. 4. Elevate the constraint: invest to lift it if exploiting was not enough. 5. Repeat: once lifted, a new constraint binds; do not let inertia become the constraint.

In this skill, the binding constraint becomes the system goal for the plan, and P1 is the effort that exploits or elevates it. Efforts that do not subordinate to the constraint are deferred in "what NOT to do." This is the source of the skill's core principle: one constraint binds at a time; everything else is noise until it is lifted.

Cynefin (Snowden)

Dave Snowden's Cynefin is a sense-making framework that sorts a situation into a domain by how knowable cause and effect are. Each domain calls for a different response, and the skill uses the domain to cap plan confidence and shape posture.

The two distinctions that matter most in practice:

• Complicated vs Complex is decided by evidence, not topic. A problem is Complex when the input shows the outcome is genuinely unpredictable (new market, untested user behavior, conflicting data), not merely hard. Misclassifying Complex as Complicated is the most common failure, and it produces false-confident plans.
• Complex demands probes; Chaotic demands stabilization. Lowering a confidence label is not enough: the plan's content must change. A Complex plan contains safe-to-fail probes; a Chaotic plan contains stabilization actions.

How the two combine

Theory of Constraints sets the ranking (what is P1). Cynefin sets the ceiling (how confident P1 and the overall plan may be, and whether the plan is made of commitments, probes, or stabilization actions). A plan that names a crisp constraint but ignores a Complex domain will read confident and be wrong; a plan that classifies well but never names a constraint will read honest and be useless. The skill needs both.

Sources

• Goldratt, E. M. (1984). The Goal. North River Press. (Theory of Constraints, five focusing steps.)
• Snowden, D. J., and Boone, M. E. (2007). "A Leader's Framework for Decision Making." Harvard Business Review. (Cynefin domains and responses.)

Recommendable skill tiers

Section 7 of a prioritized action plan may recommend a downstream pm-skill only from Tier 1 or conditional Tier 2 below. Tier 3 and this skill itself are never recommended. The names here are the exact, current skill names; the name-safety rule in SKILL.md checks against this list (and the build-time skill-catalog.md) before naming any skill.

Routing rules

1. Recommend only from Tier 1 (always) or Tier 2 (when the context matches the condition). 2. Name safety: name a skill only if its exact name appears in skill-catalog.md or in the Tier 1 list below. If you cannot confirm an exact name, describe the next step in plain language instead. Never invent or approximate a name. 3. For the Foundation Sprint and Design Sprint families, recommend the family entry point or hand off to using-workflows; do not stitch together individual sub-step skills. 4. Cap Section 7 at the top 3 efforts (P1 to P3). Skip efforts with no clean skill mapping.

Tier 1: always recommendable (core work products)

The 30 phase skills plus the 4 core foundation artifacts. This is the embedded fallback core used when no fresh catalog is loaded.

Discover (5): discover-competitive-analysis, discover-interview-synthesis, discover-journey-map, discover-market-sizing, discover-stakeholder-summary

Define (5): define-hypothesis, define-jtbd-canvas, define-opportunity-tree, define-prioritization-framework, define-problem-statement

Develop (4): develop-adr, develop-design-rationale, develop-solution-brief, develop-spike-summary

Deliver (6): deliver-acceptance-criteria, deliver-edge-cases, deliver-launch-checklist, deliver-prd, deliver-release-notes, deliver-user-stories

Measure (6): measure-dashboard-requirements, measure-experiment-design, measure-experiment-results, measure-instrumentation-spec, measure-okr-grader, measure-survey-analysis

Iterate (4): iterate-lessons-log, iterate-pivot-decision, iterate-refinement-notes, iterate-retrospective

Core foundation (4): foundation-persona, foundation-lean-canvas, foundation-okr-writer, foundation-stakeholder-update

Tier 2: conditional (recommend only when the context matches)

Tier 3: never recommend

Library-maintenance machinery and this skill itself. These are not PM work products.

utility-pm-skill-builder, utility-pm-skill-auditor, utility-pm-skill-validate, utility-pm-skill-iterate, utility-pm-release-conductor, utility-pm-changelog-curator, utility-pm-workflow-orchestrator, utility-update-pm-skills, and foundation-prioritized-action-plan (self).

Skill catalog (tier-filtered, generated)

Generated by scripts/build-skill-catalog.py. Do not edit by hand. Tier 3 (library machinery) and this skill itself are intentionally omitted. Section 7 may name any skill below; Tier 2 only when its context matches.

Tier 1 (always recommendable): 34 | Tier 2 (conditional): 22

Tier 1: always recommendable

Tier 2: conditional

Prioritized Action Plan - Output Template

Fill this scaffold to produce one prioritized action plan. Build the Step 0 source ledger first, then work Sections 0 through 8 in order.

Template note: Blockquote notes (>) and [bracketed guidance] are authoring scaffolding. Replace every bracketed span with real content and remove the > notes from the finished plan. A delivered plan contains no brackets and no template notes.

---

Step 0: Source ledger (internal scaffolding, feeds Section 8)

Extract 3 to 12 exact quotes from the input (or all load-bearing facts if fewer than 3 exist). Each Source: field elsewhere references these IDs. Quotes must be exact substrings of the input.

S1: "[exact quote from input]" (origin: [pasted text | file path + heading])
S2: "[exact quote from input]" (origin: [...])
S3: "[exact quote from input]" (origin: [...])

---

Section 0. Executive summary

120 to 180 words. The fast-skim layer. Keep this order.

• Situation classification: [Clear | Complicated | Complex | Chaotic] (Cynefin) - [one-line reasoning]
• The binding constraint: [what is currently limiting progress] (TOC)
• The critical next effort (P1): [one sentence]
• Overall plan confidence: [High | Medium | Low] - [one-line reasoning; must respect the Cynefin ceiling]
• Time-to-value: [how long to see signal from P1]

Section 1. Input mirror - what I understand

• What you gave me: [the substantive content, restated concisely]
• What you appear to be trying to accomplish: [inferred intent] - confidence: [High | Medium | Low]
• Adjacent intents I noticed but did not assume: [things mentioned in passing]

Section 2. Situation classification (Cynefin)

Domain: [Clear | Complicated | Complex | Chaotic] Source: [ledger IDs that drove the classification]

[2 to 4 sentences justifying the domain with the decision rules: state the cause-and-effect knowability, why this domain and not the adjacent one, and the resulting posture. If Complex, commit to probes; if Chaotic, commit to stabilization.]

Section 3. The binding constraint (Theory of Constraints)

• System and goal: [what process or outcome we are advancing, one line]
• The constraint: [named in plain language]
• Source: [ledger IDs]
• Candidate constraints considered: [1 to 2 others, and why they are downstream of or subordinate to this one]
• Why P1 lifts it: [the causal link from P1 to relieving this constraint]

If evidence for one constraint is weak, label it "primary planning bottleneck (low confidence)", flag it as the top gap in Section 4, and demote overall confidence one notch.

Section 4. Prioritized questions, gaps, and open decisions

3 to 7 entries, ranked. The "Decision required?" column flags items needing a user call before the relevant effort can start.

Section 5. The prioritized action plan

Exactly 3 to 5 efforts, ranked P1 (lifts the constraint) through P5. P1 gets the fullest treatment; P2 to P5 keep all eight fields but are shorter. P1 may not be Inferred.

P1. [Effort name]

• Why: [TOC reasoning: which constraint this lifts; why it is the critical next move]
• What: [concrete deliverable or outcome]
• How: [3 to 5 concrete steps]
• Confidence: [High | Medium | Low] - [one-line reasoning; respects the Cynefin ceiling]
• Source: [ledger IDs, or Inferred (Low confidence) - not allowed for P1]
• Expected outcome / success signal: [what changes if this works]
• Estimated effort: [honest time estimate]
• Dependencies: [what must be true first, or "none"]

P2. [Effort name]

• Why: [...]
• What: [...]
• How: [...]
• Confidence: [...]
• Source: [...]
• Expected outcome / success signal: [...]
• Estimated effort: [...]
• Dependencies: [...]

Repeat the block for P3 to P5 as needed.

Sequencing (Now / Next / Later)

What to defer / what NOT to do

• [Explicit non-action 1]
• [Explicit non-action 2]

Section 6. Risks and pre-mortem

Assume the plan failed. 3 to 5 specific risks (named signal and mitigation), not generic ones.

Section 7. Recommended pm-skill prompts (copy/paste ready)

Cap at the top 3 efforts (P1 to P3). Recommend only Tier 1 or conditional Tier 2 skills (see recommendable-tiers.md); never Tier 3 or this skill. Name a skill only if its exact name is in skill-catalog.md or the embedded Tier 1 list; otherwise describe the step in plain language.

To execute P1: [effort name]

Skill: [exact-skill-name] Why this skill: [one line] Source: [ledger IDs that justify recommending this next step]

Prompt:

[Full prompt with the user's actual context injected. No placeholders.]

To execute P2: [effort name]

Skill: [exact-skill-name] Why this skill: [one line] Source: [ledger IDs]

Prompt:

[Full prompt with the user's actual context injected.]

Section 8. Evidence and source map

Audit of the inline sources. Confirm the binding constraint and P1 cite non-Inferred sources.

Inferred (Low confidence) claims: [list any, and confirm none drive the binding constraint or P1] Evidence gaps: [state honestly what the input did not support]