new-project-gate

name	new-project-gate
description	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.
version	1.1.0

New Project Gate

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.

Verdict at a glance

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

How to run it

Walk the six checkpoints in order. For each one:

1. Concise why — one line on what this checkpoint protects against.
2. 1-2 line answer — verdict for this idea, holding both lenses. If the lenses disagree, say so; that disagreement is the signal.
3. Mark the check — [x] [ ] or [~].

Stop early if checkpoint 0 or 1 fails hard. No point pricing the build of a tool that shouldn't exist.

The checkpoints

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?

• Agent lens: can an agent already reach this through an existing tool or MCP?
• Human lens: do I want a separate thing to open and maintain?

1. Real problem Whose problem, how often, what's done today instead?

• Agent lens: is there a task an agent repeatedly fails at without this, and how often does it come up?
• Human lens: do I hit this daily and suffer; would I reach for it unprompted next week?

2. Dumbest version that proves it Smallest cut that validates. File-first, no agent layer yet. Ugly is fine.

• Agent lens: minimum structured surface (files + schema) to drive it.
• Human lens: minimum UI I'd actually touch within a week.

3. Agent-legible by construction Clean data model, file-based state, scriptable now, MCP-able later.

• Agent lens: can an agent read/write state without scraping a GUI?
• Human lens: is the direct-touch loop still tight — legible, not agent-fronted?

4. Fastest path to the dumb version Reuse the template. No foundations for a tool that might not survive your own usage.

• Agent lens: what can be scaffolded straight from the template?
• Human lens: what can only I decide — design, naming, taste, the "feels right" call?

5. Kill criterion set up front Usage threshold and ARCHIVE path defined before building. No guilt, no maintenance tail.

• Agent lens: what measurable signal (last-touched, invocation count) flags it dead?
• Human lens: gut — would opening it feel like a chore rather than a reach?

Output

Produce two things. No preamble, no apology — state the verdict and the cut.

1. 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.

2. One-line note to project root docs

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>.

Example

# 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.

Pipeline

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.