[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M79R5CTGCK93VC3DCAMXZQAA":3,"skill-same:01M79R5CTGCK93VC3DCAMXZQAA":58},{"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":24,"commitSha":25,"skillDirectory":26,"forksCount":14,"repositoryHtmlUrl":27,"repositoryHomepageUrl":6,"ownerHtmlUrl":28,"ownerBlogUrl":29,"ownerDescription":30,"updatedAt":31,"install":32,"resources":45},"01M79R5CTGCK93VC3DCAMXZQAA","bmad-qa-generate-e2e-tests",null,"Generate end to end automated tests for existing features. Use when the user says \"create qa automated tests for [feature]\"","thkennedy\u002Ftk-studio","thkennedy","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F4164502?v=4","01M79QZ8DMP5FF2HC6GS3S6FDF","Tim Kennedy","01M79QZ8EM9JBWJ15R5JNC4PW3",0,"MIT","https:\u002F\u002Fgithub.com\u002Fthkennedy\u002Ftk-studio\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fbmad-qa-generate-e2e-tests\u002FSKILL.md",[],[],"2026-11-15 14:19:17",false,"---\nname: bmad-qa-generate-e2e-tests\ndescription: 'Generate end to end automated tests for existing features. Use when the user says \"create qa automated tests for [feature]\"'\n---\n\n# QA Generate E2E Tests Workflow\n\n**Goal:** Generate automated API and E2E tests for implemented code.\n\n**Your Role:** You are a QA automation engineer. You generate tests ONLY — no code review or story validation (use the `bmad-code-review` skill for that).\n\n## Conventions\n\n- Bare paths (e.g. `checklist.md`) resolve from the skill root.\n- `{skill-root}` resolves to this skill's installed directory (where `customize.toml` lives).\n- `{project-root}`-prefixed paths resolve from the project working directory.\n- `{skill-name}` resolves to the skill directory's basename.\n\n## On Activation\n\n### Step 1: Resolve the Workflow Block\n\nRun: `uv run {project-root}\u002F_bmad\u002Fscripts\u002Fresolve_customization.py --skill {skill-root} --key workflow`\n\n**If the script fails**, resolve the `workflow` block yourself by reading these three files in base → team → user order and applying the same structural merge rules as the resolver:\n\n1. `{skill-root}\u002Fcustomize.toml` — defaults\n2. `{project-root}\u002F_bmad\u002Fcustom\u002F{skill-name}.toml` — team overrides\n3. `{project-root}\u002F_bmad\u002Fcustom\u002F{skill-name}.user.toml` — personal overrides\n\nAny missing file is skipped. Scalars override, tables deep-merge, arrays of tables keyed by `code` or `id` replace matching entries and append new entries, and all other arrays append.\n\n### Step 2: Execute Prepend Steps\n\nExecute each entry in `{workflow.activation_steps_prepend}` in order before proceeding.\n\n### Step 3: Load Persistent Facts\n\nTreat every entry in `{workflow.persistent_facts}` as foundational context you carry for the rest of the workflow run. Entries prefixed `file:` are paths or globs under `{project-root}` — load the referenced contents as facts. All other entries are facts verbatim.\n\n### Step 4: Load Config\n\nLoad config from `{project-root}\u002F_bmad\u002Fbmm\u002Fconfig.yaml` and resolve:\n\n- `project_name`, `user_name`\n- `communication_language`, `document_output_language`\n- `implementation_artifacts`\n- `date` as system-generated current datetime\n- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`\n\n### Step 5: Greet the User\n\nGreet `{user_name}`, speaking in `{communication_language}`.\n\n### Step 6: Execute Append Steps\n\nExecute each entry in `{workflow.activation_steps_append}` in order.\n\nActivation is complete. If `activation_steps_prepend` or `activation_steps_append` were non-empty, confirm every entry was executed in order before proceeding. Do not begin the main workflow until all activation steps have been completed.\n\n## Paths\n\n- `test_dir` = `{project-root}\u002Ftests`\n- `source_dir` = `{project-root}`\n- `default_output_file` = `{implementation_artifacts}\u002Ftests\u002Ftest-summary.md`\n\n## Execution\n\n### Step 0: Detect Test Framework\n\nCheck project for existing test framework:\n\n- Look for `package.json` dependencies (playwright, jest, vitest, cypress, etc.)\n- Check for existing test files to understand patterns\n- Use whatever test framework the project already has\n- If no framework exists:\n  - Analyze source code to determine project type (React, Vue, Node API, etc.)\n  - Search online for current recommended test framework for that stack\n  - Suggest the meta framework and use it (or ask user to confirm)\n\n### Step 1: Identify Features\n\nAsk user what to test:\n\n- Specific feature\u002Fcomponent name\n- Directory to scan (e.g., `src\u002Fcomponents\u002F`)\n- Or auto-discover features in the codebase\n\n### Step 2: Generate API Tests (if applicable)\n\nFor API endpoints\u002Fservices, generate tests that:\n\n- Test status codes (200, 400, 404, 500)\n- Validate response structure\n- Cover happy path + 1-2 error cases\n- Use project's existing test framework patterns\n\n### Step 3: Generate E2E Tests (if UI exists)\n\nFor UI features, generate tests that:\n\n- Test user workflows end-to-end\n- Use semantic locators (roles, labels, text)\n- Focus on user interactions (clicks, form fills, navigation)\n- Assert visible outcomes\n- Keep tests linear and simple\n- Follow project's existing test patterns\n\n### Step 4: Run Tests\n\nExecute tests to verify they pass (use project's test command).\n\nIf failures occur, fix them immediately.\n\n### Step 5: Create Summary\n\nOutput markdown summary:\n\n```markdown\n# Test Automation Summary\n\n## Generated Tests\n\n### API Tests\n- [x] tests\u002Fapi\u002Fendpoint.spec.ts - Endpoint validation\n\n### E2E Tests\n- [x] tests\u002Fe2e\u002Ffeature.spec.ts - User workflow\n\n## Coverage\n- API endpoints: 5\u002F10 covered\n- UI features: 3\u002F8 covered\n\n## Next Steps\n- Run tests in CI\n- Add more edge cases as needed\n```\n\n## Keep It Simple\n\n**Do:**\n\n- Use standard test framework APIs\n- Focus on happy path + critical errors\n- Write readable, maintainable tests\n- Run tests to verify they pass\n\n**Avoid:**\n\n- Complex fixture composition\n- Over-engineering\n- Unnecessary abstractions\n\n**For Advanced Features:**\n\nIf the project needs:\n\n- Risk-based test strategy\n- Test design planning\n- Quality gates and NFR assessment\n- Comprehensive coverage analysis\n- Advanced testing patterns and utilities\n\n> **Install Test Architect (TEA) module**: \u003Chttps:\u002F\u002Fbmad-code-org.github.io\u002Fbmad-method-test-architecture-enterprise\u002F>\n\n## Output\n\nSave summary to: `{default_output_file}`\n\n**Done!** Tests generated and verified. Validate against `.\u002Fchecklist.md`.\n\n## On Complete\n\nRun: `uv run {project-root}\u002F_bmad\u002Fscripts\u002Fresolve_customization.py --skill {skill-root} --key workflow.on_complete`\n\nIf the resolved `workflow.on_complete` is non-empty, follow it as the final terminal instruction before exiting.\n","# QA Generate E2E Tests Workflow\n\n**Goal:** Generate automated API and E2E tests for implemented code.\n\n**Your Role:** You are a QA automation engineer. You generate tests ONLY — no code review or story validation (use the `bmad-code-review` skill for that).\n\n## Conventions\n\n- Bare paths (e.g. `checklist.md`) resolve from the skill root.\n- `{skill-root}` resolves to this skill's installed directory (where `customize.toml` lives).\n- `{project-root}`-prefixed paths resolve from the project working directory.\n- `{skill-name}` resolves to the skill directory's basename.\n\n## On Activation\n\n### Step 1: Resolve the Workflow Block\n\nRun: `uv run {project-root}\u002F_bmad\u002Fscripts\u002Fresolve_customization.py --skill {skill-root} --key workflow`\n\n**If the script fails**, resolve the `workflow` block yourself by reading these three files in base → team → user order and applying the same structural merge rules as the resolver:\n\n1. `{skill-root}\u002Fcustomize.toml` — defaults\n2. `{project-root}\u002F_bmad\u002Fcustom\u002F{skill-name}.toml` — team overrides\n3. `{project-root}\u002F_bmad\u002Fcustom\u002F{skill-name}.user.toml` — personal overrides\n\nAny missing file is skipped. Scalars override, tables deep-merge, arrays of tables keyed by `code` or `id` replace matching entries and append new entries, and all other arrays append.\n\n### Step 2: Execute Prepend Steps\n\nExecute each entry in `{workflow.activation_steps_prepend}` in order before proceeding.\n\n### Step 3: Load Persistent Facts\n\nTreat every entry in `{workflow.persistent_facts}` as foundational context you carry for the rest of the workflow run. Entries prefixed `file:` are paths or globs under `{project-root}` — load the referenced contents as facts. All other entries are facts verbatim.\n\n### Step 4: Load Config\n\nLoad config from `{project-root}\u002F_bmad\u002Fbmm\u002Fconfig.yaml` and resolve:\n\n- `project_name`, `user_name`\n- `communication_language`, `document_output_language`\n- `implementation_artifacts`\n- `date` as system-generated current datetime\n- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`\n\n### Step 5: Greet the User\n\nGreet `{user_name}`, speaking in `{communication_language}`.\n\n### Step 6: Execute Append Steps\n\nExecute each entry in `{workflow.activation_steps_append}` in order.\n\nActivation is complete. If `activation_steps_prepend` or `activation_steps_append` were non-empty, confirm every entry was executed in order before proceeding. Do not begin the main workflow until all activation steps have been completed.\n\n## Paths\n\n- `test_dir` = `{project-root}\u002Ftests`\n- `source_dir` = `{project-root}`\n- `default_output_file` = `{implementation_artifacts}\u002Ftests\u002Ftest-summary.md`\n\n## Execution\n\n### Step 0: Detect Test Framework\n\nCheck project for existing test framework:\n\n- Look for `package.json` dependencies (playwright, jest, vitest, cypress, etc.)\n- Check for existing test files to understand patterns\n- Use whatever test framework the project already has\n- If no framework exists:\n  - Analyze source code to determine project type (React, Vue, Node API, etc.)\n  - Search online for current recommended test framework for that stack\n  - Suggest the meta framework and use it (or ask user to confirm)\n\n### Step 1: Identify Features\n\nAsk user what to test:\n\n- Specific feature\u002Fcomponent name\n- Directory to scan (e.g., `src\u002Fcomponents\u002F`)\n- Or auto-discover features in the codebase\n\n### Step 2: Generate API Tests (if applicable)\n\nFor API endpoints\u002Fservices, generate tests that:\n\n- Test status codes (200, 400, 404, 500)\n- Validate response structure\n- Cover happy path + 1-2 error cases\n- Use project's existing test framework patterns\n\n### Step 3: Generate E2E Tests (if UI exists)\n\nFor UI features, generate tests that:\n\n- Test user workflows end-to-end\n- Use semantic locators (roles, labels, text)\n- Focus on user interactions (clicks, form fills, navigation)\n- Assert visible outcomes\n- Keep tests linear and simple\n- Follow project's existing test patterns\n\n### Step 4: Run Tests\n\nExecute tests to verify they pass (use project's test command).\n\nIf failures occur, fix them immediately.\n\n### Step 5: Create Summary\n\nOutput markdown summary:\n\n```markdown\n# Test Automation Summary\n\n## Generated Tests\n\n### API Tests\n- [x] tests\u002Fapi\u002Fendpoint.spec.ts - Endpoint validation\n\n### E2E Tests\n- [x] tests\u002Fe2e\u002Ffeature.spec.ts - User workflow\n\n## Coverage\n- API endpoints: 5\u002F10 covered\n- UI features: 3\u002F8 covered\n\n## Next Steps\n- Run tests in CI\n- Add more edge cases as needed\n```\n\n## Keep It Simple\n\n**Do:**\n\n- Use standard test framework APIs\n- Focus on happy path + critical errors\n- Write readable, maintainable tests\n- Run tests to verify they pass\n\n**Avoid:**\n\n- Complex fixture composition\n- Over-engineering\n- Unnecessary abstractions\n\n**For Advanced Features:**\n\nIf the project needs:\n\n- Risk-based test strategy\n- Test design planning\n- Quality gates and NFR assessment\n- Comprehensive coverage analysis\n- Advanced testing patterns and utilities\n\n> **Install Test Architect (TEA) module**: \u003Chttps:\u002F\u002Fbmad-code-org.github.io\u002Fbmad-method-test-architecture-enterprise\u002F>\n\n## Output\n\nSave summary to: `{default_output_file}`\n\n**Done!** Tests generated and verified. Validate against `.\u002Fchecklist.md`.\n\n## On Complete\n\nRun: `uv run {project-root}\u002F_bmad\u002Fscripts\u002Fresolve_customization.py --skill {skill-root} --key workflow.on_complete`\n\nIf the resolved `workflow.on_complete` is non-empty, follow it as the final terminal instruction before exiting.\n",{"name":5,"description":7},"main","ecd23b3c0458cd511812f643d9111e3d7c8235f4",".claude\u002Fskills\u002Fbmad-qa-generate-e2e-tests","https:\u002F\u002Fgithub.com\u002Fthkennedy\u002Ftk-studio","https:\u002F\u002Fgithub.com\u002Fthkennedy","https:\u002F\u002Ftimothyhkennedy.com","Just a guy who loves making tools, automation and games.","2026-11-10 20:38:16",{"source":8,"skillName":5,"commands":33,"prompt":43,"zipAvailable":44},[34,37,40],{"tool":35,"command":36},"npx","npx skills add thkennedy\u002Ftk-studio --skill bmad-qa-generate-e2e-tests",{"tool":38,"command":39},"bunx","bunx skills add thkennedy\u002Ftk-studio --skill bmad-qa-generate-e2e-tests",{"tool":41,"command":42},"pnpm","pnpm dlx skills add thkennedy\u002Ftk-studio --skill bmad-qa-generate-e2e-tests","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fthkennedy\u002Ftk-studio\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fbmad-qa-generate-e2e-tests\u002FSKILL.md",true,[46,52],{"path":47,"resourceType":48,"resourceTypeDesc":49,"sizeBytes":50,"sourceHtmlUrl":51},"checklist.md","REFERENCE","参考文档",891,"https:\u002F\u002Fgithub.com\u002Fthkennedy\u002Ftk-studio\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fbmad-qa-generate-e2e-tests\u002Fchecklist.md",{"path":53,"resourceType":54,"resourceTypeDesc":55,"sizeBytes":56,"sourceHtmlUrl":57},"customize.toml","OTHER","其他",1639,"https:\u002F\u002Fgithub.com\u002Fthkennedy\u002Ftk-studio\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fbmad-qa-generate-e2e-tests\u002Fcustomize.toml",[59,66,73,80,87,94],{"skillNo":60,"name":61,"nameZh":6,"description":62,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":63,"categories":64,"keywords":65,"publishedAt":19},"01M79RYSQ8C3MWDFTDSRAYFJYA","tk-studio-track","Tracking verbs on the bound Jira project — `block` moves a story the loop cannot progress, and each dependent story, to \"Blocked - Awaiting User\" with a comment that @mentions the owner (or, with `--engagement`, one engagement's questions issue, which `close` later moves to \"Done\"); `reply` posts the owner's answer (or \"Done.\") with the owner's host-only token and moves the issue to \"Block Resolved\"; `validate` checks that resolution and passes the issue back to work or re-blocks it with a follow-up. Use when the user says \"block this story\", \"tk track block\", \"put it in the owner's inbox\", \"reply to the blocked issue\", \"validate the resolution\", or a supervisor or engagement payload names this skill.","https:\u002F\u002Fgithub.com\u002Fthkennedy\u002Ftk-studio\u002Fblob\u002Fmain\u002Fplugins\u002Ftk-studio\u002Fskills\u002Ftk-studio-track\u002FSKILL.md",[],[],{"skillNo":67,"name":68,"nameZh":6,"description":69,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":70,"categories":71,"keywords":72,"publishedAt":19},"01M79RYMVE0031EV5B64MBGD8V","tk-studio-session","Session discipline as a surface — land a boundary handoff (optionally carrying knowledge deltas) and end the session, or resume a fresh session from a run workspace alone. Use when the user says \"hand off this run\", \"tk session\", \"resume the run\", or a boundary\u002Fbudget trigger says the session must split.","https:\u002F\u002Fgithub.com\u002Fthkennedy\u002Ftk-studio\u002Fblob\u002Fmain\u002Fplugins\u002Ftk-studio\u002Fskills\u002Ftk-studio-session\u002FSKILL.md",[],[],{"skillNo":74,"name":75,"nameZh":6,"description":76,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":77,"categories":78,"keywords":79,"publishedAt":19},"01M79RYFM9ATWHM6HAXJ3D19WV","tk-studio-research","Run a chartered research pass — survey the topics a charter scopes, grade every finding by evidence, land the findings in the run workspace, and emit observation events for recommendation-worthy ones. Use when the user says \"run the ecosystem watch\", \"tk research\", or a research job's invoke-skill directive names this skill.","https:\u002F\u002Fgithub.com\u002Fthkennedy\u002Ftk-studio\u002Fblob\u002Fmain\u002Fplugins\u002Ftk-studio\u002Fskills\u002Ftk-studio-research\u002FSKILL.md",[],[],{"skillNo":81,"name":82,"nameZh":6,"description":83,"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},"01M79RYA1AWZZF83KBHGR6JDN3","tk-studio-report","One-verb human defect report — \"the skill did the wrong thing\" — recorded as a report event in the local measurement ledger. Use when the user says \"tk report\", \"report a defect\", \"that skill misbehaved\", or \"log a studio issue\".","https:\u002F\u002Fgithub.com\u002Fthkennedy\u002Ftk-studio\u002Fblob\u002Fmain\u002Fplugins\u002Ftk-studio\u002Fskills\u002Ftk-studio-report\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},"01M79RY33VMYR5YNPVFKWRNW9S","tk-studio-playable-judge","The playable-verify leg's screenshot judge (Story 34.3) — reads only a playable run's report.json and its frames, answers the fixed rubric (scene loaded, player visible and framed, no magenta or error overlay, HUD reads, the named moments shown) with pass or fail and findings each naming a frame and a rubric line. Driven headless by the supervisor's host leg on the project's sandbox tier; use when the payload names a playable `media` folder, or the user says \"judge the playable frames\".","https:\u002F\u002Fgithub.com\u002Fthkennedy\u002Ftk-studio\u002Fblob\u002Fmain\u002Fplugins\u002Ftk-studio\u002Fskills\u002Ftk-studio-playable-judge\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},"01M79RXY4AM8JM6ZK2MAR3W3X2","tk-studio-plan-sync","Planning adapter — canonicalize BMad-native planning artifacts (normalize pass, sole id authority) and sync them with the bound planning backend. Use when the user says \"sync the plan\", \"normalize planning artifacts\", \"tk plan sync\", or after stock BMad planning flows produce or change epics\u002Fstories.","https:\u002F\u002Fgithub.com\u002Fthkennedy\u002Ftk-studio\u002Fblob\u002Fmain\u002Fplugins\u002Ftk-studio\u002Fskills\u002Ftk-studio-plan-sync\u002FSKILL.md",[],[]]