[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6GSVRW7DEVZEREDHE8WSXGH":3,"skill-same:01M6GSVRW7DEVZEREDHE8WSXGH":75},{"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":43,"linkOnly":44,"markdownContent":45,"markdownBody":46,"frontMatter":47,"refName":50,"commitSha":51,"skillDirectory":52,"forksCount":14,"repositoryHtmlUrl":53,"repositoryHomepageUrl":6,"ownerHtmlUrl":54,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":55,"install":56,"resources":68},"01M6GSVRW7DEVZEREDHE8WSXGH","prd",null,"Create an implementation-ready PRD for a feature. Use for product requirements, feature specs, user stories, planning, or preparing for `\u002Fspec-to-tasks`. Do not implement or write code.","japurcell\u002Fskills","japurcell","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F10947458?v=4","01M6GSJK1YAG95R6VHF47V30KY","Adam Purcell","01M6GSJK6817NVR5FVDMFFNJ6H",0,"MIT","https:\u002F\u002Fgithub.com\u002Fjapurcell\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fdefault\u002Fprd\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000031","产品经理","PROFESSION","适用职业",[5,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42],"implement","change","stories","for","user stories","implementation","write","spec","product","create","tasks","code","requirements","use","true","planning","feature","ready","do","2026-11-10 10:12:30",false,"---\nname: prd\ndescription: Create an implementation-ready PRD for a feature. Use for product requirements, feature specs, user stories, planning, or preparing for `\u002Fspec-to-tasks`. Do not implement or write code.\ndisable-model-invocation: true\nargument-hint: '[\u003Cfeature or change>]'\n---\n\n# \u002Fprd\n\nCreate an unambiguous, implementation-ready PRD from the conversation and codebase context.\n\n## Rules\n\n- Do not implement or write code.\n- Do not interview the user; make reasonable assumptions and document them. If unsafe\u002Fcontradictory, stop and report the blocker.\n- Follow existing codebase patterns. Prefer YAGNI.\n- Check available workspace conventions: `AGENTS.md`, scoped docs, repo docs, scripts, tests, existing modules\u002Fpatterns.\n- Do not invent commands, files, paths, schemas, URLs, literals, DB objects, or conventions. Use exact names only when verified or clearly inferable.\n- Define each path, schema, key format, command, contract, and rollout order in one canonical place, then reference it consistently.\n- Never overwrite, rename, or delete an existing PRD.\n- Require named test targets when inferable: exact test file\u002Fclass names and intended assertions. Avoid vague metrics such as “100% tests pass.”\n\n## Save path\n\nSave to `.agents\u002Fscratchpad\u002F[feature-name]\u002Fprd.md`, where `[feature-name]` is short kebab-case. If it exists, use `[feature-name]-2`, `-3`, etc. Create directories as needed. Verify the final file exists. If saving fails, stop and report failure.\n\n## Workflow\n\n1. Activate or load the `delegate-to-subagents` skill and delegate tasks to the most suitable subagents whenever possible.\n2. Before drafting, fill any missing codebase context by dispatching 1-3 code-explorer subagents, scaled to scope, to inspect relevant repository files and conventions.\n3. Identify existing patterns, affected modules, contracts, test seams, risks, edge cases, rollout constraints, and conflicts with workspace conventions.\n4. Draft the PRD using the template below.\n5. Validate consistency across sections, especially requirements, acceptance criteria, technical decisions, Definition of Done, paths, schemas, commands, examples, and execution order.\n6. Resolve conflicts by preferring the most specific implementation-nearest source; document assumptions. If unclear, stop and report the blocker.\n7. Save to the verified unused path.\n8. Final response: feature short name, PRD path, validation status `pass`\u002F`fail`, readiness for `\u002Fspec-to-tasks`.\n\n\u003Cprd-template>\n\n# PRD: [Feature Name]\n\n## Overview\n\nDescribe the problem, users, value, and proposed solution.\n\n## Assumptions\n\nList assumptions made because the user was not interviewed.\n\n## Goals\n\n- Specific measurable goal\n\n## User Stories\n\nList enough stories to cover user-visible capabilities, roles, states, and edge cases without turning implementation tasks into stories. Each story should describe one coherent behavior slice.\n\nFormat:\n\n```md\n### US-001: [Title]\n\n**Story:** As a [user], I want [capability] so that [benefit].\n\n**Acceptance Criteria:**\n\n- [ ] Concrete, observable behavior\n- [ ] Relevant edge\u002Ffailure case\n- [ ] Relevant build\u002Ftypecheck\u002Flint\u002Ftest commands pass, using exact commands when inferable\n- [ ] For UI: Verify in browser using playwright-cli skill\n\n**Design Guidance:**\n\n- Follow existing [pattern\u002Fmodule\u002Fcomponent] because [rationale].\n```\n\nAcceptance criteria rules:\n\n- Describe observable outcomes, not implementation steps.\n- Define done using concrete inputs, outputs, states, side effects, and success\u002Ffailure behavior.\n- Include relevant error paths: validation, permissions, timeouts, dependency failure, partial failure, invalid\u002Fcorrupted state, and recovery.\n- For CLI\u002FAPI\u002Fdata features, specify contracts: inputs, outputs, status codes, exit codes, stdout\u002Fstderr, schemas, and side effects.\n- Use measurable performance targets when performance matters.\n\n## Functional Requirements\n\n- FR-1: The system must... Related: US-001\n- FR-2: When..., the system must... Related: US-002, US-003\n\nEvery functional requirement must have a stable `FR-*` ID and map to at least one user story, acceptance criterion, testing-plan item, or execution-sequence item.\n\n## Technical Decisions\n\nDocument only relevant decisions: affected modules\u002Finterfaces, contracts, dependencies, migrations, rollout, compatibility, security\u002Fprivacy, observability, performance, UI\u002Faccessibility, and rationale tied to discovered patterns.\n\nDefine each schema, key format, identifier, or contract in one canonical place and reference it elsewhere. For cleanup, retries, fallbacks, cancellation, or recovery, specify triggers, guarantees, limits, and non-goals. For observability, specify event conditions, severity\u002Fcardinality, and rate limits when relevant.\n\nDo not include file paths or code unless necessary to capture a decision precisely.\n\n## Definition of Done\n\n- Relevant build, typecheck, lint, and test commands pass, using exact commands when inferable.\n- Required behavior is covered by automated tests at the highest practical seam.\n- Edge\u002Ffailure cases listed in this PRD are verified.\n- For UI changes, browser verification using playwright-cli skill is completed.\n- Rollout, migration, cleanup, compatibility, observability, privacy\u002Fsecurity, and accessibility requirements are satisfied where applicable.\n\n## Execution Sequence\n\nList user stories or requirement groups in recommended implementation order.\n\nFor each sequence item, specify:\n\n- IDs covered, such as `US-001` or `FR-1`\n- Dependencies\n- Whether order is mandatory or recommended\n- Parallelizable work\n- Rollout, migration, cleanup, verification, or removal steps\n\nDo not imply mandatory ordering unless required by data, API, migration, rollout, safety, or compatibility constraints.\n\n## Testing Plan\n\nDescribe the highest practical test seam, preferring existing seams and minimizing new ones. Test external behavior, not implementation details. Reference similar existing tests\u002Fpatterns.\n\nWhen inferable, include exact commands\u002Fscripts, such as `npm test`, `pnpm typecheck`, `pytest path\u002Fto\u002Ftest.py`, or a repo-specific verification script. Do not invent commands.\n\nSpecify named test targets when inferable:\n\n- File\u002Fclass: `[ExactTestFileOrClass]`\n- Assertion: `[SpecificBehaviorOrContractAssertionName]`\n- Covers: `FR-*` \u002F `US-*`\n\nInclude a compact edge-case matrix when relevant: invalid inputs, missing dependencies, permissions\u002Fenvironment constraints, concurrency\u002Fraces, partial failure, fallback behavior, cleanup, and recovery.\n\n## Success Metrics\n\n- Measurable success condition\n\nFor performance metrics, specify measurement protocol: environment, input size\u002Fdataset, warm vs. cold state, percentile\u002Faverage, sample size, and threshold.\n\n## Out of Scope\n\nList what this PRD explicitly does not include.\n\n\u003C\u002Fprd-template>\n\n## Validation\n\n- [ ] Codebase context and workspace conventions were checked when available.\n- [ ] Existing PRD was not overwritten, renamed, or deleted.\n- [ ] Scope and out-of-scope items are clear.\n- [ ] Technical decisions include rationale and discovered-pattern references.\n- [ ] Sections are internally consistent across requirements, acceptance criteria, technical decisions, Definition of Done, paths, schemas, commands, and execution order.\n- [ ] Paths, schemas, commands, key formats, contracts, and rollout order are defined once and referenced consistently.\n- [ ] Functional requirements use stable IDs and map to stories, acceptance criteria, testing, or execution sequence.\n- [ ] Testing Plan names exact test files\u002Fclasses\u002Fassertions when inferable and avoids vague pass metrics.\n- [ ] Execution Sequence distinguishes mandatory dependencies from recommended order and identifies parallelizable work.\n- [ ] Edge cases and negative paths are captured in acceptance criteria or Testing Plan.\n- [ ] Exact verification commands are included when inferable; none are invented.\n- [ ] PRD saved at `.agents\u002Fscratchpad\u002F[feature-name]\u002Fprd.md` with `[feature-name]` suffixed with `-2`, `-3`, etc. if needed.\n- [ ] No existing PRD was overwritten.\n- [ ] Final response includes feature short name, PRD path, validation status, and readiness for `\u002Fspec-to-tasks`.\n","# \u002Fprd\n\nCreate an unambiguous, implementation-ready PRD from the conversation and codebase context.\n\n## Rules\n\n- Do not implement or write code.\n- Do not interview the user; make reasonable assumptions and document them. If unsafe\u002Fcontradictory, stop and report the blocker.\n- Follow existing codebase patterns. Prefer YAGNI.\n- Check available workspace conventions: `AGENTS.md`, scoped docs, repo docs, scripts, tests, existing modules\u002Fpatterns.\n- Do not invent commands, files, paths, schemas, URLs, literals, DB objects, or conventions. Use exact names only when verified or clearly inferable.\n- Define each path, schema, key format, command, contract, and rollout order in one canonical place, then reference it consistently.\n- Never overwrite, rename, or delete an existing PRD.\n- Require named test targets when inferable: exact test file\u002Fclass names and intended assertions. Avoid vague metrics such as “100% tests pass.”\n\n## Save path\n\nSave to `.agents\u002Fscratchpad\u002F[feature-name]\u002Fprd.md`, where `[feature-name]` is short kebab-case. If it exists, use `[feature-name]-2`, `-3`, etc. Create directories as needed. Verify the final file exists. If saving fails, stop and report failure.\n\n## Workflow\n\n1. Activate or load the `delegate-to-subagents` skill and delegate tasks to the most suitable subagents whenever possible.\n2. Before drafting, fill any missing codebase context by dispatching 1-3 code-explorer subagents, scaled to scope, to inspect relevant repository files and conventions.\n3. Identify existing patterns, affected modules, contracts, test seams, risks, edge cases, rollout constraints, and conflicts with workspace conventions.\n4. Draft the PRD using the template below.\n5. Validate consistency across sections, especially requirements, acceptance criteria, technical decisions, Definition of Done, paths, schemas, commands, examples, and execution order.\n6. Resolve conflicts by preferring the most specific implementation-nearest source; document assumptions. If unclear, stop and report the blocker.\n7. Save to the verified unused path.\n8. Final response: feature short name, PRD path, validation status `pass`\u002F`fail`, readiness for `\u002Fspec-to-tasks`.\n\n\u003Cprd-template>\n\n# PRD: [Feature Name]\n\n## Overview\n\nDescribe the problem, users, value, and proposed solution.\n\n## Assumptions\n\nList assumptions made because the user was not interviewed.\n\n## Goals\n\n- Specific measurable goal\n\n## User Stories\n\nList enough stories to cover user-visible capabilities, roles, states, and edge cases without turning implementation tasks into stories. Each story should describe one coherent behavior slice.\n\nFormat:\n\n```md\n### US-001: [Title]\n\n**Story:** As a [user], I want [capability] so that [benefit].\n\n**Acceptance Criteria:**\n\n- [ ] Concrete, observable behavior\n- [ ] Relevant edge\u002Ffailure case\n- [ ] Relevant build\u002Ftypecheck\u002Flint\u002Ftest commands pass, using exact commands when inferable\n- [ ] For UI: Verify in browser using playwright-cli skill\n\n**Design Guidance:**\n\n- Follow existing [pattern\u002Fmodule\u002Fcomponent] because [rationale].\n```\n\nAcceptance criteria rules:\n\n- Describe observable outcomes, not implementation steps.\n- Define done using concrete inputs, outputs, states, side effects, and success\u002Ffailure behavior.\n- Include relevant error paths: validation, permissions, timeouts, dependency failure, partial failure, invalid\u002Fcorrupted state, and recovery.\n- For CLI\u002FAPI\u002Fdata features, specify contracts: inputs, outputs, status codes, exit codes, stdout\u002Fstderr, schemas, and side effects.\n- Use measurable performance targets when performance matters.\n\n## Functional Requirements\n\n- FR-1: The system must... Related: US-001\n- FR-2: When..., the system must... Related: US-002, US-003\n\nEvery functional requirement must have a stable `FR-*` ID and map to at least one user story, acceptance criterion, testing-plan item, or execution-sequence item.\n\n## Technical Decisions\n\nDocument only relevant decisions: affected modules\u002Finterfaces, contracts, dependencies, migrations, rollout, compatibility, security\u002Fprivacy, observability, performance, UI\u002Faccessibility, and rationale tied to discovered patterns.\n\nDefine each schema, key format, identifier, or contract in one canonical place and reference it elsewhere. For cleanup, retries, fallbacks, cancellation, or recovery, specify triggers, guarantees, limits, and non-goals. For observability, specify event conditions, severity\u002Fcardinality, and rate limits when relevant.\n\nDo not include file paths or code unless necessary to capture a decision precisely.\n\n## Definition of Done\n\n- Relevant build, typecheck, lint, and test commands pass, using exact commands when inferable.\n- Required behavior is covered by automated tests at the highest practical seam.\n- Edge\u002Ffailure cases listed in this PRD are verified.\n- For UI changes, browser verification using playwright-cli skill is completed.\n- Rollout, migration, cleanup, compatibility, observability, privacy\u002Fsecurity, and accessibility requirements are satisfied where applicable.\n\n## Execution Sequence\n\nList user stories or requirement groups in recommended implementation order.\n\nFor each sequence item, specify:\n\n- IDs covered, such as `US-001` or `FR-1`\n- Dependencies\n- Whether order is mandatory or recommended\n- Parallelizable work\n- Rollout, migration, cleanup, verification, or removal steps\n\nDo not imply mandatory ordering unless required by data, API, migration, rollout, safety, or compatibility constraints.\n\n## Testing Plan\n\nDescribe the highest practical test seam, preferring existing seams and minimizing new ones. Test external behavior, not implementation details. Reference similar existing tests\u002Fpatterns.\n\nWhen inferable, include exact commands\u002Fscripts, such as `npm test`, `pnpm typecheck`, `pytest path\u002Fto\u002Ftest.py`, or a repo-specific verification script. Do not invent commands.\n\nSpecify named test targets when inferable:\n\n- File\u002Fclass: `[ExactTestFileOrClass]`\n- Assertion: `[SpecificBehaviorOrContractAssertionName]`\n- Covers: `FR-*` \u002F `US-*`\n\nInclude a compact edge-case matrix when relevant: invalid inputs, missing dependencies, permissions\u002Fenvironment constraints, concurrency\u002Fraces, partial failure, fallback behavior, cleanup, and recovery.\n\n## Success Metrics\n\n- Measurable success condition\n\nFor performance metrics, specify measurement protocol: environment, input size\u002Fdataset, warm vs. cold state, percentile\u002Faverage, sample size, and threshold.\n\n## Out of Scope\n\nList what this PRD explicitly does not include.\n\n\u003C\u002Fprd-template>\n\n## Validation\n\n- [ ] Codebase context and workspace conventions were checked when available.\n- [ ] Existing PRD was not overwritten, renamed, or deleted.\n- [ ] Scope and out-of-scope items are clear.\n- [ ] Technical decisions include rationale and discovered-pattern references.\n- [ ] Sections are internally consistent across requirements, acceptance criteria, technical decisions, Definition of Done, paths, schemas, commands, and execution order.\n- [ ] Paths, schemas, commands, key formats, contracts, and rollout order are defined once and referenced consistently.\n- [ ] Functional requirements use stable IDs and map to stories, acceptance criteria, testing, or execution sequence.\n- [ ] Testing Plan names exact test files\u002Fclasses\u002Fassertions when inferable and avoids vague pass metrics.\n- [ ] Execution Sequence distinguishes mandatory dependencies from recommended order and identifies parallelizable work.\n- [ ] Edge cases and negative paths are captured in acceptance criteria or Testing Plan.\n- [ ] Exact verification commands are included when inferable; none are invented.\n- [ ] PRD saved at `.agents\u002Fscratchpad\u002F[feature-name]\u002Fprd.md` with `[feature-name]` suffixed with `-2`, `-3`, etc. if needed.\n- [ ] No existing PRD was overwritten.\n- [ ] Final response includes feature short name, PRD path, validation status, and readiness for `\u002Fspec-to-tasks`.\n",{"name":5,"description":7,"argument-hint":48,"disable-model-invocation":49},"[\u003Cfeature or change>]",true,"main","8a912f4cf9bf915fb92e5b29671f0ed22555bcb7","skills\u002Fdefault\u002Fprd","https:\u002F\u002Fgithub.com\u002Fjapurcell\u002Fskills","https:\u002F\u002Fgithub.com\u002Fjapurcell","2026-11-11 08:59:34",{"source":8,"skillName":5,"commands":57,"prompt":67,"zipAvailable":49},[58,61,64],{"tool":59,"command":60},"npx","npx skills add japurcell\u002Fskills --skill prd",{"tool":62,"command":63},"bunx","bunx skills add japurcell\u002Fskills --skill prd",{"tool":65,"command":66},"pnpm","pnpm dlx skills add japurcell\u002Fskills --skill prd","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fjapurcell\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fdefault\u002Fprd\u002FSKILL.md",[69],{"path":70,"resourceType":71,"resourceTypeDesc":72,"sizeBytes":73,"sourceHtmlUrl":74},"agents\u002Fopenai.yaml","REFERENCE","参考文档",147,"https:\u002F\u002Fgithub.com\u002Fjapurcell\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fdefault\u002Fprd\u002Fagents\u002Fopenai.yaml",[76,94,115,143,166,187],{"skillNo":77,"name":78,"nameZh":6,"description":79,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":80,"categories":81,"keywords":83,"publishedAt":43},"01M6PT0ZTYCN4DHK3SXWS79WSY","spec-create","Create or revise a portable behavioral SPEC for a feature or whole product. Use when specifying a new idea, documenting an existing system for reimplementation, or defining a change while preserving compatibility. Implementation planning is a separate task.","https:\u002F\u002Fgithub.com\u002Fjapurcell\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fdefault\u002Fspec-create\u002FSKILL.md",[82],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[33,31,84,40,39,27,85,37,86,87,88,25,32,29,89,90,91,92,93],"spec create","system","Existing","task","output","revise","compatibility","behavioral","idea","path",{"skillNo":95,"name":96,"nameZh":6,"description":97,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":98,"categories":99,"keywords":101,"publishedAt":43},"01M6GSVHQ4MY4R4SMS8RY6324Q","prd-ralph","Complete at most one eligible unfinished PRD task, verify it, log progress, and optionally create one scoped commit.","https:\u002F\u002Fgithub.com\u002Fjapurcell\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fdefault\u002Fprd-ralph\u002FSKILL.md",[100],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[102,103,5,33,104,105,106,107,108,109,87,110,111,112,113,114,93],"prd ralph","ralph","progress","verify","at","complete","commit","it","log","scoped","false","file","id",{"skillNo":116,"name":117,"nameZh":6,"description":118,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":119,"categories":120,"keywords":124,"publishedAt":43},"01M6GSYMGHE2FEGEFKD926EJH8","fsdp-style-guide","Mandatory for all UI\u002FUX design, implementation, review, audit, or visual regression tasks. Always use for any work that affects user-facing appearance, behavior, accessibility, branding, layout, navigation, forms, dialogs, alerts, tables, or visual design.","https:\u002F\u002Fgithub.com\u002Fjapurcell\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fforest-service\u002Ffsdp-style-guide\u002FSKILL.md",[121],{"categoryNo":122,"categoryName":123,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000032","设计师",[125,126,127,128,129,130,131,132,37,133,34,134,135,136,137,138,139,140,141,142,27],"fsdp style guide","style guide","FSDP","style","guide","visual regression","regression","design","visual","review","visual design","alerts","work","branding","layout","audit","ux","behavior",{"skillNo":144,"name":145,"nameZh":6,"description":146,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":147,"categories":148,"keywords":149,"publishedAt":43},"01M6GSYHEQARNM7WN0RJA7K7T2","agency-priorities","Provide self-contained USDA strategic goals and Forest Service priorities for agency briefings, proposals, and work-plan alignment. Use when explaining agency direction or evaluating how a project contributes to USDA and Forest Service priorities.","https:\u002F\u002Fgithub.com\u002Fjapurcell\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fforest-service\u002Fagency-priorities\u002FSKILL.md",[],[150,151,152,153,154,137,155,156,157,158,159,160,161,162,37,27,163,164,165],"agency priorities","priorities","agency","self","alignment","plan","goals","proposals","direction","how","project","strategic","service","when","briefings","self-contained",{"skillNo":167,"name":168,"nameZh":6,"description":169,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":170,"categories":171,"keywords":175,"publishedAt":43},"01M6GSY9VVN8RSJ5QYM540ZJ1D","accomplishment-report","Create a concise Forest Service executive accomplishment report when all work in an ExecPlan is completed, or update its existing report. Use at ExecPlan closeout and when asked to report completed work, agency alignment, and estimated AI-assisted versus human-only time and cost savings.","https:\u002F\u002Fgithub.com\u002Fjapurcell\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fforest-service\u002Faccomplishment-report\u002FSKILL.md",[172],{"categoryNo":173,"categoryName":174,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000034","行政与办公人员",[176,177,154,178,33,137,179,180,181,182,106,152,183,162,37,184,185,186,86,163],"report","accomplishment report","cost","concise","human","time","update","only","closeout","savings","execplan",{"skillNo":188,"name":189,"nameZh":6,"description":190,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":191,"categories":192,"keywords":201,"publishedAt":43},"01M6GSY7J8ZMCE319P8Y6JZ432","writing-for-agents","Writing documents for agents. Use when creating or editing skills, or modifying AGENTS.md or CLAUDE.md.","https:\u002F\u002Fgithub.com\u002Fjapurcell\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fdefault\u002Fwriting-for-agents\u002FSKILL.md",[193,198],{"categoryNo":194,"categoryName":195,"taxonomyType":196,"taxonomyTypeDesc":197},"01JBSEEDCAT000000000000018","写作与文案","SCENARIO","使用场景",{"categoryNo":199,"categoryName":200,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000036","内容创作者",[202,203,27,37,204,205,163],"writing","writing for agents","documents","editing"]