[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71F22N3YQBNPXFJ2SNAG6BN":3,"skill-same:01M71F22N3YQBNPXFJ2SNAG6BN":71},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":17,"publishedAt":38,"linkOnly":39,"markdownContent":40,"markdownBody":41,"frontMatter":42,"refName":50,"commitSha":51,"skillDirectory":52,"forksCount":53,"repositoryHtmlUrl":54,"repositoryHomepageUrl":6,"ownerHtmlUrl":55,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":56,"install":57,"resources":70},"01M71F22N3YQBNPXFJ2SNAG6BN","tdd-flow",null,"Tool-agnostic red-green-refactor discipline for any project. Write a failing test first (RED), make it pass with the minimum change (GREEN), then refactor. Drive every cycle through the project's configured test command and record RED\u002FGREEN evidence before merge.","parada1104\u002Fai-specs-cli","parada1104","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F57575053?v=4","01M71EZZV71KAFZKJ47FQ99ZVS","01M71EZZW7JJBY2VAWA5HRD944",0,"MIT","https:\u002F\u002Fgithub.com\u002Fparada1104\u002Fai-specs-cli\u002Fblob\u002Fmain\u002Fcatalog\u002Frecipes\u002Ftdd-flow\u002Fskills\u002Ftdd-flow\u002FSKILL.md",[],[18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37],"tdd","tdd flow","flow","cycle","writing","failing","for","with","runtime","project","green","record","change","red-green-refactor","evidence","discipline","tool","first","test","code","2026-11-10 10:12:30",false,"---\nname: tdd-flow\ndescription: >\n  Tool-agnostic red-green-refactor discipline for any project. Write a failing\n  test first (RED), make it pass with the minimum change (GREEN), then refactor.\n  Drive every cycle through the project's configured test command and record\n  RED\u002FGREEN evidence before merge.\nlicense: MIT\nmetadata:\n  author: ai-specs\n  version: \"1.0\"\n  scope: runtime\n  auto_invoke:\n    - \"Writing or changing code that should be tested\"\n    - \"Verifying a change before merge\"\n---\n\n# TDD Flow\n\nRed-green-refactor is the default discipline for any change that affects testable\nbehavior. The cycle is tool-agnostic: it works the same whether the project tests\nwith a shell script, a language test runner, or a build target. The actual test\ncommand is **configuration**, never assumed by this skill.\n\n## The Test Command Is Config\n\nThis recipe does not know or hardcode how your project runs tests. The command\ncomes from your project manifest:\n\n```toml\n[recipes.tdd-flow.config]\ntest_command = \"\u003Cyour project's test command>\"\n```\n\nWhenever this skill says \"run the test command\", run exactly the value of\n`test_command` from `[recipes.tdd-flow.config]`. If it is not set, ask the user\nor read the project's runtime brief \u002F docs to discover how this project runs its\ntests, and propose setting `test_command` so the cycle is reproducible. Do not\ninvent or assume a command.\n\n## The Cycle\n\n1. **RED — write a failing test first.**\n   - Add or extend a test that expresses the intended behavior before touching\n     production code.\n   - Run the configured `test_command`. Confirm the new test fails for the right\n     reason (asserts the missing behavior, not a typo or import error).\n   - A change that cannot show a meaningful RED is a signal the test is not\n     pinning real behavior.\n\n2. **GREEN — make it pass minimally.**\n   - Write the smallest production change that makes the failing test pass.\n   - Run the configured `test_command` again. Confirm the previously failing\n     test now passes and no other tests regressed.\n   - Resist adding behavior the tests do not yet require.\n\n3. **REFACTOR — clean up under green.**\n   - With the suite green, improve names, structure, and duplication.\n   - Re-run the configured `test_command` after each meaningful refactor to keep\n     the suite green throughout.\n\nRepeat the cycle per behavior, in small increments. Prefer many tight cycles\nover one large batch.\n\n## Minimum Test Layers\n\nUse the smallest relevant set of these generic layers for a change:\n\n- **Unit** — pure logic: parsing, normalization, calculation, validation,\n  rendering. Fast and isolated; the bulk of RED\u002FGREEN cycles happen here.\n- **Integration** — components working together: a command end to end, a module\n  against a real dependency or temp fixtures, generated artifacts checked on\n  disk.\n- **Smoke** — a broad, shallow run that confirms the system is not obviously\n  broken before a change is considered ready (often the project's full suite or\n  validation target).\n\nA change usually needs unit coverage of the new logic plus at least one\nintegration or smoke layer to trust it.\n\n## Evidence Policy\n\nEvery change should leave clear evidence of the cycle:\n\n- Record the **RED** result (the failing run and which test failed) and the\n  **GREEN** result (the passing run) before merge.\n- Capture the final smoke \u002F full-suite run.\n- In structured changes, record this in the change's apply\u002Fverify artifacts. In\n  ad-hoc changes, record it in the commit message, PR description, or task\n  update.\n- Never claim a test passed unless the configured `test_command` was actually run\n  and observed to pass.\n","# TDD Flow\n\nRed-green-refactor is the default discipline for any change that affects testable\nbehavior. The cycle is tool-agnostic: it works the same whether the project tests\nwith a shell script, a language test runner, or a build target. The actual test\ncommand is **configuration**, never assumed by this skill.\n\n## The Test Command Is Config\n\nThis recipe does not know or hardcode how your project runs tests. The command\ncomes from your project manifest:\n\n```toml\n[recipes.tdd-flow.config]\ntest_command = \"\u003Cyour project's test command>\"\n```\n\nWhenever this skill says \"run the test command\", run exactly the value of\n`test_command` from `[recipes.tdd-flow.config]`. If it is not set, ask the user\nor read the project's runtime brief \u002F docs to discover how this project runs its\ntests, and propose setting `test_command` so the cycle is reproducible. Do not\ninvent or assume a command.\n\n## The Cycle\n\n1. **RED — write a failing test first.**\n   - Add or extend a test that expresses the intended behavior before touching\n     production code.\n   - Run the configured `test_command`. Confirm the new test fails for the right\n     reason (asserts the missing behavior, not a typo or import error).\n   - A change that cannot show a meaningful RED is a signal the test is not\n     pinning real behavior.\n\n2. **GREEN — make it pass minimally.**\n   - Write the smallest production change that makes the failing test pass.\n   - Run the configured `test_command` again. Confirm the previously failing\n     test now passes and no other tests regressed.\n   - Resist adding behavior the tests do not yet require.\n\n3. **REFACTOR — clean up under green.**\n   - With the suite green, improve names, structure, and duplication.\n   - Re-run the configured `test_command` after each meaningful refactor to keep\n     the suite green throughout.\n\nRepeat the cycle per behavior, in small increments. Prefer many tight cycles\nover one large batch.\n\n## Minimum Test Layers\n\nUse the smallest relevant set of these generic layers for a change:\n\n- **Unit** — pure logic: parsing, normalization, calculation, validation,\n  rendering. Fast and isolated; the bulk of RED\u002FGREEN cycles happen here.\n- **Integration** — components working together: a command end to end, a module\n  against a real dependency or temp fixtures, generated artifacts checked on\n  disk.\n- **Smoke** — a broad, shallow run that confirms the system is not obviously\n  broken before a change is considered ready (often the project's full suite or\n  validation target).\n\nA change usually needs unit coverage of the new logic plus at least one\nintegration or smoke layer to trust it.\n\n## Evidence Policy\n\nEvery change should leave clear evidence of the cycle:\n\n- Record the **RED** result (the failing run and which test failed) and the\n  **GREEN** result (the passing run) before merge.\n- Capture the final smoke \u002F full-suite run.\n- In structured changes, record this in the change's apply\u002Fverify artifacts. In\n  ad-hoc changes, record it in the commit message, PR description, or task\n  update.\n- Never claim a test passed unless the configured `test_command` was actually run\n  and observed to pass.\n",{"name":5,"license":14,"metadata":43,"description":49},{"scope":26,"author":44,"version":45,"auto_invoke":46},"ai-specs","1.0",[47,48],"Writing or changing code that should be tested","Verifying a change before merge","Tool-agnostic red-green-refactor discipline for any project. Write a failing test first (RED), make it pass with the minimum change (GREEN), then refactor. Drive every cycle through the project's configured test command and record RED\u002FGREEN evidence before merge.\n","main","c092fc1f51280350a4434827e2f6d6d99e3431ca","catalog\u002Frecipes\u002Ftdd-flow\u002Fskills\u002Ftdd-flow",2,"https:\u002F\u002Fgithub.com\u002Fparada1104\u002Fai-specs-cli","https:\u002F\u002Fgithub.com\u002Fparada1104","2026-11-14 03:51:03",{"source":8,"skillName":5,"commands":58,"prompt":68,"zipAvailable":69},[59,62,65],{"tool":60,"command":61},"npx","npx skills add parada1104\u002Fai-specs-cli --skill tdd-flow",{"tool":63,"command":64},"bunx","bunx skills add parada1104\u002Fai-specs-cli --skill tdd-flow",{"tool":66,"command":67},"pnpm","pnpm dlx skills add parada1104\u002Fai-specs-cli --skill tdd-flow","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fparada1104\u002Fai-specs-cli\u002Fblob\u002Fmain\u002Fcatalog\u002Frecipes\u002Ftdd-flow\u002Fskills\u002Ftdd-flow\u002FSKILL.md",true,[],[72,92,106,115,124,137],{"skillNo":73,"name":74,"nameZh":6,"description":75,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":76,"categories":77,"keywords":86,"publishedAt":38},"01M71F2TF9TS9DNCJ68M7C3B5S","test-skill","Test skill for fixture purposes.","https:\u002F\u002Fgithub.com\u002Fparada1104\u002Fai-specs-cli\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Frecipes\u002Ftest-fixture\u002Fskills\u002Ftest-skill\u002FSKILL.md",[78,83],{"categoryNo":79,"categoryName":80,"taxonomyType":81,"taxonomyTypeDesc":82},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",{"categoryNo":84,"categoryName":85,"taxonomyType":81,"taxonomyTypeDesc":82},"01JBSEEDCAT000000000000023","Skill与智能体开发",[87,36,24,88,89,90,91],"Test Skill","root","fixtures","fixture","testing",{"skillNo":93,"name":94,"nameZh":6,"description":95,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":96,"categories":97,"keywords":101,"publishedAt":38},"01M71F2RTH94ZB7XEAW4P6ZG0D","obsidian-markdown","Fixture skill for obsidian-markdown.","https:\u002F\u002Fgithub.com\u002Fparada1104\u002Fai-specs-cli\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fkepano-obsidian-skills\u002Fskills\u002Fobsidian-markdown\u002FSKILL.md",[98],{"categoryNo":99,"categoryName":100,"taxonomyType":81,"taxonomyTypeDesc":82},"01JBSEEDCAT000000000000002","文档处理",[102,103,104,24,90,105],"markdown","obsidian markdown","obsidian","fixture skill",{"skillNo":107,"name":108,"nameZh":6,"description":109,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":110,"categories":111,"keywords":112,"publishedAt":38},"01M71F2R20CPTJXD9F7DP4JPP6","obsidian-cli","Fixture skill for obsidian-cli.","https:\u002F\u002Fgithub.com\u002Fparada1104\u002Fai-specs-cli\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fkepano-obsidian-skills\u002Fskills\u002Fobsidian-cli\u002FSKILL.md",[],[113,104,114,24,90,105],"obsidian cli","cli",{"skillNo":116,"name":117,"nameZh":6,"description":118,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":119,"categories":120,"keywords":121,"publishedAt":38},"01M71F2PCH4NWVTT1J57SHJX33","obsidian-bases","Fixture skill for obsidian-bases.","https:\u002F\u002Fgithub.com\u002Fparada1104\u002Fai-specs-cli\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fkepano-obsidian-skills\u002Fskills\u002Fobsidian-bases\u002FSKILL.md",[],[122,123,104,24,90,105],"bases","obsidian bases",{"skillNo":125,"name":126,"nameZh":6,"description":127,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":128,"categories":129,"keywords":133,"publishedAt":38},"01M71F2MSS6EVFEYVYAA1KBYCC","json-canvas","Fixture skill for json-canvas.","https:\u002F\u002Fgithub.com\u002Fparada1104\u002Fai-specs-cli\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fkepano-obsidian-skills\u002Fskills\u002Fjson-canvas\u002FSKILL.md",[130],{"categoryNo":131,"categoryName":132,"taxonomyType":81,"taxonomyTypeDesc":82},"01JBSEEDCAT000000000000015","视觉设计",[134,135,136,105,90,24],"json","json canvas","canvas",{"skillNo":138,"name":139,"nameZh":6,"description":140,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":141,"categories":142,"keywords":143,"publishedAt":38},"01M71F2KY5QVNEN1Q3REFB0MQZ","defuddle","Fixture skill for defuddle.","https:\u002F\u002Fgithub.com\u002Fparada1104\u002Fai-specs-cli\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fkepano-obsidian-skills\u002Fskills\u002Fdefuddle\u002FSKILL.md",[],[139,105,90,24]]