[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M7C8PWPJSF99P7RV73XJM565":3,"skill-same:01M7C8PWPJSF99P7RV73XJM565":53},{"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":27,"commitSha":28,"skillDirectory":29,"forksCount":14,"repositoryHtmlUrl":30,"repositoryHomepageUrl":6,"ownerHtmlUrl":31,"ownerBlogUrl":32,"ownerDescription":6,"updatedAt":33,"install":34,"resources":46},"01M7C8PWPJSF99P7RV73XJM565","maintain-project-verification-skill",null,"Use for \u002Fmaintain-project-verification-skill, or when asked to update a repo's verify skill to the current generator, including skills from before recipes were scripts.","thanostourik\u002Fagent-config","thanostourik","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F8533815?v=4","01M7C8NR4FZRHP6XF6FAZH4QXE","Thanos Tourikas","01M7C8NR57G236RMSDVV79N29M",0,"MIT","https:\u002F\u002Fgithub.com\u002Fthanostourik\u002Fagent-config\u002Fblob\u002Fmain\u002Fskills\u002Fmaintain-project-verification-skill\u002FSKILL.md",[],[],"2026-11-15 14:19:17",false,"---\nname: maintain-project-verification-skill\nmetadata:\n  harness: \"claude-code, codex, grok, cursor\"\ndescription: \"Use for \u002Fmaintain-project-verification-skill, or when asked to update a repo's verify skill to the current generator, including skills from before recipes were scripts.\"\ndisable-model-invocation: true\n---\n\n# Maintain a project verification skill\n\n`create-project-verification-skill` generated the project's `verify-\u003Capp>` skill. The\nshipped files (`SKILL.md`, `FULL.md` and the files the generator's \"What you write\" marks\n`unchanged`) come from the generator. Everything project-specific sits in `PROJECT.md`, the\nother `bin\u002F` helpers and `features\u002F`. So an upgrade is mostly a copy, and a script does it.\nAn upgrade does not record what no recipe covers yet: `\u002Fverify-\u003Capp> full` does that.\n\nWhen you need me to make a choice before you can continue, use your question tool if you\nhave one, or ask in your reply if you don't. If the question gets no answer, ask again in\nyour reply and wait. Do not answer it yourself.\n\n`\u003Cgenerator>` below is `..\u002Fcreate-project-verification-skill\u002F` next to this skill's folder.\n\n## 1. Run the upgrade\n\nFrom the repository root, on a branch as the repo's conventions say:\n\n```bash\n\u003Cgenerator>\u002Freferences\u002Fupgrade\n```\n\nWith several `verify-*` skills, ask which one and pass its folder. The script:\n\n- copies the shipped files;\n- converts Markdown recipes into `features\u002F\u003Cfeature>.sh` scripts;\n- removes the old runner, recorder and `maintain-verify-\u003Capp>` skill;\n- keeps the old files it replaced under `.cache\u002Fupgrade\u002F` (gitignored, so they stay local);\n- ends with the list of what is left for you.\n\nIt is safe to run again. Commit its result before anything else.\n\n## 2. Do what it lists\n\nDo the items the script lists, in the order it lists them, and nothing else. An item with\nno entry below is done as its line says. Two more items, marked \"every upgrade\", are\nchecked even when the script does not list them. Do them after the `launch.sh` items.\n\n- **`PROJECT.md`**: write it from `.cache\u002Fupgrade\u002FSKILL.md` and `.cache\u002Fupgrade\u002FREADME.md`,\n  with the sections step 3 of `\u003Cgenerator>\u002FSKILL.md` names.\n  - Keep every project fact: isolation, launch and cleanup behavior, sign-in, baseline\n    data, helper calls, driving conventions that are specific to this project, gotchas.\n  - Drop the rules the shipped `SKILL.md` already states, and everything about the old\n    runner, recorders, contract maps and maintenance modes.\n- **`launch.sh` idempotent**: when the run's environment is already up, a second call\n  rebuilds and restarts only the app, and recreates nothing when the source is unchanged.\n  `doctor.sh` accepts the result. Keep the ownership record of `launch.sh` and its recovery\n  of an interrupted launch.\n- **The project's stack** (every upgrade): the repo may have an environment that\n  `\u003Cgenerator>\u002Freferences\u002Flifecycle.md` would pick as isolated and disposable, such as\n  `local-stack\u002Fstack`, while `launch.sh` builds its own. Then:\n  - Make `launch.sh` and `cleanup.sh` use the stack as `lifecycle.md` says. `launch.sh`\n    still starts the app in both modes, `VERIFY_APP=dev` and `VERIFY_APP=build`, as step 3\n    of `\u003Cgenerator>\u002FSKILL.md` says.\n  - Delete the code the stack replaces: its own Compose project, port picking and source\n    copies.\n  - Isolation is the stack's job from then on, so a leak found later is fixed in the stack.\n  - When the stack cannot start something the recipes need, stop and name it.\n- **Helper waits and errors** (every upgrade): read each `bin\u002F` helper.\n  - Make its waits and error output follow the \"Waits and errors\" rules of the new\n    `SKILL.md`, including how a helper that restarts the app waits for a real page.\n  - Check that a helper that inserts rows directly follows the fixture rule in the new\n    `SKILL.md`'s Data section, against the seed data or the dump.\n  - `verify lint` checks only recipes, so this is the only check helpers get.\n- **References to the removed scripts**: remove them. A helper that reads the old runner's\n  files, such as an `observe.sh` reading `.cache\u002Fdrive\u002F\u003Cfeature>\u002Fsteps\u002F`, reads\n  `$VERIFY_DIR\u002Flog` and `$EVIDENCE` instead.\n- **`# touches:`**: start subagents (in T3 Code `delegate_task` with `mode: \"async\"`,\n  otherwise your tool's own subagent), each with up to 6 features and this prompt:\n\n  ```\n  For each feature recipe below in .agents\u002Fskills\u002Fverify-\u003Capp>\u002Ffeatures\u002F, list the source\n  files its behavior lives in: the handlers, controllers, components, services, queries and\n  migrations it exercises, as repository paths (\u003Capp>\u002F\u003Cpath> in a companion repo). Read the\n  recipe, grep for the routes, commands or screens it drives, and follow them into the\n  source. Files only, never folders; leave out files every feature only passes through, but\n  keep a file that holds this feature's routes or handlers. Write the list on the recipe's\n  one '# touches:' line, space-separated, and change nothing else. Run\n  .agents\u002Fskills\u002Fverify-\u003Capp>\u002Fbin\u002Fverify lint \u003Cfeatures> and return its last line.\n  Features: \u003Cfeature> \u003Cfeature> ...\n  ```\n\n- **`entrypoints.sh`** and **`actions.sh`**: write them as step 3 of `\u003Cgenerator>\u002FSKILL.md`\n  says.\n- **`AGENTS.md`**: write its `## Verification` section (and the one in `CLAUDE.md`) from\n  `\u003Cgenerator>\u002Freferences\u002Fagents-verification.md`.\n- **Features the script could not convert**: run `bin\u002Fareas > .cache\u002Fareas.txt`. Then send\n  each area that holds such a feature to a recorder, as the Recorders section of the new\n  `FULL.md` says, after step 3's `bin\u002Fverify up`. The recorder keeps the area's existing\n  recipes.\n\n## 3. Prove it\n\nRun `bin\u002Fverify lint`, then `bin\u002Fverify up` twice: the second call must reuse the\nenvironment. Then drive only what the upgrade can break. Never run `bin\u002Fverify all`: an\nupgrade mostly changes rules, and a rule change breaks no feature.\n\n- Run `bin\u002Fverify affected --base \u003Cthe commit before step 1's commit>`. It drives every\n  converted or changed recipe. Under each changed helper it lists the features that use\n  it: drive by name one of them for each call of the helper the upgrade altered. Changes\n  to `SKILL.md`, `PROJECT.md` and the other rules list nothing.\n- When `bin\u002Fverify`, `bin\u002Flib.sh`, `bin\u002Freach`, `launch.sh`, `doctor.sh` or `cleanup.sh`\n  changed, also drive a few features by name, as a smoke test of the runner and the\n  environment: one plain feature, one marked `# alone`, and one marked `# shares`, each\n  when one exists.\n- When neither gives a feature to drive, drive nothing: `bin\u002Fverify lint` was the check.\n\n`bin\u002Fverify lint` ends with the `# expects:` lines that cite a file or a name the code\ndoes not have. `bin\u002Fverify affected` can never select a feature through such a line. Give\neach the name of the function that produces its behavior, as the skill's Header rules say.\nA header edit needs no drive.\n\nFix the environment yourself when `doctor.sh` stops the run.\n\nRepair two things before the PR:\n\n- A driven feature that fails.\n- An `# expects:` line marked not driven for a reason the new rules do not allow. Recipes\n  keep reasons that were written under older rules. `bin\u002Fverify uncovered` ends with every\n  such reason and its features. Check each against the Header rules in the new\n  `SKILL.md`'s Recipes section.\n\nTo repair them:\n\n1. Run `bin\u002Fareas > .cache\u002Fareas.txt` when it is missing.\n2. Start one recorder for each area that holds failing features or a reason that does not\n   hold, all at once, with their summary lines and those reasons. A recorder repairs the\n   recipe, or marks a product defect `# known failure:`, and gives each line whose reason\n   does not hold a step.\n3. Drive the features the recorders changed, together in one `bin\u002Fverify \u003Cfeature>...`.\n   Send each feature that fails there back to a recorder. Repeat until each passes or fails\n   at a known failure.\n\nFeatures the upgrade cannot break are not driven, and their old failures are not this\nskill's work. Then run `bin\u002Fverify uncovered` and `bin\u002Fverify down`.\n\n## 4. Ship and report\n\nCommit and open one PR as the repository's conventions say. Report:\n\n- what the script changed, and what you did from its list;\n- each drive with its command, number of features and time;\n- the features the recorders repaired, the expectations that now have a step, and each\n  known failure.\n\nEnd the report with exactly one of these lines. When `bin\u002Fverify uncovered` listed anything\nas not covered, fill in the count: \"\u003Cn> entry points and actions have no recipe. Run\n`\u002Fverify-\u003Capp> full` to record them.\" Otherwise: \"Recipes are up to date. Nothing else to\nrun.\" Mention `full` nowhere else in the report: the user reads any mention as a request to\nrun it.\n\nThen delete `.cache\u002Fupgrade\u002F`. A later upgrade on this machine would otherwise take its old\nfiles for its own and list their work again.\n","# Maintain a project verification skill\n\n`create-project-verification-skill` generated the project's `verify-\u003Capp>` skill. The\nshipped files (`SKILL.md`, `FULL.md` and the files the generator's \"What you write\" marks\n`unchanged`) come from the generator. Everything project-specific sits in `PROJECT.md`, the\nother `bin\u002F` helpers and `features\u002F`. So an upgrade is mostly a copy, and a script does it.\nAn upgrade does not record what no recipe covers yet: `\u002Fverify-\u003Capp> full` does that.\n\nWhen you need me to make a choice before you can continue, use your question tool if you\nhave one, or ask in your reply if you don't. If the question gets no answer, ask again in\nyour reply and wait. Do not answer it yourself.\n\n`\u003Cgenerator>` below is `..\u002Fcreate-project-verification-skill\u002F` next to this skill's folder.\n\n## 1. Run the upgrade\n\nFrom the repository root, on a branch as the repo's conventions say:\n\n```bash\n\u003Cgenerator>\u002Freferences\u002Fupgrade\n```\n\nWith several `verify-*` skills, ask which one and pass its folder. The script:\n\n- copies the shipped files;\n- converts Markdown recipes into `features\u002F\u003Cfeature>.sh` scripts;\n- removes the old runner, recorder and `maintain-verify-\u003Capp>` skill;\n- keeps the old files it replaced under `.cache\u002Fupgrade\u002F` (gitignored, so they stay local);\n- ends with the list of what is left for you.\n\nIt is safe to run again. Commit its result before anything else.\n\n## 2. Do what it lists\n\nDo the items the script lists, in the order it lists them, and nothing else. An item with\nno entry below is done as its line says. Two more items, marked \"every upgrade\", are\nchecked even when the script does not list them. Do them after the `launch.sh` items.\n\n- **`PROJECT.md`**: write it from `.cache\u002Fupgrade\u002FSKILL.md` and `.cache\u002Fupgrade\u002FREADME.md`,\n  with the sections step 3 of `\u003Cgenerator>\u002FSKILL.md` names.\n  - Keep every project fact: isolation, launch and cleanup behavior, sign-in, baseline\n    data, helper calls, driving conventions that are specific to this project, gotchas.\n  - Drop the rules the shipped `SKILL.md` already states, and everything about the old\n    runner, recorders, contract maps and maintenance modes.\n- **`launch.sh` idempotent**: when the run's environment is already up, a second call\n  rebuilds and restarts only the app, and recreates nothing when the source is unchanged.\n  `doctor.sh` accepts the result. Keep the ownership record of `launch.sh` and its recovery\n  of an interrupted launch.\n- **The project's stack** (every upgrade): the repo may have an environment that\n  `\u003Cgenerator>\u002Freferences\u002Flifecycle.md` would pick as isolated and disposable, such as\n  `local-stack\u002Fstack`, while `launch.sh` builds its own. Then:\n  - Make `launch.sh` and `cleanup.sh` use the stack as `lifecycle.md` says. `launch.sh`\n    still starts the app in both modes, `VERIFY_APP=dev` and `VERIFY_APP=build`, as step 3\n    of `\u003Cgenerator>\u002FSKILL.md` says.\n  - Delete the code the stack replaces: its own Compose project, port picking and source\n    copies.\n  - Isolation is the stack's job from then on, so a leak found later is fixed in the stack.\n  - When the stack cannot start something the recipes need, stop and name it.\n- **Helper waits and errors** (every upgrade): read each `bin\u002F` helper.\n  - Make its waits and error output follow the \"Waits and errors\" rules of the new\n    `SKILL.md`, including how a helper that restarts the app waits for a real page.\n  - Check that a helper that inserts rows directly follows the fixture rule in the new\n    `SKILL.md`'s Data section, against the seed data or the dump.\n  - `verify lint` checks only recipes, so this is the only check helpers get.\n- **References to the removed scripts**: remove them. A helper that reads the old runner's\n  files, such as an `observe.sh` reading `.cache\u002Fdrive\u002F\u003Cfeature>\u002Fsteps\u002F`, reads\n  `$VERIFY_DIR\u002Flog` and `$EVIDENCE` instead.\n- **`# touches:`**: start subagents (in T3 Code `delegate_task` with `mode: \"async\"`,\n  otherwise your tool's own subagent), each with up to 6 features and this prompt:\n\n  ```\n  For each feature recipe below in .agents\u002Fskills\u002Fverify-\u003Capp>\u002Ffeatures\u002F, list the source\n  files its behavior lives in: the handlers, controllers, components, services, queries and\n  migrations it exercises, as repository paths (\u003Capp>\u002F\u003Cpath> in a companion repo). Read the\n  recipe, grep for the routes, commands or screens it drives, and follow them into the\n  source. Files only, never folders; leave out files every feature only passes through, but\n  keep a file that holds this feature's routes or handlers. Write the list on the recipe's\n  one '# touches:' line, space-separated, and change nothing else. Run\n  .agents\u002Fskills\u002Fverify-\u003Capp>\u002Fbin\u002Fverify lint \u003Cfeatures> and return its last line.\n  Features: \u003Cfeature> \u003Cfeature> ...\n  ```\n\n- **`entrypoints.sh`** and **`actions.sh`**: write them as step 3 of `\u003Cgenerator>\u002FSKILL.md`\n  says.\n- **`AGENTS.md`**: write its `## Verification` section (and the one in `CLAUDE.md`) from\n  `\u003Cgenerator>\u002Freferences\u002Fagents-verification.md`.\n- **Features the script could not convert**: run `bin\u002Fareas > .cache\u002Fareas.txt`. Then send\n  each area that holds such a feature to a recorder, as the Recorders section of the new\n  `FULL.md` says, after step 3's `bin\u002Fverify up`. The recorder keeps the area's existing\n  recipes.\n\n## 3. Prove it\n\nRun `bin\u002Fverify lint`, then `bin\u002Fverify up` twice: the second call must reuse the\nenvironment. Then drive only what the upgrade can break. Never run `bin\u002Fverify all`: an\nupgrade mostly changes rules, and a rule change breaks no feature.\n\n- Run `bin\u002Fverify affected --base \u003Cthe commit before step 1's commit>`. It drives every\n  converted or changed recipe. Under each changed helper it lists the features that use\n  it: drive by name one of them for each call of the helper the upgrade altered. Changes\n  to `SKILL.md`, `PROJECT.md` and the other rules list nothing.\n- When `bin\u002Fverify`, `bin\u002Flib.sh`, `bin\u002Freach`, `launch.sh`, `doctor.sh` or `cleanup.sh`\n  changed, also drive a few features by name, as a smoke test of the runner and the\n  environment: one plain feature, one marked `# alone`, and one marked `# shares`, each\n  when one exists.\n- When neither gives a feature to drive, drive nothing: `bin\u002Fverify lint` was the check.\n\n`bin\u002Fverify lint` ends with the `# expects:` lines that cite a file or a name the code\ndoes not have. `bin\u002Fverify affected` can never select a feature through such a line. Give\neach the name of the function that produces its behavior, as the skill's Header rules say.\nA header edit needs no drive.\n\nFix the environment yourself when `doctor.sh` stops the run.\n\nRepair two things before the PR:\n\n- A driven feature that fails.\n- An `# expects:` line marked not driven for a reason the new rules do not allow. Recipes\n  keep reasons that were written under older rules. `bin\u002Fverify uncovered` ends with every\n  such reason and its features. Check each against the Header rules in the new\n  `SKILL.md`'s Recipes section.\n\nTo repair them:\n\n1. Run `bin\u002Fareas > .cache\u002Fareas.txt` when it is missing.\n2. Start one recorder for each area that holds failing features or a reason that does not\n   hold, all at once, with their summary lines and those reasons. A recorder repairs the\n   recipe, or marks a product defect `# known failure:`, and gives each line whose reason\n   does not hold a step.\n3. Drive the features the recorders changed, together in one `bin\u002Fverify \u003Cfeature>...`.\n   Send each feature that fails there back to a recorder. Repeat until each passes or fails\n   at a known failure.\n\nFeatures the upgrade cannot break are not driven, and their old failures are not this\nskill's work. Then run `bin\u002Fverify uncovered` and `bin\u002Fverify down`.\n\n## 4. Ship and report\n\nCommit and open one PR as the repository's conventions say. Report:\n\n- what the script changed, and what you did from its list;\n- each drive with its command, number of features and time;\n- the features the recorders repaired, the expectations that now have a step, and each\n  known failure.\n\nEnd the report with exactly one of these lines. When `bin\u002Fverify uncovered` listed anything\nas not covered, fill in the count: \"\u003Cn> entry points and actions have no recipe. Run\n`\u002Fverify-\u003Capp> full` to record them.\" Otherwise: \"Recipes are up to date. Nothing else to\nrun.\" Mention `full` nowhere else in the report: the user reads any mention as a request to\nrun it.\n\nThen delete `.cache\u002Fupgrade\u002F`. A later upgrade on this machine would otherwise take its old\nfiles for its own and list their work again.\n",{"name":5,"metadata":24,"description":7,"disable-model-invocation":26},{"harness":25},"claude-code, codex, grok, cursor",true,"main","28de6d836930ed55586f8cac365c2a65381f432b","skills\u002Fmaintain-project-verification-skill","https:\u002F\u002Fgithub.com\u002Fthanostourik\u002Fagent-config","https:\u002F\u002Fgithub.com\u002Fthanostourik","https:\u002F\u002Fthanostourikas.gr","2026-11-15 02:45:22",{"source":8,"skillName":5,"commands":35,"prompt":45,"zipAvailable":26},[36,39,42],{"tool":37,"command":38},"npx","npx skills add thanostourik\u002Fagent-config --skill maintain-project-verification-skill",{"tool":40,"command":41},"bunx","bunx skills add thanostourik\u002Fagent-config --skill maintain-project-verification-skill",{"tool":43,"command":44},"pnpm","pnpm dlx skills add thanostourik\u002Fagent-config --skill maintain-project-verification-skill","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fthanostourik\u002Fagent-config\u002Fblob\u002Fmain\u002Fskills\u002Fmaintain-project-verification-skill\u002FSKILL.md",[47],{"path":48,"resourceType":49,"resourceTypeDesc":50,"sizeBytes":51,"sourceHtmlUrl":52},"agents\u002Fopenai.yaml","REFERENCE","参考文档",43,"https:\u002F\u002Fgithub.com\u002Fthanostourik\u002Fagent-config\u002Fblob\u002Fmain\u002Fskills\u002Fmaintain-project-verification-skill\u002Fagents\u002Fopenai.yaml",[54,61,68,75,82,89],{"skillNo":55,"name":56,"nameZh":6,"description":57,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":58,"categories":59,"keywords":60,"publishedAt":19},"01M7C8QKD6FYHQHMV95PNHX8VZ","with-verification","Use when the user adds \"with verify\" or \"with verification\" to a task as an instruction to verify it with the project's verify skill. Not when verification is only the topic.","https:\u002F\u002Fgithub.com\u002Fthanostourik\u002Fagent-config\u002Fblob\u002Fmain\u002Fskills\u002Fwith-verification\u002FSKILL.md",[],[],{"skillNo":62,"name":63,"nameZh":6,"description":64,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":65,"categories":66,"keywords":67,"publishedAt":19},"01M7C8QFT8VQZ4YMEGEE2WEBJ6","triple-review","Use when the user asks for a triple review, or for three independent reviewers of a change.","https:\u002F\u002Fgithub.com\u002Fthanostourik\u002Fagent-config\u002Fblob\u002Fmain\u002Fskills\u002Ftriple-review\u002FSKILL.md",[],[],{"skillNo":69,"name":70,"nameZh":6,"description":71,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":72,"categories":73,"keywords":74,"publishedAt":19},"01M7C8QE9S718F6ETYS7T93VV3","tourik","Use when the user asks for \"tourik mode\".","https:\u002F\u002Fgithub.com\u002Fthanostourik\u002Fagent-config\u002Fblob\u002Fmain\u002Fskills\u002Ftourik\u002FSKILL.md",[],[],{"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},"01M7C8QADG0HS20BPRMX0Y9CZ8","takeover","Use when the user asks to take over someone else's PR and get it ready for the user to merge.","https:\u002F\u002Fgithub.com\u002Fthanostourik\u002Fagent-config\u002Fblob\u002Fmain\u002Fskills\u002Ftakeover\u002FSKILL.md",[],[],{"skillNo":83,"name":84,"nameZh":6,"description":85,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":86,"categories":87,"keywords":88,"publishedAt":19},"01M7C8Q6NBBZAPWY53TEP6VNY8","t3-fan-out","Use when the user wants several T3 threads or delegates started and coordinated, one per task.","https:\u002F\u002Fgithub.com\u002Fthanostourik\u002Fagent-config\u002Fblob\u002Fmain\u002Fskills\u002Ft3-fan-out\u002FSKILL.md",[],[],{"skillNo":90,"name":91,"nameZh":6,"description":92,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":93,"categories":94,"keywords":95,"publishedAt":19},"01M7C8Q51MT7D68WHF8AY0FE5B","squash-merge-pr","Use only when the user explicitly invokes squash-merge-pr.","https:\u002F\u002Fgithub.com\u002Fthanostourik\u002Fagent-config\u002Fblob\u002Fmain\u002Fskills\u002Fsquash-merge-pr\u002FSKILL.md",[],[]]