agentleFS
JacobinwweyJacobinwwey/notemdpro/skills/test-driven-development/SKILL.md

test-driven-development

Skill2 starsChanged 38 days agoMITView on GitHub

Verify portable helpers with production-module regression tests before changing behavior.

190 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use chinese-code-review, chinese-commit-conventions and 9 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • Leodorareluctant259Skill

    chinese-code-review

    中文代码审查规范——在保持专业严谨的同时,用符合国内团队文化的方式给出有效反馈

    Also in 8 projects that use this

  • Leodorareluctant259Skill

    chinese-commit-conventions

    中文 Git 提交规范 — 适配国内团队的 commit message 规范和 changelog 自动化

    Also in 8 projects that use this

  • obraSkill

    diagnosing-superpowers

    Use when a superpowers session went wrong and your human partner wants to know why — repeated work, ignored plans, stumbles, poor results, a skill that didn't fire, "it took too long", "why is it so expensive", "what is it doing" — or wants to build a bug report for the superpowers maintainers, for the current session or a past one identified by id or path, on any harness.

    Also in 19 projects that use this

  • LLl0k0laDSkill

    using-agent-skills

    Use when starting a session or when you need to discover which skill applies to the current task. This is the meta-skill that governs how all other skills are discovered and invoked.

    Also in 39 projects that use this

  • LLl0k0laDSkill

    git-workflow-and-versioning

    Use when making any code change. Use when committing, branching, resolving conflicts, or when you need to organize work across multiple parallel streams.

    Also in 47 projects that use this

  • MrCipherSmithSkill

    constraint-driven-development

    Use when a project needs a persistent, measurable quality bar — starting a project without documented standards, 'set up constraints', or when coverage/perf/a11y thresholds get re-debated per-PR. Produces CONSTRAINTS.md with enforceable numbers, ratchets, and a guard against silent weakening. NOT for throwaway prototypes or a one-off CI setup.

    Also in 15 projects that use this

  • +2 more from Leodorareluctant259
  • +3 more from LLl0k0laD

The file

We split this skill into the rules it gives an agent

1 rule. 0 are common, 1 is distinctive, and 0 are very specific to this project.

  • 0

    Common

    Most of the 178 edited versions we read keep these.

  • 1

    Distinctive

    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:

    Before a behavior fix, add a fixture demonstrating lost structure or incorrect output and confirm the failure.

    line 12

“Common” is measured: kept by at least 6 in 10 of the 178 edited versions of this file we could read. “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

Test-driven development

English

From a complete checkout, install locked dependencies with npm ci. Run npm test (Node test runner through tsx) and npm run typecheck. The tests import actual helpers; they do not use Obsidian mocks.

Before a behavior fix, add a fixture demonstrating lost structure or incorrect output and confirm the failure. Implement the smallest change, rerun focused tests, then the full local suite. Use isolated temporary directories for file tests; never delete a fixed user vault.

Cover unchanged valid content, nested/long/tilde fences, BOM and line endings, unknown Mermaid families, errors and cancellation. Parser success is not proof of semantic fidelity or visual quality. Review node/edge preservation and output diffs separately. Documentation-only changes need link and command consistency checks.

中文

在完整仓库中运行 npm ci 安装锁定依赖,再运行 npm test(通过 tsx 使用 Node 测试运行器)与 npm run typecheck。测试导入真实工具函数,不使用 Obsidian mock。

修复行为前,先增加能重现结构丢失或输出错误的样例并确认失败。实施最小修改,先跑专项测试,再跑完整本地套件。文件测试使用隔离临时目录,绝不删除固定的用户笔记库。

覆盖有效内容不变、嵌套/长/波浪号围栏、BOM 与换行、未知 Mermaid 类型、错误与取消。解析成功不能证明语义保真或视觉质量,需要另行检查节点/关系与输出差异。仅文档修改需检查链接与命令一致性。

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.