用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt;运行前请先检查来源。
npx skills add https://github.com/SocketDev/action --skill building-tdd命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地?可下载 SkillsMP 当前能够提供的文件。
Propagate a wheelhouse template change across fleet repos: worktrees, push/PR fallback, cleanup.
Run this repo's GitHub Actions locally with Agent-CI before pushing CI-sensitive changes.
Audit package exports for dead, internal-only, or weakly-consumed subpaths before pruning.
基于 SOC 职业分类
正在显示 SKILL.md
| name | building-tdd |
| description | Use red-green-refactor for a feature or bug fix when the user asks for test-first work. |
| metadata | {"internal":true} |
Red-green-refactor in vertical slices — one test → one implementation →
repeat. The loop is pnpm test <file> going red then green. Seam doctrine
(public interface, highest seam, vitest, no source-text assertions, member
co-location vs wheelhouse test/repo/):
test-layout. The deterministic
core is every pnpm test / pnpm run check run; AI owns the residue — what to
test and how to name the behaviour (code-first-then-ai).
Do NOT write all tests then all implementation. Tests written in bulk verify imagined behaviour — they assert the shape of data and signatures, pass when behaviour breaks, and outrun your understanding. One behaviour at a time.
Establish the project's behavioural vocabulary first — rg 'describe\(' test/ | head -20 to see how existing tests name behaviour, so your test names match.
Then list the behaviours to test (not implementation steps) and the public
interface under test. You can't test everything — pick the critical paths.
Write ONE test for ONE behaviour at the correct seam. Name the
pnpm test <file> invocation. Watch it go red. Write the minimal code to
make it green. This proves the path end-to-end.
For each remaining behaviour: RED (pnpm test <file> fails) → GREEN (minimal
code passes). One test at a time, only enough code to pass the current test,
don't anticipate future tests, assert observable behaviour through the public
interface — never internal structure or source text.
Only after all tests pass. Run pnpm run check + pnpm run lint. Refactor with
the green suite as your safety net; the tests shouldn't change (they verify
behaviour, not implementation). prefer-vitest-guard and no-test-in-scripts-guard
enforce the structural rules — this skill is the procedural loop they assume.
Every chosen behaviour has a passing test that exercises it through the public
interface, pnpm run check is green, and no test asserts implementation detail.
Use writing-fast-tests to pick the cheapest seam for each test you add — the unit tier is budgeted under a minute, and a spawned child costs ~68,000× an in-process call. Then reviewing-code for an independent branch review, and pushing for the complete release gate.