[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71MNRSGX0V19ZDAF7NDW2EY":3,"skill-same:01M71MNRSGX0V19ZDAF7NDW2EY":64},{"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":29,"linkOnly":30,"markdownContent":31,"markdownBody":32,"frontMatter":33,"refName":37,"commitSha":38,"skillDirectory":39,"forksCount":14,"repositoryHtmlUrl":40,"repositoryHomepageUrl":6,"ownerHtmlUrl":41,"ownerBlogUrl":42,"ownerDescription":43,"updatedAt":44,"install":45,"resources":57},"01M71MNRSGX0V19ZDAF7NDW2EY","to-spec",null,"Synthesize accepted conversation and planning decisions into a versioned specification without restarting the interview.","bbishdotdev\u002Fai-tools","bbishdotdev","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F5323528?v=4","01M71MHYW2Q0DVZA22Q79M8KER","Brenden Bishop","01M71MHYWSMQWFPGA8CBJYQANH",0,"MIT","https:\u002F\u002Fgithub.com\u002Fbbishdotdev\u002Fai-tools\u002Fblob\u002Fmain\u002Fbstack\u002Fsdlc\u002Fskills\u002Fto-spec\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28],"to spec","spec","conversation","interview","true","planning","decisions","synthesize","specification","attribution","2026-11-10 10:56:23",false,"---\nname: to-spec\ndescription: Synthesize accepted conversation and planning decisions into a versioned specification without restarting the interview.\ndisable-model-invocation: true\nmetadata:\n  author: Brenden Bishop\n  attribution: ..\u002F..\u002F..\u002FATTRIBUTION.md\n---\n\n# To spec\n\nSynthesize what is already known. Do not restart the design interview. Read [workspace access](..\u002F..\u002F..\u002Fshared\u002Freferences\u002Fworkspace.md), [work adapters](..\u002F..\u002F..\u002Fshared\u002Freferences\u002Fwork-adapters.md), and [decision authority](..\u002F..\u002F..\u002Fshared\u002Freferences\u002Fdecision-authority.md). Specs belong to the planning adapter; tickets can use a different provider later.\n\nRead the referenced decisions and relevant glossary\u002FADRs. Reuse adequate code grounding. Identify the highest existing behavioral test seam that can verify the feature, preferring fewer seams. Confirm a new material testing choice with the decision owner unless it is already agreed or delegated. Missing product decisions remain explicit open points in a draft; do not invent them to obtain approval.\n\nWrite the spec with:\n\n- The user's problem and proposed outcome.\n- User stories covering the accepted behaviors and meaningful edge cases, without padding the list.\n- Settled implementation decisions and contracts.\n- Testing decisions, behavioral acceptance, and relevant test precedents.\n- Scope exclusions and remaining notes or unresolved decisions.\n\nUse domain concepts and interfaces instead of brittle file paths or line numbers. A small prototype state machine, schema, or type can stay inline when it expresses an accepted decision better than prose. Trim demo controls and link the runnable reference separately.\n\nStore the authoritative Markdown with `spec.create` or `spec.update`, linking the exact planning questions and artifact references. Use the existing record when revising a spec. Do not create a parallel Markdown source of truth; export only when requested.\n\nFor acceptance, acquire the spec claim and read each declared question's current accepted answer. Use the [shared request helper](..\u002F..\u002F..\u002Fshared\u002Freferences\u002Fworkspace-requests.md) to call `spec.approve` with the spec and question receipts as bases and actual decision authority as input. Code derives the exact `questionSources`; do not recreate that logic. Use prior explicit approval when it covers this body; otherwise present the draft for approval. A settled subset is sufficient and does not require finishing the whole map. Missing answers or stale sources keep the spec unapproved.\n\nReturn the spec reference and whether it is draft or approved. Approval preserves an immutable revision and may feed [to-tickets](..\u002Fto-tickets\u002FSKILL.md); it is not permission to implement.\n","# To spec\n\nSynthesize what is already known. Do not restart the design interview. Read [workspace access](..\u002F..\u002F..\u002Fshared\u002Freferences\u002Fworkspace.md), [work adapters](..\u002F..\u002F..\u002Fshared\u002Freferences\u002Fwork-adapters.md), and [decision authority](..\u002F..\u002F..\u002Fshared\u002Freferences\u002Fdecision-authority.md). Specs belong to the planning adapter; tickets can use a different provider later.\n\nRead the referenced decisions and relevant glossary\u002FADRs. Reuse adequate code grounding. Identify the highest existing behavioral test seam that can verify the feature, preferring fewer seams. Confirm a new material testing choice with the decision owner unless it is already agreed or delegated. Missing product decisions remain explicit open points in a draft; do not invent them to obtain approval.\n\nWrite the spec with:\n\n- The user's problem and proposed outcome.\n- User stories covering the accepted behaviors and meaningful edge cases, without padding the list.\n- Settled implementation decisions and contracts.\n- Testing decisions, behavioral acceptance, and relevant test precedents.\n- Scope exclusions and remaining notes or unresolved decisions.\n\nUse domain concepts and interfaces instead of brittle file paths or line numbers. A small prototype state machine, schema, or type can stay inline when it expresses an accepted decision better than prose. Trim demo controls and link the runnable reference separately.\n\nStore the authoritative Markdown with `spec.create` or `spec.update`, linking the exact planning questions and artifact references. Use the existing record when revising a spec. Do not create a parallel Markdown source of truth; export only when requested.\n\nFor acceptance, acquire the spec claim and read each declared question's current accepted answer. Use the [shared request helper](..\u002F..\u002F..\u002Fshared\u002Freferences\u002Fworkspace-requests.md) to call `spec.approve` with the spec and question receipts as bases and actual decision authority as input. Code derives the exact `questionSources`; do not recreate that logic. Use prior explicit approval when it covers this body; otherwise present the draft for approval. A settled subset is sufficient and does not require finishing the whole map. Missing answers or stale sources keep the spec unapproved.\n\nReturn the spec reference and whether it is draft or approved. Approval preserves an immutable revision and may feed [to-tickets](..\u002Fto-tickets\u002FSKILL.md); it is not permission to implement.\n",{"name":5,"metadata":34,"description":7,"disable-model-invocation":36},{"author":12,"attribution":35},"..\u002F..\u002F..\u002FATTRIBUTION.md",true,"main","e7c8126d1ad4df934236dba12521dcbe7fcd9d74","bstack\u002Fsdlc\u002Fskills\u002Fto-spec","https:\u002F\u002Fgithub.com\u002Fbbishdotdev\u002Fai-tools","https:\u002F\u002Fgithub.com\u002Fbbishdotdev","bbish.dev","Husband | Father | Technologist\r\nEngineering leader helping product and delivery teams use AI to build better systems, habits, and tools.","2026-11-11 11:13:39",{"source":8,"skillName":5,"commands":46,"prompt":56,"zipAvailable":36},[47,50,53],{"tool":48,"command":49},"npx","npx skills add bbishdotdev\u002Fai-tools --skill to-spec",{"tool":51,"command":52},"bunx","bunx skills add bbishdotdev\u002Fai-tools --skill to-spec",{"tool":54,"command":55},"pnpm","pnpm dlx skills add bbishdotdev\u002Fai-tools --skill to-spec","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fbbishdotdev\u002Fai-tools\u002Fblob\u002Fmain\u002Fbstack\u002Fsdlc\u002Fskills\u002Fto-spec\u002FSKILL.md",[58],{"path":59,"resourceType":60,"resourceTypeDesc":61,"sizeBytes":62,"sourceHtmlUrl":63},"agents\u002Fopenai.yaml","REFERENCE","参考文档",43,"https:\u002F\u002Fgithub.com\u002Fbbishdotdev\u002Fai-tools\u002Fblob\u002Fmain\u002Fbstack\u002Fsdlc\u002Fskills\u002Fto-spec\u002Fagents\u002Fopenai.yaml",[65,96,107,123,156,179],{"skillNo":66,"name":67,"nameZh":6,"description":68,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":69,"categories":70,"keywords":76,"publishedAt":29},"01M71MT5NBY3RY660EA06K9CA1","why","Use for 'why does X work this way', 'why we picked Y', design rationale, regressions, postmortems, or data-backed thresholds. Discovers available MCPs and queries each evidence category (source control, issue tracker, long-form docs, real-time chat, infrastructure observability, error tracking, product analytics warehouse) in parallel, then returns a cited read on decisions and tradeoffs. Use how for runtime behavior.","https:\u002F\u002Fgithub.com\u002Fbbishdotdev\u002Fai-tools\u002Fblob\u002Fmain\u002Fbstack\u002Fupstream\u002Fpstack\u002Fskills\u002Fwhy\u002FSKILL.md",[71],{"categoryNo":72,"categoryName":73,"taxonomyType":74,"taxonomyTypeDesc":75},"01JBSEEDCAT000000000000033","数据分析师","PROFESSION","适用职业",[67,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95],"how","parallel","observability","warehouse","returns","infrastructure","source","analytics","data","issue","read","tracker","product","work","design","product analytics","time","error tracking","error",{"skillNo":97,"name":98,"nameZh":6,"description":99,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":100,"categories":101,"keywords":102,"publishedAt":29},"01M71MT4CFF7AK4TRV40P7ZZ30","unslop","Cut AI tells from any writing. Must always apply.","https:\u002F\u002Fgithub.com\u002Fbbishdotdev\u002Fai-tools\u002Fblob\u002Fmain\u002Fbstack\u002Fupstream\u002Fpstack\u002Fskills\u002Funslop\u002FSKILL.md",[],[98,103,23,104,105,106],"cut","ai tells","apply","writing",{"skillNo":108,"name":109,"nameZh":6,"description":110,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":111,"categories":112,"keywords":113,"publishedAt":29},"01M71MT37W015EGE0EB82JQYAM","typescript-best-practices","TypeScript best practices. Use when reading or editing any .ts or .tsx file.","https:\u002F\u002Fgithub.com\u002Fbbishdotdev\u002Fai-tools\u002Fblob\u002Fmain\u002Fbstack\u002Fupstream\u002Fpstack\u002Fskills\u002Ftypescript-best-practices\u002FSKILL.md",[],[114,115,116,117,118,119,120,121,23,122],"typescript","typescript best practices","best practices","use","tsx","when","editing","file","reading",{"skillNo":124,"name":125,"nameZh":6,"description":126,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":127,"categories":128,"keywords":140,"publishedAt":29},"01M71MT1092N34HQMGECW170JP","technical-writing","Layered technical-writing standard: Diátaxis structure, Google developer style sentences, STE instruction rules, Global English syntax. Use for \u002Ftechnical-writing or when writing or reviewing docs, RFCs, readmes, PR descriptions, or commit messages.","https:\u002F\u002Fgithub.com\u002Fbbishdotdev\u002Fai-tools\u002Fblob\u002Fmain\u002Fbstack\u002Fupstream\u002Fpstack\u002Fskills\u002Ftechnical-writing\u002FSKILL.md",[129,134,137],{"categoryNo":130,"categoryName":131,"taxonomyType":132,"taxonomyTypeDesc":133},"01JBSEEDCAT000000000000018","写作与文案","SCENARIO","使用场景",{"categoryNo":135,"categoryName":136,"taxonomyType":74,"taxonomyTypeDesc":75},"01JBSEEDCAT000000000000030","开发工程师",{"categoryNo":138,"categoryName":139,"taxonomyType":74,"taxonomyTypeDesc":75},"01JBSEEDCAT000000000000036","内容创作者",[141,106,142,143,144,145,146,147,148,149,119,150,151,117,23,152,125,153,154,155],"technical","technical writing","commit messages","google","syntax","style","structure","layered","english","commit","Rules","messages","for","pr","standard",{"skillNo":157,"name":158,"nameZh":6,"description":159,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":160,"categories":161,"keywords":165,"publishedAt":29},"01M71MSYRMT7KZPQFY7A2ZHGMB","teach","Explain a body of work plainly so a person actually understands it. Runs the `how` and `why` skills and weaves what they find into one clear explanation. Use for 'teach me this', 'help me really understand X', 'explain this change or subsystem to me'.","https:\u002F\u002Fgithub.com\u002Fbbishdotdev\u002Fai-tools\u002Fblob\u002Fmain\u002Fbstack\u002Fupstream\u002Fpstack\u002Fskills\u002Fteach\u002FSKILL.md",[162],{"categoryNo":163,"categoryName":164,"taxonomyType":74,"taxonomyTypeDesc":75},"01JBSEEDCAT000000000000039","教师与教育",[158,153,77,166,167,168,90,169,170,171,172,173,117,174,175,23,176,177,67,178],"me","explanation","change","help","one","it","explain","body","teach me","understand","clear","person","find",{"skillNo":180,"name":181,"nameZh":6,"description":182,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":183,"categories":184,"keywords":185,"publishedAt":29},"01M71MSWTVAEVMZAG7SMWFE1FE","tdd","Use only when the user explicitly asks for TDD, a failing test, or a regression test, OR when the bug has an obvious cheap local test target. Skip when the test path is unclear, expensive, integration-heavy, or not requested.","https:\u002F\u002Fgithub.com\u002Fbbishdotdev\u002Fai-tools\u002Fblob\u002Fmain\u002Fbstack\u002Fupstream\u002Fpstack\u002Fskills\u002Ftdd\u002FSKILL.md",[],[181,117,186,187,188,119,189,23,190,191,192,193,194,153,195,196],"path","user","regression test","only","local","failing","bug","integration","regression","target","test"]