lint-and-test-gate

WHAT: After editing shell / bats / TypeScript in this repo, run the matching gate command (`./dev/lint-shell.sh`, `./dev/test-bats-docker.sh`, or `npm test`) before claiming the change is done, and quote the pass output. WHEN: Any finished edit in dotenv/, plugins/, tests/, config/, or lib/node/. DO-NOT: Run the local `./dev/test-bats.sh` when `./dev/test-bats-docker.sh` is available; skip the gate because "it's a small change"; claim done without quoting the pass tail.

跳到安装

仓库: weikinhuang/dotfiles
最近来源活动: 2026年5月22日 22:26
检测到的 SKILL.md 语言: 英语
星标: 21
分支: 3

安装方式

默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。

用 Codex 或 Claude 帮你安装复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。

直接命令不会经过审查 Prompt；运行前请先检查来源。

npx skills add https://github.com/weikinhuang/dotfiles --skill lint-and-test-gate

命令会保持在同一行。复制前请横向滚动并检查完整内容。

想先保存到本地？可下载 SkillsMP 当前能够提供的文件。

检查来源文件

决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。

SKILL.md

来源说明 · 只读预览

name

lint-and-test-gate

description

Lint and Test Gate

Every change to shell, bats, or TypeScript in this repo has a specific gate command. Run it, quote the last few lines of pass output, then claim the change is done. This is the repo-specific instance of the harness-agnostic verify-before-claim skill.

The gate table

Match what you touched to the command you run:

Touched	Gate command
Any `.sh` file (dotenv, plugins, config, bin scripts)	`./dev/lint-shell.sh`
Any `.bats` file (added or edited)	`./dev/test-bats-docker.sh tests/<changed-path>.bats` then `./dev/test-bats-docker.sh`
Any `lib/node/*/.ts` or `lib/node/*/.spec.ts`	`npm test`
Anything that changed shell AND added/changed a test	Run both gates above.
A public-surface doc change (REFERENCE.md, README.md)	No gate - but confirm the change is consistent with the code.

Always prefer a focused run first (single file / single path), then a full-suite run to catch ordering breakage.

Docker is the default for bats

Run ./dev/test-bats-docker.sh, not ./dev/test-bats.sh, unless Docker is unavailable. Docker pins the bats, bats-support, and bats-assert versions and bypasses host drift. -q mutes pass noise, which is useful when you're running the full suite:

./dev/test-bats-docker.sh -q
./dev/test-bats-docker.sh tests/dotenv/bin/git-sync.bats     # focused
./dev/test-bats-docker.sh tests/plugins/                      # subtree

Quote the pass tail

When the gate passes, copy the last 3-6 lines of output into your reply. For bats that's the summary line (<N> tests, 0 failures); for shellcheck it's silent on success so ./dev/lint-shell.sh exiting 0 is the signal - say so explicitly.

Good:

Ran ./dev/lint-shell.sh - exited 0 (no shellcheck or shfmt findings).

Ran ./dev/test-bats-docker.sh tests/dotenv/bin/git-sync.bats:
12 tests, 0 failures

Bad:

Tests pass, looks good.

When you can skip the gate

Only when the change has no executable impact the gate could catch:

Pure documentation edits (README, REFERENCE, AGENTS.md).
A skill / agent config file that isn't code.
The user explicitly said "don't run tests, I'll run them".

If in doubt, run the gate. The cost is small; the cost of claiming done on a broken change is large.

Lint-staged and pre-commit

If lint-staged / git hooks are wired in, they run a subset of gates on commit. That's backup, not a substitute - run the gate yourself first so you can react to failures without a broken commit in progress.

Anti-patterns

"I only touched one line, no need to test." Pass the gate anyway; one-line changes have bitten this repo before.
Running just the focused test and skipping the suite on a refactor. Cross-file changes need the full suite to catch ordering / isolation bugs.
Using ./dev/test-bats.sh because Docker feels slow. Docker is the reference environment. If it's slow, run focused tests during development and the full suite before claiming done.
Claiming pass without quoting the output. Users shouldn't have to rerun to confirm.
Running npm test when only shell changed. Wrong gate - it won't catch shell issues and wastes time.
Ignoring shellcheck findings. They're treated as errors, not warnings, by ./dev/lint-shell.sh. Fix them.

Quick reference

Change	Run this
Tiny shell tweak	`./dev/lint-shell.sh`
New / edited bats test	`./dev/test-bats-docker.sh tests/<path>.bats` then `./dev/test-bats-docker.sh -q`
New bin script (script + completion + test)	`./dev/lint-shell.sh` and `./dev/test-bats-docker.sh tests/dotenv/bin/<script>.bats`
New plugin	`./dev/lint-shell.sh` and `./dev/test-bats-docker.sh tests/plugins/<name>.bats`
TypeScript helper in `lib/node/`	`npm test`
Mixed shell + TS	All three: `./dev/lint-shell.sh`, `./dev/test-bats-docker.sh -q`, `npm test`

返回搜索返回安装

krea2-prompting

Prompting rules for the open-weight **Krea 2 Turbo** text-to-image model on the comfyui `krea2` / `krea2-2gpu` workflows. Use when the user asks to generate / draw / render an image on a Krea 2 workflow. Krea 2 is an aesthetic-first natural-language model (Qwen3-VL text encoder) - write descriptive prose or real descriptor phrases, not booru tags; pass no negative prompt; and leave the baked 8-step / cfg-1 recipe alone.

2026-07-31

stress-test-idea

WHAT: Run an adversarial interview that stress-tests a raw idea before any building - surface its load-bearing assumption, steel-man the counter-case, register kill-criteria, and end with a go/no-go verdict. WHEN: Only when explicitly invoked - "grill me on X", "interview me about X", "poke holes in this", "stress-test this idea", "is this a dead end", "red-team X", "help me decide if X is worth doing", or "break this big idea into a smaller first version." DO-NOT: Do not fire unprompted on brainstorm-y talk; do not write code or a plan doc (stop at the verdict); do not endorse the idea until a real failure mode and a concrete alternative are on the table; do not cave the moment the user pushes back.

2026-07-02

feature-eval-author

WHAT: Build a behavioral eval that drives a small model of your choice (any pi provider) headless through the pi SDK to measure whether a pi extension / feature actually changes model behavior - does the model READ injected state, ACT on an injected directive, or pick the right memory. WHEN: You added or changed a pi extension that injects context, nudges, recalls, or steers (memory, todo, scratchpad, capture, recall, guardrails) and want evidence it works on a small model, not just on a frontier one. DO-NOT: Use for unit logic that vitest already covers (pure reducers, formatters, scorers - test those offline), for frontier-model-only behavior, or for anything that does not need a live model in the loop.

2026-07-01

查看这个仓库的全部 Skills

name

lint-and-test-gate

description

Lint and Test Gate

The gate table

Match what you touched to the command you run:

Touched	Gate command
Any `.sh` file (dotenv, plugins, config, bin scripts)	`./dev/lint-shell.sh`
Any `.bats` file (added or edited)	`./dev/test-bats-docker.sh tests/<changed-path>.bats` then `./dev/test-bats-docker.sh`
Any `lib/node/*/.ts` or `lib/node/*/.spec.ts`	`npm test`
Anything that changed shell AND added/changed a test	Run both gates above.
A public-surface doc change (REFERENCE.md, README.md)	No gate - but confirm the change is consistent with the code.

Always prefer a focused run first (single file / single path), then a full-suite run to catch ordering breakage.

Docker is the default for bats

./dev/test-bats-docker.sh -q
./dev/test-bats-docker.sh tests/dotenv/bin/git-sync.bats     # focused
./dev/test-bats-docker.sh tests/plugins/                      # subtree

Quote the pass tail

Good:

Ran ./dev/lint-shell.sh - exited 0 (no shellcheck or shfmt findings).

Ran ./dev/test-bats-docker.sh tests/dotenv/bin/git-sync.bats:
12 tests, 0 failures

Bad:

Tests pass, looks good.

When you can skip the gate

Only when the change has no executable impact the gate could catch:

Pure documentation edits (README, REFERENCE, AGENTS.md).
A skill / agent config file that isn't code.
The user explicitly said "don't run tests, I'll run them".

If in doubt, run the gate. The cost is small; the cost of claiming done on a broken change is large.

Lint-staged and pre-commit

Anti-patterns

"I only touched one line, no need to test." Pass the gate anyway; one-line changes have bitten this repo before.
Running just the focused test and skipping the suite on a refactor. Cross-file changes need the full suite to catch ordering / isolation bugs.
Using ./dev/test-bats.sh because Docker feels slow. Docker is the reference environment. If it's slow, run focused tests during development and the full suite before claiming done.
Claiming pass without quoting the output. Users shouldn't have to rerun to confirm.
Running npm test when only shell changed. Wrong gate - it won't catch shell issues and wastes time.
Ignoring shellcheck findings. They're treated as errors, not warnings, by ./dev/lint-shell.sh. Fix them.

Quick reference

Change	Run this
Tiny shell tweak	`./dev/lint-shell.sh`
New / edited bats test	`./dev/test-bats-docker.sh tests/<path>.bats` then `./dev/test-bats-docker.sh -q`
New bin script (script + completion + test)	`./dev/lint-shell.sh` and `./dev/test-bats-docker.sh tests/dotenv/bin/<script>.bats`
New plugin	`./dev/lint-shell.sh` and `./dev/test-bats-docker.sh tests/plugins/<name>.bats`
TypeScript helper in `lib/node/`	`npm test`
Mixed shell + TS	All three: `./dev/lint-shell.sh`, `./dev/test-bats-docker.sh -q`, `npm test`

lint-and-test-gate

来源信息

安装方式

检查来源文件

Lint and Test Gate

The gate table

Docker is the default for bats

Quote the pass tail

When you can skip the gate

Lint-staged and pre-commit

Anti-patterns

Quick reference

同仓库更多 Skills

Lint and Test Gate

The gate table

Docker is the default for bats

Quote the pass tail

When you can skip the gate

Lint-staged and pre-commit

Anti-patterns

Quick reference

同仓库更多 Skills