[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71JR2BSG6W84S686RPR8AEG":3,"skill-same:01M71JR2BSG6W84S686RPR8AEG":67},{"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":18,"publishedAt":33,"linkOnly":34,"markdownContent":35,"markdownBody":36,"frontMatter":37,"refName":39,"commitSha":40,"skillDirectory":5,"forksCount":41,"repositoryHtmlUrl":42,"repositoryHomepageUrl":43,"ownerHtmlUrl":44,"ownerBlogUrl":45,"ownerDescription":46,"updatedAt":47,"install":48,"resources":60},"01M71JR2BSG6W84S686RPR8AEG","to-spec",null,"Turn the current conversation into a spec and publish it to the project issue tracker: no interview, just synthesis of what you've already discussed.","caezium\u002Fskills","caezium","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F113233555?v=4","01M71JB77ZPBAWEK009Y2W8BP7","Henry Zhang","01M71JB792NVXCWSYD27HQ0964",3,"MIT","https:\u002F\u002Fgithub.com\u002Fcaezium\u002Fskills\u002Fblob\u002Fmain\u002Fto-spec\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32],"to spec","spec","conversation","interview","project","just","true","you","publish","tracker","issue","issue tracker","it","Synthesis","2026-11-10 10:12:30",false,"---\nname: to-spec\ndescription: \"Turn the current conversation into a spec and publish it to the project issue tracker: no interview, just synthesis of what you've already discussed.\"\ndisable-model-invocation: true\n---\n\nThis skill takes the current conversation context and codebase understanding and produces a spec. Do NOT interview the user; just synthesize what you already know.\n\nThe issue tracker and triage label vocabulary should have been provided to you. If not, tell the user to run `\u002Fsetup-matt-pocock-skills`.\n\n## First principles\n\nPlease use first-principles thinking. Do not assume that I always know exactly what I want and how to achieve it. Be prudent and start from the original needs and problems. If my motivations or goals are unclear, pause and discuss with me. If the goals are clear but the path is not the shortest, tell me and suggest a better approach.\n\n## Process\n\n1. Explore the repo to understand the current state of the codebase, if you haven't already. Use the project's domain glossary vocabulary throughout the spec, and respect any ADRs in the area you're touching.\n\n2. Sketch out the seams at which you're going to test the feature. Existing seams should be preferred to new ones. Use the highest seam possible. If new seams are needed, propose them at the highest point you can. The fewer seams across the codebase, the better - the ideal number is one.\n\nCheck with the user that these seams match their expectations.\n\n3. Write the spec using the template below, then publish it to the project issue tracker. Apply the `ready-for-agent` triage label - no need for additional triage.\n\n\u003Cspec-template>\n\n## Problem Statement\n\nThe problem that the user is facing, from the user's perspective.\n\n## Solution\n\nThe solution to the problem, from the user's perspective.\n\n## User Stories\n\nA LONG, numbered list of user stories. Each user story should be in the format of:\n\n1. As an \u003Cactor>, I want a \u003Cfeature>, so that \u003Cbenefit>\n\n\u003Cuser-story-example>\n1. As a mobile bank customer, I want to see balance on my accounts, so that I can make better informed decisions about my spending\n\u003C\u002Fuser-story-example>\n\nThis list of user stories should be extremely extensive and cover all aspects of the feature.\n\n## Implementation Decisions\n\nA list of implementation decisions that were made. This can include:\n\n- The modules that will be built\u002Fmodified\n- The interfaces of those modules that will be modified\n- Technical clarifications from the developer\n- Architectural decisions\n- Schema changes\n- API contracts\n- Specific interactions\n\nDo NOT include specific file paths or code snippets. They may end up being outdated very quickly.\n\nException: if a prototype produced a snippet that encodes a decision more precisely than prose can (state machine, reducer, schema, type shape), inline it within the relevant decision and note briefly that it came from a prototype. Trim to the decision-rich parts, not a working demo, just the important bits.\n\n## Testing Decisions\n\nA list of testing decisions that were made. Include:\n\n- A description of what makes a good test (only test external behavior, not implementation details)\n- Which modules will be tested\n- Prior art for the tests (i.e. similar types of tests in the codebase)\n\n## Out of Scope\n\nA description of the things that are out of scope for this spec.\n\n## Further Notes\n\nAny further notes about the feature.\n\n\u003C\u002Fspec-template>\n","This skill takes the current conversation context and codebase understanding and produces a spec. Do NOT interview the user; just synthesize what you already know.\n\nThe issue tracker and triage label vocabulary should have been provided to you. If not, tell the user to run `\u002Fsetup-matt-pocock-skills`.\n\n## First principles\n\nPlease use first-principles thinking. Do not assume that I always know exactly what I want and how to achieve it. Be prudent and start from the original needs and problems. If my motivations or goals are unclear, pause and discuss with me. If the goals are clear but the path is not the shortest, tell me and suggest a better approach.\n\n## Process\n\n1. Explore the repo to understand the current state of the codebase, if you haven't already. Use the project's domain glossary vocabulary throughout the spec, and respect any ADRs in the area you're touching.\n\n2. Sketch out the seams at which you're going to test the feature. Existing seams should be preferred to new ones. Use the highest seam possible. If new seams are needed, propose them at the highest point you can. The fewer seams across the codebase, the better - the ideal number is one.\n\nCheck with the user that these seams match their expectations.\n\n3. Write the spec using the template below, then publish it to the project issue tracker. Apply the `ready-for-agent` triage label - no need for additional triage.\n\n\u003Cspec-template>\n\n## Problem Statement\n\nThe problem that the user is facing, from the user's perspective.\n\n## Solution\n\nThe solution to the problem, from the user's perspective.\n\n## User Stories\n\nA LONG, numbered list of user stories. Each user story should be in the format of:\n\n1. As an \u003Cactor>, I want a \u003Cfeature>, so that \u003Cbenefit>\n\n\u003Cuser-story-example>\n1. As a mobile bank customer, I want to see balance on my accounts, so that I can make better informed decisions about my spending\n\u003C\u002Fuser-story-example>\n\nThis list of user stories should be extremely extensive and cover all aspects of the feature.\n\n## Implementation Decisions\n\nA list of implementation decisions that were made. This can include:\n\n- The modules that will be built\u002Fmodified\n- The interfaces of those modules that will be modified\n- Technical clarifications from the developer\n- Architectural decisions\n- Schema changes\n- API contracts\n- Specific interactions\n\nDo NOT include specific file paths or code snippets. They may end up being outdated very quickly.\n\nException: if a prototype produced a snippet that encodes a decision more precisely than prose can (state machine, reducer, schema, type shape), inline it within the relevant decision and note briefly that it came from a prototype. Trim to the decision-rich parts, not a working demo, just the important bits.\n\n## Testing Decisions\n\nA list of testing decisions that were made. Include:\n\n- A description of what makes a good test (only test external behavior, not implementation details)\n- Which modules will be tested\n- Prior art for the tests (i.e. similar types of tests in the codebase)\n\n## Out of Scope\n\nA description of the things that are out of scope for this spec.\n\n## Further Notes\n\nAny further notes about the feature.\n\n\u003C\u002Fspec-template>\n",{"name":5,"description":7,"disable-model-invocation":38},true,"main","6ef866230c1ba3459fd08fc65141dfd37fffd41a",0,"https:\u002F\u002Fgithub.com\u002Fcaezium\u002Fskills","https:\u002F\u002Fskills.henryzh.dev","https:\u002F\u002Fgithub.com\u002Fcaezium","henryzh.dev","quant, data science, full-stack, robotics.\r\nbuilding cool stuff","2026-08-24 19:21:44",{"source":8,"skillName":5,"commands":49,"prompt":59,"zipAvailable":38},[50,53,56],{"tool":51,"command":52},"npx","npx skills add caezium\u002Fskills --skill to-spec",{"tool":54,"command":55},"bunx","bunx skills add caezium\u002Fskills --skill to-spec",{"tool":57,"command":58},"pnpm","pnpm dlx skills add caezium\u002Fskills --skill to-spec","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fcaezium\u002Fskills\u002Fblob\u002Fmain\u002Fto-spec\u002FSKILL.md",[61],{"path":62,"resourceType":63,"resourceTypeDesc":64,"sizeBytes":65,"sourceHtmlUrl":66},"agents\u002Fopenai.yaml","REFERENCE","参考文档",135,"https:\u002F\u002Fgithub.com\u002Fcaezium\u002Fskills\u002Fblob\u002Fmain\u002Fto-spec\u002Fagents\u002Fopenai.yaml",[68,92,120,138,159,181],{"skillNo":69,"name":70,"nameZh":6,"description":71,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":72,"categories":73,"keywords":84,"publishedAt":33},"01M71JT4RYCAS18RF6003YYR1D","writing-for-agents","Writing documents for agents. Use when creating or editing skills, or modifying AGENTS.md or CLAUDE.md.","https:\u002F\u002Fgithub.com\u002Fcaezium\u002Fskills\u002Fblob\u002Fmain\u002Fwriting-for-agents\u002FSKILL.md",[74,79],{"categoryNo":75,"categoryName":76,"taxonomyType":77,"taxonomyTypeDesc":78},"01JBSEEDCAT000000000000018","写作与文案","SCENARIO","使用场景",{"categoryNo":80,"categoryName":81,"taxonomyType":82,"taxonomyTypeDesc":83},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",[85,86,87,88,89,90,91],"writing for agents","for","writing","editing","use","documents","when",{"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":101,"publishedAt":33},"01M71JT0GES4AZ5ADH8EADNN1Z","wrangler","Cloudflare Workers CLI for deploying, developing, and managing Workers, KV, R2, D1, Vectorize, Hyperdrive, Workers AI, Containers, Queues, Workflows, Pipelines, and Secrets Store. Load before running wrangler commands to ensure correct syntax and best practices. Biases towards retrieval from Cloudflare docs over pre-trained knowledge.","https:\u002F\u002Fgithub.com\u002Fcaezium\u002Fskills\u002Fblob\u002Fmain\u002Fwrangler\u002FSKILL.md",[98],{"categoryNo":99,"categoryName":100,"taxonomyType":77,"taxonomyTypeDesc":78},"01JBSEEDCAT000000000000010","后端与接口",[94,102,103,104,105,106,107,108,109,110,111,112,113,86,114,115,116,117,118,119],"cloudflare","d1","knowledge","workflows","cli","secrets","commands","syntax","cloudflare workers","r2","queues","running","containers","correct","load","workers","best practices","store",{"skillNo":121,"name":122,"nameZh":6,"description":123,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":124,"categories":125,"keywords":126,"publishedAt":33},"01M71JSWX4R203M32K9A18AAW8","workers-best-practices","Reviews and authors Cloudflare Workers code against production best practices. Load when writing new Workers, reviewing Worker code, configuring wrangler.jsonc, or checking for common Workers anti-patterns (streaming, floating promises, global state, secrets, bindings, observability). Biases towards retrieval from Cloudflare docs over pre-trained knowledge.","https:\u002F\u002Fgithub.com\u002Fcaezium\u002Fskills\u002Fblob\u002Fmain\u002Fworkers-best-practices\u002FSKILL.md",[],[127,117,118,128,129,130,86,102,131,104,132,94,87,116,91,133,134,135,136,137],"workers best practices","observability","reviews","promises","worker","new","code","common","streaming","state","anti-patterns",{"skillNo":139,"name":140,"nameZh":6,"description":141,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":142,"categories":143,"keywords":144,"publishedAt":33},"01M71JST6P88MXGT2MWDTPJGEG","wizard","Generate an interactive bash wizard that walks a human through steps only they can perform. Use when provisioning infrastructure, setting up credentials or CI secrets, walking an unfamiliar third-party dashboard, or running a one-off migration or cutover. Don't invoke this for steps the agent can perform itself.","https:\u002F\u002Fgithub.com\u002Fcaezium\u002Fskills\u002Fblob\u002Fmain\u002Fwizard\u002FSKILL.md",[],[140,113,145,86,146,147,148,149,89,150,91,151,152,153,154,155,156,157,158,107],"setting","up","ci","provisioning infrastructure","only","invoke","Bash","one","interactive","can","credentials","dashboard","generate","human",{"skillNo":160,"name":161,"nameZh":6,"description":162,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":163,"sourceHtmlUrl":164,"categories":165,"keywords":166,"publishedAt":33},"01M71JSQ95S7BQ61DAPN95X2W4","why","Use for 'why does X work this way', 'why we picked Y', design rationale, regressions, postmortems, or data-backed thresholds. Discovers available evidence sources, searches each relevant category, and returns a cited read on decisions and tradeoffs. Use how for runtime behavior.","https:\u002F\u002Fgithub.com\u002Fcaezium\u002Fskills\u002Fblob\u002Fmain\u002Fwhy\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fcaezium\u002Fskills\u002Fblob\u002Fmain\u002Fwhy\u002FSKILL.md",[],[161,167,168,169,170,86,171,172,89,173,174,175,176,177,178,179,180],"sources","thresholds","evidence","relevant","runtime","design","decisions","work","how","behavior","read","data","rationale","returns",{"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":190,"publishedAt":33},"01M71JSMHFVSH8HK8GXN6YAX6J","week-prep","Generate a briefing with calendar, tasks, and attention flags. Use for \"week prep\", \"briefing\", or \"what's on this week\".","https:\u002F\u002Fgithub.com\u002Fcaezium\u002Fskills\u002Fblob\u002Fmain\u002Fweek-prep\u002FSKILL.md",[187],{"categoryNo":188,"categoryName":189,"taxonomyType":77,"taxonomyTypeDesc":78},"01JBSEEDCAT000000000000023","Skill与智能体开发",[191,192,193,194,195,86,196,197,198,199,89,151,200,201,202,157,203,177,204,205],"week prep","prep","deep","attention","get","search","messages","briefing","MCP","tasks","with","slack","calendar","flags","grep"]