[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6C1RF9DYX7WVRQD6JK3F2BX":3,"skill-same:01M6C1RF9DYX7WVRQD6JK3F2BX":129},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":22,"publishedAt":43,"linkOnly":44,"markdownContent":45,"markdownBody":46,"frontMatter":47,"refName":61,"commitSha":62,"skillDirectory":63,"forksCount":13,"repositoryHtmlUrl":64,"repositoryHomepageUrl":6,"ownerHtmlUrl":65,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":66,"install":67,"resources":80},"01M6C1RF9DYX7WVRQD6JK3F2BX","slo-architect",null,"Use when defining, reviewing, or operating SLOs\u002FSLIs\u002Ferror budgets. Triggers on \"define an SLO\", \"what should our SLO be\", \"error budget\", \"burn rate\", \"SLI\", \"service level objective\", \"Google SRE workbook\", \"multi-window burn-rate alert\", or any reliability-target question. Ships SLO designer, error-budget calculator with multi-window burn-rate thresholds, and SLO reviewer that catches the common bugs (target too aggressive, window too short, conflicting SLOs, no SLI definition). 4 references on SLO principles + SLI design + error budget math + composition with feature-flags-architect\u002Fchaos-engineering\u002Fkubernetes-operator. NOT a generic observability skill — specifically the SLO discipline.","mne20114-hash\u002Fgest35bi","mne20114-hash","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F224168109?v=4","01M6C0JCR7334CZ39YWTZXX2NG","01M6C0JCWN0NBWMQTW1CPG2Z4G",0,"MIT","https:\u002F\u002Fgithub.com\u002Fmne20114-hash\u002Fgest35bi\u002Fblob\u002Fmain\u002Fclaude-skills\u002Fengineering\u002Fskills\u002Fslo-architect\u002FSKILL.md",[17],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000040","财务","PROFESSION","适用职业",[23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42],"architect","slo architect","google-sre-workbook","design","burn-rate","error-budget","sli","slo","feature-flags","reliability","sre","chaos-engineering","question","short","math","reviewer","common","Composition","code","cli","2026-11-10 10:12:30",false,"---\nname: slo-architect\ndescription: Use when defining, reviewing, or operating SLOs\u002FSLIs\u002Ferror budgets. Triggers on \"define an SLO\", \"what should our SLO be\", \"error budget\", \"burn rate\", \"SLI\", \"service level objective\", \"Google SRE workbook\", \"multi-window burn-rate alert\", or any reliability-target question. Ships SLO designer, error-budget calculator with multi-window burn-rate thresholds, and SLO reviewer that catches the common bugs (target too aggressive, window too short, conflicting SLOs, no SLI definition). 4 references on SLO principles + SLI design + error budget math + composition with feature-flags-architect\u002Fchaos-engineering\u002Fkubernetes-operator. NOT a generic observability skill — specifically the SLO discipline.\ncontext: fork\nversion: 2.9.0\nauthor: claude-code-skills\nlicense: MIT\ntags: [slo, sli, sla, error-budget, burn-rate, sre, reliability, google-sre-workbook, observability]\ncompatible_tools: [claude-code, codex-cli, cursor, antigravity, opencode, gemini-cli]\n---\n\n# SLO Architect\n\nDefine SLOs that mean something. Most \"SLOs\" in the wild are arbitrary numbers no one believes — 99.9% on every endpoint, no SLI definition, no error budget, no policy for what happens when budget burns. This skill enforces the discipline from Google's SRE Workbook: pick the right SLI, set a target users actually care about, calculate the error budget, wire multi-window burn-rate alerts, and have a written policy for when budget runs out.\n\n## When to use\n\n- Defining a new SLO for a service or feature\n- Reviewing existing SLOs for common bugs\n- Picking the right SLI (event-based vs time-window based vs request-based)\n- Computing error budgets and burn-rate alert thresholds\n- Tying SLOs to existing controls — feature flags abort, chaos blast radius, operator capability levels\n\n## When NOT to use\n\n- General observability strategy (metrics + logs + traces) → use `observability-designer`\n- Customer-facing SLAs with legal teeth → that's contract drafting, not engineering\n- Performance load testing (capacity, not reliability) → use `performance-profiler`\n- Active incident response → use `incident-response`\n\n## Core principle: an SLO is a promise about user experience\n\n```\nSLI  ⟶  measurable signal of user-perceived health (e.g., HTTP 2xx rate)\nSLO  ⟶  target for the SLI over a window (e.g., 99.9% over 30 days)\nSLA  ⟶  customer-facing commitment with consequences (separate concern)\nEB   ⟶  error budget: 100% − SLO target = how much \"bad\" you can spend\nBR   ⟶  burn rate: how fast you're consuming the error budget\n```\n\nThe four cardinal mistakes:\n\n1. **Target too high** (99.99%+ on services that can't support it) — every minor blip violates SLO; alerts become noise.\n2. **Wrong SLI** (CPU usage as proxy for user experience) — system can be \"green\" while users suffer.\n3. **No error budget policy** — burning budget means nothing if there's no agreed action.\n4. **Single-window burn-rate alert** — either too noisy (page on a 5-min spike) or too slow (notice budget exhausted after the fact).\n\nThe 3 tools below catch each of these.\n\n## Quick start\n\n```bash\nSKILL=engineering\u002Fslo-architect\u002Fskills\u002Fslo-architect\n\n# 1. Design an SLO\npython \"$SKILL\u002Fscripts\u002Fslo_designer.py\" \\\n  --service checkout-svc \\\n  --sli-type request-success-rate \\\n  --target 99.9 \\\n  --window-days 30\n\n# 2. Compute error budget + multi-window burn-rate alerts\npython \"$SKILL\u002Fscripts\u002Ferror_budget_calculator.py\" \\\n  --target 99.9 --window-days 30\n\n# 3. Review existing SLO definitions for common bugs\npython \"$SKILL\u002Fscripts\u002Fslo_review.py\" --slo-doc docs\u002Fslos\u002F\n```\n\n## The 3 Python tools\n\nAll stdlib-only.\n\n### `slo_designer.py`\n\nGenerates a structured SLO definition with required fields. Refuses to render if any required field is missing (`exit 1`).\n\n```bash\npython scripts\u002Fslo_designer.py \\\n  --service checkout-svc \\\n  --sli-type request-success-rate \\\n  --target 99.9 \\\n  --window-days 30 \\\n  --owner team-checkout\n```\n\n**SLI types supported:**\n- `request-success-rate` — `(total_requests - bad_requests) \u002F total_requests`\n- `request-latency` — `count(requests \u003C threshold) \u002F total_requests`\n- `availability-time` — `(window - downtime) \u002F window`\n- `data-freshness` — `count(data_age \u003C threshold) \u002F total_data_points`\n- `correctness` — `count(correct_outputs) \u002F total_outputs`\n\nOutput is markdown by default with all required fields filled or marked `\u003Cmust define>`. JSON output (`--format json`) is consumed by `slo_review.py`.\n\n### `error_budget_calculator.py`\n\nGiven target availability + window, computes:\n- Allowed downtime in the window\n- Multi-window burn-rate thresholds per Google SRE Workbook (Chapter 5):\n  - **Fast burn** — page if 2% of monthly budget consumed in 1 hour\n  - **Slow burn** — page if 10% consumed in 6 hours, ticket if 10% in 3 days\n- Recommended alerting rules (PromQL-shaped output)\n\n```bash\npython scripts\u002Ferror_budget_calculator.py --target 99.9 --window-days 30\npython scripts\u002Ferror_budget_calculator.py --target 99.95 --window-days 7 --format json\n```\n\n### `slo_review.py`\n\nAudits a directory of SLO definitions (markdown or JSON) for the common bugs.\n\n```bash\npython scripts\u002Fslo_review.py --slo-doc docs\u002Fslos\u002F\n```\n\n**Checks:**\n- `target_too_high`: target ≥ 99.99% (sustainable only with massive engineering investment)\n- `target_too_low`: target ≤ 99.0% (probably wrong SLI; users will notice)\n- `window_too_short`: window \u003C 7 days (statistical noise dominates)\n- `window_too_long`: window > 90 days (slow feedback)\n- `no_sli_definition`: SLI section missing or vague (\"everything OK\")\n- `no_error_budget_policy`: no documented action when budget burns\n- `cpu_as_sli`: CPU\u002Fmemory used as user-experience proxy (wrong signal)\n\n## SLI selection cheatsheet\n\n| User experience | SLI type | What you measure |\n|---|---|---|\n| \"Did the request succeed?\" | request-success-rate | `2xx \u002F total` |\n| \"Was the response fast?\" | request-latency | `count(p99 \u003C threshold) \u002F total` |\n| \"Was the service up?\" | availability-time | `(window - downtime) \u002F window` |\n| \"Is the data current?\" | data-freshness | `count(data_age \u003C threshold) \u002F total` |\n| \"Was the answer correct?\" | correctness | `count(correct) \u002F total` |\n\nSee `references\u002Fsli_design.md` for examples and anti-patterns.\n\n## Error budget math (the basics)\n\nFor 99.9% SLO over 30 days:\n- Allowed unavailability: `0.1% × 30 × 24 × 60 = 43.2 minutes`\n- 1-hour fast-burn threshold (2% of monthly budget burned): `2% × 43.2 \u002F 60 ≈ 1.44 ratio multiplier`\n- 6-hour slow-burn threshold (10% in 6h): `10% × 43.2 \u002F 360 ≈ 0.6 ratio multiplier`\n\n`error_budget_calculator.py` does this math for you and emits ready-to-paste alert rules.\n\n## Composition with the rest of the portfolio\n\nThis skill explicitly composes with three others:\n\n| Skill | Composition |\n|---|---|\n| `feature-flags-architect` | Rollout abort criteria reference SLO burn-rate thresholds |\n| `chaos-engineering` | Blast-radius calculator already takes monthly error budget as input — define it here |\n| `kubernetes-operator` | Operator capability L4 (Deep Insights) requires SLOs + Prometheus rules |\n\nThe `error_budget_calculator.py` output is in the same shape `engineering\u002Fskills\u002Fchaos-engineering\u002Fscripts\u002Fblast_radius_calculator.py` expects on stdin.\n\n## Workflows\n\n### Workflow 1: Define a new SLO\n\n```\n1. Pick the user journey to protect (e.g., \"checkout completion\").\n2. Choose SLI type (request-success-rate, latency, availability, freshness, correctness).\n3. Define the SLI precisely: numerator\u002Fdenominator with concrete labels.\n4. Pick a target by measuring 30 days of historical SLI value:\n     target = floor(p50 of last 30 days × 100) \u002F 100\n   This avoids targets the system has never sustained.\n5. Pick a window (28 days = 4 calendar weeks, recommended).\n6. Run slo_designer.py to render the SLO definition.\n7. Run error_budget_calculator.py to get burn-rate alerts.\n8. Write the error budget policy (what happens when budget burns).\n9. Run slo_review.py — must pass before the SLO is \"live\".\n```\n\n### Workflow 2: Quarterly SLO review\n\n```\n1. For every active SLO, run slo_review.py — fix any FAIL findings.\n2. Look at last quarter's data:\n   - Was the SLO too easy (never burned budget)? Tighten target.\n   - Was it too hard (frequently burned)? Loosen target OR fix the system.\n   - Did burn-rate alerts fire usefully (not too noisy, not too late)? Adjust thresholds.\n3. Audit error budget policies — were they actually followed when budget burned?\n4. Commit revised SLOs; archive old versions with date stamps.\n```\n\n### Workflow 3: SLO-driven rollback\n\n```\n1. New deploy starts burning error budget faster than baseline.\n2. Burn-rate alert fires (from error_budget_calculator.py thresholds).\n3. Auto-rollback via feature flag (kill switch from feature-flags-architect).\n4. Postmortem feeds into next SLO revision.\n```\n\n## References\n\n- `references\u002Fslo_principles.md` — SLI vs SLO vs SLA, Google SRE Workbook canon\n- `references\u002Fsli_design.md` — picking the right SLI; 5 types with examples\n- `references\u002Ferror_budget.md` — error budget math, burn-rate alerts, budget policy\n- `references\u002Fcomposition.md` — how SLOs feed feature flags, chaos, operators\n\n## Slash command\n\n`\u002Fslo-design` — interactive SLO design wizard that runs all 3 tools.\n\n## Asset templates\n\n- `assets\u002Fslo_template.yaml` — fillable SLO YAML\n- `assets\u002Ferror_budget_policy.md` — fillable policy template\n\n## Anti-patterns\n\n- **99.99% on every endpoint** — copy-paste SLOs that nobody verified the system can sustain\n- **CPU usage as SLI** — system metrics aren't user experience\n- **Single-window burn-rate alert** — too noisy if 5-min, too slow if 30-day\n- **No error budget policy** — burning budget means nothing without an action\n- **SLOs without owners** — no one is responsible; they bit-rot\n- **SLOs reviewed once a year** — system characteristics change faster than that\n- **SLAs in the SLO doc** — different audience, different stakes; keep them separate\n- **SLO target = SLA target** — SLO must be tighter (you should beat your contract before customers notice)\n\n## Verifiable success\n\nA team using this skill should achieve:\n\n- 100% of SLOs pass `slo_review.py` with 0 FAIL findings\n- Every SLO has a documented owner, error budget, burn-rate alerts, and policy\n- Burn-rate alerts fire ≤2 times\u002Fmonth per SLO that's hit (signal, not noise)\n- Mean time to detect SLO violation: \u003C30 min (multi-window burn-rate alerts working)\n- Quarterly SLO review happens every quarter (not annually)\n","# SLO Architect\n\nDefine SLOs that mean something. Most \"SLOs\" in the wild are arbitrary numbers no one believes — 99.9% on every endpoint, no SLI definition, no error budget, no policy for what happens when budget burns. This skill enforces the discipline from Google's SRE Workbook: pick the right SLI, set a target users actually care about, calculate the error budget, wire multi-window burn-rate alerts, and have a written policy for when budget runs out.\n\n## When to use\n\n- Defining a new SLO for a service or feature\n- Reviewing existing SLOs for common bugs\n- Picking the right SLI (event-based vs time-window based vs request-based)\n- Computing error budgets and burn-rate alert thresholds\n- Tying SLOs to existing controls — feature flags abort, chaos blast radius, operator capability levels\n\n## When NOT to use\n\n- General observability strategy (metrics + logs + traces) → use `observability-designer`\n- Customer-facing SLAs with legal teeth → that's contract drafting, not engineering\n- Performance load testing (capacity, not reliability) → use `performance-profiler`\n- Active incident response → use `incident-response`\n\n## Core principle: an SLO is a promise about user experience\n\n```\nSLI  ⟶  measurable signal of user-perceived health (e.g., HTTP 2xx rate)\nSLO  ⟶  target for the SLI over a window (e.g., 99.9% over 30 days)\nSLA  ⟶  customer-facing commitment with consequences (separate concern)\nEB   ⟶  error budget: 100% − SLO target = how much \"bad\" you can spend\nBR   ⟶  burn rate: how fast you're consuming the error budget\n```\n\nThe four cardinal mistakes:\n\n1. **Target too high** (99.99%+ on services that can't support it) — every minor blip violates SLO; alerts become noise.\n2. **Wrong SLI** (CPU usage as proxy for user experience) — system can be \"green\" while users suffer.\n3. **No error budget policy** — burning budget means nothing if there's no agreed action.\n4. **Single-window burn-rate alert** — either too noisy (page on a 5-min spike) or too slow (notice budget exhausted after the fact).\n\nThe 3 tools below catch each of these.\n\n## Quick start\n\n```bash\nSKILL=engineering\u002Fslo-architect\u002Fskills\u002Fslo-architect\n\n# 1. Design an SLO\npython \"$SKILL\u002Fscripts\u002Fslo_designer.py\" \\\n  --service checkout-svc \\\n  --sli-type request-success-rate \\\n  --target 99.9 \\\n  --window-days 30\n\n# 2. Compute error budget + multi-window burn-rate alerts\npython \"$SKILL\u002Fscripts\u002Ferror_budget_calculator.py\" \\\n  --target 99.9 --window-days 30\n\n# 3. Review existing SLO definitions for common bugs\npython \"$SKILL\u002Fscripts\u002Fslo_review.py\" --slo-doc docs\u002Fslos\u002F\n```\n\n## The 3 Python tools\n\nAll stdlib-only.\n\n### `slo_designer.py`\n\nGenerates a structured SLO definition with required fields. Refuses to render if any required field is missing (`exit 1`).\n\n```bash\npython scripts\u002Fslo_designer.py \\\n  --service checkout-svc \\\n  --sli-type request-success-rate \\\n  --target 99.9 \\\n  --window-days 30 \\\n  --owner team-checkout\n```\n\n**SLI types supported:**\n- `request-success-rate` — `(total_requests - bad_requests) \u002F total_requests`\n- `request-latency` — `count(requests \u003C threshold) \u002F total_requests`\n- `availability-time` — `(window - downtime) \u002F window`\n- `data-freshness` — `count(data_age \u003C threshold) \u002F total_data_points`\n- `correctness` — `count(correct_outputs) \u002F total_outputs`\n\nOutput is markdown by default with all required fields filled or marked `\u003Cmust define>`. JSON output (`--format json`) is consumed by `slo_review.py`.\n\n### `error_budget_calculator.py`\n\nGiven target availability + window, computes:\n- Allowed downtime in the window\n- Multi-window burn-rate thresholds per Google SRE Workbook (Chapter 5):\n  - **Fast burn** — page if 2% of monthly budget consumed in 1 hour\n  - **Slow burn** — page if 10% consumed in 6 hours, ticket if 10% in 3 days\n- Recommended alerting rules (PromQL-shaped output)\n\n```bash\npython scripts\u002Ferror_budget_calculator.py --target 99.9 --window-days 30\npython scripts\u002Ferror_budget_calculator.py --target 99.95 --window-days 7 --format json\n```\n\n### `slo_review.py`\n\nAudits a directory of SLO definitions (markdown or JSON) for the common bugs.\n\n```bash\npython scripts\u002Fslo_review.py --slo-doc docs\u002Fslos\u002F\n```\n\n**Checks:**\n- `target_too_high`: target ≥ 99.99% (sustainable only with massive engineering investment)\n- `target_too_low`: target ≤ 99.0% (probably wrong SLI; users will notice)\n- `window_too_short`: window \u003C 7 days (statistical noise dominates)\n- `window_too_long`: window > 90 days (slow feedback)\n- `no_sli_definition`: SLI section missing or vague (\"everything OK\")\n- `no_error_budget_policy`: no documented action when budget burns\n- `cpu_as_sli`: CPU\u002Fmemory used as user-experience proxy (wrong signal)\n\n## SLI selection cheatsheet\n\n| User experience | SLI type | What you measure |\n|---|---|---|\n| \"Did the request succeed?\" | request-success-rate | `2xx \u002F total` |\n| \"Was the response fast?\" | request-latency | `count(p99 \u003C threshold) \u002F total` |\n| \"Was the service up?\" | availability-time | `(window - downtime) \u002F window` |\n| \"Is the data current?\" | data-freshness | `count(data_age \u003C threshold) \u002F total` |\n| \"Was the answer correct?\" | correctness | `count(correct) \u002F total` |\n\nSee `references\u002Fsli_design.md` for examples and anti-patterns.\n\n## Error budget math (the basics)\n\nFor 99.9% SLO over 30 days:\n- Allowed unavailability: `0.1% × 30 × 24 × 60 = 43.2 minutes`\n- 1-hour fast-burn threshold (2% of monthly budget burned): `2% × 43.2 \u002F 60 ≈ 1.44 ratio multiplier`\n- 6-hour slow-burn threshold (10% in 6h): `10% × 43.2 \u002F 360 ≈ 0.6 ratio multiplier`\n\n`error_budget_calculator.py` does this math for you and emits ready-to-paste alert rules.\n\n## Composition with the rest of the portfolio\n\nThis skill explicitly composes with three others:\n\n| Skill | Composition |\n|---|---|\n| `feature-flags-architect` | Rollout abort criteria reference SLO burn-rate thresholds |\n| `chaos-engineering` | Blast-radius calculator already takes monthly error budget as input — define it here |\n| `kubernetes-operator` | Operator capability L4 (Deep Insights) requires SLOs + Prometheus rules |\n\nThe `error_budget_calculator.py` output is in the same shape `engineering\u002Fskills\u002Fchaos-engineering\u002Fscripts\u002Fblast_radius_calculator.py` expects on stdin.\n\n## Workflows\n\n### Workflow 1: Define a new SLO\n\n```\n1. Pick the user journey to protect (e.g., \"checkout completion\").\n2. Choose SLI type (request-success-rate, latency, availability, freshness, correctness).\n3. Define the SLI precisely: numerator\u002Fdenominator with concrete labels.\n4. Pick a target by measuring 30 days of historical SLI value:\n     target = floor(p50 of last 30 days × 100) \u002F 100\n   This avoids targets the system has never sustained.\n5. Pick a window (28 days = 4 calendar weeks, recommended).\n6. Run slo_designer.py to render the SLO definition.\n7. Run error_budget_calculator.py to get burn-rate alerts.\n8. Write the error budget policy (what happens when budget burns).\n9. Run slo_review.py — must pass before the SLO is \"live\".\n```\n\n### Workflow 2: Quarterly SLO review\n\n```\n1. For every active SLO, run slo_review.py — fix any FAIL findings.\n2. Look at last quarter's data:\n   - Was the SLO too easy (never burned budget)? Tighten target.\n   - Was it too hard (frequently burned)? Loosen target OR fix the system.\n   - Did burn-rate alerts fire usefully (not too noisy, not too late)? Adjust thresholds.\n3. Audit error budget policies — were they actually followed when budget burned?\n4. Commit revised SLOs; archive old versions with date stamps.\n```\n\n### Workflow 3: SLO-driven rollback\n\n```\n1. New deploy starts burning error budget faster than baseline.\n2. Burn-rate alert fires (from error_budget_calculator.py thresholds).\n3. Auto-rollback via feature flag (kill switch from feature-flags-architect).\n4. Postmortem feeds into next SLO revision.\n```\n\n## References\n\n- `references\u002Fslo_principles.md` — SLI vs SLO vs SLA, Google SRE Workbook canon\n- `references\u002Fsli_design.md` — picking the right SLI; 5 types with examples\n- `references\u002Ferror_budget.md` — error budget math, burn-rate alerts, budget policy\n- `references\u002Fcomposition.md` — how SLOs feed feature flags, chaos, operators\n\n## Slash command\n\n`\u002Fslo-design` — interactive SLO design wizard that runs all 3 tools.\n\n## Asset templates\n\n- `assets\u002Fslo_template.yaml` — fillable SLO YAML\n- `assets\u002Ferror_budget_policy.md` — fillable policy template\n\n## Anti-patterns\n\n- **99.99% on every endpoint** — copy-paste SLOs that nobody verified the system can sustain\n- **CPU usage as SLI** — system metrics aren't user experience\n- **Single-window burn-rate alert** — too noisy if 5-min, too slow if 30-day\n- **No error budget policy** — burning budget means nothing without an action\n- **SLOs without owners** — no one is responsible; they bit-rot\n- **SLOs reviewed once a year** — system characteristics change faster than that\n- **SLAs in the SLO doc** — different audience, different stakes; keep them separate\n- **SLO target = SLA target** — SLO must be tighter (you should beat your contract before customers notice)\n\n## Verifiable success\n\nA team using this skill should achieve:\n\n- 100% of SLOs pass `slo_review.py` with 0 FAIL findings\n- Every SLO has a documented owner, error budget, burn-rate alerts, and policy\n- Burn-rate alerts fire ≤2 times\u002Fmonth per SLO that's hit (signal, not noise)\n- Mean time to detect SLO violation: \u003C30 min (multi-window burn-rate alerts working)\n- Quarterly SLO review happens every quarter (not annually)\n",{"name":5,"tags":48,"author":51,"context":52,"license":14,"version":53,"description":7,"compatible_tools":54},[30,29,49,28,27,33,32,25,50],"sla","observability","claude-code-skills","fork","2.9.0",[55,56,57,58,59,60],"claude-code","codex-cli","cursor","antigravity","opencode","gemini-cli","main","510dd2917e051cc953dc55f56fd6ef442aa01b38","claude-skills\u002Fengineering\u002Fskills\u002Fslo-architect","https:\u002F\u002Fgithub.com\u002Fmne20114-hash\u002Fgest35bi","https:\u002F\u002Fgithub.com\u002Fmne20114-hash","2026-10-28 07:50:31",{"source":8,"skillName":5,"commands":68,"prompt":78,"zipAvailable":79},[69,72,75],{"tool":70,"command":71},"npx","npx skills add mne20114-hash\u002Fgest35bi --skill slo-architect",{"tool":73,"command":74},"bunx","bunx skills add mne20114-hash\u002Fgest35bi --skill slo-architect",{"tool":76,"command":77},"pnpm","pnpm dlx skills add mne20114-hash\u002Fgest35bi --skill slo-architect","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmne20114-hash\u002Fgest35bi\u002Fblob\u002Fmain\u002Fclaude-skills\u002Fengineering\u002Fskills\u002Fslo-architect\u002FSKILL.md",true,[81,87,91,97,101,105,109,115,119,123],{"path":82,"resourceType":83,"resourceTypeDesc":84,"sizeBytes":85,"sourceHtmlUrl":86},"assets\u002Ferror_budget_policy.md","ASSET","资产文件",2641,"https:\u002F\u002Fgithub.com\u002Fmne20114-hash\u002Fgest35bi\u002Fblob\u002Fmain\u002Fclaude-skills\u002Fengineering\u002Fskills\u002Fslo-architect\u002Fassets\u002Ferror_budget_policy.md",{"path":88,"resourceType":83,"resourceTypeDesc":84,"sizeBytes":89,"sourceHtmlUrl":90},"assets\u002Fslo_template.yaml",2293,"https:\u002F\u002Fgithub.com\u002Fmne20114-hash\u002Fgest35bi\u002Fblob\u002Fmain\u002Fclaude-skills\u002Fengineering\u002Fskills\u002Fslo-architect\u002Fassets\u002Fslo_template.yaml",{"path":92,"resourceType":93,"resourceTypeDesc":94,"sizeBytes":95,"sourceHtmlUrl":96},"references\u002Fcomposition.md","REFERENCE","参考文档",5266,"https:\u002F\u002Fgithub.com\u002Fmne20114-hash\u002Fgest35bi\u002Fblob\u002Fmain\u002Fclaude-skills\u002Fengineering\u002Fskills\u002Fslo-architect\u002Freferences\u002Fcomposition.md",{"path":98,"resourceType":93,"resourceTypeDesc":94,"sizeBytes":99,"sourceHtmlUrl":100},"references\u002Ferror_budget.md",4588,"https:\u002F\u002Fgithub.com\u002Fmne20114-hash\u002Fgest35bi\u002Fblob\u002Fmain\u002Fclaude-skills\u002Fengineering\u002Fskills\u002Fslo-architect\u002Freferences\u002Ferror_budget.md",{"path":102,"resourceType":93,"resourceTypeDesc":94,"sizeBytes":103,"sourceHtmlUrl":104},"references\u002Fsli_design.md",5451,"https:\u002F\u002Fgithub.com\u002Fmne20114-hash\u002Fgest35bi\u002Fblob\u002Fmain\u002Fclaude-skills\u002Fengineering\u002Fskills\u002Fslo-architect\u002Freferences\u002Fsli_design.md",{"path":106,"resourceType":93,"resourceTypeDesc":94,"sizeBytes":107,"sourceHtmlUrl":108},"references\u002Fslo_principles.md",5333,"https:\u002F\u002Fgithub.com\u002Fmne20114-hash\u002Fgest35bi\u002Fblob\u002Fmain\u002Fclaude-skills\u002Fengineering\u002Fskills\u002Fslo-architect\u002Freferences\u002Fslo_principles.md",{"path":110,"resourceType":111,"resourceTypeDesc":112,"sizeBytes":113,"sourceHtmlUrl":114},"scripts\u002Ferror_budget_calculator.py","SCRIPT","脚本",5609,"https:\u002F\u002Fgithub.com\u002Fmne20114-hash\u002Fgest35bi\u002Fblob\u002Fmain\u002Fclaude-skills\u002Fengineering\u002Fskills\u002Fslo-architect\u002Fscripts\u002Ferror_budget_calculator.py",{"path":116,"resourceType":111,"resourceTypeDesc":112,"sizeBytes":117,"sourceHtmlUrl":118},"scripts\u002Fslo_designer.py",6680,"https:\u002F\u002Fgithub.com\u002Fmne20114-hash\u002Fgest35bi\u002Fblob\u002Fmain\u002Fclaude-skills\u002Fengineering\u002Fskills\u002Fslo-architect\u002Fscripts\u002Fslo_designer.py",{"path":120,"resourceType":111,"resourceTypeDesc":112,"sizeBytes":121,"sourceHtmlUrl":122},"scripts\u002Fslo_review.py",5660,"https:\u002F\u002Fgithub.com\u002Fmne20114-hash\u002Fgest35bi\u002Fblob\u002Fmain\u002Fclaude-skills\u002Fengineering\u002Fskills\u002Fslo-architect\u002Fscripts\u002Fslo_review.py",{"path":124,"resourceType":125,"resourceTypeDesc":126,"sizeBytes":127,"sourceHtmlUrl":128},"tools.sdn","OTHER","其他",586,"https:\u002F\u002Fgithub.com\u002Formastes\u002Fsimple\u002Fblob\u002Fmain\u002Fexamples\u002F05_stdlib\u002Fspipe\u002Fdoc\u002F00_llm_process\u002Fskill_command\u002Fskills\u002Fgemini\u002Fresearch\u002Ftools.sdn",[130,167,189,212,237,256],{"skillNo":131,"name":132,"nameZh":6,"description":133,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":134,"categories":135,"keywords":147,"publishedAt":43},"01M6C27N3H0F9RGG2KASPASH04","syllabus","Generates a curated supplementary reading list from any course syllabus using Consensus academic search. Grill-me intake (syllabus input format + course audience + year range) plus a grouping forcing-options checkpoint before any search runs — so the reading list matches the course's level and recency need. Parses the syllabus to extract topics and learning outcomes, searches Consensus for recent peer-reviewed papers per topic, and produces a professionally formatted .docx with clickable Consensus links, plain-language summaries calibrated to audience level, and Bloom-higher-order discussion questions tied to course learning goals. Use when the user uploads a syllabus, course outline, or curriculum document and wants supplementary readings (e.g., 'create a reading list from this syllabus', 'find recent papers for my course') — even casual mentions with a syllabus attached should trigger this skill.","https:\u002F\u002Fgithub.com\u002Fmne20114-hash\u002Fgest35bi\u002Fblob\u002Fmain\u002Fclaude-skills\u002Fresearch\u002Fsyllabus\u002Fskills\u002Fsyllabus\u002FSKILL.md",[136,141,144],{"categoryNo":137,"categoryName":138,"taxonomyType":139,"taxonomyTypeDesc":140},"01JBSEEDCAT000000000000002","文档处理","SCENARIO","使用场景",{"categoryNo":142,"categoryName":143,"taxonomyType":139,"taxonomyTypeDesc":140},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":145,"categoryName":146,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000034","行政与办公人员",[132,148,149,150,151,152,153,154,155,156,157,158,159,160,161,162,163,164,165,166],"docx","pr","create","intake","search","audit","integrity","checkpoint","learning","js","format","direct","Rules","find","consensus","list","extract","use","outcomes",{"skillNo":168,"name":169,"nameZh":6,"description":170,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":171,"categories":172,"keywords":177,"publishedAt":43},"01M6C27DMGZ4D6ERNHSVA8H8RJ","pulse","Multi-source recency research skill that takes the pulse of any topic across Reddit, Hacker News, the open web, and optionally X\u002FTwitter within a configurable recent window (default 30 days). Forcing intake clarifies topic specificity, angle (trend\u002Fsentiment\u002Fproblems\u002Fopportunities\u002Fcomparison), time window, and platform scope before searching. Returns a synthesized briefing with citations, engagement metrics, and cross-platform pattern analysis. Use when the user requests multi-source recency intelligence on a topic (e.g., 'pulse on [topic]', 'what's happening with [topic]', 'what are people saying about [topic]', 'current conversation about [topic]', 'take the pulse of [topic]', 'trending: [topic]', 'find me info on [topic]'), and for competitor research, trend discovery, tool comparisons, and audience sentiment analysis.","https:\u002F\u002Fgithub.com\u002Fmne20114-hash\u002Fgest35bi\u002Fblob\u002Fmain\u002Fclaude-skills\u002Fresearch\u002Fpulse\u002Fskills\u002Fpulse\u002FSKILL.md",[173,176],{"categoryNo":174,"categoryName":175,"taxonomyType":139,"taxonomyTypeDesc":140},"01JBSEEDCAT000000000000021","资料检索与研究",{"categoryNo":142,"categoryName":143,"taxonomyType":139,"taxonomyTypeDesc":140},[169,178,179,149,180,151,153,181,182,154,183,184,185,186,159,160,187,161,188,165],"research","web","sentiment analysis","sentiment","Citations","analysis","discovery","open","tool","twitter","user",{"skillNo":190,"name":191,"nameZh":6,"description":192,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":193,"categories":194,"keywords":200,"publishedAt":43},"01M6C279M59X635VPD6Y9R616J","patent","Patent prior-art and landscape intelligence skill — not generic patent help. Commits to one of five sub-use-cases via forcing intake (novelty search \u002F freedom-to-operate \u002F competitive landscape \u002F acquisition diligence \u002F litigation prior-art) before any search runs. Searches Google Patents, Espacenet, USPTO, and optionally Lens.org for citation-graph signals. Output is an editable Word document (.docx) with verdict, ranked closest art (claim-text extracted), CPC-class-aware landscape, family-resolved hits, geographic coverage, FTO flags where applicable, strategy recommendations, and full audit log. Use when the user asks for patent searching or analysis (e.g., 'prior art search for [invention]', 'freedom to operate analysis for [product]'). Produces search signal, not legal advice — always recommends consulting a patent attorney before filing or licensing decisions. Trademark, copyright, and trade-secret questions are out of scope.","https:\u002F\u002Fgithub.com\u002Fmne20114-hash\u002Fgest35bi\u002Fblob\u002Fmain\u002Fclaude-skills\u002Fresearch\u002Fpatent\u002Fskills\u002Fpatent\u002FSKILL.md",[195,196,197],{"categoryNo":137,"categoryName":138,"taxonomyType":139,"taxonomyTypeDesc":140},{"categoryNo":142,"categoryName":143,"taxonomyType":139,"taxonomyTypeDesc":140},{"categoryNo":198,"categoryName":199,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000037","律师与法务",[191,148,149,201,202,203,151,152,153,183,204,205,206,160,207,208,209,210,165,211],"competitive landscape","routing","product","commits","Word","text","acquisition","decisions","strategy","coverage","advice",{"skillNo":213,"name":214,"nameZh":6,"description":215,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":216,"categories":217,"keywords":222,"publishedAt":43},"01M6C275RZWNRB3CCB14QQM7ES","notebooklm","Browser automation skill for controlling Google's NotebookLM. Use when the user wants anything done in NotebookLM (e.g., 'open NotebookLM', 'check my [name] notebook', 'ask my notebook about X', 'add [source] to NotebookLM', 'generate a Video Overview from my notebook', 'use NotebookLM Studio'). Handles reading and querying notebooks, adding sources (URLs, text, files, YouTube links, synthesized content), generating Studio outputs (Audio\u002FVideo Overviews, Mind Maps, Reports incl. Briefing Doc\u002FStudy Guide\u002FFAQ, Flashcards, Quiz, slide decks, infographics — discover the exact set from the live Studio panel; the UI evolves fast), and creating new notebooks. Requires browser automation environment — fails gracefully when unavailable.","https:\u002F\u002Fgithub.com\u002Fmne20114-hash\u002Fgest35bi\u002Fblob\u002Fmain\u002Fclaude-skills\u002Fresearch\u002Fnotebooklm\u002Fskills\u002Fnotebooklm\u002FSKILL.md",[218,221],{"categoryNo":219,"categoryName":220,"taxonomyType":139,"taxonomyTypeDesc":140},"01JBSEEDCAT000000000000016","图像与多媒体",{"categoryNo":142,"categoryName":143,"taxonomyType":139,"taxonomyTypeDesc":140},[214,223,224,178,225,226,227,228,229,230,231,232,185,206,159,233,234,235,236,165],"google","browser automation","automation","generate","browser","fast","SET","doc","Video","Audio","check","ask","environment","overview",{"skillNo":238,"name":239,"nameZh":6,"description":240,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":241,"categories":242,"keywords":247,"publishedAt":43},"01M6C2717B0QDJ3Y4PJP77BMW5","litreview","Academic literature orientation skill that searches papers via free keyless APIs (PubMed E-utilities + OpenAlex) by default — with the Consensus MCP as an optional enhancement lane when connected — builds a strategic search plan using PICO (default) or SPIDER \u002F Decomposition \u002F hybrid as fallbacks, and synthesizes findings into a formatted Word (.docx) research guide. Grill-me intake (research question specificity + framework hint + tentative depth) before the recon search; a second forcing checkpoint after Phase 2 confirms framework + sub-areas + depth before searches consume budget. Configurable depth (5\u002F10\u002F20 queries) controls coverage vs. speed. Output is a 'launching pad' — an orientation guide that lets a researcher dive in confidently, not a finished review. Use when the user starts literature-oriented research (e.g., 'litreview on [topic]', 'literature review on [topic]', 'I'm starting a literature review on X', 'I'm writing a paper on X', 'help me research X', 'I'm doing research on X', 'can you help me research X'). Do NOT use for single one-off paper searches wanting a quick list — that's a plain PubMed\u002FOpenAlex (or Consensus) query.","https:\u002F\u002Fgithub.com\u002Fmne20114-hash\u002Fgest35bi\u002Fblob\u002Fmain\u002Fclaude-skills\u002Fresearch\u002Flitreview\u002Fskills\u002Flitreview\u002FSKILL.md",[243,244,245,246],{"categoryNo":137,"categoryName":138,"taxonomyType":139,"taxonomyTypeDesc":140},{"categoryNo":174,"categoryName":175,"taxonomyType":139,"taxonomyTypeDesc":140},{"categoryNo":142,"categoryName":143,"taxonomyType":139,"taxonomyTypeDesc":140},{"categoryNo":145,"categoryName":146,"taxonomyType":20,"taxonomyTypeDesc":21},[239,148,248,249,250,149,151,152,251,252,253,155,254,205,255,160,162,35,210,165],"MCP","writing","review","lane","keyless","literature review","plan","researcher",{"skillNo":257,"name":258,"nameZh":6,"description":259,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":260,"categories":261,"keywords":266,"publishedAt":43},"01M6C26X5G3WDVWQ40Y16ZS19F","grants","NIH grant research skill for clinical researchers. Grill-me intake (research idea + career stage + preliminary data + environment + submission posture + known institute targets) locks down the funding strategy before any search runs. Runs a 5-facet Consensus positioning analysis (with draft Significance\u002FInnovation language), maps the research to the right NIH institutes and study sections via RePORTER, finds NOSIs and funded overlap, and produces an editable Word document (.docx) with budget\u002Fscope-aware mechanism recommendations, submission timelines, and a mandatory program officer recommendation. Use when the user asks about research funding or makes any grant-related request (e.g., 'grants for [topic]', 'find grants for my research idea', 'what grants match my research', 'help me find NIH funding', 'grant opportunities for my research'). NIH-only scope — non-NIH funders (PCORI, DOD CDMRP, VA, foundations) are out of scope and flagged at intake.","https:\u002F\u002Fgithub.com\u002Fmne20114-hash\u002Fgest35bi\u002Fblob\u002Fmain\u002Fclaude-skills\u002Fresearch\u002Fgrants\u002Fskills\u002Fgrants\u002FSKILL.md",[262,263,264,265],{"categoryNo":137,"categoryName":138,"taxonomyType":139,"taxonomyTypeDesc":140},{"categoryNo":174,"categoryName":175,"taxonomyType":139,"taxonomyTypeDesc":140},{"categoryNo":142,"categoryName":143,"taxonomyType":139,"taxonomyTypeDesc":140},{"categoryNo":145,"categoryName":146,"taxonomyType":20,"taxonomyTypeDesc":21},[258,148,178,149,267,151,152,153,268,269,154,183,205,160,161,162,209,235,165,270],"help","data","Budget","innovation"]