[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M70M8DK87GX45FFZCC840SW2":3,"skill-same:01M70M8DK87GX45FFZCC840SW2":117},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":22,"publishedAt":42,"linkOnly":43,"markdownContent":44,"markdownBody":45,"frontMatter":46,"refName":48,"commitSha":49,"skillDirectory":50,"forksCount":13,"repositoryHtmlUrl":51,"repositoryHomepageUrl":6,"ownerHtmlUrl":52,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":53,"install":54,"resources":66},"01M70M8DK87GX45FFZCC840SW2","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.","mingster\u002Fdotfiles","mingster","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F528506?v=4","01M6BVP9E23T80TBZM7S0F94RG","01M6BVP9JK6JMSX0SZ2G1VMEDW",1,"MIT","https:\u002F\u002Fgithub.com\u002Fmingster\u002Fdotfiles\u002Fblob\u002Fmain\u002Ftemplates\u002Fagent-team\u002F.agents\u002Fskills\u002Fwhy\u002FSKILL.md",[17],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000033","数据分析师","PROFESSION","适用职业",[5,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41],"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:12:30",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\nIn Claude Code, read [the Claude Code adapter](..\u002F..\u002Fdocs\u002Fharness\u002Fclaude-code.md) once per session before you follow this skill. It maps the Cursor names in pstack skills to Claude Code.\n\nInvestigate the motivation and intent behind code. The companion `how` skill answers what the code does and how it works. `why` answers what forces led to its shape.\n\nEach spawn below names a role line in the `pstack-models.mdc` rule and a default. Set `model` to that line's value, or to the default if the rule or the line is missing. Leave `model` unset when the value is `auto` or `inherit-parent`. If the Task tool rejects a slug, use the default and say so. If it rejects the default, use the closest valid slug of the same family from its error message. Pick each subagent's reasoning level and fast or standard speed for the job, per the Subagents section of the **poteto-mode** skill.\n\nEvery spawn is `generalPurpose` with `readonly: false` (agent mode). **Do not use readonly\u002FAsk mode.** It strips MCP access, which disables the MCP-backed investigators and the synthesizer's citation spot-checks. Investigators still shouldn't write anything.\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\nThe **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, build the seed context inline: file paths and line ranges, key symbols (functions, classes, constants), the last few commits touching the target, PR numbers from merge commits (pattern `(#1234)` in the subject line), and any linked ticket IDs. Run `git blame -L \u003Cstart>,\u003Cend> \u003Cfile>` for last-touch commits, `git log --follow -p -- \u003Cfile>` for full history with patches through renames, `git log --oneline -20 -- \u003Cfile>` for recent commits with PR numbers visible, and `git log -1 --format=%B \u003Ccommit>` to extract PR numbers. Then pull the PR bodies and discussion for any substantive commit: `gh pr view \u003Cnumber> --json title,body,author,createdAt,mergedAt,labels,closingIssuesReferences,comments,reviews`. This anchor goes to every investigator and to the synthesizer.\n\n## Step 3. Spawn Parallel Investigators\n\n**Default to the full parallel investigation.** The goal is a complete coverage map, not a minimal one. Document the null, don't skip the search.\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\nSpawn one investigator per category that has a matching MCP, all in a single message so they run concurrently, each owning exactly one tool or MCP. Don't ask one agent to cover multiple MCPs. `model`: the `why investigators` line, default `grok-4.7-xhigh-fast`.\n\nEach investigator's prompt is `references\u002Finvestigator-prompt.md` filled in, plus:\n- the category playbook `references\u002Fsources\u002F\u003Csource>.md` for the selected MCP, adapted from the examples in `references\u002Fsource-playbook.md`\n- `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)\n- the code anchor and the user's original question\n\n### Investigator roster, one per available evidence category\n\nEach category below is uniquely positioned to surface one shape of \"why\", shown after \"Best at\". Use it to know what to expect back, 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** (git history, `gh` for PRs, code comments, tests). Always spawn, the only guaranteed source. Best at *implementation-time rationale captured during review*.\n2. **Issue \u002F ticket tracker** (e.g. Linear, Jira, GitHub Issues, Plane, Shortcut MCP). Best at *the product or business forcing function*. Strongest when the why is external to engineering.\n3. **Long-form documents** (e.g. Notion, Confluence, Google Docs, Coda MCP). Best at *long-form design rationale*, written out before it becomes code.\n4. **Real-time team chat** (e.g. Slack, Discord, Microsoft Teams, Mattermost MCP). Best at *real-time deliberation that never reached a doc*. Especially important when the source control, ticket, and doc paper trail is thin.\n5. **Infrastructure observability** (e.g. Datadog, New Relic, Honeycomb, Grafana, Splunk MCP). Best at *infrastructure and runtime reality that motivated the code*. Strongest when the target reacts to an infra signal (timeouts, retries, rate limits, circuit breakers).\n6. **Error \u002F exception tracking** (e.g. Sentry, Rollbar, Bugsnag, Airbrake MCP). Best at *the specific exceptions and error trajectories that motivated defensive or corrective code*. Strongest for catch blocks, null guards, type checks, retries, and other defenses.\n7. **Product analytics warehouse** (e.g. Databricks, Snowflake, BigQuery, ClickHouse, dbt, Redshift MCP). Best at *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 with an **explicit, written justification** that goes in the final Sources Consulted. Two valid reasons:\n\n- **No MCP is available for that category** in this environment. Flag it as a gap, not a choice: \"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: \"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. `model`: the `why synthesizer` line, default `claude-opus-5-5-xhigh`. It gets:\n1. The investigator findings, including any null results and any categories skipped with justification\n2. The code anchor\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\nPresent the synthesizer's output 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 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 Sources Consulted, if the user's `why` question is a precursor to changing this code, convert the lineage findings into a Preserve \u002F Change \u002F Avoid \u002F Risk constraint set 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","# Why\n\nIn Claude Code, read [the Claude Code adapter](..\u002F..\u002Fdocs\u002Fharness\u002Fclaude-code.md) once per session before you follow this skill. It maps the Cursor names in pstack skills to Claude Code.\n\nInvestigate the motivation and intent behind code. The companion `how` skill answers what the code does and how it works. `why` answers what forces led to its shape.\n\nEach spawn below names a role line in the `pstack-models.mdc` rule and a default. Set `model` to that line's value, or to the default if the rule or the line is missing. Leave `model` unset when the value is `auto` or `inherit-parent`. If the Task tool rejects a slug, use the default and say so. If it rejects the default, use the closest valid slug of the same family from its error message. Pick each subagent's reasoning level and fast or standard speed for the job, per the Subagents section of the **poteto-mode** skill.\n\nEvery spawn is `generalPurpose` with `readonly: false` (agent mode). **Do not use readonly\u002FAsk mode.** It strips MCP access, which disables the MCP-backed investigators and the synthesizer's citation spot-checks. Investigators still shouldn't write anything.\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\nThe **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, build the seed context inline: file paths and line ranges, key symbols (functions, classes, constants), the last few commits touching the target, PR numbers from merge commits (pattern `(#1234)` in the subject line), and any linked ticket IDs. Run `git blame -L \u003Cstart>,\u003Cend> \u003Cfile>` for last-touch commits, `git log --follow -p -- \u003Cfile>` for full history with patches through renames, `git log --oneline -20 -- \u003Cfile>` for recent commits with PR numbers visible, and `git log -1 --format=%B \u003Ccommit>` to extract PR numbers. Then pull the PR bodies and discussion for any substantive commit: `gh pr view \u003Cnumber> --json title,body,author,createdAt,mergedAt,labels,closingIssuesReferences,comments,reviews`. This anchor goes to every investigator and to the synthesizer.\n\n## Step 3. Spawn Parallel Investigators\n\n**Default to the full parallel investigation.** The goal is a complete coverage map, not a minimal one. Document the null, don't skip the search.\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\nSpawn one investigator per category that has a matching MCP, all in a single message so they run concurrently, each owning exactly one tool or MCP. Don't ask one agent to cover multiple MCPs. `model`: the `why investigators` line, default `grok-4.7-xhigh-fast`.\n\nEach investigator's prompt is `references\u002Finvestigator-prompt.md` filled in, plus:\n- the category playbook `references\u002Fsources\u002F\u003Csource>.md` for the selected MCP, adapted from the examples in `references\u002Fsource-playbook.md`\n- `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)\n- the code anchor and the user's original question\n\n### Investigator roster, one per available evidence category\n\nEach category below is uniquely positioned to surface one shape of \"why\", shown after \"Best at\". Use it to know what to expect back, 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** (git history, `gh` for PRs, code comments, tests). Always spawn, the only guaranteed source. Best at *implementation-time rationale captured during review*.\n2. **Issue \u002F ticket tracker** (e.g. Linear, Jira, GitHub Issues, Plane, Shortcut MCP). Best at *the product or business forcing function*. Strongest when the why is external to engineering.\n3. **Long-form documents** (e.g. Notion, Confluence, Google Docs, Coda MCP). Best at *long-form design rationale*, written out before it becomes code.\n4. **Real-time team chat** (e.g. Slack, Discord, Microsoft Teams, Mattermost MCP). Best at *real-time deliberation that never reached a doc*. Especially important when the source control, ticket, and doc paper trail is thin.\n5. **Infrastructure observability** (e.g. Datadog, New Relic, Honeycomb, Grafana, Splunk MCP). Best at *infrastructure and runtime reality that motivated the code*. Strongest when the target reacts to an infra signal (timeouts, retries, rate limits, circuit breakers).\n6. **Error \u002F exception tracking** (e.g. Sentry, Rollbar, Bugsnag, Airbrake MCP). Best at *the specific exceptions and error trajectories that motivated defensive or corrective code*. Strongest for catch blocks, null guards, type checks, retries, and other defenses.\n7. **Product analytics warehouse** (e.g. Databricks, Snowflake, BigQuery, ClickHouse, dbt, Redshift MCP). Best at *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 with an **explicit, written justification** that goes in the final Sources Consulted. Two valid reasons:\n\n- **No MCP is available for that category** in this environment. Flag it as a gap, not a choice: \"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: \"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. `model`: the `why synthesizer` line, default `claude-opus-5-5-xhigh`. It gets:\n1. The investigator findings, including any null results and any categories skipped with justification\n2. The code anchor\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\nPresent the synthesizer's output 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 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 Sources Consulted, if the user's `why` question is a precursor to changing this code, convert the lineage findings into a Preserve \u002F Change \u002F Avoid \u002F Risk constraint set 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",{"name":5,"description":7,"disable-model-invocation":47},true,"main","d775d974eade471675ab972f749b4be9bcdad6c3","templates\u002Fagent-team\u002F.agents\u002Fskills\u002Fwhy","https:\u002F\u002Fgithub.com\u002Fmingster\u002Fdotfiles","https:\u002F\u002Fgithub.com\u002Fmingster","2026-11-11 08:37:54",{"source":8,"skillName":5,"commands":55,"prompt":65,"zipAvailable":47},[56,59,62],{"tool":57,"command":58},"npx","npx skills add mingster\u002Fdotfiles --skill why",{"tool":60,"command":61},"bunx","bunx skills add mingster\u002Fdotfiles --skill why",{"tool":63,"command":64},"pnpm","pnpm dlx skills add mingster\u002Fdotfiles --skill why","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmingster\u002Fdotfiles\u002Fblob\u002Fmain\u002Ftemplates\u002Fagent-team\u002F.agents\u002Fskills\u002Fwhy\u002FSKILL.md",[67,73,77,81,85,89,93,97,101,105,109,113],{"path":68,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":71,"sourceHtmlUrl":72},"references\u002Fepistemics.md","REFERENCE","参考文档",6736,"https:\u002F\u002Fgithub.com\u002Fmingster\u002Fdotfiles\u002Fblob\u002Fmain\u002Ftemplates\u002Fagent-team\u002F.agents\u002Fskills\u002Fwhy\u002Freferences\u002Fepistemics.md",{"path":74,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":75,"sourceHtmlUrl":76},"references\u002Finvestigator-prompt.md",5554,"https:\u002F\u002Fgithub.com\u002Fmingster\u002Fdotfiles\u002Fblob\u002Fmain\u002Ftemplates\u002Fagent-team\u002F.agents\u002Fskills\u002Fwhy\u002Freferences\u002Finvestigator-prompt.md",{"path":78,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":79,"sourceHtmlUrl":80},"references\u002Fsource-playbook.md",1363,"https:\u002F\u002Fgithub.com\u002Fmingster\u002Fdotfiles\u002Fblob\u002Fmain\u002Ftemplates\u002Fagent-team\u002F.agents\u002Fskills\u002Fwhy\u002Freferences\u002Fsource-playbook.md",{"path":82,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":83,"sourceHtmlUrl":84},"references\u002Fsources\u002Fcode-archaeology.md",1440,"https:\u002F\u002Fgithub.com\u002Fmingster\u002Fdotfiles\u002Fblob\u002Fmain\u002Ftemplates\u002Fagent-team\u002F.agents\u002Fskills\u002Fwhy\u002Freferences\u002Fsources\u002Fcode-archaeology.md",{"path":86,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":87,"sourceHtmlUrl":88},"references\u002Fsources\u002Fdatabricks.md",6994,"https:\u002F\u002Fgithub.com\u002Fmingster\u002Fdotfiles\u002Fblob\u002Fmain\u002Ftemplates\u002Fagent-team\u002F.agents\u002Fskills\u002Fwhy\u002Freferences\u002Fsources\u002Fdatabricks.md",{"path":90,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":91,"sourceHtmlUrl":92},"references\u002Fsources\u002Fdatadog.md",4971,"https:\u002F\u002Fgithub.com\u002Fmingster\u002Fdotfiles\u002Fblob\u002Fmain\u002Ftemplates\u002Fagent-team\u002F.agents\u002Fskills\u002Fwhy\u002Freferences\u002Fsources\u002Fdatadog.md",{"path":94,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":95,"sourceHtmlUrl":96},"references\u002Fsources\u002Fincident-postmortem.md",372,"https:\u002F\u002Fgithub.com\u002Fmingster\u002Fdotfiles\u002Fblob\u002Fmain\u002Ftemplates\u002Fagent-team\u002F.agents\u002Fskills\u002Fwhy\u002Freferences\u002Fsources\u002Fincident-postmortem.md",{"path":98,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":99,"sourceHtmlUrl":100},"references\u002Fsources\u002Flinear.md",2996,"https:\u002F\u002Fgithub.com\u002Fmingster\u002Fdotfiles\u002Fblob\u002Fmain\u002Ftemplates\u002Fagent-team\u002F.agents\u002Fskills\u002Fwhy\u002Freferences\u002Fsources\u002Flinear.md",{"path":102,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":103,"sourceHtmlUrl":104},"references\u002Fsources\u002Fnotion.md",2853,"https:\u002F\u002Fgithub.com\u002Fmingster\u002Fdotfiles\u002Fblob\u002Fmain\u002Ftemplates\u002Fagent-team\u002F.agents\u002Fskills\u002Fwhy\u002Freferences\u002Fsources\u002Fnotion.md",{"path":106,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":107,"sourceHtmlUrl":108},"references\u002Fsources\u002Fsentry.md",2089,"https:\u002F\u002Fgithub.com\u002Fmingster\u002Fdotfiles\u002Fblob\u002Fmain\u002Ftemplates\u002Fagent-team\u002F.agents\u002Fskills\u002Fwhy\u002Freferences\u002Fsources\u002Fsentry.md",{"path":110,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":111,"sourceHtmlUrl":112},"references\u002Fsources\u002Fslack.md",1336,"https:\u002F\u002Fgithub.com\u002Fmingster\u002Fdotfiles\u002Fblob\u002Fmain\u002Ftemplates\u002Fagent-team\u002F.agents\u002Fskills\u002Fwhy\u002Freferences\u002Fsources\u002Fslack.md",{"path":114,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":115,"sourceHtmlUrl":116},"references\u002Fsynthesizer-prompt.md",7146,"https:\u002F\u002Fgithub.com\u002Fmingster\u002Fdotfiles\u002Fblob\u002Fmain\u002Ftemplates\u002Fagent-team\u002F.agents\u002Fskills\u002Fwhy\u002Freferences\u002Fsynthesizer-prompt.md",[118,148,163,182,202,217],{"skillNo":119,"name":120,"nameZh":6,"description":121,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":122,"categories":123,"keywords":129,"publishedAt":42},"01M70M8J3PA9F7TJA4DK95GE8N","workflow-from-chats","Extract durable working preferences from recent Cursor chats and convert them into skills, rules, or workflow docs. Use when asked to learn preferences, mine feedback, personalize workflows, or generate team\u002Fperson-specific agent guidance.","https:\u002F\u002Fgithub.com\u002Fmingster\u002Fdotfiles\u002Fblob\u002Fmain\u002Ftemplates\u002Fagent-team\u002F.agents\u002Fskills\u002Fworkflow-from-chats\u002FSKILL.md",[124],{"categoryNo":125,"categoryName":126,"taxonomyType":127,"taxonomyTypeDesc":128},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[130,131,132,133,134,135,136,137,138,139,140,141,142,143,144,145,146,147],"workflow","workflow from chats","when","convert","person","mine","guidance","use","cursor","extract","Rules","feedback","preferences","team","learn","generate","workflows","docs",{"skillNo":149,"name":150,"nameZh":6,"description":151,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":152,"categories":153,"keywords":154,"publishedAt":42},"01M70M89EYB7RB4WT9EBQ19VEW","what-did-i-get-done","Summarize authored commits over a user-specified time period into a concise update","https:\u002F\u002Fgithub.com\u002Fmingster\u002Fdotfiles\u002Fblob\u002Fmain\u002Ftemplates\u002Fagent-team\u002F.agents\u002Fskills\u002Fwhat-did-i-get-done\u002FSKILL.md",[],[155,156,157,158,159,160,161,39,162],"get","done","what did i get done","summarize","update","commits","user","concise",{"skillNo":164,"name":165,"nameZh":6,"description":166,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":167,"categories":168,"keywords":169,"publishedAt":42},"01M70M887Z6CVVHAM294BC9SG3","weekly-review","Produce a weekly synthesis of authored commits with highlights by bugfix, tech debt, and net-new work","https:\u002F\u002Fgithub.com\u002Fmingster\u002Fdotfiles\u002Fblob\u002Fmain\u002Ftemplates\u002Fagent-team\u002F.agents\u002Fskills\u002Fweekly-review\u002FSKILL.md",[],[170,171,172,173,174,175,176,177,178,179,36,160,180,181],"weekly","review","weekly review","bugfix","weekly synthesis","new","debt","Synthesis","with","tech","produce","tech debt",{"skillNo":183,"name":184,"nameZh":6,"description":185,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":186,"categories":187,"keywords":188,"publishedAt":42},"01M70M86M3WNW7S7TZ1NVKSGT7","verify-this","Verify a claim with fresh local evidence: restate it falsifiably, capture baseline and treatment, compare artifacts, and return VERIFIED, NOT VERIFIED, or INCONCLUSIVE.","https:\u002F\u002Fgithub.com\u002Fmingster\u002Fdotfiles\u002Fblob\u002Fmain\u002Ftemplates\u002Fagent-team\u002F.agents\u002Fskills\u002Fverify-this\u002FSKILL.md",[],[189,190,191,192,178,193,194,195,196,197,198,199,200,201],"verify","verify this","fresh","verified","restate","it","compare","local","claim","evidence","capture","baseline","artifacts",{"skillNo":203,"name":204,"nameZh":6,"description":205,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":206,"categories":207,"keywords":208,"publishedAt":42},"01M70M84C3MN7ASJ0HBFAKT5Z6","typescript-best-practices","TypeScript best practices. Use when reading or editing any .ts or .tsx file.","https:\u002F\u002Fgithub.com\u002Fmingster\u002Fdotfiles\u002Fblob\u002Fmain\u002Ftemplates\u002Fagent-team\u002F.agents\u002Fskills\u002Ftypescript-best-practices\u002FSKILL.md",[],[209,210,211,212,213,137,214,215,216,132],"typescript best practices","best practices","typescript","reading","tsx","editing","file","true",{"skillNo":218,"name":219,"nameZh":6,"description":220,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":221,"categories":222,"keywords":226,"publishedAt":42},"01M70M81GYBZR9A093TAAP20ZG","thermo-nuclear-code-quality-review","Run an extremely strict maintainability review for abstraction quality, giant files, and spaghetti-condition growth. Use for a thermo-nuclear code quality review, thermonuclear review, deep code quality audit, or especially harsh maintainability review.","https:\u002F\u002Fgithub.com\u002Fmingster\u002Fdotfiles\u002Fblob\u002Fmain\u002Ftemplates\u002Fagent-team\u002F.agents\u002Fskills\u002Fthermo-nuclear-code-quality-review\u002FSKILL.md",[223],{"categoryNo":224,"categoryName":225,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000030","开发工程师",[227,228,229,230,171,231,232,233,234,235,236,216,237,238,239,240,137,241,242,243],"code quality review","nuclear","quality review","code quality","code","thermo nuclear code quality review","quality","condition","maintainability review","for","maintainability","deep","files","thermonuclear","growth","audit","run"]