[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6MDAQ78EN4SA13S7C10M4A0":3,"skill-same:01M6MDAQ78EN4SA13S7C10M4A0":81},{"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},"01M6MDAQ78EN4SA13S7C10M4A0","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.","JiayiV\u002Fquestion_mixing","JiayiV","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F54466889?v=4","01M6JFJYYMRZ3QRGP9339JNQ2K","01M6JFJZ35KB0QVT50NAHPJA7G",0,"MIT","https:\u002F\u002Fgithub.com\u002FJiayiV\u002Fquestion_mixing\u002Fblob\u002Fmain\u002Fskills\u002Fpublic-02-claude-skills-main-engineering-skills-slo-architect-skill-2112037a\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","slo","reliability","definition","error","operating","google-sre-workbook","burn-rate","error-budget","sli","feature-flags","design","sre","chaos-engineering","question","short","reviewer","Composition","code","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},[25,33,49,32,31,36,26,30,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","068c2486ccc0f8d200a3db4d21ec137064eda3b4","skills\u002Fpublic-02-claude-skills-main-engineering-skills-slo-architect-skill-2112037a","https:\u002F\u002Fgithub.com\u002FJiayiV\u002Fquestion_mixing","https:\u002F\u002Fgithub.com\u002FJiayiV","2026-08-25 16:30:52",{"source":8,"skillName":5,"commands":68,"prompt":78,"zipAvailable":79},[69,72,75],{"tool":70,"command":71},"npx","npx skills add JiayiV\u002Fquestion_mixing --skill slo-architect",{"tool":73,"command":74},"bunx","bunx skills add JiayiV\u002Fquestion_mixing --skill slo-architect",{"tool":76,"command":77},"pnpm","pnpm dlx skills add JiayiV\u002Fquestion_mixing --skill slo-architect","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FJiayiV\u002Fquestion_mixing\u002Fblob\u002Fmain\u002Fskills\u002Fpublic-02-claude-skills-main-engineering-skills-slo-architect-skill-2112037a\u002FSKILL.md",true,[],[82,107,135,168,196,229],{"skillNo":83,"name":84,"nameZh":6,"description":85,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":86,"categories":87,"keywords":88,"publishedAt":43},"01M6NN9PJS9NHWPDG4QP93BP8F","webmcpify","Make a web app agent-ready — propose a WebMCP tool manifest, integrate, verify in a real browser, heal; unrelated code stays untouched. Use for \"webmcpify\", \"add WebMCP\", or \"expose app actions to AI agents\".","https:\u002F\u002Fgithub.com\u002FJiayiV\u002Fquestion_mixing\u002Fblob\u002Fmain\u002Fskills\u002Fwebmcpify\u002FSKILL.md",[],[84,89,90,91,92,42,93,94,95,96,97,98,99,100,101,102,103,104,105,106],"github","ai agents","web","notes","browser","https","actions","manifest","inventory","verify","tool","use","ready","unrelated","app","scope","for","webmcp",{"skillNo":108,"name":109,"nameZh":6,"description":110,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":111,"licenseFileUrl":6,"sourceHtmlUrl":112,"categories":113,"keywords":114,"publishedAt":43},"01M6NN6KZE5RBN6NGHN2WXV1RE","vardoger-analyze","Use when the user asks to personalize the GitHub Copilot CLI assistant, adapt Copilot to their style, use vardoger, or analyze their Copilot CLI conversation history. Reads the local session directory at `~\u002F.copilot\u002Fsession-state\u002F`, extracts recurring preferences and conventions, and writes a fenced personalization block into `~\u002F.copilot\u002Fcopilot-instructions.md`. Runs entirely on the user's machine via the local `vardoger` CLI (`pipx install vardoger`); no network calls and no uploads. Triggers: 'personalize my copilot', 'analyze my copilot history', 'tailor copilot to me', 'run vardoger', 'update my copilot instructions from history', 'make copilot learn my style'.","Apache-2.0","https:\u002F\u002Fgithub.com\u002FJiayiV\u002Fquestion_mixing\u002Fblob\u002Fmain\u002Fskills\u002Fvardoger-analyze\u002FSKILL.md",[],[115,116,117,118,119,120,121,122,123,124,125,126,127,128,129,130,131,132,133,134],"vardoger analyze","analyze","directory","cli","github copilot","copilot","run","update","learn","network","my style","install","conversation","me","local","github copilot cli","pipx","my","at","copilot instructions",{"skillNo":136,"name":137,"nameZh":6,"description":138,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":139,"categories":140,"keywords":149,"publishedAt":43},"01M6NN3CZGQP3XAJ04BM1NNYGT","transloadit-media-processing","Process media files (video, audio, images, documents) using Transloadit. Use when asked to encode video to HLS\u002FMP4, generate thumbnails, resize or watermark images, extract audio, concatenate clips, add subtitles, OCR documents, or run any media processing pipeline. Covers 86+ processing robots for file transformation at scale.","https:\u002F\u002Fgithub.com\u002FJiayiV\u002Fquestion_mixing\u002Fblob\u002Fmain\u002Fskills\u002Ftransloadit-media-processing\u002FSKILL.md",[141,146],{"categoryNo":142,"categoryName":143,"taxonomyType":144,"taxonomyTypeDesc":145},"01JBSEEDCAT000000000000016","图像与多媒体","SCENARIO","使用场景",{"categoryNo":147,"categoryName":148,"taxonomyType":144,"taxonomyTypeDesc":145},"01JBSEEDCAT000000000000023","Skill与智能体开发",[150,151,152,153,154,155,156,157,158,159,160,161,162,100,163,164,165,166,105,167],"transloadit media processing","Media","media processing","processing","MCP","mcp server","documents","subtitles","pipeline","ocr","Video","Audio","mp4","images","files","transformation","free","hls",{"skillNo":169,"name":170,"nameZh":6,"description":171,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":172,"categories":173,"keywords":177,"publishedAt":43},"01M6NN28E92F9GH4WFYQ2H1Y15","terraform-azurerm-set-diff-analyzer","Analyze Terraform plan JSON output for AzureRM Provider to distinguish between false-positive diffs (order-only changes in Set-type attributes) and actual resource changes. Use when reviewing terraform plan output for Azure resources like Application Gateway, Load Balancer, Firewall, Front Door, NSG, and other resources with Set-type attributes that cause spurious diffs due to internal ordering changes.","https:\u002F\u002Fgithub.com\u002FJiayiV\u002Fquestion_mixing\u002Fblob\u002Fmain\u002Fskills\u002Fterraform-azurerm-set-diff-analyzer\u002FSKILL.md",[174],{"categoryNo":175,"categoryName":176,"taxonomyType":144,"taxonomyTypeDesc":145},"01JBSEEDCAT000000000000011","运维与部署",[178,179,180,181,182,183,184,185,186,100,187,188,189,190,191,192,193,194,195,105],"terraform","SET","terraform azurerm set diff analyzer","diff","analyzer","diffs","azure","gateway","firewall","only","resource changes","provider","resources","load balancer","attributes","front","load","balancer",{"skillNo":197,"name":198,"nameZh":6,"description":199,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":200,"categories":201,"keywords":211,"publishedAt":43},"01M6NN1QMH2TDYWTH3XY3N5XPV","technical-job-search","Use this skill when a software engineer asks for help with job search tasks: parsing or analyzing a job description, tailoring a CV\u002Fresume, writing a cover letter, evaluating a job offer, or drafting a post-interview follow-up email. Do not activate for general career advice unrelated to an active job search action.","https:\u002F\u002Fgithub.com\u002FJiayiV\u002Fquestion_mixing\u002Fblob\u002Fmain\u002Fskills\u002Ftechnical-job-search\u002FSKILL.md",[202,205,208],{"categoryNo":203,"categoryName":204,"taxonomyType":144,"taxonomyTypeDesc":145},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":206,"categoryName":207,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000036","内容创作者",{"categoryNo":209,"categoryName":210,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000038","人力资源",[212,213,214,215,216,217,218,219,116,220,100,221,222,223,224,225,226,227,105,228],"search","Job Search","technical job search","technical","writing","tasks","email","parsing","interview","up","engineer","general","activate","do","task","cv","letter",{"skillNo":230,"name":231,"nameZh":6,"description":232,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":233,"categories":234,"keywords":235,"publishedAt":43},"01M6NMZFA67XYS1GS09WT42235","steno-mode","Shorthand-first response compression that cuts ~40% of response tokens while preserving technical precision and exact literals. Use when the user says \"steno mode\", \"shorthand mode\", \"compressed responses\", \"token reduction\", \"brief structured output\", or invokes \u002Fsteno. Supports four compression levels: lite, brief, court, machine. Do not trigger for requests needing polished prose such as onboarding\u002Ftutorial content, stakeholder or customer-facing copy, or teaching-focused explanations.","https:\u002F\u002Fgithub.com\u002FJiayiV\u002Fquestion_mixing\u002Fblob\u002Fmain\u002Fskills\u002Fsteno-mode\u002FSKILL.md",[],[236,237,238,239,240,215,241,100,225,242,243,244,245,246,247,248,249,250,105,251],"steno mode","mode","customer","brief","first","tutorial","teaching","tokens","as","trigger","structured output","machine","output","court","requests","response compression"]