Update to Resolve AI

{
  "name": "prod-context",
  "description": "Get production context from Resolve for the area you're about to change — so the work is grounded in what production looks like and aware of how the change could affect it, before you start rather than after the PR is up. Use before implementing a fix or feature, when finalizing a plan or approach, or before editing anything that affects a production system — application code, infrastructure, or config-as-code (Helm, Terraform, Dockerfiles, CI/CD, SQL/migrations, protos) — or when the user says \"let's build/fix/implement X\". Surfaces the area's normal operational profile (traffic and usage, telemetry coverage, baseline latency/error rate), the regression risk of the change, plus any active alerts, open investigations, recent incidents or deploys, and known fragility.",
  "included_files": [],
  "skill_md_contents": "---\n# Copyright 2026 Resolve AI, Inc.\n# SPDX-License-Identifier: Apache-2.0\nname: prod-context\ndescription: Get production context from Resolve for the area you're about to change — so the work is grounded in what production looks like and aware of how the change could affect it, before you start rather than after the PR is up. Use before implementing a fix or feature, when finalizing a plan or approach, or before editing anything that affects a production system — application code, infrastructure, or config-as-code (Helm, Terraform, Dockerfiles, CI/CD, SQL/migrations, protos) — or when the user says \"let's build/fix/implement X\". Surfaces the area's normal operational profile (traffic and usage, telemetry coverage, baseline latency/error rate), the regression risk of the change, plus any active alerts, open investigations, recent incidents or deploys, and known fragility.\nversion: 0.1.0\nargument-hint: [optional focus, e.g. a service or concern]\nlicense: Apache-2.0\n---\n\n# Pre-implementation production context\n\nBefore implementing a change to a production-facing path, get the runtime picture the code can't\nshow — real traffic, telemetry coverage, baselines, live trouble — and let it shape the approach.\nResolve owns the telemetry and the service map; query it only for what you can't read off the repo.\n\n## When to trigger\n\nTrigger at the **plan → implement boundary**: the task is understood, the in-scope files or areas\nare known, and no code is written yet — so production reality can still shape the approach, not\njust validate it afterwards.\n\nSkip trivial changes (typo, comment, formatting, docs-only) and anything no production system\nwould monitor.\n\n## Decide whether to ask\n\nAsk Resolve only when a **production runtime unknown** would change how you build this. If the open\nquestions are answerable by reading the repo, or the area is quiet with no runtime unknowns, skip\nthe ask — say so in one line and continue with the work.\n\n## Compose the ask\n\nPick the few angles that fit this change — don't ask all of them, and don't ask generically. Each\nis something the code can't tell you.\n\nKnow the area:\n\n- **Operational profile** — real traffic and request volume, peak vs quiet, how heavily it's\n  exercised. A hot path demands far more care than a rarely-hit endpoint.\n- **Telemetry coverage** — what observability exists here (logs, metrics, traces) and where the\n  blind spots are: will you be able to see your change's effect?\n- **Baseline behavior** — the normal latency / error rate / throughput, so you know what \"good\"\n  looks like.\n\nCheck for trouble:\n\n- **Is the ground shaking?** — active alerts, ongoing incidents, or open investigations on the\n  area. Don't build on top of an active fire — or realize your change _is_ about it.\n- **Regression history** — recent deploys and prior incidents on these paths; where it's bitten\n  before, build defensively.\n- **Runtime downstream fanout** — what actually gets hit downstream at volume, from traces and the\n  service map. Scopes rollout and testing.\n- **What to verify after** — given the change, the production signals to watch post-deploy.\n\nMake it exact. Gather a tight bundle — be ruthlessly selective, no transcript dumps:\n\n- **Task** — one line on what's being implemented.\n- **In-scope files/areas** — the paths you've read or named. Paths are enough; don't map them to\n  services yourself, Resolve does that.\n- **Approach** — the intended plan, if there is one.\n- **Symptoms/errors/tickets** — verbatim where they frame the change.\n- **Git framing** — run `git rev-parse --abbrev-ref HEAD` and `git log --oneline -3`, and include\n  the branch and recent subjects.\n\nPut the concrete question(s) first, then a short `## What I'm about to change` block, and send via\n`resolve-ai:ask`. For example:\n\n- New feature/endpoint → _operational profile_ + _telemetry coverage_: \"About to add `<X>` to\n  `<service>`. How much traffic/usage does this area see, is it a hot path, and what telemetry\n  already covers it — will I be able to observe this change?\"\n- Change to a high-fanout component → _runtime fanout_ + _regression history_: \"About to change\n  `<component>` in `<files>`. What actually depends on this in production, has changing it caused\n  incidents before, and what should I watch after deploy?\"\n- Bugfix in a sensitive area → _ground shaking_ + _baseline_: \"About to fix `<bug>` in `<files>`.\n  Any open investigations or active alerts on `<area>`, and what's the normal error rate/latency so\n  I can tell if the fix actually helps?\"\n\n## After asking\n\nDon't block. Fire the ask and immediately continue planning and implementing — never gate code\nchanges, the PR, or any other work on the reply. Pause only if the user explicitly asks to wait.\n\nWhen the reply lands:\n\n- Summarize what Resolve returned in 2–4 bullets.\n- Adjust the approach and call out the change explicitly — e.g. it's a high-traffic hot path so\n  gate it behind a flag and test harder; lots depends on it downstream so stage the rollout;\n  telemetry is thin so add instrumentation with the change; an open investigation overlaps the\n  area; a recent deploy is already shaky.\n- Fire at most one sharpening follow-up if something is directly relevant.\n\nIf Resolve comes back unremarkable — low-traffic, healthy, nothing in flight — say so in one line\nand carry on.\n"
}