[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6ENRJ87Q52YR53WZ84DMBDC":3,"skill-same:01M6ENRJ87Q52YR53WZ84DMBDC":62},{"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":28,"linkOnly":29,"markdownContent":30,"markdownBody":31,"frontMatter":32,"refName":33,"commitSha":34,"skillDirectory":35,"forksCount":36,"repositoryHtmlUrl":37,"repositoryHomepageUrl":38,"ownerHtmlUrl":39,"ownerBlogUrl":6,"ownerDescription":40,"updatedAt":41,"install":42,"resources":55},"01M6ENRJ87Q52YR53WZ84DMBDC","technical-decision-record",null,"Use when making technical decisions, choosing technologies, or documenting architectural choices. Creates ADRs (Architecture Decision Records).","ComeOnOliver\u002Fskillshub","ComeOnOliver","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F43215937?v=4","01M6E5JNFECJAAVFE0W7SMWWD2","Haoran Shu","01M6E5JNNDQS7AJZDYFQ8TPZCK",67,"MIT","https:\u002F\u002Fgithub.com\u002FComeOnOliver\u002Fskillshub\u002Fblob\u002Fmain\u002Fskills\u002Faiskillstore\u002Fmarketplace\u002Fchaiwithjai\u002Ftechnical-decision-record\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27],"decision","technical","record","technical decision record","architecture","architecture decision records","decisions","use","records","2026-11-10 10:12:30",false,"---\nname: technical-decision-record\ndescription: Use when making technical decisions, choosing technologies, or documenting architectural choices. Creates ADRs (Architecture Decision Records).\n---\n\n\u003Cframework_overview>\n## What This Is\n\nA structured approach to documenting technical decisions using ADRs (Architecture Decision Records). Ensures decisions are traceable, well-reasoned, and understood by the team.\n\n## When to Use\n\n- Choosing between technologies or frameworks\n- Making architectural changes\n- Selecting third-party services\n- Changing established patterns\n- Any decision you'd want to reference later\n\u003C\u002Fframework_overview>\n\n\u003Cprinciples>\n## Core Philosophy\n\n### 1. DECISIONS ARE IMMUTABLE HISTORY\nOnce made, an ADR is never modified—only superseded. This preserves the reasoning at the time, even if context changes later.\n\n### 2. CONTEXT OVER CONCLUSION\nThe \"why\" is more valuable than the \"what.\" Future readers need to understand the constraints, options, and trade-offs that led to the decision.\n\n### 3. BIAS TOWARD REVERSIBILITY\nPrefer decisions that can be changed later. Document the reversal cost for irreversible choices.\n\n### 4. EXPLICIT OVER IMPLICIT\nIf it wasn't written down, it wasn't decided. Verbal agreements don't count as architectural decisions.\n\n### 5. TEAM OVER INDIVIDUAL\nDecisions should be reviewed by affected parties. Surprise decisions create resistance.\n\u003C\u002Fprinciples>\n\n\u003Cprocess>\n## The Process\n\n### Step 1: Define the Problem\nWhat are we deciding? Be specific.\n- \"Which database for user data\" not \"database stuff\"\n- Include the trigger: what prompted this decision?\n\n### Step 2: List Constraints\nWhat limits our options?\n- Technical: performance, scalability, existing stack\n- Business: budget, timeline, team skills\n- Compliance: security, regulatory, data residency\n\n### Step 3: Enumerate Options\nList 2-4 real options. For each:\n- Brief description\n- Pros (what it does well)\n- Cons (what it does poorly)\n- Estimated cost\u002Feffort\n\n### Step 4: Make the Decision\nChoose one option. State it clearly.\n- \"We will use [X]\"\n- Include who made the decision and when\n\n### Step 5: Document Consequences\nWhat follows from this decision?\n- Positive: benefits we expect\n- Negative: costs we accept\n- Risks: what could go wrong\n- Reversibility: how hard to change later\n\u003C\u002Fprocess>\n\n\u003Ctemplates>\n## ADR Template\n\n```markdown\n# ADR-[NUMBER]: [TITLE]\n\n**Status**: [Proposed | Accepted | Superseded by ADR-X]\n**Date**: [YYYY-MM-DD]\n**Deciders**: [Names]\n\n## Context\n\n[What is the issue? What prompted this decision?]\n\n## Constraints\n\n- [Constraint 1]\n- [Constraint 2]\n- [Constraint 3]\n\n## Options Considered\n\n### Option 1: [Name]\n[Description]\n- Pros: [...]\n- Cons: [...]\n\n### Option 2: [Name]\n[Description]\n- Pros: [...]\n- Cons: [...]\n\n### Option 3: [Name]\n[Description]\n- Pros: [...]\n- Cons: [...]\n\n## Decision\n\nWe will use **[Option X]**.\n\n[Reasoning: Why this option over others?]\n\n## Consequences\n\n### Positive\n- [Benefit 1]\n- [Benefit 2]\n\n### Negative\n- [Cost 1]\n- [Cost 2]\n\n### Risks\n- [Risk 1]: [Mitigation]\n- [Risk 2]: [Mitigation]\n\n### Reversibility\n[Easy | Moderate | Difficult | Irreversible]\n[Explanation of what reversal would require]\n```\n\u003C\u002Ftemplates>\n\n\u003Canti-patterns>\n## Common Mistakes\n\n### 1. DECIDING WITHOUT OPTIONS\nMaking a decision without exploring alternatives is not a decision—it's a default.\n\nWhy it's wrong: You can't justify a choice without knowing what you chose against.\nInstead: Always list at least 2 options, even if one is \"do nothing.\"\n\n### 2. BIKESHEDDING\nSpending more time on reversible decisions than irreversible ones.\n\nWhy it's wrong: Time spent on low-stakes decisions is time not spent on high-stakes ones.\nInstead: Match deliberation time to reversibility. Irreversible = more process.\n\n### 3. HIDDEN STAKEHOLDERS\nMaking decisions that affect teams without involving them.\n\nWhy it's wrong: Creates surprise, resistance, and rework.\nInstead: List affected parties in \"Deciders\" and get explicit sign-off.\n\n### 4. REVISION INSTEAD OF SUPERSESSION\nEditing old ADRs when context changes.\n\nWhy it's wrong: Loses the historical record of why decisions were made.\nInstead: Create a new ADR that supersedes the old one, referencing the original.\n\u003C\u002Fanti-patterns>\n\n\u003Cintake>\nWhat technical decision are you working on?\n\n1. **What's being decided?**\n   - Technology choice\n   - Architectural pattern\n   - Third-party service\n   - Process change\n   - Other: ___\n\n2. **What triggered this decision?**\n   - New requirement\n   - Performance issue\n   - Technical debt\n   - Team change\n   - Other: ___\n\n3. **How reversible should this be?**\n   - Easy to change (experiment)\n   - Moderate effort to change\n   - Significant investment\n   - Hard to reverse (commit carefully)\n\nI'll help you structure the ADR based on your answers.\n\u003C\u002Fintake>\n","\u003Cframework_overview>\n## What This Is\n\nA structured approach to documenting technical decisions using ADRs (Architecture Decision Records). Ensures decisions are traceable, well-reasoned, and understood by the team.\n\n## When to Use\n\n- Choosing between technologies or frameworks\n- Making architectural changes\n- Selecting third-party services\n- Changing established patterns\n- Any decision you'd want to reference later\n\u003C\u002Fframework_overview>\n\n\u003Cprinciples>\n## Core Philosophy\n\n### 1. DECISIONS ARE IMMUTABLE HISTORY\nOnce made, an ADR is never modified—only superseded. This preserves the reasoning at the time, even if context changes later.\n\n### 2. CONTEXT OVER CONCLUSION\nThe \"why\" is more valuable than the \"what.\" Future readers need to understand the constraints, options, and trade-offs that led to the decision.\n\n### 3. BIAS TOWARD REVERSIBILITY\nPrefer decisions that can be changed later. Document the reversal cost for irreversible choices.\n\n### 4. EXPLICIT OVER IMPLICIT\nIf it wasn't written down, it wasn't decided. Verbal agreements don't count as architectural decisions.\n\n### 5. TEAM OVER INDIVIDUAL\nDecisions should be reviewed by affected parties. Surprise decisions create resistance.\n\u003C\u002Fprinciples>\n\n\u003Cprocess>\n## The Process\n\n### Step 1: Define the Problem\nWhat are we deciding? Be specific.\n- \"Which database for user data\" not \"database stuff\"\n- Include the trigger: what prompted this decision?\n\n### Step 2: List Constraints\nWhat limits our options?\n- Technical: performance, scalability, existing stack\n- Business: budget, timeline, team skills\n- Compliance: security, regulatory, data residency\n\n### Step 3: Enumerate Options\nList 2-4 real options. For each:\n- Brief description\n- Pros (what it does well)\n- Cons (what it does poorly)\n- Estimated cost\u002Feffort\n\n### Step 4: Make the Decision\nChoose one option. State it clearly.\n- \"We will use [X]\"\n- Include who made the decision and when\n\n### Step 5: Document Consequences\nWhat follows from this decision?\n- Positive: benefits we expect\n- Negative: costs we accept\n- Risks: what could go wrong\n- Reversibility: how hard to change later\n\u003C\u002Fprocess>\n\n\u003Ctemplates>\n## ADR Template\n\n```markdown\n# ADR-[NUMBER]: [TITLE]\n\n**Status**: [Proposed | Accepted | Superseded by ADR-X]\n**Date**: [YYYY-MM-DD]\n**Deciders**: [Names]\n\n## Context\n\n[What is the issue? What prompted this decision?]\n\n## Constraints\n\n- [Constraint 1]\n- [Constraint 2]\n- [Constraint 3]\n\n## Options Considered\n\n### Option 1: [Name]\n[Description]\n- Pros: [...]\n- Cons: [...]\n\n### Option 2: [Name]\n[Description]\n- Pros: [...]\n- Cons: [...]\n\n### Option 3: [Name]\n[Description]\n- Pros: [...]\n- Cons: [...]\n\n## Decision\n\nWe will use **[Option X]**.\n\n[Reasoning: Why this option over others?]\n\n## Consequences\n\n### Positive\n- [Benefit 1]\n- [Benefit 2]\n\n### Negative\n- [Cost 1]\n- [Cost 2]\n\n### Risks\n- [Risk 1]: [Mitigation]\n- [Risk 2]: [Mitigation]\n\n### Reversibility\n[Easy | Moderate | Difficult | Irreversible]\n[Explanation of what reversal would require]\n```\n\u003C\u002Ftemplates>\n\n\u003Canti-patterns>\n## Common Mistakes\n\n### 1. DECIDING WITHOUT OPTIONS\nMaking a decision without exploring alternatives is not a decision—it's a default.\n\nWhy it's wrong: You can't justify a choice without knowing what you chose against.\nInstead: Always list at least 2 options, even if one is \"do nothing.\"\n\n### 2. BIKESHEDDING\nSpending more time on reversible decisions than irreversible ones.\n\nWhy it's wrong: Time spent on low-stakes decisions is time not spent on high-stakes ones.\nInstead: Match deliberation time to reversibility. Irreversible = more process.\n\n### 3. HIDDEN STAKEHOLDERS\nMaking decisions that affect teams without involving them.\n\nWhy it's wrong: Creates surprise, resistance, and rework.\nInstead: List affected parties in \"Deciders\" and get explicit sign-off.\n\n### 4. REVISION INSTEAD OF SUPERSESSION\nEditing old ADRs when context changes.\n\nWhy it's wrong: Loses the historical record of why decisions were made.\nInstead: Create a new ADR that supersedes the old one, referencing the original.\n\u003C\u002Fanti-patterns>\n\n\u003Cintake>\nWhat technical decision are you working on?\n\n1. **What's being decided?**\n   - Technology choice\n   - Architectural pattern\n   - Third-party service\n   - Process change\n   - Other: ___\n\n2. **What triggered this decision?**\n   - New requirement\n   - Performance issue\n   - Technical debt\n   - Team change\n   - Other: ___\n\n3. **How reversible should this be?**\n   - Easy to change (experiment)\n   - Moderate effort to change\n   - Significant investment\n   - Hard to reverse (commit carefully)\n\nI'll help you structure the ADR based on your answers.\n\u003C\u002Fintake>\n",{"name":5,"description":7},"main","def8531e65114c0fca8fb8551c1871ee0eed705c","skills\u002Faiskillstore\u002Fmarketplace\u002Fchaiwithjai\u002Ftechnical-decision-record",24,"https:\u002F\u002Fgithub.com\u002FComeOnOliver\u002Fskillshub","https:\u002F\u002Fskillshub.wtf","https:\u002F\u002Fgithub.com\u002FComeOnOliver","AI & Blockchain Engineer\r\n","2026-06-24 22:07:19",{"source":8,"skillName":5,"commands":43,"prompt":53,"zipAvailable":54},[44,47,50],{"tool":45,"command":46},"npx","npx skills add ComeOnOliver\u002Fskillshub --skill technical-decision-record",{"tool":48,"command":49},"bunx","bunx skills add ComeOnOliver\u002Fskillshub --skill technical-decision-record",{"tool":51,"command":52},"pnpm","pnpm dlx skills add ComeOnOliver\u002Fskillshub --skill technical-decision-record","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FComeOnOliver\u002Fskillshub\u002Fblob\u002Fmain\u002Fskills\u002Faiskillstore\u002Fmarketplace\u002Fchaiwithjai\u002Ftechnical-decision-record\u002FSKILL.md",true,[56],{"path":57,"resourceType":58,"resourceTypeDesc":59,"sizeBytes":60,"sourceHtmlUrl":61},"skill-report.json","REFERENCE","参考文档",11072,"https:\u002F\u002Fgithub.com\u002FComeOnOliver\u002Fskillshub\u002Fblob\u002Fmain\u002Fskills\u002Faiskillstore\u002Fmarketplace\u002Fchaiwithjai\u002Ftechnical-decision-record\u002Fskill-report.json",[63,77,87,96,102,109],{"skillNo":64,"name":65,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":66,"categories":67,"keywords":73,"publishedAt":28},"01M6FKJN13GMG4KY57J3QD8GY5","model-hierarchy-skill","https:\u002F\u002Fgithub.com\u002FComeOnOliver\u002Fskillshub\u002Fblob\u002Fmain\u002Fskills\u002Fzscole\u002Fmodel-hierarchy-skill\u002Fmodel-hierarchy-skill\u002FSKILL.md",[68],{"categoryNo":69,"categoryName":70,"taxonomyType":71,"taxonomyTypeDesc":72},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[74,75,76],"model","model hierarchy","model hierarchy skill",{"skillNo":78,"name":79,"nameZh":6,"description":6,"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":28},"01M6FKJJJ6GCAMR4PPPRD12M5X","zoom-mcp","https:\u002F\u002Fgithub.com\u002FComeOnOliver\u002Fskillshub\u002Fblob\u002Fmain\u002Fskills\u002Fzoom\u002Fskills\u002Fzoom-mcp\u002FSKILL.md",[82],{"categoryNo":69,"categoryName":70,"taxonomyType":71,"taxonomyTypeDesc":72},[84,85,86],"MCP","zoom","zoom mcp",{"skillNo":88,"name":89,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":90,"categories":91,"keywords":92,"publishedAt":28},"01M6FKJE3KYT3KPEZMEEHYKA6K","zoom-apps-sdk","https:\u002F\u002Fgithub.com\u002FComeOnOliver\u002Fskillshub\u002Fblob\u002Fmain\u002Fskills\u002Fzoom\u002Fskills\u002Fzoom-apps-sdk\u002FSKILL.md",[],[93,94,95,85],"sdk","zoom apps sdk","apps",{"skillNo":97,"name":98,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":99,"categories":100,"keywords":101,"publishedAt":28},"01M6FKJ9EDH9Q5VWDF8HAJRSP0","windows","https:\u002F\u002Fgithub.com\u002FComeOnOliver\u002Fskillshub\u002Fblob\u002Fmain\u002Fskills\u002Fzoom\u002Fskills\u002Fwindows\u002FSKILL.md",[],[98],{"skillNo":103,"name":104,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":105,"categories":106,"keywords":108,"publishedAt":28},"01M6FKJ666BEEFC3AE9GJ72Q93","whiteboard","https:\u002F\u002Fgithub.com\u002FComeOnOliver\u002Fskillshub\u002Fblob\u002Fmain\u002Fskills\u002Fzoom\u002Fskills\u002Fwhiteboard\u002FSKILL.md",[107],{"categoryNo":69,"categoryName":70,"taxonomyType":71,"taxonomyTypeDesc":72},[104],{"skillNo":110,"name":111,"nameZh":6,"description":6,"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":114,"publishedAt":28},"01M6FKJ21WFCDGTJQ2Q91T9DVW","websockets","https:\u002F\u002Fgithub.com\u002FComeOnOliver\u002Fskillshub\u002Fblob\u002Fmain\u002Fskills\u002Fzoom\u002Fskills\u002Fwebsockets\u002FSKILL.md",[],[111]]