[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6BZRAHBW3DWXT87A7F16HR7":3,"skill-same:01M6BZRAHBW3DWXT87A7F16HR7":112},{"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":34,"linkOnly":35,"markdownContent":36,"markdownBody":37,"frontMatter":38,"refName":39,"commitSha":40,"skillDirectory":41,"forksCount":14,"repositoryHtmlUrl":42,"repositoryHomepageUrl":6,"ownerHtmlUrl":43,"ownerBlogUrl":6,"ownerDescription":44,"updatedAt":45,"install":46,"resources":59},"01M6BZRAHBW3DWXT87A7F16HR7","arch-decision",null,"Run a structured 7-stage architecture decision loop on any technical choice — vendor evaluation, build-vs-buy, infra strategy, schema change, ADR. Produces a scored decision memo with a binary verifier verdict. Good triggers include \"should we use X or Y\", \"help me think through our options\", \"we need to decide\", \"evaluate approach\", \"technical trade-off\", \"which is better for our stack\", \"options for\", \"design decision\", \"ADR\", \"architecture decision\".","twidxuga\u002Fdotfiles","twidxuga","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F12471681?v=4","01M6BZR45BH8JCC79Q9SKSS6SC","Ricardo Santos","01M6BZR49CRKSBZYQD1WNQWCXW",0,"MIT","https:\u002F\u002Fgithub.com\u002Ftwidxuga\u002Fdotfiles\u002Fblob\u002Fmain\u002Fopencode\u002Fdot-config\u002Fopencode\u002Fskills\u002Farch-decision\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33],"decision","arch decision","design","change","architecture","run","help","vendor evaluation","Evaluation","loop","stack","adr","choice","technical","decide","2026-11-10 10:12:30",false,"---\nname: arch-decision\ndescription: Run a structured 7-stage architecture decision loop on any technical choice — vendor evaluation, build-vs-buy, infra strategy, schema change, ADR. Produces a scored decision memo with a binary verifier verdict. Good triggers include \"should we use X or Y\", \"help me think through our options\", \"we need to decide\", \"evaluate approach\", \"technical trade-off\", \"which is better for our stack\", \"options for\", \"design decision\", \"ADR\", \"architecture decision\".\n---\n\n# arch-decision\n\nA structured 7-stage loop for any architecture, vendor, infra, or build-vs-buy question. The skill provides the process; you make the final call.\n\n**For non-technical decisions (people, process, policy):** evidence in Stage 3 may include interviews, budget documents, policy files, and performance records. Stage 4 criteria must include legality, fairness, and privacy where applicable.\n\n## How to start\n\nPaste your question in plain language. Example: \"Decide whether to build our own webhook delivery system or buy one.\" The skill runs Stages 1–3 automatically, then stops for your input before scoring.\n\n---\n\n## Stage 1: Framer\n\n**Tool restriction: NO tools. Input only.**\n\nTurn the question into a single sentence ending with `?`, labelled `Decision question:`. Write one measurable line labelled `Success criterion:` that defines done.\n\n**MUST NOT:** express preference, list options, or suggest an approach.\n\n**End-of-stage self-check:** \"I have not expressed preference. I have not listed options. I have one decision question and one success criterion.\"\n\n**Double-review:** Review once as \"did I stay neutral?\" then once as \"is the success criterion actually measurable?\". Each pass must output at least one concrete objection OR an explicit \"No objection because [specific reason]\". If an objection is found, show the specific revision made before continuing. Declaring a review passed without visible output is invalid.\n\n---\n\n## Stage 2: Option Widener\n\n**Tool restriction: NO tools. No web search, no file reading.**\n\nEnumerate ALL options before ANY comparison.\n\n**MUST include:**\n- `Do nothing \u002F Status quo` with a non-empty `Cost\u002Fconsequence:` line\n- At least one option marked `Not in original brief`\n- The most reversible option identified with `Most reversible: yes`\n\n**MUST NOT:** score, rank, compare, or express preference.\n\n**`Cost\u002Fconsequence:` must name a specific impact, the affected party, a timeframe, and a measurable magnitude — or explicitly label missing data as `GAP:`. Vague adjectives (\"some disruption\", \"increased risk\") fail Check 2.**\n\n**End-of-stage self-check:** \"Do nothing is present with a cost. I have at least one option not in the original brief. No scores or rankings appear.\"\n\n**Double-review:** Review once as \"have I genuinely widened, or just listed what was asked?\" then once as \"is the do-nothing cost honest or vague?\". Each pass must output at least one concrete objection OR an explicit \"No objection because [specific reason]\". If an objection is found, show the specific revision made before continuing. Declaring a review passed without visible output is invalid.\n\n---\n\n## Stage 3: Evidence Analyst\n\n**Tool restriction: Web search, file reading, Deep Research ONLY. No scoring, no recommendations.**\n\nRecord the instinctive leading option (the one that looks best after Stage 2) at the top of this stage before any research begins.\n\nFor each option, gather evidence. Maintain an **Evidence ledger** table:\n\n| ID | Claim | Source\u002FGAP | Favours option |\n|----|-------|------------|----------------|\n\n**MUST:** actively hunt for evidence AGAINST the instinctive leading option.\n\nEvery claim must have a URL, file path, doc reference, or explicit `GAP: [description]` in Source\u002FGAP.\n\n**MUST NOT:** recommend, score, or imply a winner.\n\n**End-of-stage self-check:** \"Every row in my evidence ledger has a non-empty Source\u002FGAP. I have searched for evidence against my instinctive leading option.\"\n\n**Double-review:** Review once as \"are there claims in my prose not in the ledger?\" then once as \"did I actually look for counter-evidence?\". Each pass must output at least one concrete objection OR an explicit \"No objection because [specific reason]\". If an objection is found, show the specific revision made before continuing. Declaring a review passed without visible output is invalid.\n\n---\n\n## Stage 4: Numbers Analyst\n\n> ⚠️ **HUMAN GATE — STOP BEFORE THIS STAGE** ⚠️\n>\n> Output the block below and wait for a SEPARATE human reply. Do NOT proceed until the human responds.\n> **Assistant-authored weight confirmations are invalid. Copy the human's reply verbatim into the memo before any scoring begins.**\n\n```\nAWAITING WEIGHTS FROM HUMAN\n\nPlease confirm or edit the criteria weights before I score anything.\nProposed criteria (total must sum to 100):\n- [criterion 1]: [weight]\n- [criterion 2]: [weight]\n...\nReply with your confirmed weights and I will proceed.\n```\n\n**Tool restriction: No web search. Use only the Stage 3 evidence ledger and any uploaded files.**\n\nBuild a scoring matrix using ONLY the human-confirmed weights.\n\n**MUST write** immediately before the matrix:\n`Weights locked before scoring: LOCKED BEFORE SCORING — [list each criterion:weight]`\n\n**Every score cell must cite at least one evidence ledger ID (e.g. [E3]) or `GAP:` label. Unledgered reasoning is inadmissible — if you cannot cite a ledger entry for a score, add a `GAP:` row to the ledger first.**\n\n**MUST NOT:** re-score after seeing results, adjust weights retroactively.\n\n**End-of-stage self-check:** \"The weights locked line appears before any scores. I used only the human-confirmed weights. Every score cell cites a ledger ID or GAP:.\"\n\n**Double-review:** Review once as \"did I sneak in any retroactive weight adjustment?\" then once as \"are all scores defensible from Stage 3 evidence?\". Each pass must output at least one concrete objection OR an explicit \"No objection because [specific reason]\". If an objection is found, show the specific revision made before continuing. Declaring a review passed without visible output is invalid.\n\n---\n\n## Stage 5: Red Team\n\n**Tool restriction: NO tools. Pure argument only.**\n\nFor each option NOT recommended by the matrix, write its strongest steelman. Then write a pre-mortem for the winner.\n\nEach steelman must: (a) argue why that option should WIN, not merely why it is reasonable; (b) cite at least one evidence ID from Stage 3; (c) identify the winner's strongest vulnerability. A steelman a genuine advocate would reject as inadequate must be revised.\n\n**Format:**\n\n`Steelman — [Option name]:` paragraph\n\n`Pre-mortem — [Winner]:` paragraph starting \"If we chose [winner] and it failed...\"\n\n**End-of-stage self-check:** \"Each steelman argues for a win, cites evidence, and names the winner's vulnerability. My pre-mortem names a specific failure mode, not a generic risk.\"\n\n**Double-review:** Review once as \"would a genuine advocate recognise this as their best argument?\" then once as \"is the pre-mortem specific enough to act on?\". Each pass must output at least one concrete objection OR an explicit \"No objection because [specific reason]\". If an objection is found, show the specific revision made before continuing. Declaring a review passed without visible output is invalid.\n\n---\n\n## Stage 6: Recommender\n\n**Tool restriction: NO new research. Synthesise from Stages 1–5 only.**\n\nWrite a one-page decision memo:\n\n1. `Recommendation:` one sentence naming the option and the success criterion it serves\n2. `Rationale:` 2–3 paragraphs citing evidence IDs from Stage 3\n3. `Strongest counter-argument:` must (a) quote or paraphrase the Stage 5 steelman's strongest claim; (b) cite the evidence IDs that support it; (c) explain exactly why the recommendation still holds despite it\n4. `Pre-mortem mitigation:` \"If [failure mode from Stage 5], then [specific mitigation]\"\n5. `Day-one delta:` one sentence — what changed vs the instinctive answer recorded at the start of Stage 3\n6. `What we don't know:` bullet list of GAPs from Stage 3 that could change this recommendation\n\n**MUST NOT:** introduce new evidence, revisit weights.\n\n**End-of-stage self-check:** \"I have addressed the strongest counter-argument with a quote or paraphrase and evidence IDs. My pre-mortem mitigation is in If\u002Fthen form. I have named a specific day-one delta.\"\n\n**Double-review:** Review once as \"does someone who disagrees know exactly which evidence to challenge?\" then once as \"is the day-one delta specific or generic waffle?\". Each pass must output at least one concrete objection OR an explicit \"No objection because [specific reason]\". If an objection is found, show the specific revision made before continuing. Declaring a review passed without visible output is invalid.\n\n---\n\n## Stage 7: Verifier\n\n**Tool restriction: NO tools. Fresh-eyes read of the memo only.**\n\nRun all 5 checks. Return PASS or FAIL with per-check results.\n\n**The 5 checks:**\n\n1. Does the opening block contain one line starting `Decision question:` ending with `?` and a separate non-empty line starting `Success criterion:`? (NO = missing decision target or success criterion)\n2. In `Options considered`, are there ≥3 named options including `Do nothing`\u002F`Status quo` with a `Cost\u002Fconsequence:` line naming a specific impact, affected party, timeframe, and measurable magnitude or `GAP:` — AND a different option marked `Not in original brief`? (NO = option set brief-biased or do-nothing cost too vague)\n3. Does every analytical paragraph\u002Ftable row cite an evidence ID or `GAP:`, does every ledger row have a source or `GAP:`, does each option have ≥2 ledger rows with at least one non-GAP source (unless all unavailable), and does every score cell cite a ledger ID? (NO = unsourced claim, under-evidenced option, or unledgered score)\n4. Does `Weights locked before scoring:` listing each criterion and weight appear before the first scoring marker? (NO = scoring may have preceded weight-locking)\n5. Does the `Recommender` section include `Strongest counter-argument:` naming a non-recommended option and `Pre-mortem mitigation:` in `If ... then ...` form? (NO = memo does not engage the strongest opposing case with an actionable mitigation)\n\n**Output format:**\n\n```\nVERIFIER RESULT: [PASS \u002F FAIL]\n\nCheck 1: [YES\u002FNO] — [one line]\nCheck 2: [YES\u002FNO] — [one line]\nCheck 3: [YES\u002FNO] — [one line]\nCheck 4: [YES\u002FNO] — [one line]\nCheck 5: [YES\u002FNO] — [one line]\n\n[If FAIL: \"The memo does not count until all checks return YES. Return to Stage [N] and fix: [specific issue].\"]\n[If PASS: \"Memo is valid. The human may now act on this recommendation.\"]\n```\n\n---\n\n## Worked example (EKS upgrade)\n\n**Input:** \"Decide how to upgrade our EKS platform version with minimal risk to partner-facing APIs.\"\n\n**Stage 1 output:**\n\n`Decision question:` Which EKS upgrade strategy minimises downtime and rollback risk for partner-facing APIs while reaching a supported platform version within 60 days?\n\n`Success criterion:` Zero partner-facing API errors during cutover, rollback achievable within 30 minutes, target version reached by deadline.\n\n**Stage 2 options:**\n\n| Option | Most reversible? | Notes |\n|--------|-----------------|-------|\n| Do nothing \u002F accept security risk | — | `Cost\u002Fconsequence:` Unsupported version; growing CVE exposure; AWS support unavailable for incidents affecting ~N partner API calls\u002Fday until resolved |\n| In-place managed node group rolling upgrade | — | Standard path; lower ops overhead |\n| Blue-green parallel cluster | yes | `Most reversible: yes` — traffic can shift back instantly |\n| Upgrade staging first, then prod with canary traffic shift | — | `Not in original brief` — adds a rehearsal gate before prod |\n","# arch-decision\n\nA structured 7-stage loop for any architecture, vendor, infra, or build-vs-buy question. The skill provides the process; you make the final call.\n\n**For non-technical decisions (people, process, policy):** evidence in Stage 3 may include interviews, budget documents, policy files, and performance records. Stage 4 criteria must include legality, fairness, and privacy where applicable.\n\n## How to start\n\nPaste your question in plain language. Example: \"Decide whether to build our own webhook delivery system or buy one.\" The skill runs Stages 1–3 automatically, then stops for your input before scoring.\n\n---\n\n## Stage 1: Framer\n\n**Tool restriction: NO tools. Input only.**\n\nTurn the question into a single sentence ending with `?`, labelled `Decision question:`. Write one measurable line labelled `Success criterion:` that defines done.\n\n**MUST NOT:** express preference, list options, or suggest an approach.\n\n**End-of-stage self-check:** \"I have not expressed preference. I have not listed options. I have one decision question and one success criterion.\"\n\n**Double-review:** Review once as \"did I stay neutral?\" then once as \"is the success criterion actually measurable?\". Each pass must output at least one concrete objection OR an explicit \"No objection because [specific reason]\". If an objection is found, show the specific revision made before continuing. Declaring a review passed without visible output is invalid.\n\n---\n\n## Stage 2: Option Widener\n\n**Tool restriction: NO tools. No web search, no file reading.**\n\nEnumerate ALL options before ANY comparison.\n\n**MUST include:**\n- `Do nothing \u002F Status quo` with a non-empty `Cost\u002Fconsequence:` line\n- At least one option marked `Not in original brief`\n- The most reversible option identified with `Most reversible: yes`\n\n**MUST NOT:** score, rank, compare, or express preference.\n\n**`Cost\u002Fconsequence:` must name a specific impact, the affected party, a timeframe, and a measurable magnitude — or explicitly label missing data as `GAP:`. Vague adjectives (\"some disruption\", \"increased risk\") fail Check 2.**\n\n**End-of-stage self-check:** \"Do nothing is present with a cost. I have at least one option not in the original brief. No scores or rankings appear.\"\n\n**Double-review:** Review once as \"have I genuinely widened, or just listed what was asked?\" then once as \"is the do-nothing cost honest or vague?\". Each pass must output at least one concrete objection OR an explicit \"No objection because [specific reason]\". If an objection is found, show the specific revision made before continuing. Declaring a review passed without visible output is invalid.\n\n---\n\n## Stage 3: Evidence Analyst\n\n**Tool restriction: Web search, file reading, Deep Research ONLY. No scoring, no recommendations.**\n\nRecord the instinctive leading option (the one that looks best after Stage 2) at the top of this stage before any research begins.\n\nFor each option, gather evidence. Maintain an **Evidence ledger** table:\n\n| ID | Claim | Source\u002FGAP | Favours option |\n|----|-------|------------|----------------|\n\n**MUST:** actively hunt for evidence AGAINST the instinctive leading option.\n\nEvery claim must have a URL, file path, doc reference, or explicit `GAP: [description]` in Source\u002FGAP.\n\n**MUST NOT:** recommend, score, or imply a winner.\n\n**End-of-stage self-check:** \"Every row in my evidence ledger has a non-empty Source\u002FGAP. I have searched for evidence against my instinctive leading option.\"\n\n**Double-review:** Review once as \"are there claims in my prose not in the ledger?\" then once as \"did I actually look for counter-evidence?\". Each pass must output at least one concrete objection OR an explicit \"No objection because [specific reason]\". If an objection is found, show the specific revision made before continuing. Declaring a review passed without visible output is invalid.\n\n---\n\n## Stage 4: Numbers Analyst\n\n> ⚠️ **HUMAN GATE — STOP BEFORE THIS STAGE** ⚠️\n>\n> Output the block below and wait for a SEPARATE human reply. Do NOT proceed until the human responds.\n> **Assistant-authored weight confirmations are invalid. Copy the human's reply verbatim into the memo before any scoring begins.**\n\n```\nAWAITING WEIGHTS FROM HUMAN\n\nPlease confirm or edit the criteria weights before I score anything.\nProposed criteria (total must sum to 100):\n- [criterion 1]: [weight]\n- [criterion 2]: [weight]\n...\nReply with your confirmed weights and I will proceed.\n```\n\n**Tool restriction: No web search. Use only the Stage 3 evidence ledger and any uploaded files.**\n\nBuild a scoring matrix using ONLY the human-confirmed weights.\n\n**MUST write** immediately before the matrix:\n`Weights locked before scoring: LOCKED BEFORE SCORING — [list each criterion:weight]`\n\n**Every score cell must cite at least one evidence ledger ID (e.g. [E3]) or `GAP:` label. Unledgered reasoning is inadmissible — if you cannot cite a ledger entry for a score, add a `GAP:` row to the ledger first.**\n\n**MUST NOT:** re-score after seeing results, adjust weights retroactively.\n\n**End-of-stage self-check:** \"The weights locked line appears before any scores. I used only the human-confirmed weights. Every score cell cites a ledger ID or GAP:.\"\n\n**Double-review:** Review once as \"did I sneak in any retroactive weight adjustment?\" then once as \"are all scores defensible from Stage 3 evidence?\". Each pass must output at least one concrete objection OR an explicit \"No objection because [specific reason]\". If an objection is found, show the specific revision made before continuing. Declaring a review passed without visible output is invalid.\n\n---\n\n## Stage 5: Red Team\n\n**Tool restriction: NO tools. Pure argument only.**\n\nFor each option NOT recommended by the matrix, write its strongest steelman. Then write a pre-mortem for the winner.\n\nEach steelman must: (a) argue why that option should WIN, not merely why it is reasonable; (b) cite at least one evidence ID from Stage 3; (c) identify the winner's strongest vulnerability. A steelman a genuine advocate would reject as inadequate must be revised.\n\n**Format:**\n\n`Steelman — [Option name]:` paragraph\n\n`Pre-mortem — [Winner]:` paragraph starting \"If we chose [winner] and it failed...\"\n\n**End-of-stage self-check:** \"Each steelman argues for a win, cites evidence, and names the winner's vulnerability. My pre-mortem names a specific failure mode, not a generic risk.\"\n\n**Double-review:** Review once as \"would a genuine advocate recognise this as their best argument?\" then once as \"is the pre-mortem specific enough to act on?\". Each pass must output at least one concrete objection OR an explicit \"No objection because [specific reason]\". If an objection is found, show the specific revision made before continuing. Declaring a review passed without visible output is invalid.\n\n---\n\n## Stage 6: Recommender\n\n**Tool restriction: NO new research. Synthesise from Stages 1–5 only.**\n\nWrite a one-page decision memo:\n\n1. `Recommendation:` one sentence naming the option and the success criterion it serves\n2. `Rationale:` 2–3 paragraphs citing evidence IDs from Stage 3\n3. `Strongest counter-argument:` must (a) quote or paraphrase the Stage 5 steelman's strongest claim; (b) cite the evidence IDs that support it; (c) explain exactly why the recommendation still holds despite it\n4. `Pre-mortem mitigation:` \"If [failure mode from Stage 5], then [specific mitigation]\"\n5. `Day-one delta:` one sentence — what changed vs the instinctive answer recorded at the start of Stage 3\n6. `What we don't know:` bullet list of GAPs from Stage 3 that could change this recommendation\n\n**MUST NOT:** introduce new evidence, revisit weights.\n\n**End-of-stage self-check:** \"I have addressed the strongest counter-argument with a quote or paraphrase and evidence IDs. My pre-mortem mitigation is in If\u002Fthen form. I have named a specific day-one delta.\"\n\n**Double-review:** Review once as \"does someone who disagrees know exactly which evidence to challenge?\" then once as \"is the day-one delta specific or generic waffle?\". Each pass must output at least one concrete objection OR an explicit \"No objection because [specific reason]\". If an objection is found, show the specific revision made before continuing. Declaring a review passed without visible output is invalid.\n\n---\n\n## Stage 7: Verifier\n\n**Tool restriction: NO tools. Fresh-eyes read of the memo only.**\n\nRun all 5 checks. Return PASS or FAIL with per-check results.\n\n**The 5 checks:**\n\n1. Does the opening block contain one line starting `Decision question:` ending with `?` and a separate non-empty line starting `Success criterion:`? (NO = missing decision target or success criterion)\n2. In `Options considered`, are there ≥3 named options including `Do nothing`\u002F`Status quo` with a `Cost\u002Fconsequence:` line naming a specific impact, affected party, timeframe, and measurable magnitude or `GAP:` — AND a different option marked `Not in original brief`? (NO = option set brief-biased or do-nothing cost too vague)\n3. Does every analytical paragraph\u002Ftable row cite an evidence ID or `GAP:`, does every ledger row have a source or `GAP:`, does each option have ≥2 ledger rows with at least one non-GAP source (unless all unavailable), and does every score cell cite a ledger ID? (NO = unsourced claim, under-evidenced option, or unledgered score)\n4. Does `Weights locked before scoring:` listing each criterion and weight appear before the first scoring marker? (NO = scoring may have preceded weight-locking)\n5. Does the `Recommender` section include `Strongest counter-argument:` naming a non-recommended option and `Pre-mortem mitigation:` in `If ... then ...` form? (NO = memo does not engage the strongest opposing case with an actionable mitigation)\n\n**Output format:**\n\n```\nVERIFIER RESULT: [PASS \u002F FAIL]\n\nCheck 1: [YES\u002FNO] — [one line]\nCheck 2: [YES\u002FNO] — [one line]\nCheck 3: [YES\u002FNO] — [one line]\nCheck 4: [YES\u002FNO] — [one line]\nCheck 5: [YES\u002FNO] — [one line]\n\n[If FAIL: \"The memo does not count until all checks return YES. Return to Stage [N] and fix: [specific issue].\"]\n[If PASS: \"Memo is valid. The human may now act on this recommendation.\"]\n```\n\n---\n\n## Worked example (EKS upgrade)\n\n**Input:** \"Decide how to upgrade our EKS platform version with minimal risk to partner-facing APIs.\"\n\n**Stage 1 output:**\n\n`Decision question:` Which EKS upgrade strategy minimises downtime and rollback risk for partner-facing APIs while reaching a supported platform version within 60 days?\n\n`Success criterion:` Zero partner-facing API errors during cutover, rollback achievable within 30 minutes, target version reached by deadline.\n\n**Stage 2 options:**\n\n| Option | Most reversible? | Notes |\n|--------|-----------------|-------|\n| Do nothing \u002F accept security risk | — | `Cost\u002Fconsequence:` Unsupported version; growing CVE exposure; AWS support unavailable for incidents affecting ~N partner API calls\u002Fday until resolved |\n| In-place managed node group rolling upgrade | — | Standard path; lower ops overhead |\n| Blue-green parallel cluster | yes | `Most reversible: yes` — traffic can shift back instantly |\n| Upgrade staging first, then prod with canary traffic shift | — | `Not in original brief` — adds a rehearsal gate before prod |\n",{"name":5,"description":7},"main","e25eb555e87aa9eeb59b520834f46fd926ad19a3","opencode\u002Fdot-config\u002Fopencode\u002Fskills\u002Farch-decision","https:\u002F\u002Fgithub.com\u002Ftwidxuga\u002Fdotfiles","https:\u002F\u002Fgithub.com\u002Ftwidxuga","Software developer, data scientist, applications architect and all round computer geek.","2026-10-28 03:46:24",{"source":8,"skillName":5,"commands":47,"prompt":57,"zipAvailable":58},[48,51,54],{"tool":49,"command":50},"npx","npx skills add twidxuga\u002Fdotfiles --skill arch-decision",{"tool":52,"command":53},"bunx","bunx skills add twidxuga\u002Fdotfiles --skill arch-decision",{"tool":55,"command":56},"pnpm","pnpm dlx skills add twidxuga\u002Fdotfiles --skill arch-decision","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Ftwidxuga\u002Fdotfiles\u002Fblob\u002Fmain\u002Fopencode\u002Fdot-config\u002Fopencode\u002Fskills\u002Farch-decision\u002FSKILL.md",true,[60,66,72,76,80,84,88,92,96,100,104,108],{"path":61,"resourceType":62,"resourceTypeDesc":63,"sizeBytes":64,"sourceHtmlUrl":65},"agents\u002Fopenai.yml","REFERENCE","参考文档",238,"https:\u002F\u002Fgithub.com\u002FBigdrops\u002Fbigdrops-app\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fshadcn\u002Fagents\u002Fopenai.yml",{"path":67,"resourceType":68,"resourceTypeDesc":69,"sizeBytes":70,"sourceHtmlUrl":71},"assets\u002Fshadcn-small.png","ASSET","资产文件",1049,"https:\u002F\u002Fgithub.com\u002FBigdrops\u002Fbigdrops-app\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fshadcn\u002Fassets\u002Fshadcn-small.png",{"path":73,"resourceType":68,"resourceTypeDesc":69,"sizeBytes":74,"sourceHtmlUrl":75},"assets\u002Fshadcn.png",3852,"https:\u002F\u002Fgithub.com\u002FBigdrops\u002Fbigdrops-app\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fshadcn\u002Fassets\u002Fshadcn.png",{"path":77,"resourceType":62,"resourceTypeDesc":63,"sizeBytes":78,"sourceHtmlUrl":79},"cli.md",16426,"https:\u002F\u002Fgithub.com\u002FBigdrops\u002Fbigdrops-app\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fshadcn\u002Fcli.md",{"path":81,"resourceType":62,"resourceTypeDesc":63,"sizeBytes":82,"sourceHtmlUrl":83},"customization.md",6074,"https:\u002F\u002Fgithub.com\u002FBigdrops\u002Fbigdrops-app\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fshadcn\u002Fcustomization.md",{"path":85,"resourceType":62,"resourceTypeDesc":63,"sizeBytes":86,"sourceHtmlUrl":87},"evals\u002Fevals.json",3118,"https:\u002F\u002Fgithub.com\u002FBigdrops\u002Fbigdrops-app\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fshadcn\u002Fevals\u002Fevals.json",{"path":89,"resourceType":62,"resourceTypeDesc":63,"sizeBytes":90,"sourceHtmlUrl":91},"mcp.md",2385,"https:\u002F\u002Fgithub.com\u002FBigdrops\u002Fbigdrops-app\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fshadcn\u002Fmcp.md",{"path":93,"resourceType":62,"resourceTypeDesc":63,"sizeBytes":94,"sourceHtmlUrl":95},"rules\u002Fbase-vs-radix.md",6954,"https:\u002F\u002Fgithub.com\u002FBigdrops\u002Fbigdrops-app\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fshadcn\u002Frules\u002Fbase-vs-radix.md",{"path":97,"resourceType":62,"resourceTypeDesc":63,"sizeBytes":98,"sourceHtmlUrl":99},"rules\u002Fcomposition.md",4268,"https:\u002F\u002Fgithub.com\u002FBigdrops\u002Fbigdrops-app\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fshadcn\u002Frules\u002Fcomposition.md",{"path":101,"resourceType":62,"resourceTypeDesc":63,"sizeBytes":102,"sourceHtmlUrl":103},"rules\u002Fforms.md",4857,"https:\u002F\u002Fgithub.com\u002FBigdrops\u002Fbigdrops-app\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fshadcn\u002Frules\u002Fforms.md",{"path":105,"resourceType":62,"resourceTypeDesc":63,"sizeBytes":106,"sourceHtmlUrl":107},"rules\u002Ficons.md",1958,"https:\u002F\u002Fgithub.com\u002FBigdrops\u002Fbigdrops-app\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fshadcn\u002Frules\u002Ficons.md",{"path":109,"resourceType":62,"resourceTypeDesc":63,"sizeBytes":110,"sourceHtmlUrl":111},"rules\u002Fstyling.md",3795,"https:\u002F\u002Fgithub.com\u002FBigdrops\u002Fbigdrops-app\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fshadcn\u002Frules\u002Fstyling.md",[113,144,158,174,190,202],{"skillNo":114,"name":115,"nameZh":6,"description":116,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":117,"categories":118,"keywords":127,"publishedAt":34},"01M6C9Z7VKBN4HAFBDXD67K3E1","terraform-test","Comprehensive guide for writing and running Terraform tests. Use when creating test files (.tftest.hcl), writing test scenarios with run blocks, validating infrastructure behavior with assertions, mocking providers and data sources, testing module outputs and resource configurations, or troubleshooting Terraform test syntax and execution.","https:\u002F\u002Fgithub.com\u002Ftwidxuga\u002Fdotfiles\u002Fblob\u002Fmain\u002Fopencode\u002Fdot-config\u002Fopencode\u002Fskills\u002Fterraform-test\u002FSKILL.md",[119,124],{"categoryNo":120,"categoryName":121,"taxonomyType":122,"taxonomyTypeDesc":123},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",{"categoryNo":125,"categoryName":126,"taxonomyType":122,"taxonomyTypeDesc":123},"01JBSEEDCAT000000000000011","运维与部署",[128,129,130,131,132,133,24,134,135,136,137,138,139,140,141,142,143],"test","terraform","terraform test","testing","writing","infrastructure","data","ibm","Providers","execution","troubleshooting","syntax","behavior","guide","use","files",{"skillNo":145,"name":146,"nameZh":6,"description":147,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":148,"categories":149,"keywords":151,"publishedAt":34},"01M6C9Z4GWWTXCXAS8NK747K07","terraform-style-guide","Generate Terraform HCL code following HashiCorp's official style conventions and best practices. Use when writing, reviewing, or generating Terraform configurations.","https:\u002F\u002Fgithub.com\u002Ftwidxuga\u002Fdotfiles\u002Fblob\u002Fmain\u002Fopencode\u002Fdot-config\u002Fopencode\u002Fskills\u002Fterraform-style-guide\u002FSKILL.md",[150],{"categoryNo":125,"categoryName":126,"taxonomyType":122,"taxonomyTypeDesc":123},[152,141,129,153,154,155,156,132,157,142],"terraform style guide","official","generate","code","best practices","hashicorp",{"skillNo":159,"name":160,"nameZh":6,"description":161,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":162,"categories":163,"keywords":165,"publishedAt":34},"01M6C9Z1DCAC8YQQ1WS0AHBB14","terraform-stacks","Comprehensive guide for working with HashiCorp Terraform Stacks. Use when creating, modifying, or validating Terraform Stack configurations (.tfcomponent.hcl, .tfdeploy.hcl files), working with stack components and deployments from local modules, public registry, or private registry sources, managing multi-region or multi-environment infrastructure, or troubleshooting Terraform Stacks syntax and structure.","https:\u002F\u002Fgithub.com\u002Ftwidxuga\u002Fdotfiles\u002Fblob\u002Fmain\u002Fopencode\u002Fdot-config\u002Fopencode\u002Fskills\u002Fterraform-stacks\u002FSKILL.md",[164],{"categoryNo":125,"categoryName":126,"taxonomyType":122,"taxonomyTypeDesc":123},[129,166,167,143,168,169,170,171,133,172,135,157,29,138,139,173,141,142],"terraform stacks","multi-environment","deployments","public","modules","components","registry","environment",{"skillNo":175,"name":176,"nameZh":6,"description":177,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":178,"categories":179,"keywords":181,"publishedAt":34},"01M6C9YYAVCNTR81V4HGZWPFW1","terraform-search-import","Discover existing cloud resources using Terraform Search queries and bulk import them into Terraform management. Use when bringing unmanaged infrastructure under Terraform control, auditing cloud resources, or migrating to IaC.","https:\u002F\u002Fgithub.com\u002Ftwidxuga\u002Fdotfiles\u002Fblob\u002Fmain\u002Fopencode\u002Fdot-config\u002Fopencode\u002Fskills\u002Fterraform-search-import\u002FSKILL.md",[180],{"categoryNo":125,"categoryName":126,"taxonomyType":122,"taxonomyTypeDesc":123},[182,183,129,142,184,133,185,135,136,186,187,188,189],"terraform search import","search","support","cloud","list","management","version","iac",{"skillNo":191,"name":192,"nameZh":6,"description":193,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":194,"licenseFileUrl":6,"sourceHtmlUrl":195,"categories":196,"keywords":198,"publishedAt":34},"01M6BZS7EAXHWK32RG213VE65G","run-acceptance-tests","Guide for running acceptance tests for a Terraform provider. Use this when asked to run an acceptance test or to run a test with the prefix `TestAcc`.","MPL-2.0","https:\u002F\u002Fgithub.com\u002Ftwidxuga\u002Fdotfiles\u002Fblob\u002Fmain\u002Fopencode\u002Fdot-config\u002Fopencode\u002Fskills\u002Fterraform-run-acceptance-tests\u002FSKILL.md",[197],{"categoryNo":125,"categoryName":126,"taxonomyType":122,"taxonomyTypeDesc":123},[199,200,24,128,129,201,135],"run acceptance tests","acceptance","terraform provider",{"skillNo":203,"name":204,"nameZh":6,"description":205,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":206,"categories":207,"keywords":215,"publishedAt":34},"01M6BZS4MJD31PY7M7654ZWQ56","refactor-module","Transform monolithic Terraform configurations into reusable, maintainable modules following HashiCorp's module design principles and community best practices.","https:\u002F\u002Fgithub.com\u002Ftwidxuga\u002Fdotfiles\u002Fblob\u002Fmain\u002Fopencode\u002Fdot-config\u002Fopencode\u002Fskills\u002Fterraform-refactor-module\u002FSKILL.md",[208,211,212],{"categoryNo":209,"categoryName":210,"taxonomyType":122,"taxonomyTypeDesc":123},"01JBSEEDCAT000000000000007","代码审查",{"categoryNo":125,"categoryName":126,"taxonomyType":122,"taxonomyTypeDesc":123},{"categoryNo":213,"categoryName":214,"taxonomyType":122,"taxonomyTypeDesc":123},"01JBSEEDCAT000000000000015","视觉设计",[216,217,156,129,135,157,21],"refactor module","refactor"]