[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6CWJJ0ZXMQRDPC3M4BP76QC":3,"skill-same:01M6CWJJ0ZXMQRDPC3M4BP76QC":140},{"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":23,"publishedAt":38,"linkOnly":39,"markdownContent":40,"markdownBody":41,"frontMatter":42,"refName":44,"commitSha":45,"skillDirectory":46,"forksCount":47,"repositoryHtmlUrl":48,"repositoryHomepageUrl":49,"ownerHtmlUrl":50,"ownerBlogUrl":6,"ownerDescription":51,"updatedAt":52,"install":53,"resources":66},"01M6CWJJ0ZXMQRDPC3M4BP76QC","spec-simplify-code",null,"Simplify recently changed code for clarity, reuse, quality, and efficiency while preserving behavior. Use for tidy\u002Frefactor passes; use spec-debug for bugs. Not for new features or behavior changes.","leo-kuang-ai\u002Fspec-first","leo-kuang-ai","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F8476392?v=4","01M6CWDM2YRT5M8C3G3QC3YGR5","leokuang","01M6CWDM6X46EFBXT1M1GDB5XC",111,"MIT","https:\u002F\u002Fgithub.com\u002Fleo-kuang-ai\u002Fspec-first\u002Fblob\u002Fmaster\u002Fskills\u002Fspec-simplify-code\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[24,25,26,27,28,29,30,31,32,33,34,35,36,37],"spec","code","simplify","simplify code","spec simplify code","debug","refactor","tidy","clarity","quality","branch","behavior","use","efficiency","2026-11-10 10:12:30",false,"---\nname: spec-simplify-code\ndescription: \"Simplify recently changed code for clarity, reuse, quality, and efficiency while preserving behavior. Use for tidy\u002Frefactor passes; use spec-debug for bugs. Not for new features or behavior changes.\"\nargument-hint: \"[blank to simplify current branch changes, or describe what to simplify]\"\n---\n\nSimplify recently changed code for clarity, reuse, quality, and efficiency while preserving exact behavior. Prioritize readable, explicit code over compact code — fewer lines is not the goal.\n\n## Step 1: Identify scope\n\n**Not-a-simplification input first.** A request that reports broken behavior — a crash, a failing test, wrong output — is a bug, not a simplification pass. Do not fix the bug here. Name `spec-debug` in the reply and route out; the caller can return for a behavior-preserving cleanup after the fix lands.\n\nResolve the simplification scope in this order:\n\n1. **If the user explicitly named a scope** (a file, a directory, \"the function I just wrote\", \"the changes from this morning\"), use that scope. Treat user-named scope as authoritative — do not widen it.\n2. **Otherwise, in a git repository**, default to the diff between the current branch and its base branch (e.g., `git diff origin\u002Fmain...` or against the configured upstream). This covers the common case of \"simplify everything I've added on this feature branch before opening a PR.\" If the branch has no upstream or base ref, fall back to staged + unstaged changes (`git diff HEAD`).\n3. **Outside a git repository or when no diff is available**, review the most recently modified files mentioned by the user or edited earlier in this conversation.\n\nIf none of the above produces a non-empty scope, stop and ask the user what to simplify rather than guessing. Use the platform's blocking question tool: `AskUserQuestion` in Claude Code (call `ToolSearch` with `select:AskUserQuestion` first if its schema isn't loaded), `request_user_input` in Codex. Fall back to numbered options in chat only when no blocking tool exists in the harness or the call errors (e.g., Codex edit modes) — not because a schema load is required. Never silently skip the question.\n\n**Preflight — skip a no-yield scope before loading review lenses.** If the\nresolved scope contains no substantive human-authored code and consists only\nof documentation\u002FMarkdown, generated or vendored files, dependency\u002Flockfiles,\nor purely mechanical formatting, lint, or mass-rename churn, stop with a\none-line `nothing to simplify` result. On a mixed diff, narrow the scope to the\nsubstantive code files. This is a change-kind gate, not a size threshold, and\nit never widens beyond caller-authorized paths.\n\nWhen the caller provides a plan as context, the plan is not additional\nsimplification scope. Preserve any `session-settled:` structural decisions:\ndeliberately separate implementations or duplicated package-local runtime\nassets remain separate even when consolidation would otherwise look cleaner.\n\n## Step 2: Run 3 review lenses\n\n在派发 reviewer 前记录：\n\n```yaml\nworker_dispatch_authorization: authorized | missing\ncapability_probe: not_applicable | attempted | unavailable\nworker_dispatch_capability: available | missing | unknown\nworker_context_isolation: isolated | inherited | unknown\nworker_model_override: supported | unsupported | unknown\nworker_bounded_parallelism: supported | unsupported | unknown\n```\n\n`workflow invocation does not authorize dispatch`。只有当前用户或可见 upstream handoff 明确请求 subagent、delegated work、persona 或 parallel work 时，才可把三个 review lens 派发给 generic workers。缺授权时不得探测 tool schema，固定为 `capability_probe: not_applicable` + `worker_dispatch_capability: unknown`，inline 或 serial 执行全部三个 lens 并记录 `dispatch_authorization_missing`。只有授权后才把 current-session registry\u002Fschema 作为 `provider_untrusted` evidence 检查：确认缺失时记录 `subagent_capability_missing`；surface 不可用、schema 不完整或候选不唯一时记录 `worker_capability_unproven`，均 inline 或 serial。隔离、模型覆盖和有界并发只取 live facts；required isolation 未满足时保持依赖 gate 打开，model unknown 时继承，parallelism unknown 时串行。记录 `worker_dispatch_outcome`。Inline fallback 保留三个 rubric 的完整覆盖，但不得声称三个 independent reviewers 或 multi-agent coverage。\n\nWhen authorization is present and the current-session semantic probe yields one eligible generic worker candidate, dispatch three bounded workers — code-reuse, code-quality, and efficiency reviewers. Otherwise run the reviews inline or serially. For each reviewer or inline lens, read its prompt asset from this skill's directory and use the **full file content** together with the resolved scope (the full diff or file set) so the review has complete context:\n\n- `references\u002Fpersonas\u002Fcode-reuse-reviewer.md` — existing utilities, duplicated functionality, reimplemented stdlib\u002Fruntime primitives.\n- `references\u002Fpersonas\u002Fcode-quality-reviewer.md` — redundant state, parameter sprawl, copy-paste, leaky abstractions, stringly-typed code, dead code, over-nesting, and the over-simplification balance guard.\n- `references\u002Fpersonas\u002Fefficiency-reviewer.md` — unnecessary work, missed concurrency, hot-path bloat, no-op updates, memory leaks.\n\nDo not paraphrase these rubrics from memory — read each file and pass it verbatim, or the reviewer loses the gating rules that keep the pass behavior-preserving.\n\n**Bounded dispatch.** When dispatch is authorized and available, queue the three reviewers and launch only as many as the harness accepts at once; treat a concurrency\u002Factive-agent-limit error as backpressure (leave the reviewer queued and retry after a slot frees), not as reviewer failure. Inline fallback runs the lenses serially when shared context or edit overlap makes concurrency unsafe.\n\n**Model selection.** Request the balanced mid-tier only when `worker_model_override: supported` and the current schema exposes an explicit selector. Otherwise omit the override, inherit the parent model, and record `model_override_unsupported` or `model_override_unknown` as applicable; task wording alone does not select a different model.\n\n**Permission mode.** For an authorized dispatch, omit the `mode` parameter so the user's configured permission settings apply. Permission settings are execution conditions, not dispatch authorization.\n\n## Step 3: Fix issues\n\nComplete all three review lenses, whether dispatched or inline. Aggregate their findings and fix each issue directly. If a finding is a false positive or not worth addressing, note it and move on. Do not argue with the finding or raise questions to the user, just skip it.\n\nBefore applying each fix, confirm it preserves behavior: same output for every input, same error behavior, and same side effects and ordering. If a fix can't clear that test, skip it — automated checks in Step 4 don't cover every behavior.\n\n**Never simplify away a safety check.** Input validation at trust boundaries, error handling that prevents data loss, security checks (authorization, escaping, sanitization), and accessibility affordances are not removable boilerplate — preserve them even when a finding frames them as redundant or inline-able. Code that drops one of these is not simpler, it is unfinished. If a proposed simplification would thin or remove one, skip it.\n\n## Step 4: Verify behavior is preserved\n\nThe premise of this skill is that simplification preserves exact functionality. After applying fixes:\n\n**Run typecheck and lint over the full project.** They are usually fast and catch the most common simplification regressions — broken imports, unused exports, dropped type narrowings, dead code other modules still reference.\n\n**Run tests:**\n- Run tests scoped to the changed paths. CI runs the full suite on PR — this local check is a fast signal, not the final guarantee. Match scope to blast radius; a 3-line simplification doesn't warrant a 20-minute test run.\n- Broaden scope when the change has obvious wide reach — e.g., a heavily-imported utility was rewritten, or the code-quality reviewer's consolidation\u002Fdedup fixes modified shared code. This is a judgment call about ripple risk, not a mechanical rule.\n- If the test runner has no scoping mechanism, run the full suite.\n\nSurface any failure clearly with the failing check name and the relevant output. Do not relax assertions, weaken type signatures, or skip tests to make checks pass — that defeats the \"preserves functionality\" guarantee. Either fix the underlying break introduced by simplification, or revert the specific change that caused the regression.\n\nIf no test suite, lint, or typecheck is configured, state that explicitly in the summary; do not silently skip verification.\n\n## Step 5: Summarize\n\nBriefly summarize what was good vs improved and fixed, including which checks were run and their results. If there were no findings to act on, confirm the code didn't require any changes.\n\n**Quantify the impact by dimension.** Report what was actually applied, not a line count: fixes applied per reviewer dimension (reuse, quality, efficiency), how many findings were skipped as false-positive or not worth addressing, and the behavior-preservation result (checks run and outcome). For example: \"Applied 6 — reuse 2, quality 3, efficiency 1; skipped 2 false positives; typecheck + lint clean, 11 scoped tests pass.\" Do not headline a net-lines-removed figure or frame fewer lines as the win — many clarity, safety, and efficiency fixes preserve or add lines. The measure is what improved and that behavior held, not how much code shrank.\n","Simplify recently changed code for clarity, reuse, quality, and efficiency while preserving exact behavior. Prioritize readable, explicit code over compact code — fewer lines is not the goal.\n\n## Step 1: Identify scope\n\n**Not-a-simplification input first.** A request that reports broken behavior — a crash, a failing test, wrong output — is a bug, not a simplification pass. Do not fix the bug here. Name `spec-debug` in the reply and route out; the caller can return for a behavior-preserving cleanup after the fix lands.\n\nResolve the simplification scope in this order:\n\n1. **If the user explicitly named a scope** (a file, a directory, \"the function I just wrote\", \"the changes from this morning\"), use that scope. Treat user-named scope as authoritative — do not widen it.\n2. **Otherwise, in a git repository**, default to the diff between the current branch and its base branch (e.g., `git diff origin\u002Fmain...` or against the configured upstream). This covers the common case of \"simplify everything I've added on this feature branch before opening a PR.\" If the branch has no upstream or base ref, fall back to staged + unstaged changes (`git diff HEAD`).\n3. **Outside a git repository or when no diff is available**, review the most recently modified files mentioned by the user or edited earlier in this conversation.\n\nIf none of the above produces a non-empty scope, stop and ask the user what to simplify rather than guessing. Use the platform's blocking question tool: `AskUserQuestion` in Claude Code (call `ToolSearch` with `select:AskUserQuestion` first if its schema isn't loaded), `request_user_input` in Codex. Fall back to numbered options in chat only when no blocking tool exists in the harness or the call errors (e.g., Codex edit modes) — not because a schema load is required. Never silently skip the question.\n\n**Preflight — skip a no-yield scope before loading review lenses.** If the\nresolved scope contains no substantive human-authored code and consists only\nof documentation\u002FMarkdown, generated or vendored files, dependency\u002Flockfiles,\nor purely mechanical formatting, lint, or mass-rename churn, stop with a\none-line `nothing to simplify` result. On a mixed diff, narrow the scope to the\nsubstantive code files. This is a change-kind gate, not a size threshold, and\nit never widens beyond caller-authorized paths.\n\nWhen the caller provides a plan as context, the plan is not additional\nsimplification scope. Preserve any `session-settled:` structural decisions:\ndeliberately separate implementations or duplicated package-local runtime\nassets remain separate even when consolidation would otherwise look cleaner.\n\n## Step 2: Run 3 review lenses\n\n在派发 reviewer 前记录：\n\n```yaml\nworker_dispatch_authorization: authorized | missing\ncapability_probe: not_applicable | attempted | unavailable\nworker_dispatch_capability: available | missing | unknown\nworker_context_isolation: isolated | inherited | unknown\nworker_model_override: supported | unsupported | unknown\nworker_bounded_parallelism: supported | unsupported | unknown\n```\n\n`workflow invocation does not authorize dispatch`。只有当前用户或可见 upstream handoff 明确请求 subagent、delegated work、persona 或 parallel work 时，才可把三个 review lens 派发给 generic workers。缺授权时不得探测 tool schema，固定为 `capability_probe: not_applicable` + `worker_dispatch_capability: unknown`，inline 或 serial 执行全部三个 lens 并记录 `dispatch_authorization_missing`。只有授权后才把 current-session registry\u002Fschema 作为 `provider_untrusted` evidence 检查：确认缺失时记录 `subagent_capability_missing`；surface 不可用、schema 不完整或候选不唯一时记录 `worker_capability_unproven`，均 inline 或 serial。隔离、模型覆盖和有界并发只取 live facts；required isolation 未满足时保持依赖 gate 打开，model unknown 时继承，parallelism unknown 时串行。记录 `worker_dispatch_outcome`。Inline fallback 保留三个 rubric 的完整覆盖，但不得声称三个 independent reviewers 或 multi-agent coverage。\n\nWhen authorization is present and the current-session semantic probe yields one eligible generic worker candidate, dispatch three bounded workers — code-reuse, code-quality, and efficiency reviewers. Otherwise run the reviews inline or serially. For each reviewer or inline lens, read its prompt asset from this skill's directory and use the **full file content** together with the resolved scope (the full diff or file set) so the review has complete context:\n\n- `references\u002Fpersonas\u002Fcode-reuse-reviewer.md` — existing utilities, duplicated functionality, reimplemented stdlib\u002Fruntime primitives.\n- `references\u002Fpersonas\u002Fcode-quality-reviewer.md` — redundant state, parameter sprawl, copy-paste, leaky abstractions, stringly-typed code, dead code, over-nesting, and the over-simplification balance guard.\n- `references\u002Fpersonas\u002Fefficiency-reviewer.md` — unnecessary work, missed concurrency, hot-path bloat, no-op updates, memory leaks.\n\nDo not paraphrase these rubrics from memory — read each file and pass it verbatim, or the reviewer loses the gating rules that keep the pass behavior-preserving.\n\n**Bounded dispatch.** When dispatch is authorized and available, queue the three reviewers and launch only as many as the harness accepts at once; treat a concurrency\u002Factive-agent-limit error as backpressure (leave the reviewer queued and retry after a slot frees), not as reviewer failure. Inline fallback runs the lenses serially when shared context or edit overlap makes concurrency unsafe.\n\n**Model selection.** Request the balanced mid-tier only when `worker_model_override: supported` and the current schema exposes an explicit selector. Otherwise omit the override, inherit the parent model, and record `model_override_unsupported` or `model_override_unknown` as applicable; task wording alone does not select a different model.\n\n**Permission mode.** For an authorized dispatch, omit the `mode` parameter so the user's configured permission settings apply. Permission settings are execution conditions, not dispatch authorization.\n\n## Step 3: Fix issues\n\nComplete all three review lenses, whether dispatched or inline. Aggregate their findings and fix each issue directly. If a finding is a false positive or not worth addressing, note it and move on. Do not argue with the finding or raise questions to the user, just skip it.\n\nBefore applying each fix, confirm it preserves behavior: same output for every input, same error behavior, and same side effects and ordering. If a fix can't clear that test, skip it — automated checks in Step 4 don't cover every behavior.\n\n**Never simplify away a safety check.** Input validation at trust boundaries, error handling that prevents data loss, security checks (authorization, escaping, sanitization), and accessibility affordances are not removable boilerplate — preserve them even when a finding frames them as redundant or inline-able. Code that drops one of these is not simpler, it is unfinished. If a proposed simplification would thin or remove one, skip it.\n\n## Step 4: Verify behavior is preserved\n\nThe premise of this skill is that simplification preserves exact functionality. After applying fixes:\n\n**Run typecheck and lint over the full project.** They are usually fast and catch the most common simplification regressions — broken imports, unused exports, dropped type narrowings, dead code other modules still reference.\n\n**Run tests:**\n- Run tests scoped to the changed paths. CI runs the full suite on PR — this local check is a fast signal, not the final guarantee. Match scope to blast radius; a 3-line simplification doesn't warrant a 20-minute test run.\n- Broaden scope when the change has obvious wide reach — e.g., a heavily-imported utility was rewritten, or the code-quality reviewer's consolidation\u002Fdedup fixes modified shared code. This is a judgment call about ripple risk, not a mechanical rule.\n- If the test runner has no scoping mechanism, run the full suite.\n\nSurface any failure clearly with the failing check name and the relevant output. Do not relax assertions, weaken type signatures, or skip tests to make checks pass — that defeats the \"preserves functionality\" guarantee. Either fix the underlying break introduced by simplification, or revert the specific change that caused the regression.\n\nIf no test suite, lint, or typecheck is configured, state that explicitly in the summary; do not silently skip verification.\n\n## Step 5: Summarize\n\nBriefly summarize what was good vs improved and fixed, including which checks were run and their results. If there were no findings to act on, confirm the code didn't require any changes.\n\n**Quantify the impact by dimension.** Report what was actually applied, not a line count: fixes applied per reviewer dimension (reuse, quality, efficiency), how many findings were skipped as false-positive or not worth addressing, and the behavior-preservation result (checks run and outcome). For example: \"Applied 6 — reuse 2, quality 3, efficiency 1; skipped 2 false positives; typecheck + lint clean, 11 scoped tests pass.\" Do not headline a net-lines-removed figure or frame fewer lines as the win — many clarity, safety, and efficiency fixes preserve or add lines. The measure is what improved and that behavior held, not how much code shrank.\n",{"name":5,"description":7,"argument-hint":43},"[blank to simplify current branch changes, or describe what to simplify]","master","74655dc86b1270bb52239e0f8bc9517de7a7071c","skills\u002Fspec-simplify-code",13,"https:\u002F\u002Fgithub.com\u002Fleo-kuang-ai\u002Fspec-first","http:\u002F\u002Fspec-first.cn\u002F","https:\u002F\u002Fgithub.com\u002Fleo-kuang-ai","作为一个初学者或者进阶者，这并没有什么错。当一个有能力的程序员而不是领导者，这也没有什么错。真正的错误是，当你知道应该如何去提高时仍然选择做一名初学者。","2026-11-05 13:30:55",{"source":8,"skillName":5,"commands":54,"prompt":64,"zipAvailable":65},[55,58,61],{"tool":56,"command":57},"npx","npx skills add leo-kuang-ai\u002Fspec-first --skill spec-simplify-code",{"tool":59,"command":60},"bunx","bunx skills add leo-kuang-ai\u002Fspec-first --skill spec-simplify-code",{"tool":62,"command":63},"pnpm","pnpm dlx skills add leo-kuang-ai\u002Fspec-first --skill spec-simplify-code","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fleo-kuang-ai\u002Fspec-first\u002Fblob\u002Fmaster\u002Fskills\u002Fspec-simplify-code\u002FSKILL.md",true,[67,73,77,81,84,88,92,96,102,105,108,112,116,120,124,128,132,136],{"path":68,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":71,"sourceHtmlUrl":72},"evals\u002Fcases\u002Fbug-request-routes-debug.yaml","REFERENCE","参考文档",581,"https:\u002F\u002Fgithub.com\u002Fleo-kuang-ai\u002Fspec-first\u002Fblob\u002Fmaster\u002Fskills\u002Fspec-simplify-code\u002Fevals\u002Fcases\u002Fbug-request-routes-debug.yaml",{"path":74,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":75,"sourceHtmlUrl":76},"evals\u002Fcases\u002Fdocs-only-no-yield.yaml",770,"https:\u002F\u002Fgithub.com\u002Fleo-kuang-ai\u002Fspec-first\u002Fblob\u002Fmaster\u002Fskills\u002Fspec-simplify-code\u002Fevals\u002Fcases\u002Fdocs-only-no-yield.yaml",{"path":78,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":79,"sourceHtmlUrl":80},"evals\u002Fcases\u002Fr2-elegant-refactor.yaml",717,"https:\u002F\u002Fgithub.com\u002Fleo-kuang-ai\u002Fspec-first\u002Fblob\u002Fmaster\u002Fskills\u002Fspec-simplify-code\u002Fevals\u002Fcases\u002Fr2-elegant-refactor.yaml",{"path":82,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":79,"sourceHtmlUrl":83},"evals\u002Fcases\u002Fsafety-check-preserved.yaml","https:\u002F\u002Fgithub.com\u002Fleo-kuang-ai\u002Fspec-first\u002Fblob\u002Fmaster\u002Fskills\u002Fspec-simplify-code\u002Fevals\u002Fcases\u002Fsafety-check-preserved.yaml",{"path":85,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":86,"sourceHtmlUrl":87},"evals\u002Feval.yaml",452,"https:\u002F\u002Fgithub.com\u002Fleo-kuang-ai\u002Fspec-first\u002Fblob\u002Fmaster\u002Fskills\u002Fspec-simplify-code\u002Fevals\u002Feval.yaml",{"path":89,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":90,"sourceHtmlUrl":91},"evals\u002Ffixtures\u002Frepos\u002Fmini-ledger-guarded\u002Fpackage.json",96,"https:\u002F\u002Fgithub.com\u002Fleo-kuang-ai\u002Fspec-first\u002Fblob\u002Fmaster\u002Fskills\u002Fspec-simplify-code\u002Fevals\u002Ffixtures\u002Frepos\u002Fmini-ledger-guarded\u002Fpackage.json",{"path":93,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":94,"sourceHtmlUrl":95},"evals\u002Ffixtures\u002Frepos\u002Fmini-ledger-guarded\u002FREADME.md",365,"https:\u002F\u002Fgithub.com\u002Fleo-kuang-ai\u002Fspec-first\u002Fblob\u002Fmaster\u002Fskills\u002Fspec-simplify-code\u002Fevals\u002Ffixtures\u002Frepos\u002Fmini-ledger-guarded\u002FREADME.md",{"path":97,"resourceType":98,"resourceTypeDesc":99,"sizeBytes":100,"sourceHtmlUrl":101},"evals\u002Ffixtures\u002Frepos\u002Fmini-ledger-guarded\u002Fsrc\u002Fserver.js","SCRIPT","脚本",972,"https:\u002F\u002Fgithub.com\u002Fleo-kuang-ai\u002Fspec-first\u002Fblob\u002Fmaster\u002Fskills\u002Fspec-simplify-code\u002Fevals\u002Ffixtures\u002Frepos\u002Fmini-ledger-guarded\u002Fsrc\u002Fserver.js",{"path":103,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":90,"sourceHtmlUrl":104},"evals\u002Ffixtures\u002Frepos\u002Fmini-ledger\u002Fpackage.json","https:\u002F\u002Fgithub.com\u002Fleo-kuang-ai\u002Fspec-first\u002Fblob\u002Fmaster\u002Fskills\u002Fspec-simplify-code\u002Fevals\u002Ffixtures\u002Frepos\u002Fmini-ledger\u002Fpackage.json",{"path":106,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":94,"sourceHtmlUrl":107},"evals\u002Ffixtures\u002Frepos\u002Fmini-ledger\u002FREADME.md","https:\u002F\u002Fgithub.com\u002Fleo-kuang-ai\u002Fspec-first\u002Fblob\u002Fmaster\u002Fskills\u002Fspec-simplify-code\u002Fevals\u002Ffixtures\u002Frepos\u002Fmini-ledger\u002FREADME.md",{"path":109,"resourceType":98,"resourceTypeDesc":99,"sizeBytes":110,"sourceHtmlUrl":111},"evals\u002Ffixtures\u002Frepos\u002Fmini-ledger\u002Fsrc\u002Fserver.js",665,"https:\u002F\u002Fgithub.com\u002Fleo-kuang-ai\u002Fspec-first\u002Fblob\u002Fmaster\u002Fskills\u002Fspec-simplify-code\u002Fevals\u002Ffixtures\u002Frepos\u002Fmini-ledger\u002Fsrc\u002Fserver.js",{"path":113,"resourceType":98,"resourceTypeDesc":99,"sizeBytes":114,"sourceHtmlUrl":115},"evals\u002Ffixtures\u002Fscripts\u002Fasks-a-question.sh",1232,"https:\u002F\u002Fgithub.com\u002Fleo-kuang-ai\u002Fspec-first\u002Fblob\u002Fmaster\u002Fskills\u002Fspec-simplify-code\u002Fevals\u002Ffixtures\u002Fscripts\u002Fasks-a-question.sh",{"path":117,"resourceType":98,"resourceTypeDesc":99,"sizeBytes":118,"sourceHtmlUrl":119},"evals\u002Ffixtures\u002Fscripts\u002Fcheck-no-yield-scope.sh",503,"https:\u002F\u002Fgithub.com\u002Fleo-kuang-ai\u002Fspec-first\u002Fblob\u002Fmaster\u002Fskills\u002Fspec-simplify-code\u002Fevals\u002Ffixtures\u002Fscripts\u002Fcheck-no-yield-scope.sh",{"path":121,"resourceType":98,"resourceTypeDesc":99,"sizeBytes":122,"sourceHtmlUrl":123},"evals\u002Ffixtures\u002Fscripts\u002Fcheck-r2-safety-stays.sh",405,"https:\u002F\u002Fgithub.com\u002Fleo-kuang-ai\u002Fspec-first\u002Fblob\u002Fmaster\u002Fskills\u002Fspec-simplify-code\u002Fevals\u002Ffixtures\u002Fscripts\u002Fcheck-r2-safety-stays.sh",{"path":125,"resourceType":98,"resourceTypeDesc":99,"sizeBytes":126,"sourceHtmlUrl":127},"evals\u002Ffixtures\u002Fscripts\u002Fcheck-safety-preserved.sh",761,"https:\u002F\u002Fgithub.com\u002Fleo-kuang-ai\u002Fspec-first\u002Fblob\u002Fmaster\u002Fskills\u002Fspec-simplify-code\u002Fevals\u002Ffixtures\u002Fscripts\u002Fcheck-safety-preserved.sh",{"path":129,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":130,"sourceHtmlUrl":131},"references\u002Fpersonas\u002Fcode-quality-reviewer.md",3195,"https:\u002F\u002Fgithub.com\u002Fleo-kuang-ai\u002Fspec-first\u002Fblob\u002Fmaster\u002Fskills\u002Fspec-simplify-code\u002Freferences\u002Fpersonas\u002Fcode-quality-reviewer.md",{"path":133,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":134,"sourceHtmlUrl":135},"references\u002Fpersonas\u002Fcode-reuse-reviewer.md",1687,"https:\u002F\u002Fgithub.com\u002Fleo-kuang-ai\u002Fspec-first\u002Fblob\u002Fmaster\u002Fskills\u002Fspec-simplify-code\u002Freferences\u002Fpersonas\u002Fcode-reuse-reviewer.md",{"path":137,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":138,"sourceHtmlUrl":139},"references\u002Fpersonas\u002Fefficiency-reviewer.md",1423,"https:\u002F\u002Fgithub.com\u002Fleo-kuang-ai\u002Fspec-first\u002Fblob\u002Fmaster\u002Fskills\u002Fspec-simplify-code\u002Freferences\u002Fpersonas\u002Fefficiency-reviewer.md",[141,172,194,208,222,241],{"skillNo":142,"name":143,"nameZh":6,"description":144,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":145,"categories":146,"keywords":153,"publishedAt":38},"01M6CWKQCYJXDCW4MEF3FSJE26","using-spec-first","Standalone entry governor for spec-first. Use before substantial work in a spec-first repo or when the user asks what to run next; choose one public `spec-*` workflow, standalone skill, terminal command, or Direct Lane. Do not use to reroute active public workflows or bounded workers, or for lightweight facts, current-context explanations, narrow lookups, user-supplied single-document cleanup, or clearly scoped low-risk edits.","https:\u002F\u002Fgithub.com\u002Fleo-kuang-ai\u002Fspec-first\u002Fblob\u002Fmaster\u002Fskills\u002Fusing-spec-first\u002FSKILL.md",[147,152],{"categoryNo":148,"categoryName":149,"taxonomyType":150,"taxonomyTypeDesc":151},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[24,154,155,156,157,158,159,160,36,161,162,163,164,165,166,167,168,169,170,171],"first","using spec first","terminal","work","active","next","do","context","command","repo","choose","direct","risk","lane","run","cleanup","workflows","workflow",{"skillNo":173,"name":174,"nameZh":6,"description":175,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":176,"categories":177,"keywords":179,"publishedAt":38},"01M6CWKK43ZJKQXKVJB3BWWPR1","spec-write-tasks","Public workflow entrypoint (spec-write-tasks): compile a settled local spec-plan into an optional derived task pack for spec-work, or validate an existing local task pack before execution. Use for explicit plan-splitting\u002Ftask-doc requests or high-complexity work suitability; do not use for plan authoring, implementation execution, unresolved scope, small low-risk plans, progress\u002Fapproval state, remote\u002Fgeneric task lists, or generated runtime mirror edits. Keep the plan as single source of truth; tasks are derived and optional.","https:\u002F\u002Fgithub.com\u002Fleo-kuang-ai\u002Fspec-first\u002Fblob\u002Fmaster\u002Fskills\u002Fspec-write-tasks\u002FSKILL.md",[178],{"categoryNo":148,"categoryName":149,"taxonomyType":150,"taxonomyTypeDesc":151},[24,180,181,182,183,184,160,185,186,36,187,157,188,189,166,190,191,192,171,193],"tasks","write","spec write tasks","local","task","complexity","plan authoring","generated","plan","doc","execution","compile","validate","state",{"skillNo":195,"name":196,"nameZh":6,"description":197,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":198,"categories":199,"keywords":201,"publishedAt":38},"01M6CWKEK6CVPQW8EMCNSDPHBJ","spec-write-skill","公开 workflow：创建、修改或迁移项目拥有的 Agent Skill package，或对现有\u002F外部 package 做用户明确要求、零执行的只读验证与 readiness 报告时使用；也用于按已接受的 audit finding 修复 source skill。不要用于一次性回答、解释\u002F总结\u002F翻译、普通代码 review、第三方 Skill 纯安装或导入、跨仓批量修改，或直接修补 generated runtime mirrors。","https:\u002F\u002Fgithub.com\u002Fleo-kuang-ai\u002Fspec-first\u002Fblob\u002Fmaster\u002Fskills\u002Fspec-write-skill\u002FSKILL.md",[200],{"categoryNo":148,"categoryName":149,"taxonomyType":150,"taxonomyTypeDesc":151},[202,24,181,203,204,187,205,206,171,207],"spec write skill","write skill","audit","翻译","package","review",{"skillNo":209,"name":210,"nameZh":6,"description":211,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":212,"categories":213,"keywords":214,"publishedAt":38},"01M6CWKBDEZ7QFF1ZH3DP52SHA","spec-worktree","Internal helper for caller-owned git worktree isolation. Governed callers are spec-dogfood and spec-work; every caller must provide the forward invocation and intake contract.","https:\u002F\u002Fgithub.com\u002Fleo-kuang-ai\u002Fspec-first\u002Fblob\u002Fmaster\u002Fskills\u002Fspec-worktree\u002FSKILL.md",[],[24,215,216,217,218,219,220,157,221],"worktree","spec worktree","intake","git","Bash","dogfood","git worktree",{"skillNo":223,"name":224,"nameZh":6,"description":225,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":226,"categories":227,"keywords":229,"publishedAt":38},"01M6CWK5W4VREMNXGQQKXXSQ3N","spec-work","Execute a settled plan, validated task pack, spec path, or concrete implementation request end-to-end. Use spec-debug for open-ended bugs; stop when target repo, scope, source ownership, or required authorization is unresolved. Not for explicitly requested GitHub PR-review-feedback handling — route those to spec-resolve-pr-feedback.","https:\u002F\u002Fgithub.com\u002Fleo-kuang-ai\u002Fspec-first\u002Fblob\u002Fmaster\u002Fskills\u002Fspec-work\u002FSKILL.md",[228],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[157,230,24,231,232,233,29,234,184,235,236,237,36,163,238,239,188,240,189,207],"spec work","stop","github","to spec","route","github pr","implementation","auto","pr","feedback","open",{"skillNo":242,"name":243,"nameZh":6,"description":244,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":245,"categories":246,"keywords":252,"publishedAt":38},"01M6CWK1MFTSNV9MYD4C8WGB8B","spec-test-xcode","Build and test iOS apps on simulator using XcodeBuildMCP. Use after making iOS code changes, before creating a PR, or when verifying app behavior and checking for crashes on simulator.","https:\u002F\u002Fgithub.com\u002Fleo-kuang-ai\u002Fspec-first\u002Fblob\u002Fmaster\u002Fskills\u002Fspec-test-xcode\u002FSKILL.md",[247,250,251],{"categoryNo":248,"categoryName":249,"taxonomyType":150,"taxonomyTypeDesc":151},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":148,"categoryName":149,"taxonomyType":150,"taxonomyTypeDesc":151},{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[24,253,254,238,25,255,256,35,36,257,258],"test","spec test xcode","ios","build and test","default","build"]