[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6CCHM69AFVT0HB49BMW69G0":3,"skill-same:01M6CCHM69AFVT0HB49BMW69G0":63},{"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":27,"linkOnly":28,"markdownContent":29,"markdownBody":30,"frontMatter":31,"refName":34,"commitSha":35,"skillDirectory":36,"forksCount":37,"repositoryHtmlUrl":38,"repositoryHomepageUrl":39,"ownerHtmlUrl":40,"ownerBlogUrl":39,"ownerDescription":41,"updatedAt":42,"install":43,"resources":56},"01M6CCHM69AFVT0HB49BMW69G0","advisor",null,"Advisor mode. Consult a stronger (or different) model at key checkpoints: before major decisions, when stuck on an error, and before declaring a task done. Use when the user types \u002Fadvisor, asks to turn the advisor on or off, picks an advisor model, or explicitly asks for a second opinion from a stronger or different model. Never enable it on your own.","stigmer\u002Fstigmer","stigmer","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F255479904?v=4","01M6CCFBFXXRZC4ZVNS3JSDV4W","Stigmer","01M6CCFBKY7M8QGR4GH9TT35MY",9,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fstigmer\u002Fstigmer\u002Fblob\u002Fmain\u002Fplugins\u002Fadvisor\u002Fskills\u002Fadvisor\u002FSKILL.md",[],[5,19,20,21,22,23,24,25,26],"second opinion","consult","model","decisions","user","use","never","task done","2026-11-10 10:12:30",false,"---\nname: advisor\ndescription: >-\n  Advisor mode. Consult a stronger (or different) model at key checkpoints:\n  before major decisions, when stuck on an error, and before declaring a task\n  done. Use when the user types \u002Fadvisor, asks to turn the advisor on or off,\n  picks an advisor model, or explicitly asks for a second opinion from a\n  stronger or different model. Never enable it on your own.\nicon: lightbulb\ncolor: purple\n---\n\n# Advisor\n\nYou are the main model. Advisor mode adds a second, stronger model that you consult at a few key points. The advisor gets your briefing (and the full transcript when available), thinks hard, and returns a verdict with guidance. It does not edit files. You still do the work and make the final call.\n\nState lives in `.cursor\u002Fadvisor\u002Fstate.json` at the project root. When that file exists with `\"enabled\": true`, advisor mode is on for this project.\n\n## Commands\n\nThe text after `\u002Fadvisor` selects the action.\n\n| Input | Action |\n| --- | --- |\n| `\u002Fadvisor` | Enable for this conversation with the default advisor: the latest Grok at its highest reasoning effort. If a state file already exists, from this or another conversation, re-bind it here, keeping its `model` and `nudge` settings. |\n| `\u002Fadvisor \u003Cmodel>` | Same, with the given model. Any model available to subagents works: `\u002Fadvisor cursor-grok-4.6-xhigh-fast`, `\u002Fadvisor composer-2.5`. |\n| `\u002Fadvisor off` | Disable: delete `.cursor\u002Fadvisor\u002F`. |\n| `\u002Fadvisor status` | Report model, consult count, and whether the end-of-turn nudge is on. Changes nothing. |\n| `\u002Fadvisor ask \u003Cquestion>` | Consult now about the current work, regardless of checkpoint. |\n| `\u002Fadvisor nudge on` \u002F `off` | Toggle the end-of-turn reminder posted by the plugin's stop hook (default on). |\n\nIf the message also contains a task (`\u002Fadvisor, then refactor the cache layer`), enable first, then do the task under advisor mode.\n\n### Choosing the model\n\nThe default is the latest Grok model at its highest reasoning effort, currently `cursor-grok-4.6-xhigh`. If a newer Grok or a higher effort tier appears in the subagent model list available to you, prefer it and say so.\n\nFor `\u002Fadvisor \u003Cmodel>`, resolve the request against the subagent model slugs available to you:\n\n- An exact slug: use it as is.\n- A family or version name (`grok fast`, `composer`): that family's latest model at its highest reasoning tier.\n- No match: say so, name two or three close options, and keep the current model.\n\nIf the Task tool rejects a slug, read the valid slugs from its error message, pick the closest one (same family, highest reasoning tier), save it to `state.json`, and tell the user in one line. Do not block the consult on the slug.\n\n## Enabling\n\n1. Resolve the model as described above.\n2. Write `.cursor\u002Fadvisor\u002Fstate.json` with the file-writing tool (not a shell redirect), creating the directory if needed. If a state file already exists, carry over its `model` (unless this command names one) and `nudge`, and reset every other field to the values below. You cannot see which conversation an existing file belongs to, so always rewrite it: that re-binds the mode to this conversation, the hooks re-fill `conversation_id` and `transcript_path`, and the next consult starts a fresh advisor instead of resuming another chat's. Also delete `.cursor\u002Fadvisor\u002Fpending` and `.cursor\u002Fadvisor\u002Flast-response.txt` if they exist, so a marker left by another conversation cannot trigger the end-of-turn nudge here. Keep `log.md`.\n\n   ```json\n   {\n     \"enabled\": true,\n     \"model\": \"cursor-grok-4.6-xhigh\",\n     \"nudge\": true,\n     \"advisor_agent_id\": null,\n     \"conversation_id\": null,\n     \"transcript_path\": null,\n     \"consults\": 0,\n     \"last_consult_at\": null,\n     \"enabled_at\": \"\u003Ccurrent UTC time, ISO 8601>\"\n   }\n   ```\n\n   The plugin's hooks fill in `conversation_id`, `transcript_path`, `consults`, and `last_consult_at`. Leave them alone.\n3. Confirm in one line: `Advisor on: \u003Cslug>. I'll consult it before major decisions, when I'm stuck, and before I call the task done.` Then continue with any task in the same message.\n\nNever stage or commit `.cursor\u002Fadvisor\u002F`.\n\n## Checkpoints\n\nConsult at these points and nowhere else. Each consult is a strong-model call; the value comes from using it selectively.\n\n1. **Before a major decision.** Choosing between architectures or approaches; changes that are hard to reverse or have a wide blast radius (schema or data migrations, deleting or rewriting a module, public API or config format changes, dependency swaps, auth, payments, or other security-sensitive code); or a request that is ambiguous in a way that would change the work materially. Consult once you have a concrete plan and the options in hand, not before you understand the problem. One consult covers the plan; do not re-consult per file.\n2. **When stuck.** The same error or failing test after two genuine fix attempts; behavior you cannot explain from the code; or when you are about to reach for a workaround: a retry loop, a `sleep`, a broad `try\u002Fexcept`, skipping a test, or disabling a check to get past something.\n3. **Before declaring done.** Any task that changed logic or touched more than a couple of files: consult once before writing the final summary, and include what you verified and how. Skip for trivial edits (typos, comments, a one-line config change) and say so in one line.\n4. **On request.** `\u002Fadvisor ask ...`, or the user asks what the advisor thinks.\n\nDo not consult for routine steps, for things you can verify yourself (run the test, read the code), or more than once per checkpoint. If you would consult more than about four times in one task, the task should probably be split, or you should ask the user.\n\n## How to consult\n\n1. Read `.cursor\u002Fadvisor\u002Fstate.json` and decide which situation you are in:\n   - **Mode on here**: the file exists with `enabled: true` and you ran the Enabling steps in this conversation. Checkpoint consults and `\u002Fadvisor ask` both follow the steps below in full, including `resume` and state writes.\n   - **Not on here**: the file is missing, `enabled` is false, or you did not write it. A file you did not write belongs to another chat; only `\u002Fadvisor` re-binds it, so leave it alone and never `resume` an `advisor_agent_id` you did not save yourself. Do not consult at checkpoints. If the user explicitly asks for a consult in this message (`\u002Fadvisor ask ...`, or a request for a second opinion), run it as a one-off: a fresh spawn on the file's `model` if there is one, otherwise the default; no `resume`, no state writes, and no `transcript_path` (another chat's transcript is not yours to share; write \"not available\"). Mention that `\u002Fadvisor` turns the mode on for this conversation.\n2. Build the briefing from `references\u002Fbriefing-template.md`. Give the advisor everything it needs to disagree with you:\n   - The user's request verbatim, plus constraints or corrections they added later.\n   - What has happened so far, in order: what you investigated, decided, changed, tried, and ruled out.\n   - Relevant tool results verbatim: error messages, stack traces, test output, diffs. Trim unrelated noise and mark trims with `[...]`, but never paraphrase evidence.\n   - Current state: `git status --short`, `git diff --stat`, files you touched, anything half-done.\n   - Your specific questions, the options you see, and your current leaning with reasons.\n   - The `transcript_path` from `state.json` when set and the mode is on in this conversation, so the advisor can read the full conversation itself.\n   - No secrets. Redact tokens, keys, and `.env` values.\n3. Spawn the advisor in the foreground and wait for it:\n   - `subagent_type: \"advisor-subagent\"`\n   - `model: \u003Cstate.model>`\n   - `description: \"Advisor: \u003Ccheckpoint>\"`, for example `Advisor: pre-completion review`\n   - `run_in_background: false`\n   - When `state.advisor_agent_id` is set, pass it as `resume` and omit `model`; the advisor keeps its model and the context of earlier consults, so the briefing can be a delta: what changed since last time plus the new questions. If the resume fails, spawn fresh.\n   - Save the returned agent id to `advisor_agent_id` in `state.json`. Clear it when the model changes.\n4. Act on the verdict:\n   - `proceed`: go.\n   - `proceed with changes`: make the recommended changes unless they conflict with the user's instructions or facts you have verified. Say which you skipped and why.\n   - `stop`: do not continue with the plan. Rethink, or bring the disagreement to the user if it is a product or scope question.\n   - If the advisor asks for something it needs, provide it via `resume`, once. Do not ping-pong.\n   - You are accountable for the result. The advisor is a strong second opinion, not an authority. If it is wrong about the codebase, show it the evidence once, or overrule it and tell the user why.\n5. Report each consult to the user in one or two lines: `Advisor (\u003Cmodel>): \u003Cverdict>. \u003COne-line summary>. \u003CWhat you did about it.>` Keep the advisor's full response out of the chat unless the user asks; the hooks also append it to `.cursor\u002Fadvisor\u002Flog.md`.\n\n## End-of-turn nudge\n\nWhen files changed since the last consult and a turn ends without one, the plugin's `stop` hook posts a follow-up that starts with `[Advisor]`. Treat it as the \"before declaring done\" checkpoint: run the pre-completion consult, or answer in one line that the change was trivial, or that you are waiting on the user, and stop. It fires at most once per batch of edits. `\u002Fadvisor nudge off` disables it.\n\n## Disabling\n\n`\u002Fadvisor off`: delete `.cursor\u002Fadvisor\u002F` and confirm in one line. Do not consult again in this conversation unless the user re-enables the mode or explicitly asks for a one-off consult.\n\n## Guardrails\n\n- Never enable advisor mode unasked. \"Get a second opinion on this\" is a one-off consult, not a mode change.\n- The advisor is read-only. Never ask it to edit files or do the task.\n- Never loop on the advisor: at most one follow-up per checkpoint.\n- If the `advisor-subagent` subagent is unavailable (no Task tool, or a hook denies it), tell the user once and continue without it.\n- To keep this skill in context for a whole session rather than one message, the user can invoke `\u002Fadvisor` as a Custom Mode (Option+Enter \u002F Alt+Enter). The state file works either way.\n","# Advisor\n\nYou are the main model. Advisor mode adds a second, stronger model that you consult at a few key points. The advisor gets your briefing (and the full transcript when available), thinks hard, and returns a verdict with guidance. It does not edit files. You still do the work and make the final call.\n\nState lives in `.cursor\u002Fadvisor\u002Fstate.json` at the project root. When that file exists with `\"enabled\": true`, advisor mode is on for this project.\n\n## Commands\n\nThe text after `\u002Fadvisor` selects the action.\n\n| Input | Action |\n| --- | --- |\n| `\u002Fadvisor` | Enable for this conversation with the default advisor: the latest Grok at its highest reasoning effort. If a state file already exists, from this or another conversation, re-bind it here, keeping its `model` and `nudge` settings. |\n| `\u002Fadvisor \u003Cmodel>` | Same, with the given model. Any model available to subagents works: `\u002Fadvisor cursor-grok-4.6-xhigh-fast`, `\u002Fadvisor composer-2.5`. |\n| `\u002Fadvisor off` | Disable: delete `.cursor\u002Fadvisor\u002F`. |\n| `\u002Fadvisor status` | Report model, consult count, and whether the end-of-turn nudge is on. Changes nothing. |\n| `\u002Fadvisor ask \u003Cquestion>` | Consult now about the current work, regardless of checkpoint. |\n| `\u002Fadvisor nudge on` \u002F `off` | Toggle the end-of-turn reminder posted by the plugin's stop hook (default on). |\n\nIf the message also contains a task (`\u002Fadvisor, then refactor the cache layer`), enable first, then do the task under advisor mode.\n\n### Choosing the model\n\nThe default is the latest Grok model at its highest reasoning effort, currently `cursor-grok-4.6-xhigh`. If a newer Grok or a higher effort tier appears in the subagent model list available to you, prefer it and say so.\n\nFor `\u002Fadvisor \u003Cmodel>`, resolve the request against the subagent model slugs available to you:\n\n- An exact slug: use it as is.\n- A family or version name (`grok fast`, `composer`): that family's latest model at its highest reasoning tier.\n- No match: say so, name two or three close options, and keep the current model.\n\nIf the Task tool rejects a slug, read the valid slugs from its error message, pick the closest one (same family, highest reasoning tier), save it to `state.json`, and tell the user in one line. Do not block the consult on the slug.\n\n## Enabling\n\n1. Resolve the model as described above.\n2. Write `.cursor\u002Fadvisor\u002Fstate.json` with the file-writing tool (not a shell redirect), creating the directory if needed. If a state file already exists, carry over its `model` (unless this command names one) and `nudge`, and reset every other field to the values below. You cannot see which conversation an existing file belongs to, so always rewrite it: that re-binds the mode to this conversation, the hooks re-fill `conversation_id` and `transcript_path`, and the next consult starts a fresh advisor instead of resuming another chat's. Also delete `.cursor\u002Fadvisor\u002Fpending` and `.cursor\u002Fadvisor\u002Flast-response.txt` if they exist, so a marker left by another conversation cannot trigger the end-of-turn nudge here. Keep `log.md`.\n\n   ```json\n   {\n     \"enabled\": true,\n     \"model\": \"cursor-grok-4.6-xhigh\",\n     \"nudge\": true,\n     \"advisor_agent_id\": null,\n     \"conversation_id\": null,\n     \"transcript_path\": null,\n     \"consults\": 0,\n     \"last_consult_at\": null,\n     \"enabled_at\": \"\u003Ccurrent UTC time, ISO 8601>\"\n   }\n   ```\n\n   The plugin's hooks fill in `conversation_id`, `transcript_path`, `consults`, and `last_consult_at`. Leave them alone.\n3. Confirm in one line: `Advisor on: \u003Cslug>. I'll consult it before major decisions, when I'm stuck, and before I call the task done.` Then continue with any task in the same message.\n\nNever stage or commit `.cursor\u002Fadvisor\u002F`.\n\n## Checkpoints\n\nConsult at these points and nowhere else. Each consult is a strong-model call; the value comes from using it selectively.\n\n1. **Before a major decision.** Choosing between architectures or approaches; changes that are hard to reverse or have a wide blast radius (schema or data migrations, deleting or rewriting a module, public API or config format changes, dependency swaps, auth, payments, or other security-sensitive code); or a request that is ambiguous in a way that would change the work materially. Consult once you have a concrete plan and the options in hand, not before you understand the problem. One consult covers the plan; do not re-consult per file.\n2. **When stuck.** The same error or failing test after two genuine fix attempts; behavior you cannot explain from the code; or when you are about to reach for a workaround: a retry loop, a `sleep`, a broad `try\u002Fexcept`, skipping a test, or disabling a check to get past something.\n3. **Before declaring done.** Any task that changed logic or touched more than a couple of files: consult once before writing the final summary, and include what you verified and how. Skip for trivial edits (typos, comments, a one-line config change) and say so in one line.\n4. **On request.** `\u002Fadvisor ask ...`, or the user asks what the advisor thinks.\n\nDo not consult for routine steps, for things you can verify yourself (run the test, read the code), or more than once per checkpoint. If you would consult more than about four times in one task, the task should probably be split, or you should ask the user.\n\n## How to consult\n\n1. Read `.cursor\u002Fadvisor\u002Fstate.json` and decide which situation you are in:\n   - **Mode on here**: the file exists with `enabled: true` and you ran the Enabling steps in this conversation. Checkpoint consults and `\u002Fadvisor ask` both follow the steps below in full, including `resume` and state writes.\n   - **Not on here**: the file is missing, `enabled` is false, or you did not write it. A file you did not write belongs to another chat; only `\u002Fadvisor` re-binds it, so leave it alone and never `resume` an `advisor_agent_id` you did not save yourself. Do not consult at checkpoints. If the user explicitly asks for a consult in this message (`\u002Fadvisor ask ...`, or a request for a second opinion), run it as a one-off: a fresh spawn on the file's `model` if there is one, otherwise the default; no `resume`, no state writes, and no `transcript_path` (another chat's transcript is not yours to share; write \"not available\"). Mention that `\u002Fadvisor` turns the mode on for this conversation.\n2. Build the briefing from `references\u002Fbriefing-template.md`. Give the advisor everything it needs to disagree with you:\n   - The user's request verbatim, plus constraints or corrections they added later.\n   - What has happened so far, in order: what you investigated, decided, changed, tried, and ruled out.\n   - Relevant tool results verbatim: error messages, stack traces, test output, diffs. Trim unrelated noise and mark trims with `[...]`, but never paraphrase evidence.\n   - Current state: `git status --short`, `git diff --stat`, files you touched, anything half-done.\n   - Your specific questions, the options you see, and your current leaning with reasons.\n   - The `transcript_path` from `state.json` when set and the mode is on in this conversation, so the advisor can read the full conversation itself.\n   - No secrets. Redact tokens, keys, and `.env` values.\n3. Spawn the advisor in the foreground and wait for it:\n   - `subagent_type: \"advisor-subagent\"`\n   - `model: \u003Cstate.model>`\n   - `description: \"Advisor: \u003Ccheckpoint>\"`, for example `Advisor: pre-completion review`\n   - `run_in_background: false`\n   - When `state.advisor_agent_id` is set, pass it as `resume` and omit `model`; the advisor keeps its model and the context of earlier consults, so the briefing can be a delta: what changed since last time plus the new questions. If the resume fails, spawn fresh.\n   - Save the returned agent id to `advisor_agent_id` in `state.json`. Clear it when the model changes.\n4. Act on the verdict:\n   - `proceed`: go.\n   - `proceed with changes`: make the recommended changes unless they conflict with the user's instructions or facts you have verified. Say which you skipped and why.\n   - `stop`: do not continue with the plan. Rethink, or bring the disagreement to the user if it is a product or scope question.\n   - If the advisor asks for something it needs, provide it via `resume`, once. Do not ping-pong.\n   - You are accountable for the result. The advisor is a strong second opinion, not an authority. If it is wrong about the codebase, show it the evidence once, or overrule it and tell the user why.\n5. Report each consult to the user in one or two lines: `Advisor (\u003Cmodel>): \u003Cverdict>. \u003COne-line summary>. \u003CWhat you did about it.>` Keep the advisor's full response out of the chat unless the user asks; the hooks also append it to `.cursor\u002Fadvisor\u002Flog.md`.\n\n## End-of-turn nudge\n\nWhen files changed since the last consult and a turn ends without one, the plugin's `stop` hook posts a follow-up that starts with `[Advisor]`. Treat it as the \"before declaring done\" checkpoint: run the pre-completion consult, or answer in one line that the change was trivial, or that you are waiting on the user, and stop. It fires at most once per batch of edits. `\u002Fadvisor nudge off` disables it.\n\n## Disabling\n\n`\u002Fadvisor off`: delete `.cursor\u002Fadvisor\u002F` and confirm in one line. Do not consult again in this conversation unless the user re-enables the mode or explicitly asks for a one-off consult.\n\n## Guardrails\n\n- Never enable advisor mode unasked. \"Get a second opinion on this\" is a one-off consult, not a mode change.\n- The advisor is read-only. Never ask it to edit files or do the task.\n- Never loop on the advisor: at most one follow-up per checkpoint.\n- If the `advisor-subagent` subagent is unavailable (no Task tool, or a hook denies it), tell the user once and continue without it.\n- To keep this skill in context for a whole session rather than one message, the user can invoke `\u002Fadvisor` as a Custom Mode (Option+Enter \u002F Alt+Enter). The state file works either way.\n",{"icon":32,"name":5,"color":33,"description":7},"lightbulb","purple","main","49002d2ddc1f123a8d1148f6c6d73d7b385bb0b1","plugins\u002Fadvisor\u002Fskills\u002Fadvisor",6,"https:\u002F\u002Fgithub.com\u002Fstigmer\u002Fstigmer","https:\u002F\u002Fstigmer.ai","https:\u002F\u002Fgithub.com\u002Fstigmer","The open-source backend for the agents in your product.","2026-11-14 02:41:36",{"source":8,"skillName":5,"commands":44,"prompt":54,"zipAvailable":55},[45,48,51],{"tool":46,"command":47},"npx","npx skills add stigmer\u002Fstigmer --skill advisor",{"tool":49,"command":50},"bunx","bunx skills add stigmer\u002Fstigmer --skill advisor",{"tool":52,"command":53},"pnpm","pnpm dlx skills add stigmer\u002Fstigmer --skill advisor","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fstigmer\u002Fstigmer\u002Fblob\u002Fmain\u002Fplugins\u002Fadvisor\u002Fskills\u002Fadvisor\u002FSKILL.md",true,[57],{"path":58,"resourceType":59,"resourceTypeDesc":60,"sizeBytes":61,"sourceHtmlUrl":62},"references\u002Fbriefing-template.md","REFERENCE","参考文档",1552,"https:\u002F\u002Fgithub.com\u002Fstigmer\u002Fstigmer\u002Fblob\u002Fmain\u002Fplugins\u002Fadvisor\u002Fskills\u002Fadvisor\u002Freferences\u002Fbriefing-template.md",[64,93,113,131,145,161],{"skillNo":65,"name":66,"nameZh":6,"description":67,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":68,"categories":69,"keywords":83,"publishedAt":27},"01M6CCSERKR4YRSZJ2TB6B0X60","writing-hookify-rules","This skill should be used when the user asks to \"create a hookify rule\", \"write a hook rule\", \"configure hookify\", \"add a hookify rule\", or needs guidance on hookify rule syntax and patterns.","https:\u002F\u002Fgithub.com\u002Fstigmer\u002Fstigmer\u002Fblob\u002Fmain\u002Ftest\u002Fsupport\u002Ffixtures\u002Fclaude-plugins\u002Fhookify\u002Fskills\u002Fwriting-rules\u002FSKILL.md",[70,75,78],{"categoryNo":71,"categoryName":72,"taxonomyType":73,"taxonomyTypeDesc":74},"01JBSEEDCAT000000000000018","写作与文案","SCENARIO","使用场景",{"categoryNo":76,"categoryName":77,"taxonomyType":73,"taxonomyTypeDesc":74},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":79,"categoryName":80,"taxonomyType":81,"taxonomyTypeDesc":82},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",[84,85,86,87,88,89,23,90,91,92],"writing","Writing Hookify Rules","Rules","hookify rules","create","guidance","write","configure","syntax",{"skillNo":94,"name":95,"nameZh":6,"description":96,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":97,"categories":98,"keywords":105,"publishedAt":27},"01M6CCSC63RKCGC2S1EZDEMXZE","sql-migrations","Write safe database schema migrations - reversible steps, online index builds, and backfills in batches.","https:\u002F\u002Fgithub.com\u002Fstigmer\u002Fstigmer\u002Fblob\u002Fmain\u002Ftest\u002Fconformance\u002Ffixtures\u002Fworking-agent\u002Fskills\u002Fsql-migrations\u002FSKILL.md",[99,102],{"categoryNo":100,"categoryName":101,"taxonomyType":73,"taxonomyTypeDesc":74},"01JBSEEDCAT000000000000010","后端与接口",{"categoryNo":103,"categoryName":104,"taxonomyType":81,"taxonomyTypeDesc":82},"01JBSEEDCAT000000000000033","数据分析师",[106,107,108,109,90,110,111,112],"sql","sql migrations","migrations","schema","index","database","safe",{"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":119,"publishedAt":27},"01M6CCS9Q8E0R3TYHPZHCPN0JZ","repo-conventions","How to change Go code in this repository - error wrapping, table-driven tests, doc comments, no new dependencies, and running go test before finishing.","https:\u002F\u002Fgithub.com\u002Fstigmer\u002Fstigmer\u002Fblob\u002Fmain\u002Ftest\u002Fconformance\u002Ffixtures\u002Fworking-agent\u002Fskills\u002Frepo-conventions\u002FSKILL.md",[],[120,121,122,123,124,125,126,127,128,129,130],"repo","repo conventions","table","go","test","change","doc comments","code","repository","doc","how",{"skillNo":132,"name":133,"nameZh":6,"description":134,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":135,"categories":136,"keywords":137,"publishedAt":27},"01M6CCS7F2D1YZ9H3N63XTEV09","incident-postmortem","Write a blameless incident postmortem - timeline, impact, root cause, contributing factors and follow-up actions with owners.","https:\u002F\u002Fgithub.com\u002Fstigmer\u002Fstigmer\u002Fblob\u002Fmain\u002Ftest\u002Fconformance\u002Ffixtures\u002Fworking-agent\u002Fskills\u002Fincident-postmortem\u002FSKILL.md",[],[138,139,90,140,141,142,143,144],"incident postmortem","postmortem","contributing","actions","timeline","owners","up",{"skillNo":146,"name":147,"nameZh":6,"description":148,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":149,"categories":150,"keywords":155,"publishedAt":27},"01M6CCS4W1D2K257KHC40HS8JG","data-analysis","Summarise a data export or table - lead with the key finding and give every number its baseline or comparison.","https:\u002F\u002Fgithub.com\u002Fstigmer\u002Fstigmer\u002Fblob\u002Fmain\u002Ftest\u002Fconformance\u002Ffixtures\u002Fworking-agent\u002Fskills\u002Fdata-analysis\u002FSKILL.md",[151,154],{"categoryNo":152,"categoryName":153,"taxonomyType":73,"taxonomyTypeDesc":74},"01JBSEEDCAT000000000000013","分析与可视化",{"categoryNo":103,"categoryName":104,"taxonomyType":81,"taxonomyTypeDesc":82},[156,157,158,159,122,160],"analysis","data analysis","data","baseline","export",{"skillNo":162,"name":163,"nameZh":6,"description":164,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":165,"categories":166,"keywords":167,"publishedAt":27},"01M6CCS2MNQYK9S24AYHJAVPWF","customer-support","Answer customer questions about orders, returns and refunds from the written policies and the order system, ending with a clear next step.","https:\u002F\u002Fgithub.com\u002Fstigmer\u002Fstigmer\u002Fblob\u002Fmain\u002Ftest\u002Fconformance\u002Ffixtures\u002Fworking-agent\u002Fskills\u002Fcustomer-support\u002FSKILL.md",[],[168,169,170,171,172,173],"support","customer","customer support","system","refunds","returns"]