Create an Architecture Decision Record (ADR) for any technical decision. Use when asked to document a technical decision, write an ADR, record an architecture choice, or capture why a technology or approach was selected. Produces a structured ADR with context, decision, consequences, and tradeoffs.
インストールする前に、エージェントに与えられる指示の中身を確認できます。
This skill produces a complete Architecture Decision Record (ADR) following the Nygard format — the most widely adopted standard. ADRs document the reasoning behind significant technical decisions so future team members understand not just what was decided, but why.
Work from what is given. If any of these is missing, still produce the complete output: fill each gap with a reasonable assumption marked (assumed, confirm) and list those assumptions at the end. Ask a question first only when the core subject itself is missing (there is nothing to write about).
Date: [YYYY-MM-DD] Status: [Proposed / Accepted / Deprecated / Superseded by ADR-NNN] Author(s): [Name(s)] Deciders: [Who had final say — individual or team]
[3–6 sentences. Describe the situation, constraints, and forces at play that made this decision necessary. Include: the problem being solved, relevant system state, team constraints, timeline pressures, or non-negotiable requirements. Write as if explaining to someone joining the team 18 months from now who has no prior context.]
Key constraints:
For each option, produce:
Description: [What this option is — 1–3 sentences]
Pros:
Cons:
Why this was ruled out (if not chosen): [Honest reason]
We will [chosen option].
[2–4 sentences explaining the decision in plain language. This should be readable in isolation — someone should understand the decision from this paragraph alone without reading the full document.]
[Include if the decision has non-obvious implementation gotchas, or if there are related tickets/RFCs implementers will need. Skip only if the decision is purely tooling selection with no implementation ambiguity.]
[Include unless the decision is permanent or self-evidently final. State a specific trigger condition — e.g. "Review if team grows beyond 20 engineers or traffic exceeds 10M requests/day" — not just "should be reviewed periodically".]
This skill ships with support files — use them when they are available:
references/decision-scoping.md — What Deserves an ADR (and What "Context" Must Contain). Apply it while producing the output; it carries the calibration and judgment calls the method summary above compresses.templates/adr.md — a fill-in version of the deliverable with the quality gates inline. Offer it when the user wants to work the document themselves rather than have it generated.Score any output of this skill before handing it over; 32+ is ship-quality.
| Dimension | 0 | 5 | 10 |
|---|---|---|---|
| Context reconstruction | Assumes the reader already knows the problem and the pressures | Problem stated, but the forces (team constraints, scale, deadline, forcing event) are missing | A reader two years later could guess the decision from the Context section alone |
| Options honesty | Only the chosen option, or rejected options written as strawmen | ≥2 options, but rejection reasons are circular ("didn't meet requirements") | Every rejected option has genuine strengths and a specific losing constraint tied to a context pressure |
| Consequence balance | All consequences are positive | Token negatives with no operational specifics | Negatives name real debts, new operational burdens, and what must stay true for the decision to hold |
| Revisit triggers | No risks or review conditions stated | "Review periodically" — no measurable condition | Specific, measurable trigger conditions that would invalidate the decision, with an owner |
まだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
Design a 360-degree feedback survey or write a structured 360 feedback report. Use when asked to build a 360 feedback process, write 360 feedback for a colleague, design a feedback survey, or produce a feedback report. Produces either a complete survey instrument with rating scales and open-ended questions, or a structured narrative feedback report with themes, strengths, and development areas.
日本語の概要は準備中です。原文の説明を表示しています。
Decode a 401k or workplace retirement plan — the real cost of its funds, the match's fine print, vesting math, and the plan features worth using or avoiding. Use when someone asks 'is my 401k any good', 'decode my 401k plan', 'which funds should I look at', or 'what fees am I paying'. Produces a fee decode in dollars-over-time, match and vesting math, a fund-lineup triage by cost, and the questions for HR or the plan administrator.
日本語の概要は準備中です。原文の説明を表示しています。
Design statistically rigorous A/B tests for product features, UI changes, onboarding flows, and pricing experiments. Use when asked to set up an experiment, design an A/B test, calculate sample size, or interpret test results. Produces a complete test plan with hypothesis, variant definitions, sample size, duration estimate, guardrail metrics, and a results interpretation guide.
日本語の概要は準備中です。原文の説明を表示しています。
Analyse a finished A/B test and write the readout — the result, whether it's statistically and practically significant, what it means, and the ship/no-ship call. Use when asked to analyse experiment results, write an A/B test readout, interpret test data, or decide whether to ship a variant. Produces a clear verdict with the lift and confidence, segment cuts, the risks (peeking, novelty, sample), and a recommendation. Distinct from planning a test — this reads results.
日本語の概要は準備中です。原文の説明を表示しています。
Build or tailor an academic CV for faculty, postdoc, research or fellowship applications: publications, grants, teaching, supervision and service in the order the field expects, with consistent citations. Use when asked to write my academic CV, update my CV for a lectureship, tenure-track or postdoc application, format my publications list, or adapt my academic CV for an industry research role. Produces the full academic CV, a field-appropriate section order, a clean publications list in one citation style, and a two-page summary version when asked.
日本語の概要は準備中です。原文の説明を表示しています。
Generate a WCAG 2.2 accessibility audit checklist and remediation suggestions for any UI or design. Use when asked to audit for accessibility, check WCAG compliance, review a design for a11y issues, or create an accessibility remediation plan. Produces a prioritised checklist with pass/fail assessments and specific fixes.
日本語の概要は準備中です。原文の説明を表示しています。