[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71SV4F5YVCZP8KQ0J9Z948D":3,"skill-same:01M71SV4F5YVCZP8KQ0J9Z948D":79},{"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":28,"publishedAt":43,"linkOnly":44,"markdownContent":45,"markdownBody":46,"frontMatter":47,"refName":49,"commitSha":50,"skillDirectory":51,"forksCount":52,"repositoryHtmlUrl":53,"repositoryHomepageUrl":54,"ownerHtmlUrl":55,"ownerBlogUrl":56,"ownerDescription":57,"updatedAt":58,"install":59,"resources":72},"01M71SV4F5YVCZP8KQ0J9Z948D","trd-writing",null,"Author Technical Requirements Documents (TRDs) — turn a settled PRD into interfaces, data shapes, failure modes, and constraints in docs\u002Ftrds\u002FNNNN-*.md","HigorAlves\u002Forc","HigorAlves","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F11262976?v=4","01M71S79EZEMHZ8PQSV0XQJHYY","Higor Alves","01M71S79FKKTCHCN1EDR8DSTWQ",7,"MIT","https:\u002F\u002Fgithub.com\u002FHigorAlves\u002Forc\u002Fblob\u002Fmain\u002Forc\u002Fskills\u002Ftrd-writing\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",[29,30,31,32,33,34,35,36,37,38,39,40,41,42],"writing","trd writing","documents","write","data","for","modes","technical","use","requirements","author","docs","prd","constraints","2026-11-10 13:02:02",false,"---\nname: trd-writing\ndescription: Author Technical Requirements Documents (TRDs) — turn a settled PRD into interfaces, data shapes, failure modes, and constraints in docs\u002Ftrds\u002FNNNN-*.md\nwhen_to_use: Use for \"write a TRD\" or \u002Forc:trd.\n---\n\n# TRD Writing\n\n> **Defer to `orc:doc-writing`** for the shared scaffolding: the doc-type map (TRD vs PRD vs RFC vs ADR vs postmortem, and how TRD differs from each), the shared section outline, the `docs\u002F\u003Ctype>s\u002FNNNN-*.md` numbering & publication convention, and the review gates. This skill carries only the TRD-specific template, fields, and tone.\n\nA TRD turns \"what & why\" into \"what we will build, technically.\" It pins down interfaces, data, failure modes, and constraints — the things engineering will commit to producing — *before* the design debate (RFC) or the implementation breakdown (plan).\n\nA good TRD lets a reviewer say \"yes, this contract solves the PRD\" without having to read code, and lets the next person to write the RFC or plan start from a stable surface area.\n\n## When to write one\n\nWrite a TRD when **all** of these are true:\n\n- A **PRD (or equivalent product spec) has settled the \"what & why\"** — you're not still arguing about audience or scope.\n- The work introduces **non-trivial technical surface area** — new APIs, new data model, new failure modes, new dependencies, or contracts other systems must conform to.\n- Multiple engineers \u002F services \u002F repos will need to agree on the contract before parallel work can start.\n\nDon't write a TRD for:\n\n- Single-file changes inside one module → the plan is enough.\n- Pure debate of alternatives (\"pgbouncer vs. pgcat\") → that's an `orc:rfc-writing` job.\n- Locking in a single architectural decision after debate → that's `orc:adr-writing`.\n- Anything where the PRD itself is unsettled → write\u002Ffinish the PRD first (`orc:prd-writing`).\n\nA TRD without a PRD is a TRD answering a question nobody asked. A TRD with no contract section is just an RFC mislabeled.\n\n## Interview checklist (before drafting)\n\nSkip questions whose answers are already in the linked PRD or in conversation. Don't make the user repeat themselves.\n\n1. **What PRD or product context is this TRD serving?** (link)\n2. **Goals.** What technical outcomes MUST this TRD's contract enable? Be specific.\n3. **Non-goals.** What are we explicitly *not* committing to in this contract? (Heads off scope drift.)\n4. **Public interfaces.** What APIs, schemas, events, CLI surfaces, or library entry points does this introduce or modify? Public = anything another component or repo depends on.\n5. **Data model.** What persisted shapes change or get added? Migrations? Indexes? Backfill?\n6. **Failure modes.** What can go wrong in this contract, and what's the contract's response (retry \u002F dead-letter \u002F surface to user \u002F ignore)?\n7. **Constraints.** Performance budgets, security\u002Fcompliance, capacity, vendor lock-in, language\u002Fframework requirements.\n8. **Dependencies.** Other services, libraries, teams whose work this requires or affects.\n9. **Success criteria.** How will we verify the contract is met? (Tests, SLOs, integration checks.)\n10. **Open questions.** Things the author needs reviewer input on.\n\n## Template\n\nEvery TRD uses this shape. Delete sections with no real content rather than leaving `TBD`. Read [TEMPLATE.md](references\u002FTEMPLATE.md) when drafting (step 5): header block, Summary, Goals, Non-goals, Background, Public interfaces & contracts (API shapes, data model, events), Failure modes table, Constraints, Dependencies, Migration\u002Frollout, Success criteria, Open questions, Risks, Appendix.\n\n## What to do as the model\n\n1. **Confirm a TRD is warranted** — apply the \"all of these are true\" test. If borderline, surface (TRD \u002F single design note in code \u002F an RFC instead).\n2. **Locate or read the linked PRD.** A TRD without a PRD reference (or equivalent product context) is suspect — surface that and ask.\n3. **Run the interview** if input is sparse. Skip questions answered by the linked PRD or earlier in conversation.\n4. **Find the next sequence number** in `docs\u002Ftrds\u002F` (see the numbering convention in `orc:doc-writing`).\n5. **Draft from the template.** Fill every section. **Delete sections that have no content** rather than writing `TBD`. The \"Public interfaces & contracts\" section is the load-bearing one — if it's thin, the TRD isn't ready.\n6. **Show the draft to the user for review** before committing (review gates in `orc:doc-writing`).\n7. **Commit** via `orc:git-commit`. Suggested message: `docs(trd): NNNN — \u003Ckebab title>`.\n8. **Cross-link.** From the linked PRD, from any tickets, from any code that will conform to the contract.\n\n## Tone\n\nEngineer-to-engineer, plain prose, schemas and tables where they add precision. No marketing voice, no \"obvious\" or \"trivial.\" Quote constraints by name (latency budget, deadline, vendor SLA). When a constraint is non-technical (legal, vendor relationship, exec mandate), say so plainly — the future reader needs that context.\n\n## Anti-patterns\n\n- **TRDs written after implementation.** The contract gets reverse-engineered from the code; the failure-mode section gets sanitized; the unknowns section disappears. Write the TRD *before* the plan.\n- **TRDs that debate alternatives.** That's an RFC. A TRD commits to *one* contract; argument belongs upstream.\n- **Empty \"Failure modes\" section.** Every contract has failure modes. If you can't think of any, you haven't thought hard enough.\n- **TRDs without measurable success criteria.** \"We'll know when it works\" means nothing is testable.\n- **Mismatched scope vs. PRD.** A TRD wider than its PRD is scope creep; narrower means part of the PRD has no technical contract yet.\n- **TRDs with no `Non-goals`.** Without explicit exclusions, the contract grows in review until nothing ships.\n","# TRD Writing\n\n> **Defer to `orc:doc-writing`** for the shared scaffolding: the doc-type map (TRD vs PRD vs RFC vs ADR vs postmortem, and how TRD differs from each), the shared section outline, the `docs\u002F\u003Ctype>s\u002FNNNN-*.md` numbering & publication convention, and the review gates. This skill carries only the TRD-specific template, fields, and tone.\n\nA TRD turns \"what & why\" into \"what we will build, technically.\" It pins down interfaces, data, failure modes, and constraints — the things engineering will commit to producing — *before* the design debate (RFC) or the implementation breakdown (plan).\n\nA good TRD lets a reviewer say \"yes, this contract solves the PRD\" without having to read code, and lets the next person to write the RFC or plan start from a stable surface area.\n\n## When to write one\n\nWrite a TRD when **all** of these are true:\n\n- A **PRD (or equivalent product spec) has settled the \"what & why\"** — you're not still arguing about audience or scope.\n- The work introduces **non-trivial technical surface area** — new APIs, new data model, new failure modes, new dependencies, or contracts other systems must conform to.\n- Multiple engineers \u002F services \u002F repos will need to agree on the contract before parallel work can start.\n\nDon't write a TRD for:\n\n- Single-file changes inside one module → the plan is enough.\n- Pure debate of alternatives (\"pgbouncer vs. pgcat\") → that's an `orc:rfc-writing` job.\n- Locking in a single architectural decision after debate → that's `orc:adr-writing`.\n- Anything where the PRD itself is unsettled → write\u002Ffinish the PRD first (`orc:prd-writing`).\n\nA TRD without a PRD is a TRD answering a question nobody asked. A TRD with no contract section is just an RFC mislabeled.\n\n## Interview checklist (before drafting)\n\nSkip questions whose answers are already in the linked PRD or in conversation. Don't make the user repeat themselves.\n\n1. **What PRD or product context is this TRD serving?** (link)\n2. **Goals.** What technical outcomes MUST this TRD's contract enable? Be specific.\n3. **Non-goals.** What are we explicitly *not* committing to in this contract? (Heads off scope drift.)\n4. **Public interfaces.** What APIs, schemas, events, CLI surfaces, or library entry points does this introduce or modify? Public = anything another component or repo depends on.\n5. **Data model.** What persisted shapes change or get added? Migrations? Indexes? Backfill?\n6. **Failure modes.** What can go wrong in this contract, and what's the contract's response (retry \u002F dead-letter \u002F surface to user \u002F ignore)?\n7. **Constraints.** Performance budgets, security\u002Fcompliance, capacity, vendor lock-in, language\u002Fframework requirements.\n8. **Dependencies.** Other services, libraries, teams whose work this requires or affects.\n9. **Success criteria.** How will we verify the contract is met? (Tests, SLOs, integration checks.)\n10. **Open questions.** Things the author needs reviewer input on.\n\n## Template\n\nEvery TRD uses this shape. Delete sections with no real content rather than leaving `TBD`. Read [TEMPLATE.md](references\u002FTEMPLATE.md) when drafting (step 5): header block, Summary, Goals, Non-goals, Background, Public interfaces & contracts (API shapes, data model, events), Failure modes table, Constraints, Dependencies, Migration\u002Frollout, Success criteria, Open questions, Risks, Appendix.\n\n## What to do as the model\n\n1. **Confirm a TRD is warranted** — apply the \"all of these are true\" test. If borderline, surface (TRD \u002F single design note in code \u002F an RFC instead).\n2. **Locate or read the linked PRD.** A TRD without a PRD reference (or equivalent product context) is suspect — surface that and ask.\n3. **Run the interview** if input is sparse. Skip questions answered by the linked PRD or earlier in conversation.\n4. **Find the next sequence number** in `docs\u002Ftrds\u002F` (see the numbering convention in `orc:doc-writing`).\n5. **Draft from the template.** Fill every section. **Delete sections that have no content** rather than writing `TBD`. The \"Public interfaces & contracts\" section is the load-bearing one — if it's thin, the TRD isn't ready.\n6. **Show the draft to the user for review** before committing (review gates in `orc:doc-writing`).\n7. **Commit** via `orc:git-commit`. Suggested message: `docs(trd): NNNN — \u003Ckebab title>`.\n8. **Cross-link.** From the linked PRD, from any tickets, from any code that will conform to the contract.\n\n## Tone\n\nEngineer-to-engineer, plain prose, schemas and tables where they add precision. No marketing voice, no \"obvious\" or \"trivial.\" Quote constraints by name (latency budget, deadline, vendor SLA). When a constraint is non-technical (legal, vendor relationship, exec mandate), say so plainly — the future reader needs that context.\n\n## Anti-patterns\n\n- **TRDs written after implementation.** The contract gets reverse-engineered from the code; the failure-mode section gets sanitized; the unknowns section disappears. Write the TRD *before* the plan.\n- **TRDs that debate alternatives.** That's an RFC. A TRD commits to *one* contract; argument belongs upstream.\n- **Empty \"Failure modes\" section.** Every contract has failure modes. If you can't think of any, you haven't thought hard enough.\n- **TRDs without measurable success criteria.** \"We'll know when it works\" means nothing is testable.\n- **Mismatched scope vs. PRD.** A TRD wider than its PRD is scope creep; narrower means part of the PRD has no technical contract yet.\n- **TRDs with no `Non-goals`.** Without explicit exclusions, the contract grows in review until nothing ships.\n",{"name":5,"description":7,"when_to_use":48},"Use for \"write a TRD\" or \u002Forc:trd.","main","7522fd7266944e30052204c2f6df287d8b5516be","orc\u002Fskills\u002Ftrd-writing",0,"https:\u002F\u002Fgithub.com\u002FHigorAlves\u002Forc","https:\u002F\u002Forc.novacstack.com\u002F","https:\u002F\u002Fgithub.com\u002FHigorAlves","higoralves.dev","Software Engineering","2026-11-07 07:26:38",{"source":8,"skillName":5,"commands":60,"prompt":70,"zipAvailable":71},[61,64,67],{"tool":62,"command":63},"npx","npx skills add HigorAlves\u002Forc --skill trd-writing",{"tool":65,"command":66},"bunx","bunx skills add HigorAlves\u002Forc --skill trd-writing",{"tool":68,"command":69},"pnpm","pnpm dlx skills add HigorAlves\u002Forc --skill trd-writing","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FHigorAlves\u002Forc\u002Fblob\u002Fmain\u002Forc\u002Fskills\u002Ftrd-writing\u002FSKILL.md",true,[73],{"path":74,"resourceType":75,"resourceTypeDesc":76,"sizeBytes":77,"sourceHtmlUrl":78},"references\u002FTEMPLATE.md","REFERENCE","参考文档",3811,"https:\u002F\u002Fgithub.com\u002FHigorAlves\u002Forc\u002Fblob\u002Fmain\u002Forc\u002Fskills\u002Ftrd-writing\u002Freferences\u002FTEMPLATE.md",[80,108,133,154,176,196],{"skillNo":81,"name":82,"nameZh":6,"description":83,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":84,"categories":85,"keywords":91,"publishedAt":43},"01M71SW40F9TAAEDKBYYBCM814","writing-plans","Write a comprehensive implementation plan of bite-sized TDD tasks that an engineer with zero codebase context could execute — exact files, code, tests, and verification steps","https:\u002F\u002Fgithub.com\u002FHigorAlves\u002Forc\u002Fblob\u002Fmain\u002Forc\u002Fskills\u002Fwriting-plans\u002FSKILL.md",[86,87,90],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":88,"categoryName":89,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000030","开发工程师",{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},[29,92,93,94,95,96,97,98,99,100,101,102,103,32,104,105,106,34,107,37],"writing plans","plans","engineer","superpowers","implementation plan","files","when","you","code","tasks","verification","plan","steps","context","ZeRO","tests",{"skillNo":109,"name":110,"nameZh":6,"description":111,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":112,"categories":113,"keywords":119,"publishedAt":43},"01M71SW15KHE4MHJW9NEXV65X2","writing-for-agents","orc's doctrine layer for writing any document an agent consumes — skills, AGENTS.md\u002FCLAUDE.md, reference docs","https:\u002F\u002Fgithub.com\u002FHigorAlves\u002Forc\u002Fblob\u002Fmain\u002Forc\u002Fskills\u002Fwriting-for-agents\u002FSKILL.md",[114,115,118],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":116,"categoryName":117,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},[120,29,34,121,98,122,123,124,125,126,127,128,37,129,130,131,132,40],"writing for agents","matt pocock","inline","tuning","a skill","layer","doctrine","push","editing","document","github","https","reference",{"skillNo":134,"name":135,"nameZh":6,"description":136,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":137,"categories":138,"keywords":140,"publishedAt":43},"01M71SVYQKXT743HHHWGHT3G13","workspace-mode","Use when cwd is a parent dir holding multiple sibling git repos — defines repo auto-detection, --repos\u002F--repo\u002F--all-repos\u002F--this-repo precedence, per-repo dispatch, and linked-PR mechanics.","https:\u002F\u002Fgithub.com\u002FHigorAlves\u002Forc\u002Fblob\u002Fmain\u002Forc\u002Fskills\u002Fworkspace-mode\u002FSKILL.md",[139],{"categoryNo":116,"categoryName":117,"taxonomyType":21,"taxonomyTypeDesc":22},[141,142,143,144,145,98,146,147,148,149,37,150,151,152,153],"workspace mode","mode","workspace","mechanics","auto","repos","git","pr","repo","dispatch","auto-detection","detection","parent",{"skillNo":155,"name":156,"nameZh":6,"description":157,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":158,"categories":159,"keywords":161,"publishedAt":43},"01M71SVVP3BXS06G9395P2K0RH","wizard","Generate an interactive bash wizard walking a human through work only they can perform — credentials, secrets, one-off migrations","https:\u002F\u002Fgithub.com\u002FHigorAlves\u002Forc\u002Fblob\u002Fmain\u002Forc\u002Fskills\u002Fwizard\u002FSKILL.md",[160],{"categoryNo":116,"categoryName":117,"taxonomyType":21,"taxonomyTypeDesc":22},[156,162,163,164,165,121,98,166,167,168,169,170,171,104,172,173,34,37,174,175],"condition","never","provisioning infrastructure","only","Bash","work","credentials","generate","human","secrets","infrastructure","do","one","interactive",{"skillNo":177,"name":178,"nameZh":6,"description":179,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":180,"categories":181,"keywords":182,"publishedAt":43},"01M71SVT4AR6NKAM5B077E7QSJ","wait-what","Stop and re-pitch — the last message did not land; say it again simply, in the project's own vocabulary.","https:\u002F\u002Fgithub.com\u002FHigorAlves\u002Forc\u002Fblob\u002Fmain\u002Forc\u002Fskills\u002Fwait-what\u002FSKILL.md",[],[183,184,185,186,187,121,188,189,190,191,130,131,192,193,194,195],"wait what","wait","project","re","true","pitch","last","say","message","land","it","stop","vocabulary",{"skillNo":197,"name":198,"nameZh":6,"description":199,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":200,"categories":201,"keywords":206,"publishedAt":43},"01M71SVQVYRA9QBQ6G8MWR8G6F","vitest","Vitest fast unit testing framework powered by Vite with Jest-compatible API","https:\u002F\u002Fgithub.com\u002FHigorAlves\u002Forc\u002Fblob\u002Fmain\u002Forc\u002Fskills\u002Fvitest\u002FSKILL.md",[202,205],{"categoryNo":203,"categoryName":204,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":88,"categoryName":89,"taxonomyType":26,"taxonomyTypeDesc":27},[198,207,208,209,210,211,29,98,212,213,214,215,216,217,218,219,220,221,107,222],"coverage","unit","testing","testing framework","generated","api","jest","2026","at","scripts","unit testing","antfu","framework","vite","mocking","dev"]