agentleFS
aka-kikaaka-kika/akakika-skills/skills/project-intelligence/new-project-gate/SKILL.md

new-project-gate

Skill11 starsChanged 3 months agoMITView on GitHub

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.

The file

We split this skill into the rules it gives an agent

2 rules. About 0 are common, 2 are distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈2

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    After a project is built and shipped, run it through old-project-audit on the next pass to decide if it earned its keep.

    line 13
  2. Distinctive:

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

    line 31

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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 → KILLAny other [ ] → CUTAll green or [~] → GO
Tool shouldn't exist at allBuild smaller, fix the gap firstBuild 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.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.