[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M79RHXZPWVC44BS849XCE3N7":3,"skill-same:01M79RHXZPWVC44BS849XCE3N7":70},{"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},"01M79RHXZPWVC44BS849XCE3N7","{setup-skill-name}",null,"Sets up {module-name} module in a project. Use when the user requests to 'install {module-code} module', 'configure {module-name}', or 'setup {module-name}'.","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\u002Fapps\u002Fsupervisor\u002F.claude\u002Fskills\u002Fbmad-module-builder\u002Fassets\u002Fsetup-skill-template\u002FSKILL.md",[],[],"2026-11-15 14:19:17",false,"---\nname: \"{setup-skill-name}\"\ndescription: Sets up {module-name} module in a project. Use when the user requests to 'install {module-code} module', 'configure {module-name}', or 'setup {module-name}'.\n---\n\n# Module Setup\n\n## Overview\n\nInstalls and configures a BMad module into a project. Module identity (name, code, version) comes from `.\u002Fassets\u002Fmodule.yaml`. Collects user preferences and writes them to three files:\n\n- **`{project-root}\u002F_bmad\u002Fconfig.yaml`** — shared project config: core settings at root (e.g. `output_folder`, `document_output_language`) plus a section per module with metadata and module-specific values. User-only keys (`user_name`, `communication_language`) are **never** written here.\n- **`{project-root}\u002F_bmad\u002Fconfig.user.yaml`** — personal settings intended to be gitignored: `user_name`, `communication_language`, and any module variable marked `user_setting: true` in `.\u002Fassets\u002Fmodule.yaml`. These values live exclusively here.\n- **`{project-root}\u002F_bmad\u002Fmodule-help.csv`** — registers module capabilities for the help system.\n\nBoth config scripts use an anti-zombie pattern — existing entries for this module are removed before writing fresh ones, so stale values never persist.\n\n`{project-root}` is a **literal token** in config _values_ (the data written into the files above) — never substitute it there. It signals to the consuming LLM that the value is relative to the project root, not the skill root. **This does not apply to the filesystem path _arguments_ passed to the scripts below** (the `--*-path`, `--*-dir`, and `--target` arguments): those are real paths, so you **must** resolve `{project-root}` to the actual project root before running, or the scripts will write to a literal `{project-root}\u002F` directory under the skill folder. The scripts reject an unresolved token with an error.\n\n## On Activation\n\n1. Read `.\u002Fassets\u002Fmodule.yaml` for module metadata and variable definitions (the `code` field is the module identifier)\n2. Check if `{project-root}\u002F_bmad\u002Fconfig.yaml` exists — if a section matching the module's code is already present, inform the user this is an update\n3. Check for per-module configuration at `{project-root}\u002F_bmad\u002F{module-code}\u002Fconfig.yaml` and `{project-root}\u002F_bmad\u002Fcore\u002Fconfig.yaml`. If either file exists:\n   - If `{project-root}\u002F_bmad\u002Fconfig.yaml` does **not** yet have a section for this module: this is a **fresh install**. Inform the user that installer config was detected and values will be consolidated into the new format.\n   - If `{project-root}\u002F_bmad\u002Fconfig.yaml` **already** has a section for this module: this is a **legacy migration**. Inform the user that legacy per-module config was found alongside existing config, and legacy values will be used as fallback defaults.\n   - In both cases, per-module config files and directories will be cleaned up after setup.\n\nIf the user provides arguments (e.g. `accept all defaults`, `--headless`, or inline values like `user name is BMad, I speak Swahili`), map any provided values to config keys, use defaults for the rest, and skip interactive prompting. Still display the full confirmation summary at the end.\n\n## Collect Configuration\n\nAsk the user for values. Show defaults in brackets. Present all values together so the user can respond once with only the values they want to change (e.g. \"change language to Swahili, rest are fine\"). Never tell the user to \"press enter\" or \"leave blank\" — in a chat interface they must type something to respond.\n\n**Default priority** (highest wins): existing new config values > legacy config values > `.\u002Fassets\u002Fmodule.yaml` defaults. When legacy configs exist, read them and use matching values as defaults instead of `module.yaml` defaults. Only keys that match the current schema are carried forward — changed or removed keys are ignored.\n\n**Core config** (only if no core keys exist yet): `user_name` (default: BMad), `communication_language` and `document_output_language` (default: English — ask as a single language question, both keys get the same answer), `output_folder` (default: `{project-root}\u002F_bmad-output`). Of these, `user_name` and `communication_language` are written exclusively to `config.user.yaml`. The rest go to `config.yaml` at root and are shared across all modules.\n\n**Module config**: Read each variable in `.\u002Fassets\u002Fmodule.yaml` that has a `prompt` field. Ask using that prompt with its default value (or legacy value if available).\n\n## Write Files\n\nWrite a temp JSON file with the collected answers structured as `{\"core\": {...}, \"module\": {...}}` (omit `core` if it already exists). Values inside this JSON keep the literal `{project-root}` token. Then run both scripts — they can run in parallel since they write to different files.\n\nIn the commands below, replace `{project-root}` in every path argument with the actual project root (e.g. `\u002Fhome\u002Fme\u002Fmyapp`) before running — these are filesystem paths, not config values.\n\n```bash\npython3 .\u002Fscripts\u002Fmerge-config.py --config-path \"{project-root}\u002F_bmad\u002Fconfig.yaml\" --user-config-path \"{project-root}\u002F_bmad\u002Fconfig.user.yaml\" --module-yaml .\u002Fassets\u002Fmodule.yaml --answers {temp-file} --legacy-dir \"{project-root}\u002F_bmad\"\npython3 .\u002Fscripts\u002Fmerge-help-csv.py --target \"{project-root}\u002F_bmad\u002Fmodule-help.csv\" --source .\u002Fassets\u002Fmodule-help.csv --legacy-dir \"{project-root}\u002F_bmad\" --module-code {module-code}\n```\n\nBoth scripts output JSON to stdout with results. If either exits non-zero, surface the error and stop. The scripts automatically read legacy config values as fallback defaults, then delete the legacy files after a successful merge. Check `legacy_configs_deleted` and `legacy_csvs_deleted` in the output to confirm cleanup.\n\nRun `.\u002Fscripts\u002Fmerge-config.py --help` or `.\u002Fscripts\u002Fmerge-help-csv.py --help` for full usage.\n\n## Create Output Directories\n\nAfter writing config, create any output directories that were configured. For filesystem operations only (such as creating directories), resolve the `{project-root}` token to the actual project root and create each path-type value from `config.yaml` that does not yet exist — this includes `output_folder` and any module variable whose value starts with `{project-root}\u002F`. The paths stored in the config files must continue to use the literal `{project-root}` token; only the directories on disk should use the resolved paths. Use `mkdir -p` or equivalent to create the full path.\n\n## Cleanup Legacy Directories\n\nAfter both merge scripts complete successfully, remove the installer's package directories. Skills and agents in these directories are already installed at `.claude\u002Fskills\u002F` — the `_bmad\u002F` directory should only contain config files.\n\nAs with the merge scripts, replace `{project-root}` in the `--bmad-dir` and `--skills-dir` path arguments with the actual project root before running.\n\n```bash\npython3 .\u002Fscripts\u002Fcleanup-legacy.py --bmad-dir \"{project-root}\u002F_bmad\" --module-code {module-code} --also-remove _config --skills-dir \"{project-root}\u002F.claude\u002Fskills\"\n```\n\nThe script verifies that every skill in the legacy directories exists at `.claude\u002Fskills\u002F` before removing anything. Directories without skills (like `_config\u002F`) are removed directly. If the script exits non-zero, surface the error and stop. Missing directories (already cleaned by a prior run) are not errors — the script is idempotent.\n\nCheck `directories_removed` and `files_removed_count` in the JSON output for the confirmation step. Run `.\u002Fscripts\u002Fcleanup-legacy.py --help` for full usage.\n\n## Confirm\n\nUse the script JSON output to display what was written — config values set (written to `config.yaml` at root for core, module section for module values), user settings written to `config.user.yaml` (`user_keys` in result), help entries added, fresh install vs update. If legacy files were deleted, mention the migration. If legacy directories were removed, report the count and list (e.g. \"Cleaned up 106 installer package files from bmb\u002F, core\u002F, \\_config\u002F — skills are installed at .claude\u002Fskills\u002F\"). Then display the `module_greeting` from `.\u002Fassets\u002Fmodule.yaml` to the user.\n\n## Outcome\n\nOnce the user's `user_name` and `communication_language` are known (from collected input, arguments, or existing config), use them consistently for the remainder of the session: address the user by their configured name and communicate in their configured `communication_language`.\n","# Module Setup\n\n## Overview\n\nInstalls and configures a BMad module into a project. Module identity (name, code, version) comes from `.\u002Fassets\u002Fmodule.yaml`. Collects user preferences and writes them to three files:\n\n- **`{project-root}\u002F_bmad\u002Fconfig.yaml`** — shared project config: core settings at root (e.g. `output_folder`, `document_output_language`) plus a section per module with metadata and module-specific values. User-only keys (`user_name`, `communication_language`) are **never** written here.\n- **`{project-root}\u002F_bmad\u002Fconfig.user.yaml`** — personal settings intended to be gitignored: `user_name`, `communication_language`, and any module variable marked `user_setting: true` in `.\u002Fassets\u002Fmodule.yaml`. These values live exclusively here.\n- **`{project-root}\u002F_bmad\u002Fmodule-help.csv`** — registers module capabilities for the help system.\n\nBoth config scripts use an anti-zombie pattern — existing entries for this module are removed before writing fresh ones, so stale values never persist.\n\n`{project-root}` is a **literal token** in config _values_ (the data written into the files above) — never substitute it there. It signals to the consuming LLM that the value is relative to the project root, not the skill root. **This does not apply to the filesystem path _arguments_ passed to the scripts below** (the `--*-path`, `--*-dir`, and `--target` arguments): those are real paths, so you **must** resolve `{project-root}` to the actual project root before running, or the scripts will write to a literal `{project-root}\u002F` directory under the skill folder. The scripts reject an unresolved token with an error.\n\n## On Activation\n\n1. Read `.\u002Fassets\u002Fmodule.yaml` for module metadata and variable definitions (the `code` field is the module identifier)\n2. Check if `{project-root}\u002F_bmad\u002Fconfig.yaml` exists — if a section matching the module's code is already present, inform the user this is an update\n3. Check for per-module configuration at `{project-root}\u002F_bmad\u002F{module-code}\u002Fconfig.yaml` and `{project-root}\u002F_bmad\u002Fcore\u002Fconfig.yaml`. If either file exists:\n   - If `{project-root}\u002F_bmad\u002Fconfig.yaml` does **not** yet have a section for this module: this is a **fresh install**. Inform the user that installer config was detected and values will be consolidated into the new format.\n   - If `{project-root}\u002F_bmad\u002Fconfig.yaml` **already** has a section for this module: this is a **legacy migration**. Inform the user that legacy per-module config was found alongside existing config, and legacy values will be used as fallback defaults.\n   - In both cases, per-module config files and directories will be cleaned up after setup.\n\nIf the user provides arguments (e.g. `accept all defaults`, `--headless`, or inline values like `user name is BMad, I speak Swahili`), map any provided values to config keys, use defaults for the rest, and skip interactive prompting. Still display the full confirmation summary at the end.\n\n## Collect Configuration\n\nAsk the user for values. Show defaults in brackets. Present all values together so the user can respond once with only the values they want to change (e.g. \"change language to Swahili, rest are fine\"). Never tell the user to \"press enter\" or \"leave blank\" — in a chat interface they must type something to respond.\n\n**Default priority** (highest wins): existing new config values > legacy config values > `.\u002Fassets\u002Fmodule.yaml` defaults. When legacy configs exist, read them and use matching values as defaults instead of `module.yaml` defaults. Only keys that match the current schema are carried forward — changed or removed keys are ignored.\n\n**Core config** (only if no core keys exist yet): `user_name` (default: BMad), `communication_language` and `document_output_language` (default: English — ask as a single language question, both keys get the same answer), `output_folder` (default: `{project-root}\u002F_bmad-output`). Of these, `user_name` and `communication_language` are written exclusively to `config.user.yaml`. The rest go to `config.yaml` at root and are shared across all modules.\n\n**Module config**: Read each variable in `.\u002Fassets\u002Fmodule.yaml` that has a `prompt` field. Ask using that prompt with its default value (or legacy value if available).\n\n## Write Files\n\nWrite a temp JSON file with the collected answers structured as `{\"core\": {...}, \"module\": {...}}` (omit `core` if it already exists). Values inside this JSON keep the literal `{project-root}` token. Then run both scripts — they can run in parallel since they write to different files.\n\nIn the commands below, replace `{project-root}` in every path argument with the actual project root (e.g. `\u002Fhome\u002Fme\u002Fmyapp`) before running — these are filesystem paths, not config values.\n\n```bash\npython3 .\u002Fscripts\u002Fmerge-config.py --config-path \"{project-root}\u002F_bmad\u002Fconfig.yaml\" --user-config-path \"{project-root}\u002F_bmad\u002Fconfig.user.yaml\" --module-yaml .\u002Fassets\u002Fmodule.yaml --answers {temp-file} --legacy-dir \"{project-root}\u002F_bmad\"\npython3 .\u002Fscripts\u002Fmerge-help-csv.py --target \"{project-root}\u002F_bmad\u002Fmodule-help.csv\" --source .\u002Fassets\u002Fmodule-help.csv --legacy-dir \"{project-root}\u002F_bmad\" --module-code {module-code}\n```\n\nBoth scripts output JSON to stdout with results. If either exits non-zero, surface the error and stop. The scripts automatically read legacy config values as fallback defaults, then delete the legacy files after a successful merge. Check `legacy_configs_deleted` and `legacy_csvs_deleted` in the output to confirm cleanup.\n\nRun `.\u002Fscripts\u002Fmerge-config.py --help` or `.\u002Fscripts\u002Fmerge-help-csv.py --help` for full usage.\n\n## Create Output Directories\n\nAfter writing config, create any output directories that were configured. For filesystem operations only (such as creating directories), resolve the `{project-root}` token to the actual project root and create each path-type value from `config.yaml` that does not yet exist — this includes `output_folder` and any module variable whose value starts with `{project-root}\u002F`. The paths stored in the config files must continue to use the literal `{project-root}` token; only the directories on disk should use the resolved paths. Use `mkdir -p` or equivalent to create the full path.\n\n## Cleanup Legacy Directories\n\nAfter both merge scripts complete successfully, remove the installer's package directories. Skills and agents in these directories are already installed at `.claude\u002Fskills\u002F` — the `_bmad\u002F` directory should only contain config files.\n\nAs with the merge scripts, replace `{project-root}` in the `--bmad-dir` and `--skills-dir` path arguments with the actual project root before running.\n\n```bash\npython3 .\u002Fscripts\u002Fcleanup-legacy.py --bmad-dir \"{project-root}\u002F_bmad\" --module-code {module-code} --also-remove _config --skills-dir \"{project-root}\u002F.claude\u002Fskills\"\n```\n\nThe script verifies that every skill in the legacy directories exists at `.claude\u002Fskills\u002F` before removing anything. Directories without skills (like `_config\u002F`) are removed directly. If the script exits non-zero, surface the error and stop. Missing directories (already cleaned by a prior run) are not errors — the script is idempotent.\n\nCheck `directories_removed` and `files_removed_count` in the JSON output for the confirmation step. Run `.\u002Fscripts\u002Fcleanup-legacy.py --help` for full usage.\n\n## Confirm\n\nUse the script JSON output to display what was written — config values set (written to `config.yaml` at root for core, module section for module values), user settings written to `config.user.yaml` (`user_keys` in result), help entries added, fresh install vs update. If legacy files were deleted, mention the migration. If legacy directories were removed, report the count and list (e.g. \"Cleaned up 106 installer package files from bmb\u002F, core\u002F, \\_config\u002F — skills are installed at .claude\u002Fskills\u002F\"). Then display the `module_greeting` from `.\u002Fassets\u002Fmodule.yaml` to the user.\n\n## Outcome\n\nOnce the user's `user_name` and `communication_language` are known (from collected input, arguments, or existing config), use them consistently for the remainder of the session: address the user by their configured name and communicate in their configured `communication_language`.\n",{"name":5,"description":7},"main","ecd23b3c0458cd511812f643d9111e3d7c8235f4","apps\u002Fsupervisor\u002F.claude\u002Fskills\u002Fbmad-module-builder\u002Fassets\u002Fsetup-skill-template","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 \"{setup-skill-name}\"",{"tool":38,"command":39},"bunx","bunx skills add thkennedy\u002Ftk-studio --skill \"{setup-skill-name}\"",{"tool":41,"command":42},"pnpm","pnpm dlx skills add thkennedy\u002Ftk-studio --skill \"{setup-skill-name}\"","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fthkennedy\u002Ftk-studio\u002Fblob\u002Fmain\u002Fapps\u002Fsupervisor\u002F.claude\u002Fskills\u002Fbmad-module-builder\u002Fassets\u002Fsetup-skill-template\u002FSKILL.md",true,[46,52,56,62,66],{"path":47,"resourceType":48,"resourceTypeDesc":49,"sizeBytes":50,"sourceHtmlUrl":51},"assets\u002Fmodule-help.csv","ASSET","资产文件",123,"https:\u002F\u002Fgithub.com\u002Fthkennedy\u002Ftk-studio\u002Fblob\u002Fmain\u002Fapps\u002Fsupervisor\u002F.claude\u002Fskills\u002Fbmad-module-builder\u002Fassets\u002Fsetup-skill-template\u002Fassets\u002Fmodule-help.csv",{"path":53,"resourceType":48,"resourceTypeDesc":49,"sizeBytes":54,"sourceHtmlUrl":55},"assets\u002Fmodule.yaml",96,"https:\u002F\u002Fgithub.com\u002Fthkennedy\u002Ftk-studio\u002Fblob\u002Fmain\u002Fapps\u002Fsupervisor\u002F.claude\u002Fskills\u002Fbmad-module-builder\u002Fassets\u002Fsetup-skill-template\u002Fassets\u002Fmodule.yaml",{"path":57,"resourceType":58,"resourceTypeDesc":59,"sizeBytes":60,"sourceHtmlUrl":61},"scripts\u002Fcleanup-legacy.py","SCRIPT","脚本",8904,"https:\u002F\u002Fgithub.com\u002Fthkennedy\u002Ftk-studio\u002Fblob\u002Fmain\u002Fapps\u002Fsupervisor\u002F.claude\u002Fskills\u002Fbmad-module-builder\u002Fassets\u002Fsetup-skill-template\u002Fscripts\u002Fcleanup-legacy.py",{"path":63,"resourceType":58,"resourceTypeDesc":59,"sizeBytes":64,"sourceHtmlUrl":65},"scripts\u002Fmerge-config.py",15430,"https:\u002F\u002Fgithub.com\u002Fthkennedy\u002Ftk-studio\u002Fblob\u002Fmain\u002Fapps\u002Fsupervisor\u002F.claude\u002Fskills\u002Fbmad-module-builder\u002Fassets\u002Fsetup-skill-template\u002Fscripts\u002Fmerge-config.py",{"path":67,"resourceType":58,"resourceTypeDesc":59,"sizeBytes":68,"sourceHtmlUrl":69},"scripts\u002Fmerge-help-csv.py",7760,"https:\u002F\u002Fgithub.com\u002Fthkennedy\u002Ftk-studio\u002Fblob\u002Fmain\u002Fapps\u002Fsupervisor\u002F.claude\u002Fskills\u002Fbmad-module-builder\u002Fassets\u002Fsetup-skill-template\u002Fscripts\u002Fmerge-help-csv.py",[71,78,85,92,99,106],{"skillNo":72,"name":73,"nameZh":6,"description":74,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":75,"categories":76,"keywords":77,"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":79,"name":80,"nameZh":6,"description":81,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":82,"categories":83,"keywords":84,"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":86,"name":87,"nameZh":6,"description":88,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":89,"categories":90,"keywords":91,"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":93,"name":94,"nameZh":6,"description":95,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":96,"categories":97,"keywords":98,"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":100,"name":101,"nameZh":6,"description":102,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":103,"categories":104,"keywords":105,"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":107,"name":108,"nameZh":6,"description":109,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":110,"categories":111,"keywords":112,"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",[],[]]