[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6CR4VYSPHG6QSWPRBJNWZFZ":3,"skill-same:01M6CR4VYSPHG6QSWPRBJNWZFZ":80},{"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":39,"linkOnly":40,"markdownContent":41,"markdownBody":42,"frontMatter":43,"refName":44,"commitSha":45,"skillDirectory":46,"forksCount":14,"repositoryHtmlUrl":47,"repositoryHomepageUrl":6,"ownerHtmlUrl":48,"ownerBlogUrl":49,"ownerDescription":50,"updatedAt":51,"install":52,"resources":65},"01M6CR4VYSPHG6QSWPRBJNWZFZ","serve-live",null,"Before a person looks at a running service, make sure what is running IS the code in the checkout. Restart the services your change actually touched — not every service — and verify each is serving the current commit rather than merely answering; check the remaining dependencies are up without bouncing them. Use whenever you finish work a person will view in a browser or client, whenever you say a page or service is ready, after any commit that changes served code, and when asked to 'restart', 'refresh the services', 'is it live', or 'serve the latest'. Also covers waiting for lazy warm-up before calling a service ready.","maxjbarfuss\u002Fmax_llm","maxjbarfuss","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F13053317?v=4","01M6CR3EGHV8C2C90PGAQEXZ27","Max Barfuss","01M6CR3EN0FXE8RZXAXCT7DWJG",0,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fmaxjbarfuss\u002Fmax_llm\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fserve-live\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"serve live","refresh","dependencies","calling","restart","say","finish","up","ready","use","change","view","check","work","page","verify","services","browser","code","commit","2026-11-10 10:12:30",false,"---\nname: serve-live\ndescription: \"Before a person looks at a running service, make sure what is running IS the code in the checkout. Restart the services your change actually touched — not every service — and verify each is serving the current commit rather than merely answering; check the remaining dependencies are up without bouncing them. Use whenever you finish work a person will view in a browser or client, whenever you say a page or service is ready, after any commit that changes served code, and when asked to 'restart', 'refresh the services', 'is it live', or 'serve the latest'. Also covers waiting for lazy warm-up before calling a service ready.\"\n---\n\n# Serve live — never hand over a stale process\n\n\u003C!-- agent-sync:start serve-live -->\n*Vendor-neutral and machine-wide: this lives in `~\u002F.agents\u002Fskills\u002F`, the\ncross-tool location Codex, Grok and Kilo read themselves; Claude Code gets a\none-line pointer to it. It is written to be followed by any coding\nagent — Codex, Grok, Claude, Kilo, Cursor, Gemini, Copilot — or by a person.*\n\n## The failure this exists to prevent\n\nA service started before your last commit keeps answering. Every health check\npasses. The port is bound, requests return 200, logs look normal. And the\nperson looking at it is looking at **old code** — reviewing work you did not\ndo, reporting bugs you already fixed, or seeing none of the feature you just\ndescribed to them.\n\nThis is not a rare edge case. It is the default outcome of committing while a\nserver runs, and it is silent: nothing in the served response says \"I am three\ncommits behind\" unless the application deliberately says so.\n\n**It wastes a person's attention, which is the most expensive thing you spend.**\n\n## The rule\n\n**Committing code that a running service serves is not finished work until you\nhave restarted that service and verified the restart.**\n\nDo it on your own initiative. Do not wait to be asked, do not ask permission\nfor a dev service, and do not announce a page as ready, live, or working\nwithout doing it first.\n\nWork ready for a person to test is live before you say so: read the push's\n`svc deploy: serving \u003Cproj> at \u003Csha>` line, then the service's own reported\nbuild. A deploy or restart that did not happen (refused, failed, skipped) is\nyours to finish now with `svc restart \u003Cservice>` — never handed back as \"close\nyour tabs\" or \"run this as max\". An open page, sitting or job is not a reason\nto wait on a dev service: restart, then say what it cut off.\n\n## What \"verified\" means\n\nAnswering is not the check. A wedged or stale process answers.\n\nVerify **identity**, in this order:\n\n1. **The running process reports the current commit.** If the service exposes\n   its build (many do: a `\u002Fhealth` field, a banner, a version endpoint),\n   compare it to `git rev-parse --short HEAD` and require equality. This is the\n   only check that actually proves freshness.\n2. **If it exposes no build,** verify by behaviour: request something that only\n   exists after your change and require the new answer. A status code is not\n   enough — assert on content only the new code could produce.\n3. **Restart time is later than commit time.** The weakest check; use it only\n   when neither of the above is possible, and say that you used it.\n\nA check that cannot distinguish the new code from the old proves nothing.\n\n## Drive the path you changed\n\nAny path is not the check; *the* path is. A streaming request is a separate\ncode path from a plain one, so a fix proven on one is unproven on the other —\nsend both. A fix to a refusal is proven by a request that should be refused\n*being* refused, not by the allow path still working; a fix that only proves\nthe allow path is half a fix.\n\n## Verifying a UI: sign in, do not infer\n\nA change to a user interface is verified by **loading the page**, not by\nreading the source and reasoning that it must render. Source can be correct\nwhile the feature is unreachable — hidden behind a click with no affordance,\nrendered off-screen, or gated on an identity the viewer does not have. Those\nare real defects and no amount of re-reading the component finds them.\n\nTwo things block this, and both look like the app being broken:\n\n- **Credentials come from the environment, never from a read.** Use the\n  test credential the execution environment provides; never read `.env` or a\n  keyfile to find one, and never print it or run with shell tracing on.\n- **An API key is not a login.** Keys usually authenticate as *nobody*, while a\n  management UI is a person's surface. Find the project's designated\n  agent-usable account and sign in as it. Projects that expect agents to verify\n  UI work provide one; look for it in the project's own docs before concluding\n  you cannot log in. Check the sign-in route against the client code rather\n  than guessing at `\u002Fauth\u002Fsignin` or `\u002Flogin`.\n- **A self-signed cert on a dev service.** `curl` reads it as a hard failure\n  without `-k`, and an `http:\u002F\u002F` probe of an HTTPS port reports the service down\n  while it is serving happily. A headless browser stops at an interstitial and\n  never mounts the app — `ERR_CERT_AUTHORITY_INVALID`, a \"Privacy error\" title\n  and a near-empty body, which reads exactly like a crash. Click through it\n  (`Advanced`, then the proceed link) before judging anything.\n\nWhen you assert on rendered text, match case-insensitively or read the\naccessibility tree. CSS routinely uppercases labels, so a literal test for\n`Offered for` fails on the `OFFERED FOR` that is plainly on screen — and that\nfalse negative sends you hunting a bug that does not exist.\n\nIf a surface stays locked after signing in as the agent account, check whether\nit is meant to be. An ordinary account being refused an operator-only page is\ncorrect behaviour, not a failed login.\n\n## Restart what you touched. Check the rest.\n\nTwo different obligations, and conflating them wastes time and takes down\nthings that were fine.\n\n**Restart** — only what your change actually reaches:\n\n- The service whose code you edited.\n- Anything that **imported or vendored** it, including sidecars and workers\n  that load their own copy at spawn time and so keep running old code even\n  after the parent restarts.\n- Anything that **cached** it: a compiled bundle, a generated client, a\n  template cache. A frontend served from a bundle needs its build step re-run,\n  not just a server bounce.\n\n**Check, do not restart** — everything else it depends on:\n\n- Upstreams you did not change: confirm they answer and report their state.\n- Services owned by another session or person: never bounce one to make yours\n  look good. Report what you saw and let the owner decide.\n\nIf you are unsure whether your change reaches a service, ask what would have\nto be true for it to be stale — did its process load the code you changed? If\nno, leave it alone and say you left it alone. A change to docs or comments\nreaches no process: restart nothing, and say so.\n\n## Restarting safely\n\n- **Never restart onto code that does not pass.** A live check against a\n  broken build tells you nothing, and it takes down a working one to do it.\n- **Note work in flight, then restart.** An open session, a running job, a\n  live upload. Say what it cost. Do not wait and do not ask. Another session\n  using the service is not a reason to leave stale code running.\n- **Kill by PID, and take the PID from something that cannot be you.**\n  `pkill -f \"\u003Cservice>\"` can match the agent's own command line and kill the\n  session. `pgrep -f \"\u003Cservice>\"` first and then killing those PIDs is the same\n  pattern with the same result: a shell that runs the restart and then greps\n  for the service is killed along with it. Take the PID from the port\n  (`ss -ltnp 'sport = :\u003Cport>'`), or anchor the pattern at the start of the\n  server's own argv (`^[^ ]*python[^ ]* [^ ]*\u002F\u003Centry> serve`). No shell's\n  command line starts that way.\n- **Escalate only when needed.** Try a graceful stop; if the process is already\n  wedged in shutdown (a held socket, a draining connection that never drains),\n  a graceful signal cannot work and you escalate.\n- **Confirm the port is free before starting again**, or you get a second\n  process fighting for it, or a start that silently fails.\n- **Prefer no-reload in a shared tree.** If several agents or a person edit the\n  same checkout, a file-watch reloader can be triggered by someone else's save\n  and wedge mid-restart. Autoreload is a convenience, not a substitute for\n  this skill: it is exactly what produces \"the port is bound but nothing\n  answers\".\n\n## Live is an end state\n\nThe restarted service must still be running when you hand back. Do not start\nit inside a test harness, behind a cleanup trap, or from a command whose\nenvironment reaps its children when it returns — a screenshot of a process\nthat was then stopped is not a live verification. Make the final health\nrequest in a separate command, after the restart has returned; if the\nenvironment reaps background children, start the service under the user's\nservice manager instead.\n\n## Warm-up is not readiness\n\nMany services report empty or partial subsystems for seconds after start —\nmodels load lazily, engines warm on first use, caches fill on demand. Checking\ntoo early and reporting \"the engine is empty, something is broken\" is a wrong\ndiagnosis that costs a person real time.\n\n**Wait for the subsystem to report ready before you judge it.** Poll until it\nis populated or until a timeout you state. If it is still empty at the\ntimeout, *then* it is a finding — and say how long you waited.\n\n## Write it down once\n\nIf you restart a service by hand more than once in a session, put the sequence\nin the project as a script — stop by PID, wait for the port, start, then block\nuntil the reported build equals HEAD, exiting non-zero if it does not. A script\nthat returns success while serving the wrong commit is worse than no script.\nMake the freshness assertion the thing that gates its exit code.\n\n## What to say at the end\n\n- The service, the port, and the commit it is **now** serving — with the\n  checkout's commit beside it, so the match is visible rather than claimed.\n- Any subsystem you waited for, and how long.\n- Upstreams you checked but did not restart, and who owns them.\n- Anything you could **not** verify — a page behind a login you cannot pass, a\n  client you cannot drive. Name it plainly instead of implying you saw it work.\n\nNever say \"it is live\" or \"ready to look at\" without the commit match behind\nit. If you could not verify, say what you actually did and what remains\nunproven.\n\u003C!-- agent-sync:end -->\n","# Serve live — never hand over a stale process\n\n\u003C!-- agent-sync:start serve-live -->\n*Vendor-neutral and machine-wide: this lives in `~\u002F.agents\u002Fskills\u002F`, the\ncross-tool location Codex, Grok and Kilo read themselves; Claude Code gets a\none-line pointer to it. It is written to be followed by any coding\nagent — Codex, Grok, Claude, Kilo, Cursor, Gemini, Copilot — or by a person.*\n\n## The failure this exists to prevent\n\nA service started before your last commit keeps answering. Every health check\npasses. The port is bound, requests return 200, logs look normal. And the\nperson looking at it is looking at **old code** — reviewing work you did not\ndo, reporting bugs you already fixed, or seeing none of the feature you just\ndescribed to them.\n\nThis is not a rare edge case. It is the default outcome of committing while a\nserver runs, and it is silent: nothing in the served response says \"I am three\ncommits behind\" unless the application deliberately says so.\n\n**It wastes a person's attention, which is the most expensive thing you spend.**\n\n## The rule\n\n**Committing code that a running service serves is not finished work until you\nhave restarted that service and verified the restart.**\n\nDo it on your own initiative. Do not wait to be asked, do not ask permission\nfor a dev service, and do not announce a page as ready, live, or working\nwithout doing it first.\n\nWork ready for a person to test is live before you say so: read the push's\n`svc deploy: serving \u003Cproj> at \u003Csha>` line, then the service's own reported\nbuild. A deploy or restart that did not happen (refused, failed, skipped) is\nyours to finish now with `svc restart \u003Cservice>` — never handed back as \"close\nyour tabs\" or \"run this as max\". An open page, sitting or job is not a reason\nto wait on a dev service: restart, then say what it cut off.\n\n## What \"verified\" means\n\nAnswering is not the check. A wedged or stale process answers.\n\nVerify **identity**, in this order:\n\n1. **The running process reports the current commit.** If the service exposes\n   its build (many do: a `\u002Fhealth` field, a banner, a version endpoint),\n   compare it to `git rev-parse --short HEAD` and require equality. This is the\n   only check that actually proves freshness.\n2. **If it exposes no build,** verify by behaviour: request something that only\n   exists after your change and require the new answer. A status code is not\n   enough — assert on content only the new code could produce.\n3. **Restart time is later than commit time.** The weakest check; use it only\n   when neither of the above is possible, and say that you used it.\n\nA check that cannot distinguish the new code from the old proves nothing.\n\n## Drive the path you changed\n\nAny path is not the check; *the* path is. A streaming request is a separate\ncode path from a plain one, so a fix proven on one is unproven on the other —\nsend both. A fix to a refusal is proven by a request that should be refused\n*being* refused, not by the allow path still working; a fix that only proves\nthe allow path is half a fix.\n\n## Verifying a UI: sign in, do not infer\n\nA change to a user interface is verified by **loading the page**, not by\nreading the source and reasoning that it must render. Source can be correct\nwhile the feature is unreachable — hidden behind a click with no affordance,\nrendered off-screen, or gated on an identity the viewer does not have. Those\nare real defects and no amount of re-reading the component finds them.\n\nTwo things block this, and both look like the app being broken:\n\n- **Credentials come from the environment, never from a read.** Use the\n  test credential the execution environment provides; never read `.env` or a\n  keyfile to find one, and never print it or run with shell tracing on.\n- **An API key is not a login.** Keys usually authenticate as *nobody*, while a\n  management UI is a person's surface. Find the project's designated\n  agent-usable account and sign in as it. Projects that expect agents to verify\n  UI work provide one; look for it in the project's own docs before concluding\n  you cannot log in. Check the sign-in route against the client code rather\n  than guessing at `\u002Fauth\u002Fsignin` or `\u002Flogin`.\n- **A self-signed cert on a dev service.** `curl` reads it as a hard failure\n  without `-k`, and an `http:\u002F\u002F` probe of an HTTPS port reports the service down\n  while it is serving happily. A headless browser stops at an interstitial and\n  never mounts the app — `ERR_CERT_AUTHORITY_INVALID`, a \"Privacy error\" title\n  and a near-empty body, which reads exactly like a crash. Click through it\n  (`Advanced`, then the proceed link) before judging anything.\n\nWhen you assert on rendered text, match case-insensitively or read the\naccessibility tree. CSS routinely uppercases labels, so a literal test for\n`Offered for` fails on the `OFFERED FOR` that is plainly on screen — and that\nfalse negative sends you hunting a bug that does not exist.\n\nIf a surface stays locked after signing in as the agent account, check whether\nit is meant to be. An ordinary account being refused an operator-only page is\ncorrect behaviour, not a failed login.\n\n## Restart what you touched. Check the rest.\n\nTwo different obligations, and conflating them wastes time and takes down\nthings that were fine.\n\n**Restart** — only what your change actually reaches:\n\n- The service whose code you edited.\n- Anything that **imported or vendored** it, including sidecars and workers\n  that load their own copy at spawn time and so keep running old code even\n  after the parent restarts.\n- Anything that **cached** it: a compiled bundle, a generated client, a\n  template cache. A frontend served from a bundle needs its build step re-run,\n  not just a server bounce.\n\n**Check, do not restart** — everything else it depends on:\n\n- Upstreams you did not change: confirm they answer and report their state.\n- Services owned by another session or person: never bounce one to make yours\n  look good. Report what you saw and let the owner decide.\n\nIf you are unsure whether your change reaches a service, ask what would have\nto be true for it to be stale — did its process load the code you changed? If\nno, leave it alone and say you left it alone. A change to docs or comments\nreaches no process: restart nothing, and say so.\n\n## Restarting safely\n\n- **Never restart onto code that does not pass.** A live check against a\n  broken build tells you nothing, and it takes down a working one to do it.\n- **Note work in flight, then restart.** An open session, a running job, a\n  live upload. Say what it cost. Do not wait and do not ask. Another session\n  using the service is not a reason to leave stale code running.\n- **Kill by PID, and take the PID from something that cannot be you.**\n  `pkill -f \"\u003Cservice>\"` can match the agent's own command line and kill the\n  session. `pgrep -f \"\u003Cservice>\"` first and then killing those PIDs is the same\n  pattern with the same result: a shell that runs the restart and then greps\n  for the service is killed along with it. Take the PID from the port\n  (`ss -ltnp 'sport = :\u003Cport>'`), or anchor the pattern at the start of the\n  server's own argv (`^[^ ]*python[^ ]* [^ ]*\u002F\u003Centry> serve`). No shell's\n  command line starts that way.\n- **Escalate only when needed.** Try a graceful stop; if the process is already\n  wedged in shutdown (a held socket, a draining connection that never drains),\n  a graceful signal cannot work and you escalate.\n- **Confirm the port is free before starting again**, or you get a second\n  process fighting for it, or a start that silently fails.\n- **Prefer no-reload in a shared tree.** If several agents or a person edit the\n  same checkout, a file-watch reloader can be triggered by someone else's save\n  and wedge mid-restart. Autoreload is a convenience, not a substitute for\n  this skill: it is exactly what produces \"the port is bound but nothing\n  answers\".\n\n## Live is an end state\n\nThe restarted service must still be running when you hand back. Do not start\nit inside a test harness, behind a cleanup trap, or from a command whose\nenvironment reaps its children when it returns — a screenshot of a process\nthat was then stopped is not a live verification. Make the final health\nrequest in a separate command, after the restart has returned; if the\nenvironment reaps background children, start the service under the user's\nservice manager instead.\n\n## Warm-up is not readiness\n\nMany services report empty or partial subsystems for seconds after start —\nmodels load lazily, engines warm on first use, caches fill on demand. Checking\ntoo early and reporting \"the engine is empty, something is broken\" is a wrong\ndiagnosis that costs a person real time.\n\n**Wait for the subsystem to report ready before you judge it.** Poll until it\nis populated or until a timeout you state. If it is still empty at the\ntimeout, *then* it is a finding — and say how long you waited.\n\n## Write it down once\n\nIf you restart a service by hand more than once in a session, put the sequence\nin the project as a script — stop by PID, wait for the port, start, then block\nuntil the reported build equals HEAD, exiting non-zero if it does not. A script\nthat returns success while serving the wrong commit is worse than no script.\nMake the freshness assertion the thing that gates its exit code.\n\n## What to say at the end\n\n- The service, the port, and the commit it is **now** serving — with the\n  checkout's commit beside it, so the match is visible rather than claimed.\n- Any subsystem you waited for, and how long.\n- Upstreams you checked but did not restart, and who owns them.\n- Anything you could **not** verify — a page behind a login you cannot pass, a\n  client you cannot drive. Name it plainly instead of implying you saw it work.\n\nNever say \"it is live\" or \"ready to look at\" without the commit match behind\nit. If you could not verify, say what you actually did and what remains\nunproven.\n\u003C!-- agent-sync:end -->\n",{"name":5,"description":7},"main","16426a8647c4bf341798845ddf222a5b8c1ac861",".agents\u002Fskills\u002Fserve-live","https:\u002F\u002Fgithub.com\u002Fmaxjbarfuss\u002Fmax_llm","https:\u002F\u002Fgithub.com\u002Fmaxjbarfuss","https:\u002F\u002Fwww.altavega.io","Software Engineer, AI, Robotics, Systems, Full-Stack","2026-09-29 21:59:21",{"source":8,"skillName":5,"commands":53,"prompt":63,"zipAvailable":64},[54,57,60],{"tool":55,"command":56},"npx","npx skills add maxjbarfuss\u002Fmax_llm --skill serve-live",{"tool":58,"command":59},"bunx","bunx skills add maxjbarfuss\u002Fmax_llm --skill serve-live",{"tool":61,"command":62},"pnpm","pnpm dlx skills add maxjbarfuss\u002Fmax_llm --skill serve-live","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmaxjbarfuss\u002Fmax_llm\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fserve-live\u002FSKILL.md",true,[66,72,76],{"path":67,"resourceType":68,"resourceTypeDesc":69,"sizeBytes":70,"sourceHtmlUrl":71},"catalog.json","REFERENCE","参考文档",1710,"https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Ftrading\u002Fbankrbot-official-botcoin-miner\u002Fcatalog.json",{"path":73,"resourceType":68,"resourceTypeDesc":69,"sizeBytes":74,"sourceHtmlUrl":75},"SOURCE.md",317,"https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Ftrading\u002Fbankrbot-official-botcoin-miner\u002FSOURCE.md",{"path":77,"resourceType":68,"resourceTypeDesc":69,"sizeBytes":78,"sourceHtmlUrl":79},"TRUST.auto.yaml",2157,"https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Ftrading\u002Fbankrbot-official-botcoin-miner\u002FTRUST.auto.yaml",[81,98,103,117,131,146],{"skillNo":82,"name":83,"nameZh":6,"description":84,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":85,"categories":86,"keywords":87,"publishedAt":39},"01M6CR6B20826Y0PPVXJQ2D0QJ","train","Launch a new max_llm training run on both GPUs (RTX 4090 + RTX 3090 Ti) through torchrun DDP, resolving the TOML config by name or path. Use only when the user explicitly asks to start, launch or begin a run — \"resume\", \"continue\" or \"keep training\" mean the existing run; takes an optional config name or path.","https:\u002F\u002Fgithub.com\u002Fmaxjbarfuss\u002Fmax_llm\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Ftrain\u002FSKILL.md",[],[83,88,89,90,91,28,92,93,94,95,96,97],"config","max","resume","only","user","continue","start","run","training","launch",{"skillNo":99,"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":100,"categories":101,"keywords":102,"publishedAt":39},"01M6CR67YE4MW1R46KB8NV85ZT","https:\u002F\u002Fgithub.com\u002Fmaxjbarfuss\u002Fmax_llm\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fserve-live\u002FSKILL.md",[],[19,35,34,33,36,37,32,31,38,29,30,20,28,21,22,23,24,25,26,27],{"skillNo":104,"name":105,"nameZh":6,"description":106,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":107,"categories":108,"keywords":109,"publishedAt":39},"01M6CR665ZD6GG1SQKD0XS4GJS","review","Review a local change, branch, pull request, or stack for correctness, regressions, security, tests, and unnecessary complexity. Use when asked to review rather than implement.","https:\u002F\u002Fgithub.com\u002Fmaxjbarfuss\u002Fmax_llm\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Freview\u002FSKILL.md",[],[105,110,29,28,111,112,113,114,115,116],"complexity","stack","pull","pull request","implement","security","branch",{"skillNo":118,"name":119,"nameZh":6,"description":120,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":121,"categories":122,"keywords":123,"publishedAt":39},"01M6CR64DYZJFD4JM1QCKMCGFN","regression-coverage","Reshape a slow or brittle test suite around observable user journeys and published contracts. Use when pruning tests, repairing weak smoke coverage, or addressing repeated feature regressions.","https:\u002F\u002Fgithub.com\u002Fmaxjbarfuss\u002Fmax_llm\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fregression-coverage\u002FSKILL.md",[],[124,125,126,127,128,129,28,92,130],"regression","coverage","regression coverage","smoke","contracts","test suite","test",{"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":39},"01M6CR62A9C4BB3YR6XZPVBKY3","pr-babysit","Monitor selected pull requests and report or safely act on review, CI, mergeability, and stack state.","https:\u002F\u002Fgithub.com\u002Fmaxjbarfuss\u002Fmax_llm\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fpr-babysit\u002FSKILL.md",[],[138,139,140,141,142,105,143,111,144,112,145],"pr babysit","babysit","pr","monitor","pull requests","report","ci","state",{"skillNo":147,"name":148,"nameZh":6,"description":149,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":150,"categories":151,"keywords":152,"publishedAt":39},"01M6CR5ZWFQFGJ6QY17DN0Q3NF","keel","Use a project's local keel code graph to assess change impact, find callers and reuse candidates, validate a plan, or check an edit. Applies only in a repository with a .keel\u002F directory; skip it for prose-only work.","https:\u002F\u002Fgithub.com\u002Fmaxjbarfuss\u002Fmax_llm\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fkeel\u002FSKILL.md",[],[148,153,154,91,28,155,31,32,156,157,158,37,159,29,160],"find","prose","edit","plan","repository","graph","validate","directory"]