[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71MT5NBY3RY660EA06K9CA1":3,"skill-same:01M71MT5NBY3RY660EA06K9CA1":120},{"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":23,"publishedAt":43,"linkOnly":44,"markdownContent":45,"markdownBody":46,"frontMatter":47,"refName":49,"commitSha":50,"skillDirectory":51,"forksCount":14,"repositoryHtmlUrl":52,"repositoryHomepageUrl":6,"ownerHtmlUrl":53,"ownerBlogUrl":54,"ownerDescription":55,"updatedAt":56,"install":57,"resources":69},"01M71MT5NBY3RY660EA06K9CA1","why",null,"Use for 'why does X work this way', 'why we picked Y', design rationale, regressions, postmortems, or data-backed thresholds. Discovers available MCPs and queries each evidence category (source control, issue tracker, long-form docs, real-time chat, infrastructure observability, error tracking, product analytics warehouse) in parallel, then returns a cited read on decisions and tradeoffs. Use how for runtime behavior.","bbishdotdev\u002Fai-tools","bbishdotdev","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F5323528?v=4","01M71MHYW2Q0DVZA22Q79M8KER","Brenden Bishop","01M71MHYWSMQWFPGA8CBJYQANH",0,"MIT","https:\u002F\u002Fgithub.com\u002Fbbishdotdev\u002Fai-tools\u002Fblob\u002Fmain\u002Fbstack\u002Fupstream\u002Fpstack\u002Fskills\u002Fwhy\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000033","数据分析师","PROFESSION","适用职业",[5,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42],"read","parallel","observability","warehouse","returns","infrastructure","source","analytics","data","issue","tracker","how","product","work","design","product analytics","time","error tracking","error","2026-11-10 10:56:23",false,"---\nname: why\ndescription: \"Use for 'why does X work this way', 'why we picked Y', design rationale, regressions, postmortems, or data-backed thresholds. Discovers available MCPs and queries each evidence category (source control, issue tracker, long-form docs, real-time chat, infrastructure observability, error tracking, product analytics warehouse) in parallel, then returns a cited read on decisions and tradeoffs. Use how for runtime behavior.\"\ndisable-model-invocation: true\n---\n\n# Why\n\nInvestigate the motivation and intent behind code.\n\nCompanion to the `how` skill. `how` answers what the code does and how it works. `why` answers what forces led to its shape.\n\n## Operating Posture\n\nOperate as a **careful, cautious, and precise investigator**. Be honest about what you know vs what you're inferring. Read `references\u002Fepistemics.md` for the full confidence framework and phrasing guide. The synthesizer must follow it.\n\n## Step 1. Understand the Target and the Question\n\nParse what the user is asking. The **target** is usually a chunk of code, a pattern, a feature, or a named design decision. The **question** is usually a design rationale, a tradeoff, a motivating edge case, an external constraint, dead code, or a broad history sweep.\n\nIf the target is vague (\"why do we do it this way?\" with no clear referent), make your best guess from conversation context (open files, recent edits, cursor location, what was just discussed). State your interpretation briefly so the user can redirect if you're off, then proceed.\n\n## Step 2. Establish the Code Anchor\n\nBefore spawning investigators, anchor the investigation in concrete code. You need:\n\n- The relevant file path(s) and line range(s)\n- The key symbols (function names, class names, constants)\n- An initial commit list. The last few commits touching the target.\n- PR numbers from merge commits (pattern `(#1234)` in the subject line)\n\nBuild this inline.\n\n```bash\n# Blame target lines for last-touch commits\ngit blame -L \u003Cstart>,\u003Cend> \u003Cfile>\n\n# Full file history, with patches, through renames\ngit log --follow -p -- \u003Cfile>\n\n# Last N commits touching the file, PR numbers visible\ngit log --oneline -20 -- \u003Cfile>\n\n# Extract PR numbers from a commit message\ngit log -1 --format=%B \u003Ccommit>\n```\n\nPull PR bodies and discussion via `gh` for any substantive commits:\n\n```bash\ngh pr view \u003Cnumber> --json title,body,author,createdAt,mergedAt,labels,closingIssuesReferences,comments,reviews\n```\n\nCapture this as seed context (file paths, symbols, commits, PR numbers, linked ticket IDs). Pass it to the investigators.\n\n## Step 3. Spawn Parallel Investigators (default posture)\n\n**Default to the full parallel investigation.**\n\n### Discovery\n\nBefore spawning investigators, list the available MCPs from the Cursor environment. Use the available-tools map when present. Otherwise inspect the `mcps\u002F` directory Cursor exposes for enabled MCP servers.\n\nMap each available MCP to one evidence category:\n\n1. Source control history\n2. Issue \u002F ticket tracker\n3. Long-form documents\n4. Real-time team chat\n5. Infrastructure observability\n6. Error \u002F exception tracking\n7. Product analytics warehouse\n\nSource control is always available through git and `gh`. For the other six, classify using the MCP name, server instructions, tool names, and resource descriptors. If an MCP could fit more than one category, choose the one matching its primary evidence. Record ambiguous cases in the coverage map.\n\nAim for a complete **coverage map**, not a minimal one. Document the null, don't skip the search.\n\nLaunch all matching investigators in a single message so they run concurrently. Don't ask one agent to cover multiple MCPs.\n\nSubagent config (each):\n- `subagent_type`: `generalPurpose`\n- `model`: your configured why-investigators model (default `grok-4.6-fast-xhigh`)\n- `readonly`: `false` (agent mode). **Do not use readonly\u002FAsk mode.** It strips MCP access, which disables MCP-backed investigators entirely. Investigators still shouldn't write anything.\n\nEach investigator gets:\n1. The base prompt from `references\u002Finvestigator-prompt.md`\n2. The category playbook `references\u002Fsources\u002F\u003Csource>.md` for the selected MCP, adapted from the examples in `references\u002Fsource-playbook.md`\n3. The cross-cutting `references\u002Fsources\u002Fincident-postmortem.md` **if the target code looks defensive** (null checks, retry logic, timeout handling, rate limiting, feature flags, egress guards, OOM handlers)\n4. The code anchor from Step 2 (file paths, symbols, commit hashes, PR numbers, ticket IDs)\n5. The user's original question\n\n### Investigator roster. One per available evidence category\n\nSpawn one investigator per category that has a matching MCP. Each owns exactly one tool or MCP.\n\nEach entry names the category and the kind of \"why\" it uniquely surfaces. Use it to know what to expect back, how to name a gap when a category returns empty, and (only in the rare provably-irrelevant case) to justify a skip.\n\n1. **Source control investigator**. Git history, `gh` for PRs, code comments, tests. Always spawn. The only guaranteed source. Best at surfacing *implementation-time rationale captured during review*.\n\n2. **Issue \u002F ticket tracker investigator** (e.g. Linear, Jira, GitHub Issues, Plane, Shortcut MCP). Best at surfacing *the product or business forcing function*. Strongest when the why is external to engineering.\n\n3. **Long-form documents investigator** (e.g. Notion, Confluence, Google Docs, Coda MCP). Best at surfacing *long-form design rationale*. Where the why is written out before it becomes code.\n\n4. **Real-time team chat investigator** (e.g. Slack, Discord, Microsoft Teams, Mattermost MCP). Best at surfacing *real-time deliberation that never reached a doc*. Especially important when the source control, ticket, and doc paper trail is thin.\n\n5. **Infrastructure observability investigator** (e.g. Datadog, New Relic, Honeycomb, Grafana, Splunk MCP). Infra\u002Fruntime view. Best at surfacing *infrastructure and runtime reality that motivated the code*. Strongest when the target reacts to an infra signal (timeouts, retries, rate limits, circuit breakers).\n\n6. **Error \u002F exception tracking investigator** (e.g. Sentry, Rollbar, Bugsnag, Airbrake MCP). Best at surfacing *the specific exceptions and error trajectories that motivated defensive or corrective code*. Strongest for catch blocks, null guards, type checks, retries, and other defenses.\n\n7. **Product analytics warehouse investigator** (e.g. Databricks, Snowflake, BigQuery, ClickHouse, dbt, Redshift MCP). Product\u002Fdata view. Best at surfacing *product and data reality that shaped the code*. Strongest for flag-gated code, experiment-driven ships, data migrations, and \"where did this number come from\" questions.\n\n### When to skip an investigator\n\nOnly skip with an **explicit, written justification** that goes in the final \"Sources Consulted\" section. Two valid reasons:\n\n- **No MCP is available for that category** in this environment. Flag this as a gap, not a choice. Example: \"Real-time team chat skipped. No matching MCP available, so the conversational record was not searchable.\"\n- **The source is provably irrelevant**, not just \"probably irrelevant.\" A high bar. Example: \"Error \u002F exception tracking skipped. Target is a build-time script with no runtime code path.\"\n\nIf your scope assessment suggests a single-commit trivial target where the PR description already contains the complete answer, you may answer inline **only after** confirming all seven available category searches would be redundant. Say so explicitly. This should be rare.\n\n## Step 4. Synthesize\n\nSpawn one synthesizer subagent:\n\n- `subagent_type`: `generalPurpose`\n- `model`: your configured why-synthesizer model (default `claude-fable-5-1-thinking-max`)\n- `readonly`: `false` (agent mode). The synthesizer's quality check spot-verifies citations, which can require MCP access. Readonly\u002FAsk mode strips MCPs and defeats that.\n\nThe synthesizer gets:\n1. The investigator findings, including any null results and any categories skipped with justification\n2. The code anchor from Step 2 (file paths, symbols, commit hashes, PR numbers, ticket IDs)\n3. The user's original question\n4. The epistemics framework from `references\u002Fepistemics.md`\n5. The synthesizer prompt template from `references\u002Fsynthesizer-prompt.md`\n\n## Step 5. Present\n\nTake the synthesizer's output and present it to the user. You may lightly edit for clarity or add context from the conversation, but **do not rewrite the confidence language**.\n\n## Output Format\n\nThe output structure is the one in `references\u002Fsynthesizer-prompt.md`: The Question, The Code in Question, What We Found, What We Can Reasonably Infer, Competing Hypotheses, What We Don't Know, Sources Consulted, Confidence Summary. Adapt as needed, but keep the confidence separation intact, and keep Sources Consulted as one line per investigator, including the ones that returned nothing or were skipped, with the reason.\n\nAfter the Sources Consulted block, if the user's `why` question is a precursor to actually changing this code, convert the lineage findings into a Preserve \u002F Change \u002F Avoid \u002F Risk constraint set suitable for planning the change.\n\n## Common Failure Modes to Avoid\n\n- **Recency bias**. Assuming the most recent commit is authoritative. The current shape is often the accretion of many earlier decisions. Trace back.\n\n## Reference Files\n\n- `references\u002Fepistemics.md`. Confidence tiers and phrasing guide. The synthesizer must follow it.\n- `references\u002Finvestigator-prompt.md`. Base prompt template for investigator subagents.\n- `references\u002Fsource-playbook.md`. Index pointing at the category playbooks below.\n- `references\u002Fsources\u002F*.md`. One self-contained example playbook per category, plus cross-cutting `incident-postmortem.md`. Give an investigator the single file that matches its category and adapt it to the available MCP.\n- `references\u002Fsynthesizer-prompt.md`. Prompt template for the synthesizer subagent, including the output format.\n","# Why\n\nInvestigate the motivation and intent behind code.\n\nCompanion to the `how` skill. `how` answers what the code does and how it works. `why` answers what forces led to its shape.\n\n## Operating Posture\n\nOperate as a **careful, cautious, and precise investigator**. Be honest about what you know vs what you're inferring. Read `references\u002Fepistemics.md` for the full confidence framework and phrasing guide. The synthesizer must follow it.\n\n## Step 1. Understand the Target and the Question\n\nParse what the user is asking. The **target** is usually a chunk of code, a pattern, a feature, or a named design decision. The **question** is usually a design rationale, a tradeoff, a motivating edge case, an external constraint, dead code, or a broad history sweep.\n\nIf the target is vague (\"why do we do it this way?\" with no clear referent), make your best guess from conversation context (open files, recent edits, cursor location, what was just discussed). State your interpretation briefly so the user can redirect if you're off, then proceed.\n\n## Step 2. Establish the Code Anchor\n\nBefore spawning investigators, anchor the investigation in concrete code. You need:\n\n- The relevant file path(s) and line range(s)\n- The key symbols (function names, class names, constants)\n- An initial commit list. The last few commits touching the target.\n- PR numbers from merge commits (pattern `(#1234)` in the subject line)\n\nBuild this inline.\n\n```bash\n# Blame target lines for last-touch commits\ngit blame -L \u003Cstart>,\u003Cend> \u003Cfile>\n\n# Full file history, with patches, through renames\ngit log --follow -p -- \u003Cfile>\n\n# Last N commits touching the file, PR numbers visible\ngit log --oneline -20 -- \u003Cfile>\n\n# Extract PR numbers from a commit message\ngit log -1 --format=%B \u003Ccommit>\n```\n\nPull PR bodies and discussion via `gh` for any substantive commits:\n\n```bash\ngh pr view \u003Cnumber> --json title,body,author,createdAt,mergedAt,labels,closingIssuesReferences,comments,reviews\n```\n\nCapture this as seed context (file paths, symbols, commits, PR numbers, linked ticket IDs). Pass it to the investigators.\n\n## Step 3. Spawn Parallel Investigators (default posture)\n\n**Default to the full parallel investigation.**\n\n### Discovery\n\nBefore spawning investigators, list the available MCPs from the Cursor environment. Use the available-tools map when present. Otherwise inspect the `mcps\u002F` directory Cursor exposes for enabled MCP servers.\n\nMap each available MCP to one evidence category:\n\n1. Source control history\n2. Issue \u002F ticket tracker\n3. Long-form documents\n4. Real-time team chat\n5. Infrastructure observability\n6. Error \u002F exception tracking\n7. Product analytics warehouse\n\nSource control is always available through git and `gh`. For the other six, classify using the MCP name, server instructions, tool names, and resource descriptors. If an MCP could fit more than one category, choose the one matching its primary evidence. Record ambiguous cases in the coverage map.\n\nAim for a complete **coverage map**, not a minimal one. Document the null, don't skip the search.\n\nLaunch all matching investigators in a single message so they run concurrently. Don't ask one agent to cover multiple MCPs.\n\nSubagent config (each):\n- `subagent_type`: `generalPurpose`\n- `model`: your configured why-investigators model (default `grok-4.6-fast-xhigh`)\n- `readonly`: `false` (agent mode). **Do not use readonly\u002FAsk mode.** It strips MCP access, which disables MCP-backed investigators entirely. Investigators still shouldn't write anything.\n\nEach investigator gets:\n1. The base prompt from `references\u002Finvestigator-prompt.md`\n2. The category playbook `references\u002Fsources\u002F\u003Csource>.md` for the selected MCP, adapted from the examples in `references\u002Fsource-playbook.md`\n3. The cross-cutting `references\u002Fsources\u002Fincident-postmortem.md` **if the target code looks defensive** (null checks, retry logic, timeout handling, rate limiting, feature flags, egress guards, OOM handlers)\n4. The code anchor from Step 2 (file paths, symbols, commit hashes, PR numbers, ticket IDs)\n5. The user's original question\n\n### Investigator roster. One per available evidence category\n\nSpawn one investigator per category that has a matching MCP. Each owns exactly one tool or MCP.\n\nEach entry names the category and the kind of \"why\" it uniquely surfaces. Use it to know what to expect back, how to name a gap when a category returns empty, and (only in the rare provably-irrelevant case) to justify a skip.\n\n1. **Source control investigator**. Git history, `gh` for PRs, code comments, tests. Always spawn. The only guaranteed source. Best at surfacing *implementation-time rationale captured during review*.\n\n2. **Issue \u002F ticket tracker investigator** (e.g. Linear, Jira, GitHub Issues, Plane, Shortcut MCP). Best at surfacing *the product or business forcing function*. Strongest when the why is external to engineering.\n\n3. **Long-form documents investigator** (e.g. Notion, Confluence, Google Docs, Coda MCP). Best at surfacing *long-form design rationale*. Where the why is written out before it becomes code.\n\n4. **Real-time team chat investigator** (e.g. Slack, Discord, Microsoft Teams, Mattermost MCP). Best at surfacing *real-time deliberation that never reached a doc*. Especially important when the source control, ticket, and doc paper trail is thin.\n\n5. **Infrastructure observability investigator** (e.g. Datadog, New Relic, Honeycomb, Grafana, Splunk MCP). Infra\u002Fruntime view. Best at surfacing *infrastructure and runtime reality that motivated the code*. Strongest when the target reacts to an infra signal (timeouts, retries, rate limits, circuit breakers).\n\n6. **Error \u002F exception tracking investigator** (e.g. Sentry, Rollbar, Bugsnag, Airbrake MCP). Best at surfacing *the specific exceptions and error trajectories that motivated defensive or corrective code*. Strongest for catch blocks, null guards, type checks, retries, and other defenses.\n\n7. **Product analytics warehouse investigator** (e.g. Databricks, Snowflake, BigQuery, ClickHouse, dbt, Redshift MCP). Product\u002Fdata view. Best at surfacing *product and data reality that shaped the code*. Strongest for flag-gated code, experiment-driven ships, data migrations, and \"where did this number come from\" questions.\n\n### When to skip an investigator\n\nOnly skip with an **explicit, written justification** that goes in the final \"Sources Consulted\" section. Two valid reasons:\n\n- **No MCP is available for that category** in this environment. Flag this as a gap, not a choice. Example: \"Real-time team chat skipped. No matching MCP available, so the conversational record was not searchable.\"\n- **The source is provably irrelevant**, not just \"probably irrelevant.\" A high bar. Example: \"Error \u002F exception tracking skipped. Target is a build-time script with no runtime code path.\"\n\nIf your scope assessment suggests a single-commit trivial target where the PR description already contains the complete answer, you may answer inline **only after** confirming all seven available category searches would be redundant. Say so explicitly. This should be rare.\n\n## Step 4. Synthesize\n\nSpawn one synthesizer subagent:\n\n- `subagent_type`: `generalPurpose`\n- `model`: your configured why-synthesizer model (default `claude-fable-5-1-thinking-max`)\n- `readonly`: `false` (agent mode). The synthesizer's quality check spot-verifies citations, which can require MCP access. Readonly\u002FAsk mode strips MCPs and defeats that.\n\nThe synthesizer gets:\n1. The investigator findings, including any null results and any categories skipped with justification\n2. The code anchor from Step 2 (file paths, symbols, commit hashes, PR numbers, ticket IDs)\n3. The user's original question\n4. The epistemics framework from `references\u002Fepistemics.md`\n5. The synthesizer prompt template from `references\u002Fsynthesizer-prompt.md`\n\n## Step 5. Present\n\nTake the synthesizer's output and present it to the user. You may lightly edit for clarity or add context from the conversation, but **do not rewrite the confidence language**.\n\n## Output Format\n\nThe output structure is the one in `references\u002Fsynthesizer-prompt.md`: The Question, The Code in Question, What We Found, What We Can Reasonably Infer, Competing Hypotheses, What We Don't Know, Sources Consulted, Confidence Summary. Adapt as needed, but keep the confidence separation intact, and keep Sources Consulted as one line per investigator, including the ones that returned nothing or were skipped, with the reason.\n\nAfter the Sources Consulted block, if the user's `why` question is a precursor to actually changing this code, convert the lineage findings into a Preserve \u002F Change \u002F Avoid \u002F Risk constraint set suitable for planning the change.\n\n## Common Failure Modes to Avoid\n\n- **Recency bias**. Assuming the most recent commit is authoritative. The current shape is often the accretion of many earlier decisions. Trace back.\n\n## Reference Files\n\n- `references\u002Fepistemics.md`. Confidence tiers and phrasing guide. The synthesizer must follow it.\n- `references\u002Finvestigator-prompt.md`. Base prompt template for investigator subagents.\n- `references\u002Fsource-playbook.md`. Index pointing at the category playbooks below.\n- `references\u002Fsources\u002F*.md`. One self-contained example playbook per category, plus cross-cutting `incident-postmortem.md`. Give an investigator the single file that matches its category and adapt it to the available MCP.\n- `references\u002Fsynthesizer-prompt.md`. Prompt template for the synthesizer subagent, including the output format.\n",{"name":5,"description":7,"disable-model-invocation":48},true,"main","e7c8126d1ad4df934236dba12521dcbe7fcd9d74","bstack\u002Fupstream\u002Fpstack\u002Fskills\u002Fwhy","https:\u002F\u002Fgithub.com\u002Fbbishdotdev\u002Fai-tools","https:\u002F\u002Fgithub.com\u002Fbbishdotdev","bbish.dev","Husband | Father | Technologist\r\nEngineering leader helping product and delivery teams use AI to build better systems, habits, and tools.","2026-11-11 11:13:39",{"source":8,"skillName":5,"commands":58,"prompt":68,"zipAvailable":48},[59,62,65],{"tool":60,"command":61},"npx","npx skills add bbishdotdev\u002Fai-tools --skill why",{"tool":63,"command":64},"bunx","bunx skills add bbishdotdev\u002Fai-tools --skill why",{"tool":66,"command":67},"pnpm","pnpm dlx skills add bbishdotdev\u002Fai-tools --skill why","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fbbishdotdev\u002Fai-tools\u002Fblob\u002Fmain\u002Fbstack\u002Fupstream\u002Fpstack\u002Fskills\u002Fwhy\u002FSKILL.md",[70,76,80,84,88,92,96,100,104,108,112,116],{"path":71,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":74,"sourceHtmlUrl":75},"references\u002Fepistemics.md","REFERENCE","参考文档",7749,"https:\u002F\u002Fgithub.com\u002Fbbishdotdev\u002Fai-tools\u002Fblob\u002Fmain\u002Fbstack\u002Fupstream\u002Fpstack\u002Fskills\u002Fwhy\u002Freferences\u002Fepistemics.md",{"path":77,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":78,"sourceHtmlUrl":79},"references\u002Finvestigator-prompt.md",6985,"https:\u002F\u002Fgithub.com\u002Fbbishdotdev\u002Fai-tools\u002Fblob\u002Fmain\u002Fbstack\u002Fupstream\u002Fpstack\u002Fskills\u002Fwhy\u002Freferences\u002Finvestigator-prompt.md",{"path":81,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":82,"sourceHtmlUrl":83},"references\u002Fsource-playbook.md",1363,"https:\u002F\u002Fgithub.com\u002Fbbishdotdev\u002Fai-tools\u002Fblob\u002Fmain\u002Fbstack\u002Fupstream\u002Fpstack\u002Fskills\u002Fwhy\u002Freferences\u002Fsource-playbook.md",{"path":85,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":86,"sourceHtmlUrl":87},"references\u002Fsources\u002Fcode-archaeology.md",3489,"https:\u002F\u002Fgithub.com\u002Fbbishdotdev\u002Fai-tools\u002Fblob\u002Fmain\u002Fbstack\u002Fupstream\u002Fpstack\u002Fskills\u002Fwhy\u002Freferences\u002Fsources\u002Fcode-archaeology.md",{"path":89,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":90,"sourceHtmlUrl":91},"references\u002Fsources\u002Fdatabricks.md",6994,"https:\u002F\u002Fgithub.com\u002Fbbishdotdev\u002Fai-tools\u002Fblob\u002Fmain\u002Fbstack\u002Fupstream\u002Fpstack\u002Fskills\u002Fwhy\u002Freferences\u002Fsources\u002Fdatabricks.md",{"path":93,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":94,"sourceHtmlUrl":95},"references\u002Fsources\u002Fdatadog.md",5323,"https:\u002F\u002Fgithub.com\u002Fbbishdotdev\u002Fai-tools\u002Fblob\u002Fmain\u002Fbstack\u002Fupstream\u002Fpstack\u002Fskills\u002Fwhy\u002Freferences\u002Fsources\u002Fdatadog.md",{"path":97,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":98,"sourceHtmlUrl":99},"references\u002Fsources\u002Fincident-postmortem.md",1973,"https:\u002F\u002Fgithub.com\u002Fbbishdotdev\u002Fai-tools\u002Fblob\u002Fmain\u002Fbstack\u002Fupstream\u002Fpstack\u002Fskills\u002Fwhy\u002Freferences\u002Fsources\u002Fincident-postmortem.md",{"path":101,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":102,"sourceHtmlUrl":103},"references\u002Fsources\u002Flinear.md",2993,"https:\u002F\u002Fgithub.com\u002Fbbishdotdev\u002Fai-tools\u002Fblob\u002Fmain\u002Fbstack\u002Fupstream\u002Fpstack\u002Fskills\u002Fwhy\u002Freferences\u002Fsources\u002Flinear.md",{"path":105,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":106,"sourceHtmlUrl":107},"references\u002Fsources\u002Fnotion.md",2853,"https:\u002F\u002Fgithub.com\u002Fbbishdotdev\u002Fai-tools\u002Fblob\u002Fmain\u002Fbstack\u002Fupstream\u002Fpstack\u002Fskills\u002Fwhy\u002Freferences\u002Fsources\u002Fnotion.md",{"path":109,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":110,"sourceHtmlUrl":111},"references\u002Fsources\u002Fsentry.md",4947,"https:\u002F\u002Fgithub.com\u002Fbbishdotdev\u002Fai-tools\u002Fblob\u002Fmain\u002Fbstack\u002Fupstream\u002Fpstack\u002Fskills\u002Fwhy\u002Freferences\u002Fsources\u002Fsentry.md",{"path":113,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":114,"sourceHtmlUrl":115},"references\u002Fsources\u002Fslack.md",3105,"https:\u002F\u002Fgithub.com\u002Fbbishdotdev\u002Fai-tools\u002Fblob\u002Fmain\u002Fbstack\u002Fupstream\u002Fpstack\u002Fskills\u002Fwhy\u002Freferences\u002Fsources\u002Fslack.md",{"path":117,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":118,"sourceHtmlUrl":119},"references\u002Fsynthesizer-prompt.md",7984,"https:\u002F\u002Fgithub.com\u002Fbbishdotdev\u002Fai-tools\u002Fblob\u002Fmain\u002Fbstack\u002Fupstream\u002Fpstack\u002Fskills\u002Fwhy\u002Freferences\u002Fsynthesizer-prompt.md",[121,133,149,182,205,223],{"skillNo":122,"name":123,"nameZh":6,"description":124,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":125,"categories":126,"keywords":127,"publishedAt":43},"01M71MT4CFF7AK4TRV40P7ZZ30","unslop","Cut AI tells from any writing. Must always apply.","https:\u002F\u002Fgithub.com\u002Fbbishdotdev\u002Fai-tools\u002Fblob\u002Fmain\u002Fbstack\u002Fupstream\u002Fpstack\u002Fskills\u002Funslop\u002FSKILL.md",[],[123,128,129,130,131,132],"apply","writing","true","ai tells","cut",{"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":139,"publishedAt":43},"01M71MT37W015EGE0EB82JQYAM","typescript-best-practices","TypeScript best practices. Use when reading or editing any .ts or .tsx file.","https:\u002F\u002Fgithub.com\u002Fbbishdotdev\u002Fai-tools\u002Fblob\u002Fmain\u002Fbstack\u002Fupstream\u002Fpstack\u002Fskills\u002Ftypescript-best-practices\u002FSKILL.md",[],[140,141,142,143,144,145,146,147,130,148],"best practices","typescript","typescript best practices","tsx","file","editing","when","use","reading",{"skillNo":150,"name":151,"nameZh":6,"description":152,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":153,"categories":154,"keywords":166,"publishedAt":43},"01M71MT1092N34HQMGECW170JP","technical-writing","Layered technical-writing standard: Diátaxis structure, Google developer style sentences, STE instruction rules, Global English syntax. Use for \u002Ftechnical-writing or when writing or reviewing docs, RFCs, readmes, PR descriptions, or commit messages.","https:\u002F\u002Fgithub.com\u002Fbbishdotdev\u002Fai-tools\u002Fblob\u002Fmain\u002Fbstack\u002Fupstream\u002Fpstack\u002Fskills\u002Ftechnical-writing\u002FSKILL.md",[155,160,163],{"categoryNo":156,"categoryName":157,"taxonomyType":158,"taxonomyTypeDesc":159},"01JBSEEDCAT000000000000018","写作与文案","SCENARIO","使用场景",{"categoryNo":161,"categoryName":162,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000030","开发工程师",{"categoryNo":164,"categoryName":165,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000036","内容创作者",[129,167,168,169,170,147,146,130,171,172,173,151,174,175,176,177,178,179,180,181],"technical writing","technical","standard","Rules","commit","structure","messages","for","pr","english","commit messages","google","syntax","style","layered",{"skillNo":183,"name":184,"nameZh":6,"description":185,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":186,"categories":187,"keywords":191,"publishedAt":43},"01M71MSYRMT7KZPQFY7A2ZHGMB","teach","Explain a body of work plainly so a person actually understands it. Runs the `how` and `why` skills and weaves what they find into one clear explanation. Use for 'teach me this', 'help me really understand X', 'explain this change or subsystem to me'.","https:\u002F\u002Fgithub.com\u002Fbbishdotdev\u002Fai-tools\u002Fblob\u002Fmain\u002Fbstack\u002Fupstream\u002Fpstack\u002Fskills\u002Fteach\u002FSKILL.md",[188],{"categoryNo":189,"categoryName":190,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000039","教师与教育",[184,192,193,194,195,196,197,198,130,199,200,5,201,202,174,35,147,203,204,37],"it","explain","one","body","teach me","me","understand","clear","person","find","help","explanation","change",{"skillNo":206,"name":207,"nameZh":6,"description":208,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":209,"categories":210,"keywords":211,"publishedAt":43},"01M71MSWTVAEVMZAG7SMWFE1FE","tdd","Use only when the user explicitly asks for TDD, a failing test, or a regression test, OR when the bug has an obvious cheap local test target. Skip when the test path is unclear, expensive, integration-heavy, or not requested.","https:\u002F\u002Fgithub.com\u002Fbbishdotdev\u002Fai-tools\u002Fblob\u002Fmain\u002Fbstack\u002Fupstream\u002Fpstack\u002Fskills\u002Ftdd\u002FSKILL.md",[],[207,212,213,214,215,216,174,217,218,130,219,220,221,146,147,222],"local","failing","bug","integration","regression","target","test","path","user","regression test","only",{"skillNo":224,"name":225,"nameZh":6,"description":226,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":227,"categories":228,"keywords":229,"publishedAt":43},"01M71MSVGH8V70VHAJH5RF4V4G","swarm","Fan out N parallel workers, drain them, and return one report. Use for \u002Fswarm, 'swarm this', or parallel coverage, races, gauntlets, and exploration.","https:\u002F\u002Fgithub.com\u002Fbbishdotdev\u002Fai-tools\u002Fblob\u002Fmain\u002Fbstack\u002Fupstream\u002Fpstack\u002Fskills\u002Fswarm\u002FSKILL.md",[],[225,230,194,231,147,130,232,174,233,25,234,235],"fan out","workers","report","exploration","drain","coverage"]