[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6RBK2WFCVHTD3XQB1CRSJTS":3,"skill-same:01M6RBK2WFCVHTD3XQB1CRSJTS":73},{"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":38,"linkOnly":39,"markdownContent":40,"markdownBody":41,"frontMatter":42,"refName":50,"commitSha":51,"skillDirectory":52,"forksCount":53,"repositoryHtmlUrl":54,"repositoryHomepageUrl":6,"ownerHtmlUrl":55,"ownerBlogUrl":56,"ownerDescription":57,"updatedAt":58,"install":59,"resources":72},"01M6RBK2WFCVHTD3XQB1CRSJTS","decide",null,"Explores a problem, its context, and possible solutions before someone makes a significant decision. Use when the user invokes \u002Fdecide, is uncertain about a direction, has not yet evaluated their options, or wants help thinking through a problem. This skill covers the exploration phase. To record a decision that is ready for review, or that the team already adopted, use \u002Flog-decision.","azborgonovo\u002Fai-skills","azborgonovo","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F2183810?v=4","01M6RBCX0K17Z412GQ5A1S9AX4","André Borgonovo","01M6RBCX4STCJD1YSDJB66HEBG",1,"MIT","https:\u002F\u002Fgithub.com\u002Fazborgonovo\u002Fai-skills\u002Fblob\u002Fmain\u002Fskills\u002Fdecisions\u002Fdecide\u002FSKILL.md",[],[5,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37],"thinking","when","phase","for","about","direction","problem","options","record","exploration","review","log","ready","use","read","grep","decision","team","help","2026-11-10 10:12:30",false,"---\nname: decide\ndescription: >\n  Explores a problem, its context, and possible solutions before someone makes a significant\n  decision. Use when the user invokes \u002Fdecide, is uncertain about a direction, has not yet evaluated\n  their options, or wants help thinking through a problem. This skill covers the exploration phase.\n  To record a decision that is ready for review, or that the team already adopted, use \u002Flog-decision.\nargument-hint: \"[decision topic]\"\nallowed-tools: [Read, Glob, Grep, AskUserQuestion]\n---\n\n# Decide\n\nHelp the user think through a significant decision. Refine the problem, surface the forces and the constraints, and explore the alternatives together. This is a conversation between thinking partners, not a form to fill in. Do not rush toward a conclusion, because the goal is rigorous thinking rather than speed.\n\nWhen the user invokes `\u002Fdecide` with an argument, use `$ARGUMENTS` as the opening topic. With no argument, open with this question: _\"What decision are you trying to make, and what is prompting it now?\"_\n\n## Phase 1: Frame the problem\n\nHelp the user state the problem sharply and honestly. Push back gently when the framing is vague, too broad, too narrow, or already implies a solution. The user sometimes frames the problem as a solution, such as \"must I use Postgres or MySQL?\". Zoom out first, and ask what the underlying data problem is.\n\nDraw on these probing questions as you need them. Pick the ones that fit, and do not use them all:\n- \"What happens if you make no decision at all?\"\n- \"Is what you described the root problem, or a symptom of something deeper?\"\n- \"Who is affected by this, and how?\"\n- \"What does success look like? How will you know that you made the right call?\"\n- \"Are you solving this problem, or a problem that you *think* causes this problem?\"\n- \"Are there relevant code areas, issues, or prior decisions that give context I must look at?\"\n\nOnce the problem feels well framed, reflect it back in one or two sentences, and confirm it before you move on. If the user reframes it, update your summary.\n\n## Phase 2: Forces and constraints\n\nExplore what shapes the decision space. Work through these clusters one at a time, not all at once, and reflect back what you hear after each one:\n\n| Cluster | What to explore |\n|---|---|\n| **Hard constraints** | The non-negotiables: regulatory, financial, time, team capability, existing commitments |\n| **Soft constraints** | Preferences or norms that *feel* fixed, and that the right option can challenge |\n| **Assumptions** | Things taken for granted that can turn out to be false |\n| **Stakeholders** | Whose buy-in the decision needs, and what each of them cares about most |\n| **Reversibility** | What it costs to undo this in 6 months, and in 2 years |\n\nName a tension between constraints out loud. For example: _\"You need low cost and high reliability. Those often pull in opposite directions. Which one wins if you have to choose?\"_\n\nSummarize the forces and the constraints, and confirm them before you move to alternatives.\n\n## Phase 3: Generate and evaluate alternatives\n\nBefore you evaluate the options that the user already has in mind, push for breadth:\n\n> \"Before we assess the options you are already considering, let us make sure that we missed nothing. What is the most conservative path? What is the most radical one? What would you do if cost, time, and skill were not constraints?\"\n\nThen work through each option, including the ones the user brought, with this structure:\n- A brief description.\n- What the option serves well.\n- What it gives up, or makes harder.\n- Which assumptions it depends on.\n\nPlay devil's advocate for every option, including the one the user seems to favor. Challenge a weak pro, and surface an underweighted con. When an option is dominated, which means it holds no real advantage over another, say so directly instead of treating every option as equally viable.\n\n## Phase 4: Converge\n\nOnce the user reaches a clear preference, or enough clarity to decide, summarize the thinking:\n\n- **Problem:** [one sentence]\n- **Key constraints:** [bullet list]\n- **Options considered:** [names only]\n- **Leading option:** [name plus the core reason]\n- **Main trade-off accepted:** [what the user accepts or sacrifices]\n- **References:** [links to relevant code, issues, prior DRs, or external resources. Omit this line when there are none.]\n\nConfirm the summary with the user, then ask:\n\n> \"Would you like to log this as a decision record?\"\n\nIf the user says yes, go straight into the workflow of the log-decision skill. Do not ask the user to type a command. Use the title derived from the decision summary as the DR title. Carry the context of this conversation forward: the problem statement, the forces, the options, the leading option, and the trade-off. Then nobody asks the user again for what this conversation already established.\n\n## Principles\n\n- **One question at a time.** Never present a wall of questions. Ask, listen, reflect, then ask the next thing.\n- **Produce no document.** This skill produces clarity. `\u002Flog-decision` produces the document.\n","# Decide\n\nHelp the user think through a significant decision. Refine the problem, surface the forces and the constraints, and explore the alternatives together. This is a conversation between thinking partners, not a form to fill in. Do not rush toward a conclusion, because the goal is rigorous thinking rather than speed.\n\nWhen the user invokes `\u002Fdecide` with an argument, use `$ARGUMENTS` as the opening topic. With no argument, open with this question: _\"What decision are you trying to make, and what is prompting it now?\"_\n\n## Phase 1: Frame the problem\n\nHelp the user state the problem sharply and honestly. Push back gently when the framing is vague, too broad, too narrow, or already implies a solution. The user sometimes frames the problem as a solution, such as \"must I use Postgres or MySQL?\". Zoom out first, and ask what the underlying data problem is.\n\nDraw on these probing questions as you need them. Pick the ones that fit, and do not use them all:\n- \"What happens if you make no decision at all?\"\n- \"Is what you described the root problem, or a symptom of something deeper?\"\n- \"Who is affected by this, and how?\"\n- \"What does success look like? How will you know that you made the right call?\"\n- \"Are you solving this problem, or a problem that you *think* causes this problem?\"\n- \"Are there relevant code areas, issues, or prior decisions that give context I must look at?\"\n\nOnce the problem feels well framed, reflect it back in one or two sentences, and confirm it before you move on. If the user reframes it, update your summary.\n\n## Phase 2: Forces and constraints\n\nExplore what shapes the decision space. Work through these clusters one at a time, not all at once, and reflect back what you hear after each one:\n\n| Cluster | What to explore |\n|---|---|\n| **Hard constraints** | The non-negotiables: regulatory, financial, time, team capability, existing commitments |\n| **Soft constraints** | Preferences or norms that *feel* fixed, and that the right option can challenge |\n| **Assumptions** | Things taken for granted that can turn out to be false |\n| **Stakeholders** | Whose buy-in the decision needs, and what each of them cares about most |\n| **Reversibility** | What it costs to undo this in 6 months, and in 2 years |\n\nName a tension between constraints out loud. For example: _\"You need low cost and high reliability. Those often pull in opposite directions. Which one wins if you have to choose?\"_\n\nSummarize the forces and the constraints, and confirm them before you move to alternatives.\n\n## Phase 3: Generate and evaluate alternatives\n\nBefore you evaluate the options that the user already has in mind, push for breadth:\n\n> \"Before we assess the options you are already considering, let us make sure that we missed nothing. What is the most conservative path? What is the most radical one? What would you do if cost, time, and skill were not constraints?\"\n\nThen work through each option, including the ones the user brought, with this structure:\n- A brief description.\n- What the option serves well.\n- What it gives up, or makes harder.\n- Which assumptions it depends on.\n\nPlay devil's advocate for every option, including the one the user seems to favor. Challenge a weak pro, and surface an underweighted con. When an option is dominated, which means it holds no real advantage over another, say so directly instead of treating every option as equally viable.\n\n## Phase 4: Converge\n\nOnce the user reaches a clear preference, or enough clarity to decide, summarize the thinking:\n\n- **Problem:** [one sentence]\n- **Key constraints:** [bullet list]\n- **Options considered:** [names only]\n- **Leading option:** [name plus the core reason]\n- **Main trade-off accepted:** [what the user accepts or sacrifices]\n- **References:** [links to relevant code, issues, prior DRs, or external resources. Omit this line when there are none.]\n\nConfirm the summary with the user, then ask:\n\n> \"Would you like to log this as a decision record?\"\n\nIf the user says yes, go straight into the workflow of the log-decision skill. Do not ask the user to type a command. Use the title derived from the decision summary as the DR title. Carry the context of this conversation forward: the problem statement, the forces, the options, the leading option, and the trade-off. Then nobody asks the user again for what this conversation already established.\n\n## Principles\n\n- **One question at a time.** Never present a wall of questions. Ask, listen, reflect, then ask the next thing.\n- **Produce no document.** This skill produces clarity. `\u002Flog-decision` produces the document.\n",{"name":5,"description":43,"allowed-tools":44,"argument-hint":49},"Explores a problem, its context, and possible solutions before someone makes a significant decision. Use when the user invokes \u002Fdecide, is uncertain about a direction, has not yet evaluated their options, or wants help thinking through a problem. This skill covers the exploration phase. To record a decision that is ready for review, or that the team already adopted, use \u002Flog-decision.\n",[45,46,47,48],"Read","Glob","Grep","AskUserQuestion","[decision topic]","main","b220d596fb54aeca37127a2b4683ec1454d158e8","skills\u002Fdecisions\u002Fdecide",0,"https:\u002F\u002Fgithub.com\u002Fazborgonovo\u002Fai-skills","https:\u002F\u002Fgithub.com\u002Fazborgonovo","andreborgonovo.com","Tech Lead","2026-11-06 19:56:53",{"source":8,"skillName":5,"commands":60,"prompt":70,"zipAvailable":71},[61,64,67],{"tool":62,"command":63},"npx","npx skills add azborgonovo\u002Fai-skills --skill decide",{"tool":65,"command":66},"bunx","bunx skills add azborgonovo\u002Fai-skills --skill decide",{"tool":68,"command":69},"pnpm","pnpm dlx skills add azborgonovo\u002Fai-skills --skill decide","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fazborgonovo\u002Fai-skills\u002Fblob\u002Fmain\u002Fskills\u002Fdecisions\u002Fdecide\u002FSKILL.md",true,[],[74,109,132,153,172,195],{"skillNo":75,"name":76,"nameZh":6,"description":77,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":78,"categories":79,"keywords":90,"publishedAt":38},"01M6RBP6K9YQ0P9BFAA50DMRS5","work-item","Drafts a well-formed work item with testable acceptance criteria, then creates it in whatever tracker is connected, when the user asks for that explicitly. Applies the same standard to tighten an existing work item. Use when the user invokes \u002Fwork-item, or asks to draft, write up, create, or fix up a ticket, issue, task, story, bug report, or sub-task, for Jira, GitHub, Azure DevOps, Linear, or any other tracker. Use it even when the user names no tracker and never says \"ticket\", as in \"log a bug for...\", \"file an issue about...\", \"write up a task for...\", \"can you create a story for...\", and \"this ticket has no acceptance criteria, can you add some\". Do NOT use it for general prose writing, a PR description, or a commit message, because those follow different conventions.","https:\u002F\u002Fgithub.com\u002Fazborgonovo\u002Fai-skills\u002Fblob\u002Fmain\u002Fskills\u002Fplanning\u002Fwork-item\u002FSKILL.md",[80,85],{"categoryNo":81,"categoryName":82,"taxonomyType":83,"taxonomyTypeDesc":84},"01JBSEEDCAT000000000000018","写作与文案","SCENARIO","使用场景",{"categoryNo":86,"categoryName":87,"taxonomyType":88,"taxonomyTypeDesc":89},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",[91,92,93,94,95,96,97,98,99,100,101,102,30,103,104,105,106,107,108,20],"work","work item","writing","commit","azure devops","jira","create","acceptance","write","fix","never","up","tracker","message","line","ticket","you","drafts",{"skillNo":110,"name":111,"nameZh":6,"description":112,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":113,"categories":114,"keywords":115,"publishedAt":38},"01M6RBNK9Q1FY81BEPH4EA0GE3","triage-work-item","Triages a tracker work item, which is a bug, a task, or a story, end-to-end against the codebase. It reads the item with its full comment thread, links, and parent epic, cross-references related items, investigates the codebases behind the affected feature, corroborates with attached evidence and observability data, then posts a verified analysis comment back to the item. That comment gives the root cause for a bug, or the current behavior, the approach, and the effort for a change request. Ships with Jira and GitHub Issues tracker adapters, plus Grafana and CloudWatch observability adapters, and degrades to any reachable platform. Use when the user gives a work-item URL or key, on Jira (`…atlassian.net\u002Fbrowse\u002FKEY`) or GitHub (`github.com\u002F\u003Co>\u002F\u003Cr>\u002Fissues\u002F\u003Cn>`), and asks to triage, investigate, diagnose, or root-cause it, even without the word \"triage\", as in \"look into TICKET-123 and post what you find\". Do not use it to read or summarize a work item with no code investigation, or to write new work items.","https:\u002F\u002Fgithub.com\u002Fazborgonovo\u002Fai-skills\u002Fblob\u002Fmain\u002Fskills\u002Fplanning\u002Ftriage-work-item\u002FSKILL.md",[],[116,91,117,118,119,120,121,122,123,124,125,126,127,106,128,107,129,130,131,20],"triage","triage work item","change","code","issues","grafana","analysis","Bash","references","back","end","dry","URL","posts","affected","which",{"skillNo":133,"name":134,"nameZh":6,"description":135,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":136,"categories":137,"keywords":138,"publishedAt":38},"01M6RBNAY7GTHTK5G0YYFZCGXG","update-branch","Brings a branch up to date with its base branch, usually main. It rebases onto origin\u002F\u003Cbase>, or merges when the user agrees, then builds and runs the relevant tests. It pushes on its own when the risk is low, and asks first, with the reason, when it is not. It never uses a plain --force, and it never disturbs uncommitted work: a clone on another branch gets a separate git worktree. This skill is user-only: it runs only when the user invokes \u002Fupdate-branch [branch] [--base \u003Cbranch>] [merge]. When the user wants to update a branch with main, rebase onto main, or fix \"branch is behind main\", suggest this command.","https:\u002F\u002Fgithub.com\u002Fazborgonovo\u002Fai-skills\u002Fblob\u002Fmain\u002Fskills\u002Fgit-workflow\u002Fupdate-branch\u002FSKILL.md",[],[139,140,141,142,143,144,145,146,91,147,100,101,148,102,50,149,150,151,152,20],"update","branch","update branch","merge","worktree","risk","first","git worktree","command","only","tests","relevant","with","true",{"skillNo":154,"name":155,"nameZh":6,"description":156,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":157,"categories":158,"keywords":159,"publishedAt":38},"01M6RBMN4XJ6GK79227ZGKPYZ9","standard-first","Guides technical implementation to always prefer the standard, officially-documented solution over custom or AI-generated code. Use when you are about to write new code for a feature, suggest or add a library or package, scaffold a new project, or configure a framework, in any language, including .NET and C#, Node.js and npm, Python, Go, Java, and the rest. Use it above all when the problem sounds like something that a built-in framework feature or a package registry already solves, such as logging enrichment, auth, serialization, retries, health checks, or migrations. Do not skip this skill because the answer feels obvious from training data.","https:\u002F\u002Fgithub.com\u002Fazborgonovo\u002Fai-skills\u002Fblob\u002Fmain\u002Fskills\u002Fengineering-practices\u002Fstandard-first\u002FSKILL.md",[],[145,160,161,162,163,119,164,123,165,166,33,99,167,168,25,169,170,107,171,20],"standard","standard first","auth","training","data","configure","node","generated","project","guides","retries","websearch",{"skillNo":173,"name":174,"nameZh":6,"description":175,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":176,"categories":177,"keywords":178,"publishedAt":38},"01M6RBMDKSZP3VM6X189CNADW3","team-topologies","Knowledge base for Team Topologies concepts — the framework for organizing business and technology teams for fast flow. Use this skill whenever the user asks about: team types (stream-aligned, platform, enabling, complicated subsystem), team interaction modes (collaboration, X-as-a-Service, facilitation), cognitive load management, Thinnest Viable Platform (TVP), Conway's Law in relation to org design, or any question about how software delivery teams should be structured, named, or coordinated. Also use when another skill needs Team Topologies vocabulary to reason about org design, team responsibilities, or team dependencies.","https:\u002F\u002Fgithub.com\u002Fazborgonovo\u002Fai-skills\u002Fblob\u002Fmain\u002Fskills\u002Fdrafts\u002Fteam-topologies\u002FSKILL.md",[],[36,179,180,181,182,183,184,185,32,186,187,188,189,190,191,192,193,22,194,20],"team topologies","design","collaboration","teams","knowledge","question","business","software delivery","technology","knowledge base","platform","as","interaction","types","load","modes",{"skillNo":196,"name":197,"nameZh":6,"description":198,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":199,"categories":200,"keywords":201,"publishedAt":38},"01M6RBKRN96NS1CD2CVQEWZXMW","pareto","Processes the user's request through the Pareto Principle. It ranks the causes that generate most of the outcome, spends roughly a fifth of the effort on the interventions that address them, and reports what that effort bought. This skill is user-only: it runs only when the user invokes \u002Fpareto [request]. When the user wants the highest-leverage slice of a large task, asks \"what matters most here\", wants to cut scope to what moves the needle, or wants an 80\u002F20 pass over analysis, planning, test coverage, refactoring, or cleanup, suggest this command. Do not use it for work whose value depends on being complete, such as a security fix, a compliance change, a migration, or a specific reported bug.","https:\u002F\u002Fgithub.com\u002Fazborgonovo\u002Fai-skills\u002Fblob\u002Fmain\u002Fskills\u002Fdrafts\u002Fpareto\u002FSKILL.md",[],[197,202,203,122,204,100,32,148,205,206,207,208,190,209,210,152,22,211,212,20],"cleanup","planning","coverage","reports","do","task","leverage","scope","complete","value","slice"]