Extract design rationale
Skill jpoindexter/design-case-study-skills/skills/extract-design-rationale
Evidence-backed UX and AI-agent case study skills for Codex and Claude
npx -y skills add jpoindexter/design-case-study-skills --skill extract-design-rationaleAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- 14 days oldThe repository was created 14 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Extract defensible design rationale from project notes, logs, specifications, research, and artifacts. Use when a case study shows what was built but not why, needs a constraint-alternatives-decision matrix, must explain rejected options and trade-offs, or needs to connect a UI, product, system, or AI-agent decision to evidence and measurable consequences.
SKILL.md
2.1 KB, as published. Nobody here has run it
Extract Design Rationale
Turn implementation history into a decision argument. Read references/rationale-matrix.md.
Workflow
- Inventory candidate decisions in the supplied evidence.
- Keep only decisions that changed user outcomes, system behavior, risk, cost, delivery, or learning.
- For each decision, extract:
- the constraint or problem;
- the tension between competing goals;
- the alternatives genuinely considered;
- why each alternative was rejected or deferred;
- the final decision and owner;
- the evidence available at decision time;
- the observed consequence or metric.
- Separate contemporary evidence from hindsight.
- Mark absent alternatives, rationale, ownership, or outcomes as evidence gaps.
- Rank the records by narrative importance.
Do not invent alternatives to make a decision look rigorous. Do not convert a team decision into sole-designer ownership. Do not claim business alignment without a named goal, constraint, or metric.
Output
Return:
- a one-sentence decision thesis;
- a ranked shortlist of pivotal decisions;
- one rationale matrix per decision;
- the strongest visual or artifact to pair with each record;
- unresolved evidence gaps.
Example
Input:
Users missed background-agent failures. We considered persistent alerts, a blocking
modal, and an activity timeline. Support logs showed most failures were recoverable.
We shipped the timeline plus a thresholded alert; failed-task recovery rose from 62%
to 84% in the beta.
Expected outcome: a matrix naming failure visibility as the constraint, the modal and persistent-alert trade-offs, the selected timeline-plus-threshold model, the support-log evidence, and the 62%→84% recovery result.