[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6PT0ZTYCN4DHK3SXWS79WSY":3,"skill-same:01M6PT0ZTYCN4DHK3SXWS79WSY":91},{"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":49,"commitSha":50,"skillDirectory":51,"forksCount":14,"repositoryHtmlUrl":52,"repositoryHomepageUrl":6,"ownerHtmlUrl":53,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":54,"install":55,"resources":68},"01M6PT0ZTYCN4DHK3SXWS79WSY","spec-create",null,"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.","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\u002Fspec-create\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000031","产品经理","PROFESSION","适用职业",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42],"spec create","create","spec","compatibility","Existing","for","path","output","revise","feature","task","idea","implementation","behavioral","use","system","product","planning","change","2026-11-10 10:12:30",false,"---\nname: spec-create\ndescription: 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.\nargument-hint: \"[\u003Cfeature, product, or existing spec>] [\u003Coutput path>]\"\n---\n\n# spec-create\n\nWrite a Markdown contract that an independent team can implement and check using only the SPEC and its declared public contracts. A planner should be able to choose a different language, architecture, or test framework without renegotiating behavior.\n\n## Choose the boundary and destination\n\nIdentify who uses the system, through which interfaces, and what outcomes are in scope. For a feature, include the callers and neighboring behavior the feature can affect. For a product, define shared rules once and cover journeys that cross feature boundaries.\n\nUse an explicit output path first. Otherwise, revise the existing canonical spec for this scope in place or follow the project's established spec location. If neither exists, use:\n\n- Product: `SPEC.md` at the project root.\n- Feature: `docs\u002Fspecs\u002F\u003Cshort-kebab-case-feature-name>\u002FSPEC.md`, for example `docs\u002Fspecs\u002Fjob-cancellation\u002FSPEC.md`.\n\nRead an existing spec before editing. Preserve unrelated contracts, conformance cases, and useful organization. Check that the chosen file belongs to this scope before writing.\n\n## Establish what the spec can promise\n\n- **New idea.** Draft the behavior supported by the request and declared public contracts. Ask only about unresolved choices that would change a caller's experience or the verdict of a conformance check. Group independent questions in one round and continue drafting settled parts.\n- **Existing system.** Start at its normal entry points. Use current docs, callers, tests, and code to identify compatibility cases, then exercise them where practical. Capture concrete inputs, outputs, visible effects, and relevant failure or recovery behavior. Distinguish direct observations, reported observations, and inferences. If the system is unavailable, identify what could not be checked.\n- **Change to an existing system.** Establish that baseline for the affected scope. Identify what callers can still rely on, what intentionally changes, and what happens to existing callers, data, or in-flight work where relevant. Apply existing rules to the change without silently extending them. A single example can demonstrate an outcome without establishing a general policy. If two plausible policies produce different results, find a distinguishing case or ask.\n\nWhen evidence disagrees, record the competing behaviors and investigate caller reliance. If the intended contract remains unclear, ask which behavior to preserve. Keep the decision open and the spec in **Draft**. Silence, an implementation accident, and an inability to run the system do not authorize a new promise.\n\n## Write the contract\n\nUse descriptive headings for scope, observable behavior, and conformance cases. Add sections such as state transitions, interfaces, failures, or compatibility only where they carry distinct obligations. A small feature may need just a few rules.\n\nUse `MUST` for requirements, `SHOULD` for recommendations with reasons to depart, and `MAY` for permitted choices. State exact formats, names, units, limits, or protocols when users, callers, or integrations rely on them. Express other constraints through their effects. For example, preserve a public `job_id` field and say whether an accepted job survives restart. Leave the storage engine to the planner.\n\nDescribe deliberate variation precisely enough to judge either implementation. If listing order is immaterial, require each eligible item exactly once and allow any order. If callers depend on knowing an implementation's chosen policy, require the implementation to document it. Keep unresolved decisions distinct from permitted variation.\n\nGive every required behavior an observable pass\u002Ffail criterion. Under the relevant heading or in a conformance section, state the initial conditions, action, and expected result or allowed range. Use ordinary prose, examples, or a compact table. Refer to behaviors by descriptive headings and case descriptions, without assigning per-behavior IDs. Include relevant failure, recovery, compatibility, and cross-feature cases. For an optional capability, make its checks conditional on providing it.\n\nIf source paths, test names, observations, or verification gaps help explain a decision, collect them in a short **informational** appendix. Keep the normative contract intelligible without that appendix or access to the original repository.\n\n## Decide whether it is ready for planning\n\nRead the spec as two independent implementers. Find a concrete input, failure, or sequence where both could follow the text and produce materially different outcomes. Try relevant boundaries such as a retry after a lost response, a restart mid-operation, or competing requests. For each difference, tighten the rule and its check, explicitly allow both outcomes, or surface the unresolved choice.\n\nMark the spec **Ready for planning** only when each required behavior has a check, compatibility obligations are accounted for, and no material decision remains open. Otherwise save a **Draft** with the unresolved questions, their consequences, and any gaps in the baseline evidence. Report the file, status, and decisions needed. Building an implementation, choosing its tests, and proving it passes belong to downstream work.\n","# spec-create\n\nWrite a Markdown contract that an independent team can implement and check using only the SPEC and its declared public contracts. A planner should be able to choose a different language, architecture, or test framework without renegotiating behavior.\n\n## Choose the boundary and destination\n\nIdentify who uses the system, through which interfaces, and what outcomes are in scope. For a feature, include the callers and neighboring behavior the feature can affect. For a product, define shared rules once and cover journeys that cross feature boundaries.\n\nUse an explicit output path first. Otherwise, revise the existing canonical spec for this scope in place or follow the project's established spec location. If neither exists, use:\n\n- Product: `SPEC.md` at the project root.\n- Feature: `docs\u002Fspecs\u002F\u003Cshort-kebab-case-feature-name>\u002FSPEC.md`, for example `docs\u002Fspecs\u002Fjob-cancellation\u002FSPEC.md`.\n\nRead an existing spec before editing. Preserve unrelated contracts, conformance cases, and useful organization. Check that the chosen file belongs to this scope before writing.\n\n## Establish what the spec can promise\n\n- **New idea.** Draft the behavior supported by the request and declared public contracts. Ask only about unresolved choices that would change a caller's experience or the verdict of a conformance check. Group independent questions in one round and continue drafting settled parts.\n- **Existing system.** Start at its normal entry points. Use current docs, callers, tests, and code to identify compatibility cases, then exercise them where practical. Capture concrete inputs, outputs, visible effects, and relevant failure or recovery behavior. Distinguish direct observations, reported observations, and inferences. If the system is unavailable, identify what could not be checked.\n- **Change to an existing system.** Establish that baseline for the affected scope. Identify what callers can still rely on, what intentionally changes, and what happens to existing callers, data, or in-flight work where relevant. Apply existing rules to the change without silently extending them. A single example can demonstrate an outcome without establishing a general policy. If two plausible policies produce different results, find a distinguishing case or ask.\n\nWhen evidence disagrees, record the competing behaviors and investigate caller reliance. If the intended contract remains unclear, ask which behavior to preserve. Keep the decision open and the spec in **Draft**. Silence, an implementation accident, and an inability to run the system do not authorize a new promise.\n\n## Write the contract\n\nUse descriptive headings for scope, observable behavior, and conformance cases. Add sections such as state transitions, interfaces, failures, or compatibility only where they carry distinct obligations. A small feature may need just a few rules.\n\nUse `MUST` for requirements, `SHOULD` for recommendations with reasons to depart, and `MAY` for permitted choices. State exact formats, names, units, limits, or protocols when users, callers, or integrations rely on them. Express other constraints through their effects. For example, preserve a public `job_id` field and say whether an accepted job survives restart. Leave the storage engine to the planner.\n\nDescribe deliberate variation precisely enough to judge either implementation. If listing order is immaterial, require each eligible item exactly once and allow any order. If callers depend on knowing an implementation's chosen policy, require the implementation to document it. Keep unresolved decisions distinct from permitted variation.\n\nGive every required behavior an observable pass\u002Ffail criterion. Under the relevant heading or in a conformance section, state the initial conditions, action, and expected result or allowed range. Use ordinary prose, examples, or a compact table. Refer to behaviors by descriptive headings and case descriptions, without assigning per-behavior IDs. Include relevant failure, recovery, compatibility, and cross-feature cases. For an optional capability, make its checks conditional on providing it.\n\nIf source paths, test names, observations, or verification gaps help explain a decision, collect them in a short **informational** appendix. Keep the normative contract intelligible without that appendix or access to the original repository.\n\n## Decide whether it is ready for planning\n\nRead the spec as two independent implementers. Find a concrete input, failure, or sequence where both could follow the text and produce materially different outcomes. Try relevant boundaries such as a retry after a lost response, a restart mid-operation, or competing requests. For each difference, tighten the rule and its check, explicitly allow both outcomes, or surface the unresolved choice.\n\nMark the spec **Ready for planning** only when each required behavior has a check, compatibility obligations are accounted for, and no material decision remains open. Otherwise save a **Draft** with the unresolved questions, their consequences, and any gaps in the baseline evidence. Report the file, status, and decisions needed. Building an implementation, choosing its tests, and proving it passes belong to downstream work.\n",{"name":5,"description":7,"argument-hint":48},"[\u003Cfeature, product, or existing spec>] [\u003Coutput path>]","main","d780499db4f8a16fdc74317b54bc44b5aa6df948","skills\u002Fdefault\u002Fspec-create","https:\u002F\u002Fgithub.com\u002Fjapurcell\u002Fskills","https:\u002F\u002Fgithub.com\u002Fjapurcell","2026-11-13 07:27:52",{"source":8,"skillName":5,"commands":56,"prompt":66,"zipAvailable":67},[57,60,63],{"tool":58,"command":59},"npx","npx skills add japurcell\u002Fskills --skill spec-create",{"tool":61,"command":62},"bunx","bunx skills add japurcell\u002Fskills --skill spec-create",{"tool":64,"command":65},"pnpm","pnpm dlx skills add japurcell\u002Fskills --skill spec-create","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fjapurcell\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fdefault\u002Fspec-create\u002FSKILL.md",true,[69,75,79,83,87],{"path":70,"resourceType":71,"resourceTypeDesc":72,"sizeBytes":73,"sourceHtmlUrl":74},"evals\u002Fevals.json","REFERENCE","参考文档",3703,"https:\u002F\u002Fgithub.com\u002Fjapurcell\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fdefault\u002Fspec-create\u002Fevals\u002Fevals.json",{"path":76,"resourceType":71,"resourceTypeDesc":72,"sizeBytes":77,"sourceHtmlUrl":78},"evals\u002Ffixtures\u002Fcollapse-lines\u002FREADME.md",442,"https:\u002F\u002Fgithub.com\u002Fjapurcell\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fdefault\u002Fspec-create\u002Fevals\u002Ffixtures\u002Fcollapse-lines\u002FREADME.md",{"path":80,"resourceType":71,"resourceTypeDesc":72,"sizeBytes":81,"sourceHtmlUrl":82},"evals\u002Ffixtures\u002Flabel-export\u002Fcontracts\u002Flabels.md",347,"https:\u002F\u002Fgithub.com\u002Fjapurcell\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fdefault\u002Fspec-create\u002Fevals\u002Ffixtures\u002Flabel-export\u002Fcontracts\u002Flabels.md",{"path":84,"resourceType":71,"resourceTypeDesc":72,"sizeBytes":85,"sourceHtmlUrl":86},"evals\u002Ffixtures\u002Flabel-export\u002Fsupport.md",257,"https:\u002F\u002Fgithub.com\u002Fjapurcell\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fdefault\u002Fspec-create\u002Fevals\u002Ffixtures\u002Flabel-export\u002Fsupport.md",{"path":88,"resourceType":71,"resourceTypeDesc":72,"sizeBytes":89,"sourceHtmlUrl":90},"evals\u002FREADME.md",1136,"https:\u002F\u002Fgithub.com\u002Fjapurcell\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fdefault\u002Fspec-create\u002Fevals\u002FREADME.md",[92,114,143,166,187,206],{"skillNo":93,"name":94,"nameZh":6,"description":95,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":96,"categories":97,"keywords":99,"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",[98],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[100,101,102,25,103,104,105,106,107,108,34,109,110,111,112,113,30],"prd ralph","ralph","prd","progress","verify","at","complete","commit","it","log","scoped","false","file","id",{"skillNo":115,"name":116,"nameZh":6,"description":117,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":118,"categories":119,"keywords":123,"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",[120],{"categoryNo":121,"categoryName":122,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000032","设计师",[124,125,126,127,128,129,130,131,38,132,133,134,135,136,137,138,139,140,141,142,29],"fsdp style guide","style guide","FSDP","style","guide","visual regression","regression","design","visual","tasks","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,38,29,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,25,137,179,180,181,182,105,152,183,162,38,184,185,186,28,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,29,38,204,205,163],"writing","writing for agents","documents","editing",{"skillNo":207,"name":208,"nameZh":6,"description":209,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":210,"categories":211,"keywords":212,"publishedAt":43},"01M6GSY44J636RZ4NEVAC6KTG3","web-performance","Optimize web performance for faster loading and better user experience. Use when asked to \"speed up my site\", \"optimize performance\", \"reduce load time\", \"fix slow loading\", \"improve page speed\", or \"performance audit\".","https:\u002F\u002Fgithub.com\u002Fjapurcell\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fdefault\u002Fweb-performance\u002FSKILL.md",[],[213,214,215,216,181,217,218,219,220,140,221,222,223,224,38,225,226,227,228,229,163,230,231,29],"performance","web performance","web","loading","up","fix","improve","optimize","user experience","my","page","speed","load","quality","optimize web","site","user","reduce","performance audit"]