[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6CWKK43ZJKQXKVJB3BWWPR1":3,"skill-same:01M6CWKK43ZJKQXKVJB3BWWPR1":180},{"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":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":49,"commitSha":50,"skillDirectory":51,"forksCount":52,"repositoryHtmlUrl":53,"repositoryHomepageUrl":54,"ownerHtmlUrl":55,"ownerBlogUrl":6,"ownerDescription":56,"updatedAt":57,"install":58,"resources":71},"01M6CWKK43ZJKQXKVJB3BWWPR1","spec-write-tasks",null,"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.","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-write-tasks\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"spec write tasks","tasks","spec","write","work","local","task","do","complexity","plan authoring","use","generated","plan","doc","risk","execution","compile","state","validate","workflow","2026-11-10 10:12:30",false,"---\nname: spec-write-tasks\ndescription: \"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.\"\n---\n\n# `spec-write-tasks`\n\n`spec-write-tasks` is an optional derived layer between `spec-plan` and `spec-work`. It does not execute code. It either compiles a settled source plan into a derived task pack, validates an existing task pack, or returns a no-task-pack decision.\n\nIt is a public workflow with the unified entrypoint `spec-write-tasks`.\n\n## Purpose\n\nDecide whether a derived task pack is worthwhile, compile one when it reduces execution risk or context load, and validate existing task packs before they reach `spec-work`.\n\n## Workflow Contract Summary\n\n### When To Use\n\nUse when a settled local source plan is too large or dependent for direct execution, when the user explicitly asks to split a plan into tasks, or when an existing local task pack needs validation before `spec-work`.\n\n### When Not To Use\n\nDo not use for unresolved product or architecture scope, small changes that do not need a derived layer, remote repositories or package names, marketplace skill lookup, or implementation prompts that should go directly to `spec-work`.\n\n### Inputs\n\nA local source plan path, existing task-pack path, or clear task-splitting request that resolves to one local source plan. Inputs must stay local and source-owned; remote repos, packages, marketplace identifiers, and generic task lists are rejected.\n\n### Outputs\n\nOne of: executable derived task pack, validated existing task-pack handoff, `skip`, `return-to-plan`, `draft-only`, or `validate-only` envelope. Task packs are derived execution indexes and never replace the source plan.\n\n### Artifacts\n\nExecutable task packs live under `docs\u002Ftasks\u002F` and must carry an artifact-root-relative POSIX `source_plan`, canonical `source_plan_hash`, `generated_by: spec-write-tasks`, `mode: derived`, and a valid `Task Pack Contract` JSON block. Executable identity is `source-plan-path+body-hash`; `spec_id` is an optional compatibility trace rather than a required identity field.\n\n### Failure Modes\n\nUse machine-readable reason codes: `source_plan_missing`, `ambiguous_plan`, `wrong_chain`, `stale_hash`, `unverifiable_hash`, `invalid_contract`, `repo_scope_missing`, or `scope_gap`.\n\n### Workflow\n\nClassify input, verify plan identity and repo scope, choose one branch (`compile`, `skip`, `return-to-plan`, `draft-only`, `validate-only`), use bounded source orientation only when it improves task boundaries, write or validate the task pack, then return the final decision envelope.\n\n### Downstream Consumers\n\n`spec-work`, high-risk `spec-doc-review` handoff, human reviewers, and later code-review\u002Fcompound workflows.\n\n## Scenario Capability\n\nFollows `docs\u002Fcontracts\u002Fworkflows\u002Fscenario-capability-matrix.md` (default).\n\nOverrides: none\n\n## Core Rules\n\n1. `spec-plan` is always the single source of truth.\n2. A task pack may rearrange execution slices, but must not change scope, acceptance criteria, non-goals, repo ownership, or product decisions.\n3. A task pack is not progress state, approval state, a lifecycle database, or a second plan.\n4. `context_refs` are bounded reading pointers, not scope authority. Whole-plan or whole-directory refs are low-quality unless paired with narrower anchors.\n5. If parent-workspace scope is present, the plan or task pack must name `target_repo` at top level or per task. Missing repo scope returns to `spec-plan`.\n6. Source orientation is advisory and bounded: source plan sections, plan-declared files, nearby tests, and precise local contracts only when they improve task boundaries.\n7. Scripts validate identity, freshness, structure, hashes, concrete paths, and same-wave overlap. LLM\u002Freviewers judge semantic task quality.\n8. Do not hand-edit `.claude\u002F`, `.codex\u002F`, or `.agents\u002Fskills\u002F` as source fixes.\n9. `--repo \u003Cartifact-root>` selects the artifact\u002Fsource resolution root only. It does not authorize or select the downstream mutation `target_repo`.\n10. Compile executable tasks only from `status: active`. `completed`, `partially-shipped`, and `superseded` plans return `source_plan_non_active`; do not hash them into a new executable task pack or route them to `spec-work`. A legacy plan without managed status remains a visible `source-plan-lifecycle-unmanaged` limitation.\n\n## Input Paths\n\n- Source plan path: read the source plan frontmatter and focused sections: Requirements, Scope Boundaries, Technical Approach, Implementation Units, Files, Test Scenarios, Verification, and Deferred to Implementation.\n- Existing task-pack path: read the task pack, source plan, and `Task Pack Contract`; validate identity\u002Ffreshness\u002Fstructure before treating it as executable.\n- Bare task-splitting request: resolve exactly one local source plan; if resolution is ambiguous, ask for the path.\n\nUse [Task Quality Guide](references\u002Ftask-quality-guide.md) for accepted\u002Frejected input classes, task-ready source plan rules, source orientation, traceability, vertical slices, `context_refs`, `done_signal`, `stop_if`, and review-intent quality guidance.\n\n## Branches\n\n- `compile`: plan is task-ready and a task pack reduces execution risk or context load.\n- `skip`: direct `spec-work` is cheaper and safer than adding a derived layer.\n- `return-to-plan`: scope, acceptance, architecture, verification, or repo ownership is unresolved.\n- `draft-only`: a non-executable outline may help discussion but cannot be handed to `spec-work`.\n- `validate-only`: an existing task pack is checked before execution.\n\nUse [Execution Handoff Contract](references\u002Fexecution-handoff-contract.md) for branch outputs, final envelope fields, high-risk review handoff, hash rules, and failure reason codes.\n\n## Task Pack Output\n\nWhen compiling, read [Task Pack Schema](references\u002Ftask-pack-schema.md) and write the task pack body with:\n\n- Overview\n- Source Summary\n- Traceability Matrix\n- Task Graph\n- Execution Waves\n- Task Pack Contract\n- Task Cards\n- Orientation Evidence\n- Validation Notes\n- Regeneration Rules\n\nThe `Task Pack Contract` fenced JSON block is the machine-readable source for validators. Human-readable sections compress context for executors and reviewers, but deterministic validation proves only identity, freshness, and structure.\n\n## Final Decision Envelope\n\nEvery run must end with the compact envelope from [Execution Handoff Contract](references\u002Fexecution-handoff-contract.md).\n\nRequired posture:\n\n- include `decision`, `reason_code`, `identity_basis`, `artifact_root`, `source_plan`, `task_pack`, `task_pack_validity`, `deterministic_handoff`, `validity_scope`, `semantic_posture`, `dispatch_authorization`, `validation`, `orientation`, and `next_action`;\n- ? GATE (verification): run `spec-first tasks validate \u003Ctask-pack-path> --repo \u003Cartifact-root> --json` before reporting `deterministic_handoff` or validation fields;\n- run `spec-first tasks hash \u003Cplan-path> --repo \u003Cartifact-root> --json` when computing or comparing `source_plan_hash`, and copy its portable `source_plan` field rather than deriving identity from an absolute machine path;\n- ? GATE (verification): never self-report `deterministic_handoff: true` without CLI JSON evidence;\n- ? GATE (handoff): allow `next_action: spec-work-task-pack` only for valid deterministic handoff plus semantic posture `generated-this-run` or `reviewed-existing`;\n- ? GATE (verification): for `semantic_posture: reviewed-existing`, the envelope must carry evidence metadata or a verifiable review-outcome reference; a bare `reviewed-existing` claim without current evidence is not eligible for `next_action: spec-work-task-pack`;\n- ? GATE (handoff): for `dispatch_authorization: authorized`, the envelope must carry a bounded continuation reference or doc-review outcome reference; absent that, report `dispatch_authorization: missing`.\n\nHigh-risk packs return `next_action: review-task-pack` with one reason and the copy-ready current-host invocation `spec-doc-review mode:headless mutation:report-only output:json roster:full \u003Ctask-pack-path>`。Consumer 必须把 derived task pack 保持 byte-preserving，并从 `task_pack_outcome` 读取 deterministic intake、semantic review 与 terminal owner；不要仅凭 `Review complete` 推导 `reviewed-existing`。`roster:full` 仍只保留实际 qualified personas，但不会让 high-risk review 因 standard budget 丢失同时成立的 security、scope 或 adversarial lens。Do not auto-dispatch review unless the explicit bounded continuation conditions in [Execution Handoff Contract](references\u002Fexecution-handoff-contract.md) are met.\n\n## Portability Boundary\n\nRuntime references must be packaged skill files (`references\u002F`, `agents\u002F`) or optional named integration points distributed with spec-first. `spec-plan`, `spec-work`, and `spec-doc-review` are integration names, not required files to read from this package.\n\n`evals\u002F` files are maintainer-only validation fixtures; the official `.skill` packager excludes root `evals\u002F`, so runtime users must not need them. Repo-local scripts, validation reports, technical plans, project-role documents, historical snapshots, and `.spec-first\u002Faudits\u002F**` are maintainer evidence, not user-runtime dependencies.\n\n## Do Not\n\n- Do not execute implementation work.\n- Do not generate task packs for small low-risk plans by default.\n- Do not invent missing scope, acceptance criteria, repo targets, or product decisions.\n- Do not turn `review_gate` into approval state or validator-owned semantic risk.\n- Do not make task quality analyzer warnings a hard validator gate.\n- Do not list repo-local validation reports or historical plans as runtime references.\n\n## References\n\n- [Execution Handoff Contract](references\u002Fexecution-handoff-contract.md)\n- [Task Pack Schema](references\u002Ftask-pack-schema.md)\n- [Task Quality Guide](references\u002Ftask-quality-guide.md)\n","# `spec-write-tasks`\n\n`spec-write-tasks` is an optional derived layer between `spec-plan` and `spec-work`. It does not execute code. It either compiles a settled source plan into a derived task pack, validates an existing task pack, or returns a no-task-pack decision.\n\nIt is a public workflow with the unified entrypoint `spec-write-tasks`.\n\n## Purpose\n\nDecide whether a derived task pack is worthwhile, compile one when it reduces execution risk or context load, and validate existing task packs before they reach `spec-work`.\n\n## Workflow Contract Summary\n\n### When To Use\n\nUse when a settled local source plan is too large or dependent for direct execution, when the user explicitly asks to split a plan into tasks, or when an existing local task pack needs validation before `spec-work`.\n\n### When Not To Use\n\nDo not use for unresolved product or architecture scope, small changes that do not need a derived layer, remote repositories or package names, marketplace skill lookup, or implementation prompts that should go directly to `spec-work`.\n\n### Inputs\n\nA local source plan path, existing task-pack path, or clear task-splitting request that resolves to one local source plan. Inputs must stay local and source-owned; remote repos, packages, marketplace identifiers, and generic task lists are rejected.\n\n### Outputs\n\nOne of: executable derived task pack, validated existing task-pack handoff, `skip`, `return-to-plan`, `draft-only`, or `validate-only` envelope. Task packs are derived execution indexes and never replace the source plan.\n\n### Artifacts\n\nExecutable task packs live under `docs\u002Ftasks\u002F` and must carry an artifact-root-relative POSIX `source_plan`, canonical `source_plan_hash`, `generated_by: spec-write-tasks`, `mode: derived`, and a valid `Task Pack Contract` JSON block. Executable identity is `source-plan-path+body-hash`; `spec_id` is an optional compatibility trace rather than a required identity field.\n\n### Failure Modes\n\nUse machine-readable reason codes: `source_plan_missing`, `ambiguous_plan`, `wrong_chain`, `stale_hash`, `unverifiable_hash`, `invalid_contract`, `repo_scope_missing`, or `scope_gap`.\n\n### Workflow\n\nClassify input, verify plan identity and repo scope, choose one branch (`compile`, `skip`, `return-to-plan`, `draft-only`, `validate-only`), use bounded source orientation only when it improves task boundaries, write or validate the task pack, then return the final decision envelope.\n\n### Downstream Consumers\n\n`spec-work`, high-risk `spec-doc-review` handoff, human reviewers, and later code-review\u002Fcompound workflows.\n\n## Scenario Capability\n\nFollows `docs\u002Fcontracts\u002Fworkflows\u002Fscenario-capability-matrix.md` (default).\n\nOverrides: none\n\n## Core Rules\n\n1. `spec-plan` is always the single source of truth.\n2. A task pack may rearrange execution slices, but must not change scope, acceptance criteria, non-goals, repo ownership, or product decisions.\n3. A task pack is not progress state, approval state, a lifecycle database, or a second plan.\n4. `context_refs` are bounded reading pointers, not scope authority. Whole-plan or whole-directory refs are low-quality unless paired with narrower anchors.\n5. If parent-workspace scope is present, the plan or task pack must name `target_repo` at top level or per task. Missing repo scope returns to `spec-plan`.\n6. Source orientation is advisory and bounded: source plan sections, plan-declared files, nearby tests, and precise local contracts only when they improve task boundaries.\n7. Scripts validate identity, freshness, structure, hashes, concrete paths, and same-wave overlap. LLM\u002Freviewers judge semantic task quality.\n8. Do not hand-edit `.claude\u002F`, `.codex\u002F`, or `.agents\u002Fskills\u002F` as source fixes.\n9. `--repo \u003Cartifact-root>` selects the artifact\u002Fsource resolution root only. It does not authorize or select the downstream mutation `target_repo`.\n10. Compile executable tasks only from `status: active`. `completed`, `partially-shipped`, and `superseded` plans return `source_plan_non_active`; do not hash them into a new executable task pack or route them to `spec-work`. A legacy plan without managed status remains a visible `source-plan-lifecycle-unmanaged` limitation.\n\n## Input Paths\n\n- Source plan path: read the source plan frontmatter and focused sections: Requirements, Scope Boundaries, Technical Approach, Implementation Units, Files, Test Scenarios, Verification, and Deferred to Implementation.\n- Existing task-pack path: read the task pack, source plan, and `Task Pack Contract`; validate identity\u002Ffreshness\u002Fstructure before treating it as executable.\n- Bare task-splitting request: resolve exactly one local source plan; if resolution is ambiguous, ask for the path.\n\nUse [Task Quality Guide](references\u002Ftask-quality-guide.md) for accepted\u002Frejected input classes, task-ready source plan rules, source orientation, traceability, vertical slices, `context_refs`, `done_signal`, `stop_if`, and review-intent quality guidance.\n\n## Branches\n\n- `compile`: plan is task-ready and a task pack reduces execution risk or context load.\n- `skip`: direct `spec-work` is cheaper and safer than adding a derived layer.\n- `return-to-plan`: scope, acceptance, architecture, verification, or repo ownership is unresolved.\n- `draft-only`: a non-executable outline may help discussion but cannot be handed to `spec-work`.\n- `validate-only`: an existing task pack is checked before execution.\n\nUse [Execution Handoff Contract](references\u002Fexecution-handoff-contract.md) for branch outputs, final envelope fields, high-risk review handoff, hash rules, and failure reason codes.\n\n## Task Pack Output\n\nWhen compiling, read [Task Pack Schema](references\u002Ftask-pack-schema.md) and write the task pack body with:\n\n- Overview\n- Source Summary\n- Traceability Matrix\n- Task Graph\n- Execution Waves\n- Task Pack Contract\n- Task Cards\n- Orientation Evidence\n- Validation Notes\n- Regeneration Rules\n\nThe `Task Pack Contract` fenced JSON block is the machine-readable source for validators. Human-readable sections compress context for executors and reviewers, but deterministic validation proves only identity, freshness, and structure.\n\n## Final Decision Envelope\n\nEvery run must end with the compact envelope from [Execution Handoff Contract](references\u002Fexecution-handoff-contract.md).\n\nRequired posture:\n\n- include `decision`, `reason_code`, `identity_basis`, `artifact_root`, `source_plan`, `task_pack`, `task_pack_validity`, `deterministic_handoff`, `validity_scope`, `semantic_posture`, `dispatch_authorization`, `validation`, `orientation`, and `next_action`;\n- ? GATE (verification): run `spec-first tasks validate \u003Ctask-pack-path> --repo \u003Cartifact-root> --json` before reporting `deterministic_handoff` or validation fields;\n- run `spec-first tasks hash \u003Cplan-path> --repo \u003Cartifact-root> --json` when computing or comparing `source_plan_hash`, and copy its portable `source_plan` field rather than deriving identity from an absolute machine path;\n- ? GATE (verification): never self-report `deterministic_handoff: true` without CLI JSON evidence;\n- ? GATE (handoff): allow `next_action: spec-work-task-pack` only for valid deterministic handoff plus semantic posture `generated-this-run` or `reviewed-existing`;\n- ? GATE (verification): for `semantic_posture: reviewed-existing`, the envelope must carry evidence metadata or a verifiable review-outcome reference; a bare `reviewed-existing` claim without current evidence is not eligible for `next_action: spec-work-task-pack`;\n- ? GATE (handoff): for `dispatch_authorization: authorized`, the envelope must carry a bounded continuation reference or doc-review outcome reference; absent that, report `dispatch_authorization: missing`.\n\nHigh-risk packs return `next_action: review-task-pack` with one reason and the copy-ready current-host invocation `spec-doc-review mode:headless mutation:report-only output:json roster:full \u003Ctask-pack-path>`。Consumer 必须把 derived task pack 保持 byte-preserving，并从 `task_pack_outcome` 读取 deterministic intake、semantic review 与 terminal owner；不要仅凭 `Review complete` 推导 `reviewed-existing`。`roster:full` 仍只保留实际 qualified personas，但不会让 high-risk review 因 standard budget 丢失同时成立的 security、scope 或 adversarial lens。Do not auto-dispatch review unless the explicit bounded continuation conditions in [Execution Handoff Contract](references\u002Fexecution-handoff-contract.md) are met.\n\n## Portability Boundary\n\nRuntime references must be packaged skill files (`references\u002F`, `agents\u002F`) or optional named integration points distributed with spec-first. `spec-plan`, `spec-work`, and `spec-doc-review` are integration names, not required files to read from this package.\n\n`evals\u002F` files are maintainer-only validation fixtures; the official `.skill` packager excludes root `evals\u002F`, so runtime users must not need them. Repo-local scripts, validation reports, technical plans, project-role documents, historical snapshots, and `.spec-first\u002Faudits\u002F**` are maintainer evidence, not user-runtime dependencies.\n\n## Do Not\n\n- Do not execute implementation work.\n- Do not generate task packs for small low-risk plans by default.\n- Do not invent missing scope, acceptance criteria, repo targets, or product decisions.\n- Do not turn `review_gate` into approval state or validator-owned semantic risk.\n- Do not make task quality analyzer warnings a hard validator gate.\n- Do not list repo-local validation reports or historical plans as runtime references.\n\n## References\n\n- [Execution Handoff Contract](references\u002Fexecution-handoff-contract.md)\n- [Task Pack Schema](references\u002Ftask-pack-schema.md)\n- [Task Quality Guide](references\u002Ftask-quality-guide.md)\n",{"name":5,"description":7},"master","74655dc86b1270bb52239e0f8bc9517de7a7071c","skills\u002Fspec-write-tasks",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-12 18:28:30",{"source":8,"skillName":5,"commands":59,"prompt":69,"zipAvailable":70},[60,63,66],{"tool":61,"command":62},"npx","npx skills add leo-kuang-ai\u002Fspec-first --skill spec-write-tasks",{"tool":64,"command":65},"bunx","bunx skills add leo-kuang-ai\u002Fspec-first --skill spec-write-tasks",{"tool":67,"command":68},"pnpm","pnpm dlx skills add leo-kuang-ai\u002Fspec-first --skill spec-write-tasks","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fleo-kuang-ai\u002Fspec-first\u002Fblob\u002Fmaster\u002Fskills\u002Fspec-write-tasks\u002FSKILL.md",true,[72,78,82,86,90,94,98,104,108,112,116,120,124,128,132,136,142,146,150,154,160,164,168,172,176],{"path":73,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":76,"sourceHtmlUrl":77},"agents\u002Fopenai.yaml","REFERENCE","参考文档",538,"https:\u002F\u002Fgithub.com\u002Fleo-kuang-ai\u002Fspec-first\u002Fblob\u002Fmaster\u002Fskills\u002Fspec-write-tasks\u002Fagents\u002Fopenai.yaml",{"path":79,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":80,"sourceHtmlUrl":81},"evals\u002Fboundary-cases.json",5920,"https:\u002F\u002Fgithub.com\u002Fleo-kuang-ai\u002Fspec-first\u002Fblob\u002Fmaster\u002Fskills\u002Fspec-write-tasks\u002Fevals\u002Fboundary-cases.json",{"path":83,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":84,"sourceHtmlUrl":85},"evals\u002Feval.yaml",478,"https:\u002F\u002Fgithub.com\u002Fleo-kuang-ai\u002Fspec-first\u002Fblob\u002Fmaster\u002Fskills\u002Fspec-write-tasks\u002Fevals\u002Feval.yaml",{"path":87,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":88,"sourceHtmlUrl":89},"evals\u002Fexpected-behavior-cases.json",2070,"https:\u002F\u002Fgithub.com\u002Fleo-kuang-ai\u002Fspec-first\u002Fblob\u002Fmaster\u002Fskills\u002Fspec-write-tasks\u002Fevals\u002Fexpected-behavior-cases.json",{"path":91,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":92,"sourceHtmlUrl":93},"evals\u002Ffailure-cases.json",3683,"https:\u002F\u002Fgithub.com\u002Fleo-kuang-ai\u002Fspec-first\u002Fblob\u002Fmaster\u002Fskills\u002Fspec-write-tasks\u002Fevals\u002Ffailure-cases.json",{"path":95,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":96,"sourceHtmlUrl":97},"evals\u002Foutput-quality-cases.json",11873,"https:\u002F\u002Fgithub.com\u002Fleo-kuang-ai\u002Fspec-first\u002Fblob\u002Fmaster\u002Fskills\u002Fspec-write-tasks\u002Fevals\u002Foutput-quality-cases.json",{"path":99,"resourceType":100,"resourceTypeDesc":101,"sizeBytes":102,"sourceHtmlUrl":103},"evals\u002Foutput\u002Fcases.jsonl","OTHER","其他",2675,"https:\u002F\u002Fgithub.com\u002Fleo-kuang-ai\u002Fspec-first\u002Fblob\u002Fmaster\u002Fskills\u002Fspec-write-tasks\u002Fevals\u002Foutput\u002Fcases.jsonl",{"path":105,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":106,"sourceHtmlUrl":107},"evals\u002FREADME.md",2697,"https:\u002F\u002Fgithub.com\u002Fleo-kuang-ai\u002Fspec-first\u002Fblob\u002Fmaster\u002Fskills\u002Fspec-write-tasks\u002Fevals\u002FREADME.md",{"path":109,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":110,"sourceHtmlUrl":111},"evals\u002Fsemantic_config.json",1219,"https:\u002F\u002Fgithub.com\u002Fleo-kuang-ai\u002Fspec-first\u002Fblob\u002Fmaster\u002Fskills\u002Fspec-write-tasks\u002Fevals\u002Fsemantic_config.json",{"path":113,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":114,"sourceHtmlUrl":115},"evals\u002Fskillup\u002Fcases\u002Fbare-request-asks-path.yaml",456,"https:\u002F\u002Fgithub.com\u002Fleo-kuang-ai\u002Fspec-first\u002Fblob\u002Fmaster\u002Fskills\u002Fspec-write-tasks\u002Fevals\u002Fskillup\u002Fcases\u002Fbare-request-asks-path.yaml",{"path":117,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":118,"sourceHtmlUrl":119},"evals\u002Fskillup\u002Fcases\u002Fnon-active-rejected.yaml",705,"https:\u002F\u002Fgithub.com\u002Fleo-kuang-ai\u002Fspec-first\u002Fblob\u002Fmaster\u002Fskills\u002Fspec-write-tasks\u002Fevals\u002Fskillup\u002Fcases\u002Fnon-active-rejected.yaml",{"path":121,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":122,"sourceHtmlUrl":123},"evals\u002Fskillup\u002Fcases\u002Fremote-input-rejected.yaml",563,"https:\u002F\u002Fgithub.com\u002Fleo-kuang-ai\u002Fspec-first\u002Fblob\u002Fmaster\u002Fskills\u002Fspec-write-tasks\u002Fevals\u002Fskillup\u002Fcases\u002Fremote-input-rejected.yaml",{"path":125,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":126,"sourceHtmlUrl":127},"evals\u002Fskillup\u002Fcases\u002Fsmall-plan-skip.yaml",702,"https:\u002F\u002Fgithub.com\u002Fleo-kuang-ai\u002Fspec-first\u002Fblob\u002Fmaster\u002Fskills\u002Fspec-write-tasks\u002Fevals\u002Fskillup\u002Fcases\u002Fsmall-plan-skip.yaml",{"path":129,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":130,"sourceHtmlUrl":131},"evals\u002Fskillup\u002Ffixtures\u002Frepos\u002Fdone-plan\u002Fdocs\u002Fplans\u002F2026-08-01-001-feat-old-thing-plan.md",178,"https:\u002F\u002Fgithub.com\u002Fleo-kuang-ai\u002Fspec-first\u002Fblob\u002Fmaster\u002Fskills\u002Fspec-write-tasks\u002Fevals\u002Fskillup\u002Ffixtures\u002Frepos\u002Fdone-plan\u002Fdocs\u002Fplans\u002F2026-08-01-001-feat-old-thing-plan.md",{"path":133,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":134,"sourceHtmlUrl":135},"evals\u002Fskillup\u002Ffixtures\u002Frepos\u002Ftiny-plan\u002Fdocs\u002Fplans\u002F2026-09-01-001-feat-month-filter-plan.md",297,"https:\u002F\u002Fgithub.com\u002Fleo-kuang-ai\u002Fspec-first\u002Fblob\u002Fmaster\u002Fskills\u002Fspec-write-tasks\u002Fevals\u002Fskillup\u002Ffixtures\u002Frepos\u002Ftiny-plan\u002Fdocs\u002Fplans\u002F2026-09-01-001-feat-month-filter-plan.md",{"path":137,"resourceType":138,"resourceTypeDesc":139,"sizeBytes":140,"sourceHtmlUrl":141},"evals\u002Fskillup\u002Ffixtures\u002Fscripts\u002Fasks-a-question.sh","SCRIPT","脚本",1232,"https:\u002F\u002Fgithub.com\u002Fleo-kuang-ai\u002Fspec-first\u002Fblob\u002Fmaster\u002Fskills\u002Fspec-write-tasks\u002Fevals\u002Fskillup\u002Ffixtures\u002Fscripts\u002Fasks-a-question.sh",{"path":143,"resourceType":138,"resourceTypeDesc":139,"sizeBytes":144,"sourceHtmlUrl":145},"evals\u002Fskillup\u002Ffixtures\u002Fscripts\u002Frejects-remote.sh",501,"https:\u002F\u002Fgithub.com\u002Fleo-kuang-ai\u002Fspec-first\u002Fblob\u002Fmaster\u002Fskills\u002Fspec-write-tasks\u002Fevals\u002Fskillup\u002Ffixtures\u002Fscripts\u002Frejects-remote.sh",{"path":147,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":148,"sourceHtmlUrl":149},"evals\u002Ftrigger-cases.json",1622,"https:\u002F\u002Fgithub.com\u002Fleo-kuang-ai\u002Fspec-first\u002Fblob\u002Fmaster\u002Fskills\u002Fspec-write-tasks\u002Fevals\u002Ftrigger-cases.json",{"path":151,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":152,"sourceHtmlUrl":153},"evals\u002Fyao-trigger-cases.json",1500,"https:\u002F\u002Fgithub.com\u002Fleo-kuang-ai\u002Fspec-first\u002Fblob\u002Fmaster\u002Fskills\u002Fspec-write-tasks\u002Fevals\u002Fyao-trigger-cases.json",{"path":155,"resourceType":156,"resourceTypeDesc":157,"sizeBytes":158,"sourceHtmlUrl":159},"LICENSE.txt","LICENSE","许可证",441,"https:\u002F\u002Fgithub.com\u002Filderaj\u002Fagent-plugin-marketplace\u002Fblob\u002Fmain\u002Fplugins\u002Fcodex--figma\u002Fskills\u002Ffigma-create-design-system-rules\u002FLICENSE.txt",{"path":161,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":162,"sourceHtmlUrl":163},"references\u002Fexecution-handoff-contract.md",12570,"https:\u002F\u002Fgithub.com\u002Fleo-kuang-ai\u002Fspec-first\u002Fblob\u002Fmaster\u002Fskills\u002Fspec-write-tasks\u002Freferences\u002Fexecution-handoff-contract.md",{"path":165,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":166,"sourceHtmlUrl":167},"references\u002Frule-template.md",334,"https:\u002F\u002Fgithub.com\u002Filderaj\u002Fagent-plugin-marketplace\u002Fblob\u002Fmain\u002Fplugins\u002Fcodex--figma\u002Fskills\u002Ffigma-create-design-system-rules\u002Freferences\u002Frule-template.md",{"path":169,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":170,"sourceHtmlUrl":171},"references\u002Ftask-pack-schema.md",17227,"https:\u002F\u002Fgithub.com\u002Fleo-kuang-ai\u002Fspec-first\u002Fblob\u002Fmaster\u002Fskills\u002Fspec-write-tasks\u002Freferences\u002Ftask-pack-schema.md",{"path":173,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":174,"sourceHtmlUrl":175},"references\u002Ftask-quality-guide.md",22785,"https:\u002F\u002Fgithub.com\u002Fleo-kuang-ai\u002Fspec-first\u002Fblob\u002Fmaster\u002Fskills\u002Fspec-write-tasks\u002Freferences\u002Ftask-quality-guide.md",{"path":177,"resourceType":138,"resourceTypeDesc":139,"sizeBytes":178,"sourceHtmlUrl":179},"scripts\u002Fcheck_agents_md.sh",191,"https:\u002F\u002Fgithub.com\u002Filderaj\u002Fagent-plugin-marketplace\u002Fblob\u002Fmain\u002Fplugins\u002Fcodex--figma\u002Fskills\u002Ffigma-create-design-system-rules\u002Fscripts\u002Fcheck_agents_md.sh",[181,208,222,236,256,276],{"skillNo":182,"name":183,"nameZh":6,"description":184,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":185,"categories":186,"keywords":193,"publishedAt":44},"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",[187,188],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":189,"categoryName":190,"taxonomyType":191,"taxonomyTypeDesc":192},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[26,194,195,196,197,28,198,199,31,34,200,201,202,43,203,204,38,205,206,207],"first","using spec first","terminal","workflows","active","next","context","command","repo","choose","direct","lane","run","cleanup",{"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":215,"publishedAt":44},"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",[214],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[26,216,27,217,218,35,219,220,43,221],"write skill","spec write skill","package","翻译","audit","review",{"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":228,"publishedAt":44},"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",[],[229,26,230,231,28,232,233,234,235],"spec worktree","worktree","dogfood","Bash","git worktree","git","intake",{"skillNo":237,"name":238,"nameZh":6,"description":239,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":240,"categories":241,"keywords":243,"publishedAt":44},"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",[242],{"categoryNo":189,"categoryName":190,"taxonomyType":191,"taxonomyTypeDesc":192},[26,28,244,37,245,246,247,248,221,249,36,250,202,34,251,252,253,254,30,255],"spec work","pr","debug","to spec","github","open","feedback","auto","implementation","stop","github pr","route",{"skillNo":257,"name":258,"nameZh":6,"description":259,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":260,"categories":261,"keywords":267,"publishedAt":44},"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",[262,265,266],{"categoryNo":263,"categoryName":264,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":189,"categoryName":190,"taxonomyType":191,"taxonomyTypeDesc":192},[26,268,269,270,271,34,272,273,274,245,275],"test","spec test xcode","default","build","behavior","ios","code","build and test",{"skillNo":277,"name":278,"nameZh":6,"description":279,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":280,"categories":281,"keywords":284,"publishedAt":44},"01M6CWJXMAXKVRW5MA4E9EJJQW","spec-test-browser","Run browser tests on pages affected by current PR or branch. Use after code changes when browser verification is requested before review or merge. Not for diagnosing failures those runs uncover — route defects to spec-debug.","https:\u002F\u002Fgithub.com\u002Fleo-kuang-ai\u002Fspec-first\u002Fblob\u002Fmaster\u002Fskills\u002Fspec-test-browser\u002FSKILL.md",[282,283],{"categoryNo":263,"categoryName":264,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":189,"categoryName":190,"taxonomyType":191,"taxonomyTypeDesc":192},[26,285,286,268,287,288,246,245,206,274,221,247,34,255,289,290,291],"spec test browser","browser","test browser","merge","branch","pipeline","verification"]