[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M7C92JBFDF1BDFSPHT4TSHZ3":3,"skill-same:01M7C92JBFDF1BDFSPHT4TSHZ3":74},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":19,"linkOnly":20,"markdownContent":21,"markdownBody":22,"frontMatter":23,"refName":26,"commitSha":27,"skillDirectory":28,"forksCount":29,"repositoryHtmlUrl":30,"repositoryHomepageUrl":6,"ownerHtmlUrl":31,"ownerBlogUrl":6,"ownerDescription":32,"updatedAt":33,"install":34,"resources":47},"01M7C92JBFDF1BDFSPHT4TSHZ3","test-authoring-edho-ferdian",null,"Write unit and component tests well: React Testing Library, pytest, Go and Vue, plus regression-test patterns. Use for \"tulis test untuk component ini\", \"bagaimana test hook ini\", \"test yang bagus untuk fitur X\", \"tulis test pytest\u002FGo\u002FVue\", or dev-kickoff's TEST stage.","edhoferdian\u002FEEF","edhoferdian","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F64404158?v=4","01M7C8538ZVVZWZEN1AW2MQXCV","Edho F","01M7C8539NS56BMJ4GXN8A47TQ",22,"MIT","https:\u002F\u002Fgithub.com\u002Fedhoferdian\u002FEEF\u002Fblob\u002Fmain\u002F.kiro\u002Fskills\u002Ftest-authoring-edho-ferdian\u002FSKILL.md",[],[],"2026-11-15 14:19:17",false,"---\nname: test-authoring-edho-ferdian\ndescription: >-\n  Write unit and component tests well: React Testing Library, pytest, Go and\n  Vue, plus regression-test patterns. Use for \"tulis test untuk component\n  ini\", \"bagaimana test hook ini\", \"test yang bagus untuk fitur X\", \"tulis\n  test pytest\u002FGo\u002FVue\", or dev-kickoff's TEST stage.\nmetadata:\n  last_reviewed: \"2026-10-27\"\n---\n\n# Test Authoring — Edho Ferdian Mode\n\nYou are helping someone **write** a unit or component test — choosing\nqueries, structuring setup, mocking the network, testing a hook in\nisolation, asserting the right thing the first time. This skill is about\ncraft at the point of authorship, not about judging a test after the fact.\n\n---\n\n## The three-way boundary (read this before anything else)\n\nThis ecosystem has three other skills that sound adjacent to this one. They\nare not substitutes for each other — each answers a different question:\n\n| Skill | Question it answers | When it runs |\n|---|---|---|\n| **test-authoring-edho-ferdian** (this skill) | *How do I write this test well?* Query choice, async handling, mocking, hook isolation, a11y assertions, snapshot discipline. | While the test is being written — during dev-kickoff's TEST stage, or any time someone is authoring a new unit\u002Fcomponent test. |\n| **code-review-edho-ferdian** → `references\u002Ftest-quality-lens.md` (TQ-01..06) | *Is this already-written test actually good?* Behavioral mapping, edge-case\u002Ferror-path coverage, assertion strength, flakiness, isolation\u002Fnaming, coverage-vs-behavior divergence. | After code exists, during review — judges tests that already exist, doesn't teach how to write new ones. |\n| **dev-kickoff-edho-ferdian** → `references\u002Ftest-design-checklist.md` | *Which edge-case categories and anti-patterns apply, regardless of stack?* An 8-category checklist (null\u002Fundefined, empty, invalid types, boundary values, error paths, race conditions, large data, special characters) and 4 anti-patterns. Stack-agnostic — no React\u002FJest\u002Fpytest specifics. | Both by this skill (to decide *which* cases to author tests for) and by reviews (to check *which* cases got missed). It is the shared checklist, not owned by either side. |\n| **e2e-testing-edho-ferdian** | *Does this full user journey work end-to-end in a real browser?* Login → checkout, multi-page flows, anything touching money or auth. | Separate layer entirely — Playwright\u002FChrome-DevTools-driven, Page Object Model, journey mapping. Not unit or component level. |\n\nIn short:\n\n- **This skill = authoring.** It teaches the mechanics of writing a good\n  test *before* it exists.\n- **test-quality-lens = reviewing.** It judges a test that already exists,\n  with tool-backed evidence (run the suite, run coverage) before labeling\n  anything High confidence.\n- **test-design-checklist = the shared checklist.** Both authoring and\n  review should apply its 8 categories and 4 anti-patterns; it belongs to\n  neither exclusively.\n- **e2e-testing = a different layer.** Full user flows in a real browser,\n  not the unit\u002Fcomponent tests this skill covers.\n\nIf someone asks \"is this test any good?\" about code that's already written,\npoint them at `code-review-edho-ferdian`'s test-quality-lens instead of this\nskill. If someone asks \"does the whole login flow work?\", point them at\n`e2e-testing-edho-ferdian`. This skill is for the moment of writing a new\nunit or component test.\n\n> Evaluating an **agent's** reliability (pass@k \u002F pass^k, model-based vs\n> code-based graders) is a different discipline from authoring software\n> tests and lives in `gan-harness-edho-ferdian\u002Freferences\u002Fevaluate-phase.md`,\n> not here.\n\n---\n\n## Core principle\n\nTest what the user sees and does, not implementation details.\n\nA good test:\n\n- Renders the component with the same providers it has in production.\n- Interacts via accessible queries (role, label) and `userEvent`.\n- Asserts visible output and observable side effects (a callback fired, a\n  request was sent) — not internal state, not which hooks ran, not render\n  count.\n\nApply the stack-agnostic edge-case categories from\n`dev-kickoff-edho-ferdian\u002Freferences\u002Ftest-design-checklist.md` when deciding\n*which* cases to write tests for — this skill covers *how* to write each one\nwell once you've decided it belongs.\n\n## Baseline standards (stack-agnostic)\n\n- **`references\u002Fbaseline-testing-standards.md`** — the numbers and the loop:\n  the 80% coverage floor (and its three qualifications), the unit\u002F\n  integration\u002FE2E layer split, RED→GREEN→REFACTOR, Arrange-Act-Assert\n  structure, behaviour-describing naming, the diagnose-in-order protocol for\n  a failing test, and how to close a coverage gap deliberately rather than\n  file-by-file. Read this before authoring in any stack — the stack-specific\n  files below cover *how*, this file covers *how much and in what order*.\n\n## Stack-specific guidance\n\n- **React \u002F Testing Library**: `references\u002Freact.md` — query priority,\n  `userEvent.setup()` discipline, async assertions, MSW network mocking,\n  `renderHook` for custom hooks (including the shared-QueryClient flake\n  trap), `jest-axe` accessibility assertions, the RTL vs Playwright\n  Component Testing vs full E2E decision boundary, and coverage\n  expectations per layer.\n- **Regression tests (stack-agnostic)**: `references\u002Fregression-testing.md` —\n  writing the test a found bug earned, the four recurring regression patterns\n  (dual-path shape drift, projection omission, error-state leakage, missing\n  rollback), DB-free sandbox-mode testing, and why AI self-review is not\n  evidence.\n\n- **Python\u002Fpytest**: `references\u002Fpython-pytest.md` — fixtures and scoping,\n  parametrize with `ids`, `unittest.mock`\u002F`pytest-mock` (patch-site rule,\n  `autospec`), `pytest-asyncio` async tests and `AsyncMock`, coverage\n  configuration.\n- **Go**: `references\u002Fgo.md` — table-driven tests, `t.Run` subtests\n  (including the loop-variable capture trap), interface-based mocking,\n  testify vs stdlib `testing`, benchmark tests.\n- **Vue**: `references\u002Fvue.md` — Vue Test Utils mount strategies, testing\n  Composition API composables in isolation, Pinia store testing with\n  `createTestingPinia`, Vitest async-update handling.\n\nWhen a stack isn't covered above, apply the core principle and the\nstack-agnostic checklist above by hand, and note in your response that\nstack-specific guidance for that language isn't written yet — don't\nsilently fall back to React-flavored advice for a non-React stack.\n\n## Language routing (fixed — see skill-authoring-edho-ferdian's canonical contract)\n\nCommunication to the user in Bahasa Indonesia; test code, test names, and\nassertions in English — fixed, never ask. Full contract:\n`skill-authoring-edho-ferdian` §7.\n","# Test Authoring — Edho Ferdian Mode\n\nYou are helping someone **write** a unit or component test — choosing\nqueries, structuring setup, mocking the network, testing a hook in\nisolation, asserting the right thing the first time. This skill is about\ncraft at the point of authorship, not about judging a test after the fact.\n\n---\n\n## The three-way boundary (read this before anything else)\n\nThis ecosystem has three other skills that sound adjacent to this one. They\nare not substitutes for each other — each answers a different question:\n\n| Skill | Question it answers | When it runs |\n|---|---|---|\n| **test-authoring-edho-ferdian** (this skill) | *How do I write this test well?* Query choice, async handling, mocking, hook isolation, a11y assertions, snapshot discipline. | While the test is being written — during dev-kickoff's TEST stage, or any time someone is authoring a new unit\u002Fcomponent test. |\n| **code-review-edho-ferdian** → `references\u002Ftest-quality-lens.md` (TQ-01..06) | *Is this already-written test actually good?* Behavioral mapping, edge-case\u002Ferror-path coverage, assertion strength, flakiness, isolation\u002Fnaming, coverage-vs-behavior divergence. | After code exists, during review — judges tests that already exist, doesn't teach how to write new ones. |\n| **dev-kickoff-edho-ferdian** → `references\u002Ftest-design-checklist.md` | *Which edge-case categories and anti-patterns apply, regardless of stack?* An 8-category checklist (null\u002Fundefined, empty, invalid types, boundary values, error paths, race conditions, large data, special characters) and 4 anti-patterns. Stack-agnostic — no React\u002FJest\u002Fpytest specifics. | Both by this skill (to decide *which* cases to author tests for) and by reviews (to check *which* cases got missed). It is the shared checklist, not owned by either side. |\n| **e2e-testing-edho-ferdian** | *Does this full user journey work end-to-end in a real browser?* Login → checkout, multi-page flows, anything touching money or auth. | Separate layer entirely — Playwright\u002FChrome-DevTools-driven, Page Object Model, journey mapping. Not unit or component level. |\n\nIn short:\n\n- **This skill = authoring.** It teaches the mechanics of writing a good\n  test *before* it exists.\n- **test-quality-lens = reviewing.** It judges a test that already exists,\n  with tool-backed evidence (run the suite, run coverage) before labeling\n  anything High confidence.\n- **test-design-checklist = the shared checklist.** Both authoring and\n  review should apply its 8 categories and 4 anti-patterns; it belongs to\n  neither exclusively.\n- **e2e-testing = a different layer.** Full user flows in a real browser,\n  not the unit\u002Fcomponent tests this skill covers.\n\nIf someone asks \"is this test any good?\" about code that's already written,\npoint them at `code-review-edho-ferdian`'s test-quality-lens instead of this\nskill. If someone asks \"does the whole login flow work?\", point them at\n`e2e-testing-edho-ferdian`. This skill is for the moment of writing a new\nunit or component test.\n\n> Evaluating an **agent's** reliability (pass@k \u002F pass^k, model-based vs\n> code-based graders) is a different discipline from authoring software\n> tests and lives in `gan-harness-edho-ferdian\u002Freferences\u002Fevaluate-phase.md`,\n> not here.\n\n---\n\n## Core principle\n\nTest what the user sees and does, not implementation details.\n\nA good test:\n\n- Renders the component with the same providers it has in production.\n- Interacts via accessible queries (role, label) and `userEvent`.\n- Asserts visible output and observable side effects (a callback fired, a\n  request was sent) — not internal state, not which hooks ran, not render\n  count.\n\nApply the stack-agnostic edge-case categories from\n`dev-kickoff-edho-ferdian\u002Freferences\u002Ftest-design-checklist.md` when deciding\n*which* cases to write tests for — this skill covers *how* to write each one\nwell once you've decided it belongs.\n\n## Baseline standards (stack-agnostic)\n\n- **`references\u002Fbaseline-testing-standards.md`** — the numbers and the loop:\n  the 80% coverage floor (and its three qualifications), the unit\u002F\n  integration\u002FE2E layer split, RED→GREEN→REFACTOR, Arrange-Act-Assert\n  structure, behaviour-describing naming, the diagnose-in-order protocol for\n  a failing test, and how to close a coverage gap deliberately rather than\n  file-by-file. Read this before authoring in any stack — the stack-specific\n  files below cover *how*, this file covers *how much and in what order*.\n\n## Stack-specific guidance\n\n- **React \u002F Testing Library**: `references\u002Freact.md` — query priority,\n  `userEvent.setup()` discipline, async assertions, MSW network mocking,\n  `renderHook` for custom hooks (including the shared-QueryClient flake\n  trap), `jest-axe` accessibility assertions, the RTL vs Playwright\n  Component Testing vs full E2E decision boundary, and coverage\n  expectations per layer.\n- **Regression tests (stack-agnostic)**: `references\u002Fregression-testing.md` —\n  writing the test a found bug earned, the four recurring regression patterns\n  (dual-path shape drift, projection omission, error-state leakage, missing\n  rollback), DB-free sandbox-mode testing, and why AI self-review is not\n  evidence.\n\n- **Python\u002Fpytest**: `references\u002Fpython-pytest.md` — fixtures and scoping,\n  parametrize with `ids`, `unittest.mock`\u002F`pytest-mock` (patch-site rule,\n  `autospec`), `pytest-asyncio` async tests and `AsyncMock`, coverage\n  configuration.\n- **Go**: `references\u002Fgo.md` — table-driven tests, `t.Run` subtests\n  (including the loop-variable capture trap), interface-based mocking,\n  testify vs stdlib `testing`, benchmark tests.\n- **Vue**: `references\u002Fvue.md` — Vue Test Utils mount strategies, testing\n  Composition API composables in isolation, Pinia store testing with\n  `createTestingPinia`, Vitest async-update handling.\n\nWhen a stack isn't covered above, apply the core principle and the\nstack-agnostic checklist above by hand, and note in your response that\nstack-specific guidance for that language isn't written yet — don't\nsilently fall back to React-flavored advice for a non-React stack.\n\n## Language routing (fixed — see skill-authoring-edho-ferdian's canonical contract)\n\nCommunication to the user in Bahasa Indonesia; test code, test names, and\nassertions in English — fixed, never ask. Full contract:\n`skill-authoring-edho-ferdian` §7.\n",{"name":5,"metadata":24,"description":7},{"last_reviewed":25},"2026-10-27","main","533d32ad55c92d40fbabe93cbe21fe048598fe5a",".kiro\u002Fskills\u002Ftest-authoring-edho-ferdian",0,"https:\u002F\u002Fgithub.com\u002Fedhoferdian\u002FEEF","https:\u002F\u002Fgithub.com\u002Fedhoferdian","Elevating ideas through AI, rising from humble beginnings to mastering the frontiers of the web. Every line of code is open-sourced on GitHub, inviting you to f","2026-10-30 03:34:17",{"source":8,"skillName":5,"commands":35,"prompt":45,"zipAvailable":46},[36,39,42],{"tool":37,"command":38},"npx","npx skills add edhoferdian\u002FEEF --skill test-authoring-edho-ferdian",{"tool":40,"command":41},"bunx","bunx skills add edhoferdian\u002FEEF --skill test-authoring-edho-ferdian",{"tool":43,"command":44},"pnpm","pnpm dlx skills add edhoferdian\u002FEEF --skill test-authoring-edho-ferdian","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fedhoferdian\u002FEEF\u002Fblob\u002Fmain\u002F.kiro\u002Fskills\u002Ftest-authoring-edho-ferdian\u002FSKILL.md",true,[48,54,58,62,66,70],{"path":49,"resourceType":50,"resourceTypeDesc":51,"sizeBytes":52,"sourceHtmlUrl":53},"references\u002Fbaseline-testing-standards.md","REFERENCE","参考文档",6143,"https:\u002F\u002Fgithub.com\u002Fedhoferdian\u002FEEF\u002Fblob\u002Fmain\u002F.kiro\u002Fskills\u002Ftest-authoring-edho-ferdian\u002Freferences\u002Fbaseline-testing-standards.md",{"path":55,"resourceType":50,"resourceTypeDesc":51,"sizeBytes":56,"sourceHtmlUrl":57},"references\u002Fgo.md",11143,"https:\u002F\u002Fgithub.com\u002Fedhoferdian\u002FEEF\u002Fblob\u002Fmain\u002F.kiro\u002Fskills\u002Ftest-authoring-edho-ferdian\u002Freferences\u002Fgo.md",{"path":59,"resourceType":50,"resourceTypeDesc":51,"sizeBytes":60,"sourceHtmlUrl":61},"references\u002Fpython-pytest.md",14522,"https:\u002F\u002Fgithub.com\u002Fedhoferdian\u002FEEF\u002Fblob\u002Fmain\u002F.kiro\u002Fskills\u002Ftest-authoring-edho-ferdian\u002Freferences\u002Fpython-pytest.md",{"path":63,"resourceType":50,"resourceTypeDesc":51,"sizeBytes":64,"sourceHtmlUrl":65},"references\u002Freact.md",13641,"https:\u002F\u002Fgithub.com\u002Fedhoferdian\u002FEEF\u002Fblob\u002Fmain\u002F.kiro\u002Fskills\u002Ftest-authoring-edho-ferdian\u002Freferences\u002Freact.md",{"path":67,"resourceType":50,"resourceTypeDesc":51,"sizeBytes":68,"sourceHtmlUrl":69},"references\u002Fregression-testing.md",6051,"https:\u002F\u002Fgithub.com\u002Fedhoferdian\u002FEEF\u002Fblob\u002Fmain\u002F.kiro\u002Fskills\u002Ftest-authoring-edho-ferdian\u002Freferences\u002Fregression-testing.md",{"path":71,"resourceType":50,"resourceTypeDesc":51,"sizeBytes":72,"sourceHtmlUrl":73},"references\u002Fvue.md",13571,"https:\u002F\u002Fgithub.com\u002Fedhoferdian\u002FEEF\u002Fblob\u002Fmain\u002F.kiro\u002Fskills\u002Ftest-authoring-edho-ferdian\u002Freferences\u002Fvue.md",[75,82,87,94,101,108],{"skillNo":76,"name":77,"nameZh":6,"description":78,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":79,"categories":80,"keywords":81,"publishedAt":19},"01M7C9FY2EWE5NB7M3YW0KJX62","video-style-edho-ferdian","Measure a reference video's look and pacing (colour grade as a 3D LUT, cut rhythm, overlays) and reproduce it: grade, cut and composite new footage, verify numerically, hand off an NLE timeline. Use for \"tiru look video ini\", \"samakan grading\", \"bikin video dengan gaya referensi\", \"LUT dari referensi\", \"cut rhythm\".","https:\u002F\u002Fgithub.com\u002Fedhoferdian\u002FEEF\u002Fblob\u002Fmain\u002Fskills\u002Fvideo-style-edho-ferdian\u002FSKILL.md",[],[],{"skillNo":83,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":84,"categories":85,"keywords":86,"publishedAt":19},"01M7C9FT74P7JXGQ73116B9WS1","https:\u002F\u002Fgithub.com\u002Fedhoferdian\u002FEEF\u002Fblob\u002Fmain\u002Fskills\u002Ftest-authoring-edho-ferdian\u002FSKILL.md",[],[],{"skillNo":88,"name":89,"nameZh":6,"description":90,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":91,"categories":92,"keywords":93,"publishedAt":19},"01M7C9FMPE9W76FS7S8ZZ48ARE","system-design-edho-ferdian","Mid-project architecture decisions: ADRs, trade-off analysis, non-functional requirements, scaling tiers and blast radius. Use for \"desain arsitektur\", \"keputusan teknis besar\", \"bikin ADR\", \"trade-off antara X dan Y\", \"microservices atau monolith\", \"apa yang rusak kalau X diubah\", or a capacity question.","https:\u002F\u002Fgithub.com\u002Fedhoferdian\u002FEEF\u002Fblob\u002Fmain\u002Fskills\u002Fsystem-design-edho-ferdian\u002FSKILL.md",[],[],{"skillNo":95,"name":96,"nameZh":6,"description":97,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":98,"categories":99,"keywords":100,"publishedAt":19},"01M7C9FETATAHKG5WKPT4AP1A2","spec-mining-edho-ferdian","Extract behavioural specs from a codebase with none: WHEN\u002FTHEN requirements and invariants, each anchored to the code that enforces it, unclear behaviour recorded as uncertainty. Use for \"ekstrak spec\", \"buat spec dari kode\", \"reverse-engineer the spec\", \"repo ini tidak ada dokumentasi\", or a missing BEHAVIOR_SPEC in dev-kickoff.","https:\u002F\u002Fgithub.com\u002Fedhoferdian\u002FEEF\u002Fblob\u002Fmain\u002Fskills\u002Fspec-mining-edho-ferdian\u002FSKILL.md",[],[],{"skillNo":102,"name":103,"nameZh":6,"description":104,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":105,"categories":106,"keywords":107,"publishedAt":19},"01M7C9F93YCXFCVRDG4S5QFAH4","skill-authoring-edho-ferdian","Create and govern this ecosystem's skills: search before building, a quality bar, compliance checks, promoting repeated principles to rules, and packaging dist\u002F*.skill. Use for \"bikin skill baru\", \"ada skill buat X gak\", \"fork skill ini\", \"skill gue kepake gak sih\", \"package skill ini\", \"buatkan .skill-nya\".","https:\u002F\u002Fgithub.com\u002Fedhoferdian\u002FEEF\u002Fblob\u002Fmain\u002Fskills\u002Fskill-authoring-edho-ferdian\u002FSKILL.md",[],[],{"skillNo":109,"name":110,"nameZh":6,"description":111,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":112,"categories":113,"keywords":114,"publishedAt":19},"01M7C9F4XZJ59R0GS4YEP4E1RD","skill-audit-edho-ferdian","Audit this repo's skills\u002F for staleness, redundancy, broken cross-references and weak descriptions (not the ~\u002F.claude setup: that is config-hygiene). Use for \"audit skill saya\", \"cek skill yang sudah dibuat\", \"ada yang redundan gak\", \"skill mana yang basi\".","https:\u002F\u002Fgithub.com\u002Fedhoferdian\u002FEEF\u002Fblob\u002Fmain\u002Fskills\u002Fskill-audit-edho-ferdian\u002FSKILL.md",[],[]]