本文へ移動
cccskills
無料GitHub で公開

os-what-could-go-wrong

ALWAYS invoke this skill before anything hard to undo gets agreed to - a contract, a purchase, a migration, a launch, a price change, a reorganisation - and whenever the user asks "what could go wrong", "what are we missing", "poke holes in this", or for a premortem or a red team, in any language. Assumes the decision already failed and works backwards to find out why, in a fresh agent that had no hand in making it. Sweeps nine areas and shows what each produced, including the empty ones. Ends on one verdict: go ahead, go but fix these first, try it small first, think again, do not do this.

インストール方法を見る

含まれるファイル(6)

  • SKILL.md7.2 KB
  • references/01-office-lease.md14.3 KB
  • references/02-clinic-database-move.md21.5 KB
  • references/premortem-prompt.md10.4 KB
  • references/why-these-rules.md1.3 KB
  • scripts/prompt.sh472 B

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

os-what-could-go-wrong

Assume it already failed, then work backwards to find out why - while there is still time to change it. The attack runs in a fresh agent that had no part in the decision, because an agent that helped shape one reviews it far too gently: it defends its own reasoning, and it misses the thing that kills the plan out of politeness.

os-ask-simple screens a choice before the user picks one. This one runs after the choice is made and before it can no longer be taken back.

Language

Write in the language the user speaks in this session, detected from the conversation. Names, figures and identifiers stay as they are. The fresh agent cannot see this conversation, so the language travels in the handover.

Step 1 - write down what is actually being decided

Find the decision first. Given as text or a document, that is it. Asked at the end of a discussion, it is the decision the discussion arrived at, and say which one you took it to be. If neither, ask which decision to attack.

Then fill every line. This is the only thing the fresh agent will ever see.

DECISION BRIEF
What will be done: three to seven sentences
What it is for: the problem it solves, and what success looks like, measured
  wherever it can be
The main moves: the money, the people, the systems, the dates
What is fixed: the constraints, plus the surrounding facts that matter
Who it lands on: who and what is affected if this goes wrong
What cannot be undone: which parts are one-way
When we would know: the date success or failure actually gets judged
What we know: facts from documents, data, the repository, past incidents,
  each with where it came from
What we are assuming: every gap nobody could close, written as an assumption

Close the gaps in this order, and stop as soon as a gap is closed.

  1. Look it up yourself. Documents, data, the repository, the last report in ~/.claude/open-steps/reports/, what went wrong last time.
  2. Ask, but earn the ask. Only a gap where guessing wrong would change the verdict, one question at a time through os-ask-simple, three at most. Nobody there to answer, or an answer that would not move the verdict -> 3.
  3. Write the guess down as a guess. Put the assumed value in its line, mark it (assumed), and repeat it under "What we are assuming".

The brief states facts and open questions. It never makes the case for the decision: a brief that argues gets a report that agrees.

Step 2 - hand it to an agent that had no part in it

Pick the depth, say which in one line, and carry on; the user can change it.

DepthWhen
FullHard to undo, or being wrong costs money, trust or data beyond one team
QuickReversible, and cheap to be wrong about, whoever it touches

When in doubt, Full. The cost of a full look is a few minutes; the cost of a quick look at a one-way door is the door.

Dispatch one fresh agent, not several: in Claude Code, a general-purpose agent; elsewhere, whatever starts with an empty context. Send it four things and nothing else: the analysis prompt copied exactly from the bottom of this skill, MODE: Full or MODE: Quick, LANGUAGE: <the language above>, and the brief. Never send an instruction to run this skill: the fresh session would load it and start over.

If no fresh agent can be started, run the prompt yourself with the same MODE, LANGUAGE and brief. The prompt says you did not help make this decision; for you that is false, so work from the brief alone and attack your own reasoning hardest. Never call the result independent.

Step 3 - give it to the user straight

The user never sees what the agent returned: a tool result is visible only to you. So your final message is that report, copied whole, first line to last. One line goes before it: the depth, and whether a fresh agent ran (if not, name your tool and say this session wrote the report). Anything of your own comes after it, never instead of it: no summary in its place, no "details above", no reassurance the analysis did not earn, no dropped card because the user seemed committed. Bad news that arrives late is worth nothing.

Then offer to turn the "Fix before you commit" list into real things: edits to the plan, tickets, an owner and a date per item, a reminder for each early warning. "Go ahead" is delivered just as plainly.

Hard rules

  1. The agent that helped decide does not attack the decision when a fresh one can. Dispatch one every time, even with it all in context. Skipping it changes the answer. Only a tool that cannot start one takes the fallback.
  2. No quota of risks. Publish what has a real chain behind it and nothing else. Three well-anchored risks beat seven padded ones, and "only two survived" is a finding worth saying out loud.
  3. The verdict is decided last and printed first. Never make the reader assemble it from the risks.
  4. Every area of the sweep is accounted for, including the ones that produced nothing. An area nobody mentions and an area nobody checked look the same to the reader.
  5. A skipped section keeps its one line saying why.
  6. A lease and a database migration get the same treatment. This is not a technical review; the nine areas apply to both, and the money and people ones are where technical decisions usually actually fail.
  7. "The plan is sound" is a legitimate answer once the attack has run. It is never a substitute for running one.
  8. The final message is the report itself. The user cannot see what the agent returned; a summary of it, however good, is not it.

Known gotchas

  • No date to be judged by means no premortem. Pick a date that fits the decision, and say you picked it.
  • Something reversible and cheap does not need this. Quick look, or say so.
  • "Try it small first" is not a soft no. Test unknowns before money moves.
  • The user may go ahead against all of it. Note it once, set the tripwires up if they want them, and do not re-argue the report.

The reasoning behind these is in references/why-these-rules.md.

The analysis prompt, verbatim

The block below is the whole of references/premortem-prompt.md, inlined when this skill loads through scripts/prompt.sh, so no file has to be read at dispatch time. If it shows a literal command instead, your tool does not run inline commands: open that file next to this one and use its full text.

!bash ${CLAUDE_SKILL_DIR}/scripts/prompt.sh

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

同じリポジトリのスキル

概要と使いどころ

ALWAYS invoke this skill before asking the user any technical question or offering options, and whenever they ask to be asked in plain words - "ask simple", "ask me simply", "ask me in plain words" - in any language. ALWAYS invoke it too when the user asks for your view on a technical choice: whether it is worth doing, more than the problem needs, or replaceable by something simpler, and which option you would take. Invoke it even when the code makes the answer look obvious: the checks are what make the answer more than a guess. Rewrites the question in plain words and always ends with one marked recommendation. A structural choice first passes six checks, shown as a table: effort now, simpler substitute, extra work later, lock-in, over-engineering, easy to undo. Doing nothing is always weighed.

日本語の概要は準備中です。原文の説明を表示しています。

kharmanskyi/open-steps1,2822026年10月6日 更新

ALWAYS invoke this skill when the user asks where the project as a whole stands - "where are we", "what's the big picture", "what have we built", "what is in this project", "map the project", "what does this thing even do", "what is stale", "what can we delete", "update the roadmap" - in any language, and whenever a session report has just been written. It keeps one file, BIG-PICTURE.md: what the product is, every feature with how far it got, which parts nobody has touched, and what is queued next. Age and wiring are measured from git; how far a feature got comes from the reports or says "not checked". Where a tracker is connected it offers to open the queue as tickets, after a yes and never before. Never invents work, never deletes code.

日本語の概要は準備中です。原文の説明を表示しています。

kharmanskyi/open-steps1,2822026年10月6日 更新

ALWAYS invoke this skill when the user asks about work done outside this session - "check work", "check the others", "check other sessions" - or to accept one: "the session is done, check it", "can we merge it" - in any language. You are the receiving party: treat the report as a claim, verify each part against machine state, name every gap between claimed and true. Verified-ready work merges in the same pass. End with what is left, one next step, and any reply another session needs, ready to paste.

日本語の概要は準備中です。原文の説明を表示しています。

kharmanskyi/open-steps1,2822026年10月6日 更新

ALWAYS invoke this skill when work wraps up or the user asks how it went - "done or not", "are we done", "what happened", "report", "what's the status of this ticket" - in any language, and when a Stop hook asks for a session report. Produces a ten-line plain- language report: a lead, a checkmark table, and a verdict - fully done, anything needed from you, new debt, safe to close. Every "yes" names its proof; unverified says "not checked". Saves the report so the next session starts from it instead of re-exploring the repo.

日本語の概要は準備中です。原文の説明を表示しています。

kharmanskyi/open-steps1,2822026年10月6日 更新

ALWAYS invoke this skill when the user asks for simpler or shorter about something said or written - "say it simply", "what does this mean", "I don't understand your answer", "too long", "wait, what?", "bro" - in any language, about any text: your own answer, a report, a review comment, an error. "I don't understand what to DO" is os-step-by-step; this skill restates text. It restates for a reader who does not read code: leads with the point, keeps every number, warning and caveat - no facts added, no bad news dropped. A number returns exactly that many points, most important first.

日本語の概要は準備中です。原文の説明を表示しています。

kharmanskyi/open-steps1,2822026年10月6日 更新

ALWAYS invoke this skill when you need the user to act - run a command, paste a secret, click, approve - and whenever they ask how to do something or say they do not know what to do: "step by step", "walk me through it", "what do I do", "what should I do", "I don't understand what to do", "explain what I need to do", in any language. Picking which task comes next is os-whats-next; this skill is for doing the thing in front of you. First earn the ask: try it yourself, find another route, shrink it to the part only they can do. Then one action per step, commands labelled by what they touch, no jargon. Commands are single lines that prompt for any value - typing hidden for secrets - and confirm in plain words. Afterwards verify their step.

日本語の概要は準備中です。原文の説明を表示しています。

kharmanskyi/open-steps1,2822026年10月6日 更新

kharmanskyi のスキルをすべて見る

このスキルの問題を報告する