Use when creating a new project folder, starter pack, app scaffold, or agent-ready workspace — AGENTS.md, README, TASKS, DECISIONS, PROMPTS, an idempotent bootstrap script, and starter-pack modes.
日本語の概要は準備中です。原文の説明を表示しています。
Run before building anything new — a pre-build gate that decides whether an idea deserves its own tool, judged from both the agent lens (legible, drivable, automatable) and the human lens (will I touch it, do I want to maintain it). Trigger on "should I build X", "starting a new project / app / tool / repo", "is this worth making", "want to spin up", or any new-build intent — even if the word "checklist" never appears. Outputs a backed GATE.md with checkmarks and a one-line verdict note in the project root docs. Do NOT load for small config tweaks, one-off scripts, bug fixes on existing things, or anything that is clearly a feature of something you already run.
インストールする前に、エージェントに与えられる指示の中身を確認できます。
A gate, not a form. Run it before the editor opens.
The job is to kill bad ideas cheaply and let good ones through with their smallest proving cut already named. The failure mode this guards against is sprawl — fast at building the wrong thing is just faster sprawl.
After a project is built and shipped, run it through old-project-audit on the next pass to decide if it earned its keep.
Checkpoint 0 or 1 → KILL | Any other [ ] → CUT | All green or [~] → GO |
|---|---|---|
| Tool shouldn't exist at all | Build smaller, fix the gap first | Build the dumbest proving cut |
[x] = passed · [ ] = failed · [~] = unsure / needs the human
Walk the six checkpoints in order. For each one:
[x] [ ] or [~].Stop early if checkpoint 0 or 1 fails hard. No point pricing the build of a tool that shouldn't exist.
0. Deserves to exist as its own tool Standalone thing, or a feature of something already running? Overlap with the catalogue? Is a new surface justified?
1. Real problem Whose problem, how often, what's done today instead?
2. Dumbest version that proves it Smallest cut that validates. File-first, no agent layer yet. Ugly is fine.
3. Agent-legible by construction Clean data model, file-based state, scriptable now, MCP-able later.
4. Fastest path to the dumb version Reuse the template. No foundations for a tool that might not survive your own usage.
5. Kill criterion set up front Usage threshold and ARCHIVE path defined before building. No guilt, no maintenance tail.
Produce two things. No preamble, no apology — state the verdict and the cut.
GATE.md (or <idea-slug>-gate.md)# <Idea> — New Project Gate
Date: <today>
Verdict: GO / CUT / KILL
- [x] 0. Deserves to exist — <1-2 line answer>
why: <concise why>
- [x] 1. Real problem — <1-2 line answer>
why: <concise why>
- [ ] 2. Dumbest proving version — <1-2 line answer>
why: <concise why>
- [~] 3. Agent-legible — <1-2 line answer>
why: <concise why>
- [x] 4. Fastest path — <1-2 line answer>
why: <concise why>
- [x] 5. Kill criterion — <1-2 line answer>
why: <concise why>
Smallest proving cut: <one line — what to actually build first>
Kill criterion: <one line — when this gets archived>
Verdict rule: any [ ] on checkpoint 0 or 1 → KILL. Any other [ ] → CUT. All green or [~] → GO.
Append one line to the project's root doc — CLAUDE.md if present, else AGENTS.md, else README.md, else create NOTES.md:
> Gate <date>: <VERDICT> — <smallest proving cut>. Kill if <criterion>.
# Daily Writing Habit Tracker — New Project Gate
Date: 2026-06-28
Verdict: CUT
- [x] 0. Deserves to exist — Not in my toolbox. No existing tool
covers daily-writing-with-streak-stats.
why: Stop adding tools that duplicate existing surfaces.
- [~] 1. Real problem — I think I want this. Not sure I hit it daily.
Maybe 2x/month when I'm in a streak mood.
why: Catch vibe-driven "ideas" before they become apps.
- [ ] 2. Dumbest proving version — Was going to build a SwiftUI app.
Way too much for an unproven itch.
why: First cut must be tiny enough to abandon cheaply.
- [x] 3. Agent-legible — A flat JSON file + a small CLI would work.
why: If an agent can't read it, the data rots.
- [x] 4. Fastest path — Could scaffold from my starter template in
an evening. Two scripts: append + report.
why: Reuse before reinventing.
- [x] 5. Kill criterion — Archive if not used for 30 days or under
10 entries by end of month 2.
why: Set the kill bar before you fall in love with the build.
Smallest proving cut: Plain JSON log + daily cron-style CLI for 30 days, no UI.
Kill criterion: Under 10 entries in 60 days → archive, no rebuild.
Lens note: checkpoint 1 is [~] because the human side is honest about the vibe-driven itch. That's exactly the case the gate is built for — CUT, not KILL, because checkpoint 0 is green. Build the dumb version first; the kill criterion decides if it earns the upgrade.
Built something and shipped it? Run old-project-audit on it within a season. Tools that aren't re-audited go to limbo, which is the most expensive state a tool can sit in.
まだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
Use when creating a new project folder, starter pack, app scaffold, or agent-ready workspace — AGENTS.md, README, TASKS, DECISIONS, PROMPTS, an idempotent bootstrap script, and starter-pack modes.
日本語の概要は準備中です。原文の説明を表示しています。
Use when designing or implementing states for AI agent tasks, background jobs, local model runs, queues, and notifications — one shared set of states, only legal transitions, and a recovery path out of every failure.
日本語の概要は準備中です。原文の説明を表示しています。
Use when exposing app features to App Intents, Shortcuts, Siri, Spotlight, widgets, controls, or system actions — small safe AppIntents, AppShortcutsProvider, AppEnum/AppEntity, parameters, and open-vs-background behavior.
日本語の概要は準備中です。原文の説明を表示しています。
Use when designing, reviewing, or implementing a command-palette / ⌘K layer for an Apple-platform app — keyboard-first global search, ranked and grouped results, native floating panel, and protected destructive commands.
日本語の概要は準備中です。原文の説明を表示しています。
Use when designing or implementing empty, first-run, no-result, offline, error, or waiting states in Apple-platform apps — every empty state explains what is missing, why it matters, and what to do next.
日本語の概要は準備中です。原文の説明を表示しています。
Use when designing or implementing feedback, status, progress, alerts, errors, success states, and live activity indicators in Apple-platform apps — inline status, banners, alerts, notifications, and loading states.
日本語の概要は準備中です。原文の説明を表示しています。