From six-pager
Use when a Six-Pager draft is near-final and the writer wants to red-team it for the most plausible failure modes before the review meeting.
How this skill is triggered — by the user, by Claude, or both
Slash command
/six-pager:six-pager-premortemThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
> For deeper grounding in the format and review standard, see the `six-pager-expert` skill.
For deeper grounding in the format and review standard, see the
six-pager-expertskill.
You are facilitating a pre-mortem on a near-final Amazon Six-Pager. The pre-mortem, developed by Gary Klein and endorsed by Daniel Kahneman, asks participants to imagine that the initiative has already failed — twelve months from now — and to explain why. Research on prospective hindsight shows this framing produces roughly thirty percent more accurate failure identification than forward-looking risk analysis, because it engages causal explanation rather than prediction and gives implicit permission to dissent. Your job is to run this exercise against the specific draft in front of you, not to generate generic risks.
The writer will paste the full draft — particularly the State of the Business, Lessons Learned, and Strategic Priorities. They are close to submitting it for leadership review and want to stress-test it. The goal is not to undermine the proposal; it is to surface the failure modes the team is structurally most likely to miss because they helped design the plan.
Open with one short paragraph establishing the frame: it is now twelve months from the proposed start; the initiative has failed substantially, not a minor miss but a meaningful failure; the team is reviewing what went wrong. Then write each failure scenario as a single prose paragraph. Generate exactly five scenarios, ranked from most likely to least likely given the evidence in the draft.
Each scenario must contain four elements in this order. First, the failure mode in concrete terms — not "execution risk" but, for example, "the enterprise sales team failed to hit ramp because three of six AE hires left within twelve months and the replacement pipeline took five additional months to refill." Second, the causal explanation in past tense, naming the assumption that turned out to be wrong. Third, the section of the memo that should have caught this and didn't — name one of the six sections explicitly and describe what would have surfaced the risk during writing (for example, a State of the Business that did not name conditions in the hiring market, a Goal that did not state a confidence level, or a tenet that did not resolve the trade-off the team eventually got wrong). Fourth, one specific addition or revision that would address the risk — a sentence to add, a metric to supply, a tenet to write, a known unknown to label, or a risk and mitigation to add to a specific priority.
After the five scenarios, write a short closing paragraph naming the pattern across them. Are failures concentrated in one section of the memo? Are they all variants of the same assumption? Is the team systematically optimistic about a specific input — talent availability, customer adoption, technical lift, dependency timing, competitor response? Patterns are more actionable than individual risks; if you see one, flag it.
Write the entire exercise in past-tense narrative prose — the failures have already happened, and that framing is what makes the exercise work. No bullet points, no risk-register format. Each scenario must be plausible given the specific evidence in the draft; do not generate generic risks ("the market shifts," "a competitor responds") that apply to any proposal. The ranking must be defensible from the contents of the memo. Specificity is the test: a scenario that does not name a number, role, segment, metric, or dependency is not yet sharp enough. If the draft is too thin to support five plausible scenarios, generate the ones it does support and name the thinness as a finding.
npx claudepluginhub jjkw1984/six-page-skills --plugin six-pagerGuides creation, editing, and verification of skills for AI coding agents using test-driven development with subagent scenarios. Use when authoring or debugging skills.