[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6RVSM5KFSGKQYNAF06W747R":3,"skill-same:01M6RVSM5KFSGKQYNAF06W747R":67},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":17,"publishedAt":38,"linkOnly":39,"markdownContent":40,"markdownBody":41,"frontMatter":42,"refName":48,"commitSha":49,"skillDirectory":50,"forksCount":13,"repositoryHtmlUrl":51,"repositoryHomepageUrl":6,"ownerHtmlUrl":52,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":53,"install":54,"resources":66},"01M6RVSM5KFSGKQYNAF06W747R","parallel-execution-optimizer",null,"Use when the user wants a task done much faster through parallel work, concurrent agents, batched tool calls, isolated worktrees, or many independent verification lanes without losing correctness.","sakamoto-family-smile\u002Fagent_monorepo","sakamoto-family-smile","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F132812403?v=4","01M6RTAT3H8PMWX5SJ65KP3VYF","01M6RTAV321WB5RAHCWTZMX5CV",0,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fsakamoto-family-smile\u002Fagent_monorepo\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fecc\u002Fparallel-execution-optimizer\u002FSKILL.md",[],[18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37],"execution","parallel","parallel execution optimizer","optimizer","parallel execution","when","verification","tool calls","calls","correctness","done","task","worktrees","task done","use","write","read","work","tool","Bash","2026-11-10 10:12:30",false,"---\nname: be-commit\ndescription: \"Create a commit from staged changes with validated message.\"\nargument-hint: \"[topic: \u003Chint>] [short]\"\nuser-invocable: true\nallowed-tools: Read, Edit, Write, Glob, Bash\n---\n\n# Smart Commit\n\nCreate a git commit from already-staged changes with a validated commit message following project conventions.\n\n## Instructions\n\n### Step 0: Validate Configuration\n\n1. Read `.claude\u002Fbackend-webflux-plugin.json`\n2. If missing, tell the user to run `\u002Fbackend-webflux-plugin:be-init` first and stop\n3. `pluginRoot`: the one line of `${CLAUDE_CONFIG_DIR:-$HOME\u002F.claude}\u002Fplugins\u002Fdata\u002Fbackend-webflux-plugin\u002FpluginRoot` (plugin CLAUDE.md § Configuration) — every `templates\u002F…` path in this document is `{pluginRoot}\u002Ftemplates\u002F…`; missing → stop: start a new session so the hook writes it.\n\n### Step 1: Check Staged Changes\n\nRun `git diff --staged` to see what is staged.\n\n- If nothing is staged, inform the user:\n  > \"No staged changes found. Stage your changes with `git add` first.\"\n- Stop if nothing is staged\n\n### Step 1.5: Pipeline Status Warning\n\nCheck if any feature progress files exist in `{workDocDir}\u002F.progress\u002F`:\n\n1. Glob `{workDocDir}\u002F.progress\u002F*.json` — exclude files matching `review-report-*.json` or `fix-report-*.json` (only keep entity progress files)\n2. For each progress file, read `pipeline.status`\n3. If any feature has a status other than `reviewed` or `done` (i.e., `scaffolded`, `implementing`, `implemented`, `verified`, `verify-failed`, `review-failed`, `fixing`, `resolved`, `escalated`):\n   > \"Warning: Feature '{feature}' is in '{status}' status — review\u002Fverification may not be complete.\"\n   > \"Continue with commit?\"\n   If the user declines, stop here.\n4. Compute `{pluginRoot}\u002Fscripts\u002Fsource-tree-hash.sh --staged` once — the index is what this commit will contain (exit 0 and a 40-hex id, else a tooling error: report it and stop — an empty value must not be compared). For each `reviewed`\u002F`done` feature that has not been committed since it was verified (`pipeline.verification.committed` is not `true`; Step 6.5 sets it), it must equal `pipeline.verification.tree`; different (or the field missing) — an unstaged edit, an untracked new file, or a change made after `be-verify` ran:\n   > \"Warning: the staged tree is not the tree feature '{feature}' was verified on — the review describes different code. Stage everything under src\u002F and the build files, or re-run be-verify and be-review.\"\n   > \"Continue with commit?\"\n   If the user declines, stop here. A feature already committed on the tree it was verified on is not re-checked: later tickets change the tree without invalidating its record.\n5. If all features are `reviewed`, `done` with a matching (or already committed) tree, or no progress files exist: proceed without warning\n\n### Step 2: Parse Arguments\n\n- `topic: \u003Ctopic>` -- optional topic hint for the commit message (inferred from diff if omitted)\n- `short` -- if present, generate subject line only (skip body)\n\n### Step 3: Security Scan\n\nRun `{pluginRoot}\u002Fscripts\u002Fpre-commit-check.sh security` to scan staged changes for secrets and dangerous files (the scan is not optional).\n\n- If the script reports issues, show the findings and **abort the commit**\n- Do not proceed to message drafting until the security scan passes\n\n### Step 4: Analyze Changes\n\nFrom the staged diff, determine:\n\n1. Which files were changed, added, or deleted\n2. The nature of the change: new feature, enhancement, bug fix, refactoring, test, configuration\n3. The domain\u002Fmodule affected\n4. If a topic hint was provided, use it to guide the message focus\n\n### Step 5: Draft Commit Message\n\nFollow CLAUDE.md commit standards:\n\n1. **Subject line** (mandatory):\n   - English, present tense, imperative mood (\"Add\", \"Fix\", \"Update\", not \"Added\", \"Fixes\")\n   - Maximum 50 characters\n   - Start with uppercase letter (exception: lowercase identifiers like function names)\n   - No prefix (no `fix:`, `feat:`, `docs:`, etc.)\n   - Focus on \"why\" rather than \"what\"\n\n2. **Body** (skip if `short` argument):\n   - Blank line after subject\n   - Maximum 72 characters per line\n   - Only break within paragraphs when exceeding 72 characters\n   - Describe the motivation and context\n   - Do not mention test code\n   - Do not list file names\n   - Do not include tool advertisements or branding\n\n**Worked example 1 — new feature:**\n\nStaged diff summary: adds `command\u002FCreateEmployee.java`, `commandmodel\u002FCreateEmployeeCommandExecutor.java`, `domain\u002Fapi\u002FEmployeeRouter.java`; wires a new `POST \u002Fhr\u002Femployees` route.\n\n```\nAdd employee creation endpoint\n\nIntroduce the command executor and router wiring needed to\ncreate an employee via POST \u002Fhr\u002Femployees. The executor\nvalidates the email is unique before persisting, matching the\nduplicate-check pattern used by the existing customer domain.\n```\n\n**Worked example 2 — bug fix, with an edge case:**\n\nStaged diff summary: changes `data\u002FEmployeeRepository.java` and `commandmodel\u002FUpdateEmployeeCommandExecutor.java` only — a one-line fix plus a null check. Small diffs are still expected to explain *why*, not just restate the diff:\n\n```\nFix duplicate-email race on concurrent update\n\nTwo concurrent updates to the same email could both pass the\nuniqueness check before either write committed. Wrap the check\nand update in TransactionalOperator so the second writer sees\nthe first writer's row and fails the uniqueness constraint\ninstead of silently overwriting it.\n```\n\nEdge case: if the diff is a one-line change with no obvious \"why\" recoverable from the diff alone (e.g. a config value bump), keep the body short rather than inventing a rationale — a single sentence stating what changed and, if known from the topic hint, why is acceptable; never fabricate a motivation the diff doesn't support.\n\n### Step 6: Validate\n\nCheck the draft message against commit message rules from CLAUDE.md:\n\n- [ ] English (#1)\n- [ ] Present tense imperative (#2)\n- [ ] Subject \u003C= 50 characters (#3)\n- [ ] Blank line between subject and body (#4)\n- [ ] Body lines \u003C= 72 characters (#5)\n- [ ] Only break within a paragraph when exceeding 72 characters (#6)\n- [ ] No test code mentions (#7)\n- [ ] No prefix (fix:, feat:, docs:, etc.) (#8)\n- [ ] Starts with uppercase (or justified lowercase identifier) (#9)\n- [ ] No branding\u002Fpromotional content (#10)\n\nIf validation fails, revise the message.\n\nNote: CLAUDE.md rules #11-13 (staged-only, ensure staging, separate git commands) are workflow constraints enforced in Step 1 and the Constraints section, not message format rules.\n\n### Step 6.5: Close the Fix Cycle\n\nBefore the commit, for every feature progress file whose status is `reviewed` or `done`, set\n`pipeline.fix.round` to `0` — and, when its `pipeline.verification.tree` equals the staged hash Step 1.5\ncomputed, `pipeline.verification.committed` to `true` (this commit consumes that verification; Step 1.5\nstops comparing it to later trees) — (read-modify-write, preserving everything else) under\n`{workDocDir}\u002F.progress\u002F.lock` (`operation: be-commit`, a fresh `runId`), taken and released (per CLAUDE.md § State File Safety) around the writes exactly as every other\nprogress-file writer does (CLAUDE.md § State File Safety); if the lock is held by a live operation,\nskip the reset and say so rather than wait. The counter bounds fix attempts within one review cycle;\na commit ends that cycle. Left as is, a feature committed at `reviewed` with `round: 2` makes the\nnext ticket's first `be-fix` round 3 — and `be-fix` Step 3 blocks on a prompt an unattended\n`be-jira-auto` run cannot answer.\n\nThis runs before Step 7, not after: a progress file that is tracked and staged would otherwise be\ncommitted with the old round and dirty again the moment the commit lands. For such a file — listed by\n`git diff --cached --name-only` and, before this step's write, carrying no unstaged edit\n(`git diff --quiet -- {file}`) — refresh its staged copy with `git add -- {file}`: the one `git add`\nthis skill makes, on a path the user already staged, adding only this step's own fields. A tracked\nbut unstaged progress file, or one that had unstaged edits of the user's, stays as it was (say so).\n\n### Step 7: Execute Commit\n\nA multi-paragraph body passed via `-m \"{message}\"` is fragile (shell quoting can mangle or\ntruncate it). Pass the drafted message through stdin with `git commit -F -` inside a\nheredoc instead:\n\n```bash\ngit commit -F - \u003C\u003C'EOF'\n{subject line}\n\n{body}\nEOF\n```\n\nIf the `short` argument was passed (Step 2), the heredoc contains only `{subject line}` —\nomit the blank line and body.\n\nCheck the command's exit code:\n\n- **Non-zero exit** (for example a pre-commit hook rejected the commit): the commit did\n  **not** happen. Undo Step 6.5 entirely — under `{workDocDir}\u002F.progress\u002F.lock` again, re-reading each file\n  first and restoring only the two fields it wrote, each to the value kept in memory from before\n  Step 6.5 (`pipeline.fix.round`; `pipeline.verification.committed` — removed only where Step 6.5\n  added it, a mark an earlier commit set stays; the verification was not consumed and the fix\n  cycle did not end), re-staging the same files Step 6.5 re-staged. Show the command's output to the user verbatim, explain that no commit\n  was created, and **stop** — do not proceed to Step 8.\n- **Zero exit**: proceed to Step 8.\n\n### Step 8: Report\n\nOnly report a commit after Step 7 exited zero. Get the actual hash from the repository —\nnever assume or construct it:\n\n```bash\ngit rev-parse --short HEAD\n```\n\nReport using the hash this command printed:\n\n> \"Committed: `{short hash from git rev-parse output}` {subject line}\"\n\n### Constraints\n\n- **Never run `git add`** on a path the user has not staged -- only operate on already-staged changes (Step 6.5 refreshes an already-staged progress file, nothing else)\n- **Never add to or remove from the staging area** -- the user controls what is staged\n- If the diff is too large to summarize in 50 characters, focus on the primary change\n","# Smart Commit\n\nCreate a git commit from already-staged changes with a validated commit message following project conventions.\n\n## Instructions\n\n### Step 0: Validate Configuration\n\n1. Read `.claude\u002Fbackend-webflux-plugin.json`\n2. If missing, tell the user to run `\u002Fbackend-webflux-plugin:be-init` first and stop\n3. `pluginRoot`: the one line of `${CLAUDE_CONFIG_DIR:-$HOME\u002F.claude}\u002Fplugins\u002Fdata\u002Fbackend-webflux-plugin\u002FpluginRoot` (plugin CLAUDE.md § Configuration) — every `templates\u002F…` path in this document is `{pluginRoot}\u002Ftemplates\u002F…`; missing → stop: start a new session so the hook writes it.\n\n### Step 1: Check Staged Changes\n\nRun `git diff --staged` to see what is staged.\n\n- If nothing is staged, inform the user:\n  > \"No staged changes found. Stage your changes with `git add` first.\"\n- Stop if nothing is staged\n\n### Step 1.5: Pipeline Status Warning\n\nCheck if any feature progress files exist in `{workDocDir}\u002F.progress\u002F`:\n\n1. Glob `{workDocDir}\u002F.progress\u002F*.json` — exclude files matching `review-report-*.json` or `fix-report-*.json` (only keep entity progress files)\n2. For each progress file, read `pipeline.status`\n3. If any feature has a status other than `reviewed` or `done` (i.e., `scaffolded`, `implementing`, `implemented`, `verified`, `verify-failed`, `review-failed`, `fixing`, `resolved`, `escalated`):\n   > \"Warning: Feature '{feature}' is in '{status}' status — review\u002Fverification may not be complete.\"\n   > \"Continue with commit?\"\n   If the user declines, stop here.\n4. Compute `{pluginRoot}\u002Fscripts\u002Fsource-tree-hash.sh --staged` once — the index is what this commit will contain (exit 0 and a 40-hex id, else a tooling error: report it and stop — an empty value must not be compared). For each `reviewed`\u002F`done` feature that has not been committed since it was verified (`pipeline.verification.committed` is not `true`; Step 6.5 sets it), it must equal `pipeline.verification.tree`; different (or the field missing) — an unstaged edit, an untracked new file, or a change made after `be-verify` ran:\n   > \"Warning: the staged tree is not the tree feature '{feature}' was verified on — the review describes different code. Stage everything under src\u002F and the build files, or re-run be-verify and be-review.\"\n   > \"Continue with commit?\"\n   If the user declines, stop here. A feature already committed on the tree it was verified on is not re-checked: later tickets change the tree without invalidating its record.\n5. If all features are `reviewed`, `done` with a matching (or already committed) tree, or no progress files exist: proceed without warning\n\n### Step 2: Parse Arguments\n\n- `topic: \u003Ctopic>` -- optional topic hint for the commit message (inferred from diff if omitted)\n- `short` -- if present, generate subject line only (skip body)\n\n### Step 3: Security Scan\n\nRun `{pluginRoot}\u002Fscripts\u002Fpre-commit-check.sh security` to scan staged changes for secrets and dangerous files (the scan is not optional).\n\n- If the script reports issues, show the findings and **abort the commit**\n- Do not proceed to message drafting until the security scan passes\n\n### Step 4: Analyze Changes\n\nFrom the staged diff, determine:\n\n1. Which files were changed, added, or deleted\n2. The nature of the change: new feature, enhancement, bug fix, refactoring, test, configuration\n3. The domain\u002Fmodule affected\n4. If a topic hint was provided, use it to guide the message focus\n\n### Step 5: Draft Commit Message\n\nFollow CLAUDE.md commit standards:\n\n1. **Subject line** (mandatory):\n   - English, present tense, imperative mood (\"Add\", \"Fix\", \"Update\", not \"Added\", \"Fixes\")\n   - Maximum 50 characters\n   - Start with uppercase letter (exception: lowercase identifiers like function names)\n   - No prefix (no `fix:`, `feat:`, `docs:`, etc.)\n   - Focus on \"why\" rather than \"what\"\n\n2. **Body** (skip if `short` argument):\n   - Blank line after subject\n   - Maximum 72 characters per line\n   - Only break within paragraphs when exceeding 72 characters\n   - Describe the motivation and context\n   - Do not mention test code\n   - Do not list file names\n   - Do not include tool advertisements or branding\n\n**Worked example 1 — new feature:**\n\nStaged diff summary: adds `command\u002FCreateEmployee.java`, `commandmodel\u002FCreateEmployeeCommandExecutor.java`, `domain\u002Fapi\u002FEmployeeRouter.java`; wires a new `POST \u002Fhr\u002Femployees` route.\n\n```\nAdd employee creation endpoint\n\nIntroduce the command executor and router wiring needed to\ncreate an employee via POST \u002Fhr\u002Femployees. The executor\nvalidates the email is unique before persisting, matching the\nduplicate-check pattern used by the existing customer domain.\n```\n\n**Worked example 2 — bug fix, with an edge case:**\n\nStaged diff summary: changes `data\u002FEmployeeRepository.java` and `commandmodel\u002FUpdateEmployeeCommandExecutor.java` only — a one-line fix plus a null check. Small diffs are still expected to explain *why*, not just restate the diff:\n\n```\nFix duplicate-email race on concurrent update\n\nTwo concurrent updates to the same email could both pass the\nuniqueness check before either write committed. Wrap the check\nand update in TransactionalOperator so the second writer sees\nthe first writer's row and fails the uniqueness constraint\ninstead of silently overwriting it.\n```\n\nEdge case: if the diff is a one-line change with no obvious \"why\" recoverable from the diff alone (e.g. a config value bump), keep the body short rather than inventing a rationale — a single sentence stating what changed and, if known from the topic hint, why is acceptable; never fabricate a motivation the diff doesn't support.\n\n### Step 6: Validate\n\nCheck the draft message against commit message rules from CLAUDE.md:\n\n- [ ] English (#1)\n- [ ] Present tense imperative (#2)\n- [ ] Subject \u003C= 50 characters (#3)\n- [ ] Blank line between subject and body (#4)\n- [ ] Body lines \u003C= 72 characters (#5)\n- [ ] Only break within a paragraph when exceeding 72 characters (#6)\n- [ ] No test code mentions (#7)\n- [ ] No prefix (fix:, feat:, docs:, etc.) (#8)\n- [ ] Starts with uppercase (or justified lowercase identifier) (#9)\n- [ ] No branding\u002Fpromotional content (#10)\n\nIf validation fails, revise the message.\n\nNote: CLAUDE.md rules #11-13 (staged-only, ensure staging, separate git commands) are workflow constraints enforced in Step 1 and the Constraints section, not message format rules.\n\n### Step 6.5: Close the Fix Cycle\n\nBefore the commit, for every feature progress file whose status is `reviewed` or `done`, set\n`pipeline.fix.round` to `0` — and, when its `pipeline.verification.tree` equals the staged hash Step 1.5\ncomputed, `pipeline.verification.committed` to `true` (this commit consumes that verification; Step 1.5\nstops comparing it to later trees) — (read-modify-write, preserving everything else) under\n`{workDocDir}\u002F.progress\u002F.lock` (`operation: be-commit`, a fresh `runId`), taken and released (per CLAUDE.md § State File Safety) around the writes exactly as every other\nprogress-file writer does (CLAUDE.md § State File Safety); if the lock is held by a live operation,\nskip the reset and say so rather than wait. The counter bounds fix attempts within one review cycle;\na commit ends that cycle. Left as is, a feature committed at `reviewed` with `round: 2` makes the\nnext ticket's first `be-fix` round 3 — and `be-fix` Step 3 blocks on a prompt an unattended\n`be-jira-auto` run cannot answer.\n\nThis runs before Step 7, not after: a progress file that is tracked and staged would otherwise be\ncommitted with the old round and dirty again the moment the commit lands. For such a file — listed by\n`git diff --cached --name-only` and, before this step's write, carrying no unstaged edit\n(`git diff --quiet -- {file}`) — refresh its staged copy with `git add -- {file}`: the one `git add`\nthis skill makes, on a path the user already staged, adding only this step's own fields. A tracked\nbut unstaged progress file, or one that had unstaged edits of the user's, stays as it was (say so).\n\n### Step 7: Execute Commit\n\nA multi-paragraph body passed via `-m \"{message}\"` is fragile (shell quoting can mangle or\ntruncate it). Pass the drafted message through stdin with `git commit -F -` inside a\nheredoc instead:\n\n```bash\ngit commit -F - \u003C\u003C'EOF'\n{subject line}\n\n{body}\nEOF\n```\n\nIf the `short` argument was passed (Step 2), the heredoc contains only `{subject line}` —\nomit the blank line and body.\n\nCheck the command's exit code:\n\n- **Non-zero exit** (for example a pre-commit hook rejected the commit): the commit did\n  **not** happen. Undo Step 6.5 entirely — under `{workDocDir}\u002F.progress\u002F.lock` again, re-reading each file\n  first and restoring only the two fields it wrote, each to the value kept in memory from before\n  Step 6.5 (`pipeline.fix.round`; `pipeline.verification.committed` — removed only where Step 6.5\n  added it, a mark an earlier commit set stays; the verification was not consumed and the fix\n  cycle did not end), re-staging the same files Step 6.5 re-staged. Show the command's output to the user verbatim, explain that no commit\n  was created, and **stop** — do not proceed to Step 8.\n- **Zero exit**: proceed to Step 8.\n\n### Step 8: Report\n\nOnly report a commit after Step 7 exited zero. Get the actual hash from the repository —\nnever assume or construct it:\n\n```bash\ngit rev-parse --short HEAD\n```\n\nReport using the hash this command printed:\n\n> \"Committed: `{short hash from git rev-parse output}` {subject line}\"\n\n### Constraints\n\n- **Never run `git add`** on a path the user has not staged -- only operate on already-staged changes (Step 6.5 refreshes an already-staged progress file, nothing else)\n- **Never add to or remove from the staging area** -- the user controls what is staged\n- If the diff is too large to summarize in 50 characters, focus on the primary change\n",{"name":43,"description":44,"allowed-tools":45,"argument-hint":46,"user-invocable":47},"be-commit","Create a commit from staged changes with validated message.","Read, Edit, Write, Glob, Bash","[topic: \u003Chint>] [short]",true,"main","99f07e592261c66756a2927d0440fc5fef950507",".claude\u002Fskills\u002Fecc\u002Fparallel-execution-optimizer","https:\u002F\u002Fgithub.com\u002Fsakamoto-family-smile\u002Fagent_monorepo","https:\u002F\u002Fgithub.com\u002Fsakamoto-family-smile","2026-11-08 20:29:14",{"source":8,"skillName":43,"commands":55,"prompt":65,"zipAvailable":47},[56,59,62],{"tool":57,"command":58},"npx","npx skills add sakamoto-family-smile\u002Fagent_monorepo --skill be-commit",{"tool":60,"command":61},"bunx","bunx skills add sakamoto-family-smile\u002Fagent_monorepo --skill be-commit",{"tool":63,"command":64},"pnpm","pnpm dlx skills add sakamoto-family-smile\u002Fagent_monorepo --skill be-commit","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fsakamoto-family-smile\u002Fagent_monorepo\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fecc\u002Fparallel-execution-optimizer\u002FSKILL.md",[],[68,103,111,131,154,181],{"skillNo":69,"name":70,"nameZh":6,"description":71,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":72,"categories":73,"keywords":82,"publishedAt":38},"01M6RW50THEFSKK42YNR8XFZA1","remotion-video-creation","Best practices for Remotion - Video creation in React. 29 domain-specific rules covering 3D, animations, audio, captions, charts, transitions, and more.","https:\u002F\u002Fgithub.com\u002Fsakamoto-family-smile\u002Fagent_monorepo\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fecc\u002Fremotion-video-creation\u002FSKILL.md",[74,79],{"categoryNo":75,"categoryName":76,"taxonomyType":77,"taxonomyTypeDesc":78},"01JBSEEDCAT000000000000009","前端开发","SCENARIO","使用场景",{"categoryNo":80,"categoryName":81,"taxonomyType":77,"taxonomyTypeDesc":78},"01JBSEEDCAT000000000000016","图像与多媒体",[83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102],"Video","remotion video","remotion video creation","creation","Remotion","Charts","Captions","Audio","3D","Composition","Animation","best practices","more","animations","domain-specific","domain","three","Rules","Lottie","for",{"skillNo":104,"name":105,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":106,"categories":107,"keywords":108,"publishedAt":38},"01M6VCJ23NPECPSZJKGY691F75","hotcook-recipes","https:\u002F\u002Fgithub.com\u002Fsakamoto-family-smile\u002Fagent_monorepo\u002Fblob\u002Fmain\u002Fhotcook-agent\u002Fdata\u002Fskills\u002Fhotcook-recipes\u002FSKILL.md",[],[109,110],"hotcook recipes","recipes",{"skillNo":112,"name":113,"nameZh":6,"description":114,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":115,"categories":116,"keywords":125,"publishedAt":38},"01M6VCHHE00X5XHSDRD1KH1BW2","code-helper","Code review and assistance skill","https:\u002F\u002Fgithub.com\u002Fsakamoto-family-smile\u002Fagent_monorepo\u002Fblob\u002Fmain\u002Fagent-system-2\u002Fskills\u002Fcode-helper\u002Fskill.md",[117,120],{"categoryNo":118,"categoryName":119,"taxonomyType":77,"taxonomyTypeDesc":78},"01JBSEEDCAT000000000000007","代码审查",{"categoryNo":121,"categoryName":122,"taxonomyType":123,"taxonomyTypeDesc":124},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[126,127,128,129,130],"code helper","helper","code","code review","review",{"skillNo":132,"name":133,"nameZh":6,"description":134,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":135,"categories":136,"keywords":143,"publishedAt":38},"01M6VCH3Q31A20H6SQ1H0J7JB2","research-assistant","Web research assistant skill using Brave Search MCP","https:\u002F\u002Fgithub.com\u002Fsakamoto-family-smile\u002Fagent_monorepo\u002Fblob\u002Fmain\u002Fagent-system-1\u002Fskills\u002Fresearch-assistant\u002Fskill.md",[137,140],{"categoryNo":138,"categoryName":139,"taxonomyType":77,"taxonomyTypeDesc":78},"01JBSEEDCAT000000000000021","资料检索与研究",{"categoryNo":141,"categoryName":142,"taxonomyType":77,"taxonomyTypeDesc":78},"01JBSEEDCAT000000000000023","Skill与智能体开发",[144,145,146,147,148,149,150,151,152,153],"research assistant","research","assistant","MCP","web","search","brave search","web research","brave","web research assistant",{"skillNo":155,"name":156,"nameZh":6,"description":157,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":158,"categories":159,"keywords":164,"publishedAt":38},"01M6VCGZZGPNVJSCZ1JTMNZAHY","x-api","X\u002FTwitter API integration for posting tweets, threads, reading timelines, search, and analytics. Covers OAuth auth patterns, rate limits, and platform-native content posting. Use when the user wants to interact with X programmatically.","https:\u002F\u002Fgithub.com\u002Fsakamoto-family-smile\u002Fagent_monorepo\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fecc\u002Fx-api\u002FSKILL.md",[160,163],{"categoryNo":161,"categoryName":162,"taxonomyType":77,"taxonomyTypeDesc":78},"01JBSEEDCAT000000000000010","后端与接口",{"categoryNo":121,"categoryName":122,"taxonomyType":123,"taxonomyTypeDesc":124},[165,166,167,23,168,169,102,170,171,172,173,174,175,176,177,32,178,179,149,180],"x api","api","with","limits","rate","threads","reading","native","posting","platform","patterns","api integration","twitter","auth","analytics","OAuth",{"skillNo":182,"name":183,"nameZh":6,"description":184,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":185,"categories":186,"keywords":188,"publishedAt":38},"01M6VCGVX6DGB1FKTA53QBBCQB","workspace-surface-audit","Audit the active repo, MCP servers, plugins, connectors, env surfaces, and harness setup, then recommend the highest-value ECC-native skills, hooks, agents, and operator workflows. Use when the user wants help setting up Claude Code or understanding what capabilities are actually available in their environment.","https:\u002F\u002Fgithub.com\u002Fsakamoto-family-smile\u002Fagent_monorepo\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fecc\u002Fworkspace-surface-audit\u002FSKILL.md",[187],{"categoryNo":141,"categoryName":142,"taxonomyType":77,"taxonomyTypeDesc":78},[189,190,191,192,147,193,194,128,195,196,197,198,32,199,200,201,202,172,203,23],"workspace surface audit","workspace","audit","hooks","workflows","connectors","capabilities","harness","repo","environment","up","harness setup","active","env","value"]