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.
中文简介正在准备中。当前显示原文说明。
实测评分 未实测
查看安装方法安装前可以查看交给 AI 代理的指令内容。
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.
中文简介正在准备中。当前显示原文说明。