Framework Note — Source-Verified Decision Framework Card
Turn a framework name (premortem, OODA loop, Eisenhower Matrix) into a source-checked 4-part reference card instead of a from-memory summary that may be wrong. Given the name of a decision-making framework or mental model, it builds a card with four parts: Definition, How to Use It, Applied Example and Limits, plus a Sources list. Every factual claim (origin, year, usage, data points) must trace to a real source and be tagged quote, paraphrase or unverified. With web access it looks for the originating text; without it, it omits the claim or labels it unverified. The Applied Example must be a real, named case, or clearly labeled as an undocumented illustration. Paywalled sources are cited through public summaries with a plain note that the original was not accessed. It quotes only short passages and keeps critiques about the idea, never a named person. It does not present remembered details as settled fact.
Example input
Use the Framework Note on this (a sample I wrote). I run a small team that builds a scheduling app, and we keep launching features that quietly stall. I want a reference card for the "premortem" technique that I can pin in our team wiki. Please ground it in real sources rather than a generic paraphrase, and tell me honestly where you could not verify something. I only need the card itself, not a long essay. Our team is five people, we plan in two-week sprints, and we usually start a new feature by writing a one-page brief. Keep the example real if one exists, and if you cannot confirm one, say so and give me a clearly labeled illustration instead. I do not have a paid subscription to any business journal, so mention if a source is paywalled. My contact is team@example.com if you need to reference where to send corrections.
Example output
## Premortem ### Definition A premortem is a team exercise run before a project starts: everyone imagines the project has already failed, then writes down the reasons why, so risks surface while the plan can still change. It was proposed by the psychologist Gary Klein, and is commonly dated to his 2007 Harvard Business Review article "Performing a Project Premortem." — Source: Gary Klein, HBR, 2007 (paraphrase; unverified — from general knowledge, not independently confirmed; no web access was used in this run, and the HBR original is paywalled so even with access only public summaries could be cited). The idea is often linked to Klein's earlier work on "prospective hindsight" research; that link is also unverified here. ### How to Use It 1. Brief the team on the plan, and make sure everyone understands it well enough to picture it running. (paraphrase of the common description; unverified) 2. Announce the premise: "Imagine it is some time in the future and this project has failed, completely." Pick a concrete review date, such as the end of the quarter. 3. Each person works silently and alone for a few minutes, writing every reason they can think of for the failure, so quieter members are not drowned out. 4. Go around the room and collect one reason per person at a time until the list is exhausted; do not debate yet. 5. Sort the list. Choose the most likely and most damaging reasons and decide what to change in the plan (add a check, drop a risky dependency, assign an owner). 6. Revisit the list at a later checkpoint to see which risks materialized. Steps are a standard summary of how the technique is usually taught; I cannot attribute this exact breakdown to a specific source without verification (unverified). ### Applied Example No verifiable real-world example found — I could not confirm a specific named company or project that documented a premortem, and I will not invent one. Illustrative example below is not documented: A five-person team is about to build a "recurring appointments" feature. In the premortem they imagine it shipped and failed. Reasons written down: time-zone bugs for users who travel; the calendar-sync partner changes its API; nobody owns support tickets; the one-page brief never defined what "done" means. The team adds a time-zone test pass to the sprint, names a support owner, and rewrites the brief with a success metric. (illustration, not a real case) ### Limits - It surfaces risks but does not rank them with data. The output is a list of opinions, so the loudest or most imaginative fears can crowd out likelier ones. …
Real output from running the skill on a sample problem, shortened. The skill file itself is not published here.