ワンクリックで
user-action-edge-cases
Use when finishing anything that depends on external state a person controls - a file, a record, a folder.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
メニュー
Use when finishing anything that depends on external state a person controls - a file, a record, a folder.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Use when about to show any prose a human will read - docs, README, commit bodies, UI copy, store text.
Use when building any mechanic that could fail on a machine out of reach - a shipped product, a CLI a user runs, a server.
Use when doing any work in a project that has the instincts plugin installed
Use when touching build scripts, release or packaging steps, publish flows, or CI config.
Use when about to build something someone proposed, especially when the proposer sounds confident and the idea sounds obviously fine.
Use when adding any cross-cutting change - a new gate, limit, permission check, or rule that must apply everywhere.
| name | user-action-edge-cases |
| description | Use when finishing anything that depends on external state a person controls - a file, a record, a folder. |
Anything you depend on that a user can touch will get renamed, moved, deleted, and duplicated. If your code assumes a fixed path or a single copy, it breaks the first time the user does something ordinary. Before you finish, run those four actions through your head.
Your code reads, writes, or depends on a file, a record, a document, or any state the user can edit outside your code.
For each thing you depend on, ask the four questions: renamed? moved? deleted? duplicated?
Prefer finding things by type or id over a hardcoded path or name. Decide what happens in each case instead of assuming it won't happen.
Your app stores its settings in a file at a hardcoded path. It works on your machine. Then a user renames the file, and the app silently writes a fresh one with defaults, losing their config. Or they copy the project folder, and now two copies fight over the same path. Looking the file up by a stable marker instead of a fixed name, and handling "not found" and "more than one" on purpose, turns four silent bugs into defined behavior.
| Thought | Reality |
|---|---|
| "The file is always at this path" | Until the user moves it. |
| "There's only ever one" | Until they duplicate it. |
| "They won't rename it" | They will. |