跳到正文
cccskills
免费在 GitHub 公开

new-project-gate

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.

中文简介正在准备中。当前显示原文说明。

实测评分 未实测

查看安装方法

包含的文件(1)

  • SKILL.md6.4 KB

SKILL.md(原文)

安装前可以查看交给 AI 代理的指令内容。

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.

评价

还没有评价。欢迎分享你的使用感受。

评论

无需登录即可发表。欢迎分享使用感受、提问,或说明在哪些环境下无法运行。

还没有评论。来写第一条吧。

提交后会立即公开。请勿填写邮箱、电话等个人信息。URL 最多 2 个。

0 / 1000 字

此表单受 reCAPTCHA 保护,适用 Google 的隐私权政策和服务条款。

同一仓库的技能

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.

中文简介正在准备中。当前显示原文说明。

aka-kika/akakika-skills112026年9月12日 更新

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.

中文简介正在准备中。当前显示原文说明。

aka-kika/akakika-skills112026年9月12日 更新

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.

中文简介正在准备中。当前显示原文说明。

aka-kika/akakika-skills112026年9月12日 更新

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.

中文简介正在准备中。当前显示原文说明。

aka-kika/akakika-skills112026年9月12日 更新

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.

中文简介正在准备中。当前显示原文说明。

aka-kika/akakika-skills112026年9月12日 更新

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.

中文简介正在准备中。当前显示原文说明。

aka-kika/akakika-skills112026年9月12日 更新

查看 aka-kika 的全部技能

报告此技能的问题