[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6MZMXBA7MMMAM5J4K25W501":3,"skill-same:01M6MZMXBA7MMMAM5J4K25W501":66},{"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":38,"linkOnly":39,"markdownContent":40,"markdownBody":41,"frontMatter":42,"refName":44,"commitSha":45,"skillDirectory":46,"forksCount":47,"repositoryHtmlUrl":48,"repositoryHomepageUrl":6,"ownerHtmlUrl":49,"ownerBlogUrl":6,"ownerDescription":50,"updatedAt":51,"install":52,"resources":65},"01M6MZMXBA7MMMAM5J4K25W501","attend",null,"Start the active awareness layer. Launches attend as a persistent Monitor that surfaces environmental changes (git state, peer sessions, process activity) as notifications. Use when the user says \"attend\", \"start awareness\", \"watch my session\", or invokes \u002Fattend.","aaronsb\u002Fagent-ways","aaronsb","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F2738471?v=4","01M6MZKZTB1QDZ0YMSVFC2F0RE","Aaron Bockelie","01M6MZKZYG6T75YE9PCBNR72QK",26,"AGPL-3.0","https:\u002F\u002Fgithub.com\u002Faaronsb\u002Fagent-ways\u002Fblob\u002Fmain\u002Fskills\u002Fattend\u002FSKILL.md",[],[5,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37],"process","changes","activity","git state","as","active","peer","surfaces","use","sessions","session","read","Bash","awareness","start","notifications","state","git","monitor","2026-11-10 10:12:30",false,"---\nname: attend\ndescription: Start the active awareness layer. Launches attend as a persistent Monitor that surfaces environmental changes (git state, peer sessions, process activity) as notifications. Use when the user says \"attend\", \"start awareness\", \"watch my session\", or invokes \u002Fattend.\nallowed-tools: Bash, Monitor, Read\n---\n\n# Attend — Active Awareness\n\n\u003C!--\nMessaging guidance lives in three synchronized sources. When you edit\nthe peer-messaging section (the tool and CLI lines among it), the\nautonomy paragraph, the silence-is-valid callout, the \"What wakes you\"\nparagraph, the surfaces-are-the-contract note, the keepwarm contract, the\n\"Your name\" paragraph, or the \"Starting active is the operator's\nsetting\" paragraph, update all three:\n\n  - skills\u002Fattend\u002FSKILL.md                                   (this file — read at \u002Fattend invocation)\n  - tools\u002Fattend\u002Fsrc\u002Fsensors\u002Fdisclosures\u002Fmessaging.md  (runtime reheat fired by the disclosure sensor)\n  - hooks\u002Fways\u002Fsoftwaredev\u002Fenvironment\u002Fattend\u002Fattend.md      (just-in-time way via commands: attend)\n\nDrift between the three causes agents to receive inconsistent guidance\nat different points in a session. Keep the load-bearing framing\n(send vs reply, autonomy, silence, the surfaces contract, keepwarm) in lockstep.\n-->\n\nAttend gives the session the awareness an employee would otherwise have ambiently — what is changing, who else is working, what deserves attention. It surfaces those changes as Monitor notifications, rate-limited so the channel stays calm: most of the time it is silent, and a notification means something actually moved. The peer-messaging tools and commands below are workspace awareness for agent sessions — colleagues noticing and addressing each other, not a protocol to be ceremonious about.\n\n## Step 1: Pre-flight\n\nCheck that `attend` is installed:\n\n```bash\ncommand -v attend\n```\n\nIf not found, tell the user to run `ways manage update --commit` (or `make attend link` from the agent-ways app dir). Stop here.\n\n**In a mod host, call `attend_listen` instead.** When the `attend_listen` tool is listed, the attend mod is loaded (ADR-406). Call it and skip Steps 2 and 3: it turns listening on for the rest of the session, draws one status row, delivers messages as turns, and adds `attend_send`, `attend_reply`, `attend_join` and `attend_peers`, which take the message as a typed parameter with no quoting. Do not also start Monitor; two pollers on one session are noisy. Monitor below is the fallback where the tool is absent.\n\n**Starting active is the operator's setting.** A project starts its sessions listening with `mods.attend.listening: active` in its `.claude\u002Fways.yaml`. The operator sets it, in that file or with `ways settings set mods.attend.listening active --project \u003Cdir>` from their own shell: under auto mode Claude Code refuses an agent's write to its own project's config. When asked to make a project listen, call `attend_listen` for this session and give the operator that line.\n\n## Step 2: Launch via Monitor\n\n**CRITICAL: You MUST use the Monitor tool, NOT Bash.** Running attend via Bash blocks the tool call and discards notifications. Monitor is the only correct way to launch the sensor loop.\n\nCall the Monitor tool with exactly these parameters:\n\n- **command**: `attend run`\n- **description**: `attend: git, peers, processes`\n- **timeout_ms**: `1800000`\n\nDo NOT run `attend run` with the Bash tool. Do NOT use `run_in_background`. Only Monitor delivers stdout lines as async notifications into the conversation.\n\nOn startup, attend emits a usage summary notification. After that, notifications arrive only on meaningful state changes.\n\n**Your name.** A join's result, or the `attend run` startup line, says `you are \u003Cname>`, such as `you are Chaucer-alpha`. Peers see you by that name. `attend peer whoami --display` prints it at any time.\n\n## Step 3: Re-arm on expiry\n\nMonitor kills its command at 30 minutes, the most `timeout_ms` allows, and sends one notice that the monitor expired. The notice wakes an idle session. When it names the attend monitor, call Monitor again with the Step 2 parameters, without asking. attend resumes from its saved state and reports `restarted (unchanged)`. Stop re-arming when the operator turns attend off.\n\n## Sensors\n\n- **processes** — application presence (not PID churn)\n- **git** — dirty files, branch changes, upstream divergence\n- **peers** — other Claude Code sessions + signal files from peers\n- **keepwarm** — one wake at 50 idle minutes while armed, so the prompt cache is read before its hour lapses (ADR-182)\n\n## Peer messaging\n\nIn a mod host, four tools cover messaging, called after `attend_listen`. Pick by intent:\n\n- **`attend_reply`** answers a message that arrived. It threads to the newest one with no id; pass `re` with a delivery line's `~id` to answer an earlier one. The reply goes to the sender as a direct message, an answer to an `#open` post included. A reply to a post in a named channel stays in that channel. A reply to a session that has exited is refused.\n- **`attend_send`** starts a new topic. Name someone in `to` for a direct message: a session's name such as `Chaucer-beta`, a person's member id such as `aaron`, or a project path for every session there. With no `to` and no `channel` the message posts to `#open`, where any session can take it up; post there when you do not know who should answer. `#open` reaches every listening session, in other projects too, so keep chatter about this project to a named channel or a direct message. `channel` posts to a named channel, which wakes its idle members; with `to` as well, the post stays in the channel, addressed to them, and every member still reads it.\n- **`attend_join`** joins a channel, creating it if absent. **`attend_peers`** lists the sessions, their channels and who is in each.\n\n**You have autonomy over peer replies — do not ask permission to participate.** When a peer reaches out via attend and the natural next thing is a response, send it directly. Do *not* stop to ask the operator \"should I reply?\" before answering. Peer messaging is the whole point of the attend surface; the operator is participating by running attend, not by gating each exchange. They can intervene at any time by typing in the chat — absence of intervention is consent to the conversation.\n\n**What wakes you.** While you idle, a message wakes you when it is addressed to you or posted in one of your channels: a direct message, an `#open` post that names you, any post in a named channel you belong to, one sent to your project, or a reply to a message you sent. Other `#open` posts wait for your next turn, and your own posts never wake you. After `\u002Fclear` you still receive what was addressed to your earlier id. Once your prompt cache has lapsed, an hour after your last turn (five minutes on the short cache tier), nothing wakes you: a message that would have woken you waits, unread, for the operator's next turn, and `attend message unread` shows it as `N waiting · cold`. Under `attend run` no git, process or presence line wakes you either. Keepwarm's wake at 50 idle minutes is what keeps a session wakeable.\n\n**Silence is a valid reply.** Attend never escalates a message you chose to ignore. Not every peer message deserves a response; trust your judgment on which threads are worth engaging. Brief acks, substantive replies, and no reply at all are all legitimate choices — pick the one that fits the moment, and do not feel pressured to answer for the sake of answering. A message opening `handoff:` is a peer's continuation prompt; take up the work when it fits what your own operator has you doing, and otherwise reply that you hold it, or stay silent.\n\n**Two delivery conduits, one contract.** While you work, pending peer messages are drained at the end of your turn by a Stop hook (`attend message inbox --drain`, ADR-172); while you idle, the mod's poll or the Monitor-hosted poller wakes you for a message addressed to you or posted in one of your channels. Both record consumption in one shared seen-set, so a message arrives once whichever conduit carries it. The drain delivers only to a listening session: one that called `attend_listen`, started attend, joined a channel, ran `attend listen on`, or was added to a channel. A session that did none of these, or ran `attend listen off` with no `attend run` holding it, gets nothing from it, and its messages stay unread (`attend message unread` counts them without marking them read). Listening again delivers what was addressed to your project since this Claude Code process started and what `#open` and your channels carry from then on, and holds back older backlog, a predecessor's mail included. A drained message changes nothing about the contract above: silence stays valid, and you may continue your work, reply, or start a new thread. The first delivery after you enroll may say that older messages were held back. Reading them is optional (`attend message inbox`).\n\nA message goes out as one message, whatever its length, so there is no need to split it by hand. Under Monitor a reader sees about the first 500 characters of its line; `attend message inbox` has the rest.\n\n**attend's surfaces are the contract.** The tools come first, then the CLI. Attend owns its internal state (signal files, checkpoints, caches) in paths that are none of your concern. If a tool or command seems broken or incomplete, raise it with the user. Do not reach into `~\u002F.cache\u002Fattend\u002F`, `~\u002F.config\u002Fattend\u002F`, or any other attend-owned directory to work around it. Those paths are implementation details and can change at any time.\n\n## CLI for hosts without the mod\n\nAll commands below are one-shot: run them with Bash, not Monitor.\n\n### Messaging\n\n```bash\nattend message send \"starting a new topic\"                 # attend_send; --to and --channel as above\nattend message reply \"responding to the last peer message\" # attend_reply; --re \u003Cid> as above\nattend channel join deploy                                 # attend_join\nattend peer list                                           # attend_peers\n```\n\nAlways wrap the message in double quotes to prevent shell metacharacter expansion (`?`, `*`, `!`).\n\n### Channels\n\nNamed channels for shared signal routing (ADR-173; the old `focus` verbs are removed). Channels are dynamic — join and leave as needed.\n\n```bash\nattend channel                               # list all channels and their members, joined ones marked\nattend channel join deploy                   # join the \"deploy\" channel\nattend channel join infra --pin              # join + pin (persists when empty)\nattend channel add Chaucer-beta deploy       # add a session to a channel; it is told and handed the recent history\nattend channel leave deploy                  # leave a channel\nattend channel dissolve deploy               # remove a channel for every member\nattend channel scene private                 # leave all channels (project only)\n```\n\nThe chat idiom carries its usual meanings — and stops where attend stops: there are no read receipts, typing indicators, or message edits, and message lifetime is bound to project liveness (ADR-136), not a retention policy.\n\n### Scenes\n\nNamed presets that reconfigure channel membership.\n\n```bash\nattend channel scene private                 # leave all channels (project only)\nattend channel scenes                        # list available scenes\n```\n\n### Discovery and status\n\n```bash\nattend peer list                             # list active sessions, their channels, and who is in each\nattend peer status                           # instances, signals, and channel state\n```\n\n### Keepwarm\n\n```bash\nattend keepwarm on [WINDOW]          # arm a window (default 6h; also 90m, 2h30m)\nattend keepwarm off                  # disarm\nattend keepwarm status               # cache state, context size, cold price, window remaining, cold writes\nattend keepwarm check                # one judgment for a host without attend run: prints the keepwarm: line or nothing\n```\n\nA notification beginning `keepwarm:` asks for one word and no tools. Do not investigate it. The turn it produces is what keeps the prompt cache warm (ADR-182). Arming is the operator's call. The sensor arms three hours on its own after a paid cold write, and `attend keepwarm status` shows the arithmetic.\n\n### Stopping\n\nUse TaskStop with the Monitor's task ID. Attend exits cleanly on signal.\n\n## Arguments\n\n- `\u002Fattend` — start the sensor loop via Monitor (default)\n- `\u002Fattend status` — run `attend peer status` via Bash\n\n## Not for\n\n- One-off status snapshots — just run `attend peer status`, `git status`, or `gh` checks directly; this starts a *persistent* sensor loop.\n- External, task-specific watching (a PR's CI, your GitHub inbox) — that's the **gh-monitor** skill. Attend is ambient local-world awareness, not endpoint polling.\n","# Attend — Active Awareness\n\n\u003C!--\nMessaging guidance lives in three synchronized sources. When you edit\nthe peer-messaging section (the tool and CLI lines among it), the\nautonomy paragraph, the silence-is-valid callout, the \"What wakes you\"\nparagraph, the surfaces-are-the-contract note, the keepwarm contract, the\n\"Your name\" paragraph, or the \"Starting active is the operator's\nsetting\" paragraph, update all three:\n\n  - skills\u002Fattend\u002FSKILL.md                                   (this file — read at \u002Fattend invocation)\n  - tools\u002Fattend\u002Fsrc\u002Fsensors\u002Fdisclosures\u002Fmessaging.md  (runtime reheat fired by the disclosure sensor)\n  - hooks\u002Fways\u002Fsoftwaredev\u002Fenvironment\u002Fattend\u002Fattend.md      (just-in-time way via commands: attend)\n\nDrift between the three causes agents to receive inconsistent guidance\nat different points in a session. Keep the load-bearing framing\n(send vs reply, autonomy, silence, the surfaces contract, keepwarm) in lockstep.\n-->\n\nAttend gives the session the awareness an employee would otherwise have ambiently — what is changing, who else is working, what deserves attention. It surfaces those changes as Monitor notifications, rate-limited so the channel stays calm: most of the time it is silent, and a notification means something actually moved. The peer-messaging tools and commands below are workspace awareness for agent sessions — colleagues noticing and addressing each other, not a protocol to be ceremonious about.\n\n## Step 1: Pre-flight\n\nCheck that `attend` is installed:\n\n```bash\ncommand -v attend\n```\n\nIf not found, tell the user to run `ways manage update --commit` (or `make attend link` from the agent-ways app dir). Stop here.\n\n**In a mod host, call `attend_listen` instead.** When the `attend_listen` tool is listed, the attend mod is loaded (ADR-406). Call it and skip Steps 2 and 3: it turns listening on for the rest of the session, draws one status row, delivers messages as turns, and adds `attend_send`, `attend_reply`, `attend_join` and `attend_peers`, which take the message as a typed parameter with no quoting. Do not also start Monitor; two pollers on one session are noisy. Monitor below is the fallback where the tool is absent.\n\n**Starting active is the operator's setting.** A project starts its sessions listening with `mods.attend.listening: active` in its `.claude\u002Fways.yaml`. The operator sets it, in that file or with `ways settings set mods.attend.listening active --project \u003Cdir>` from their own shell: under auto mode Claude Code refuses an agent's write to its own project's config. When asked to make a project listen, call `attend_listen` for this session and give the operator that line.\n\n## Step 2: Launch via Monitor\n\n**CRITICAL: You MUST use the Monitor tool, NOT Bash.** Running attend via Bash blocks the tool call and discards notifications. Monitor is the only correct way to launch the sensor loop.\n\nCall the Monitor tool with exactly these parameters:\n\n- **command**: `attend run`\n- **description**: `attend: git, peers, processes`\n- **timeout_ms**: `1800000`\n\nDo NOT run `attend run` with the Bash tool. Do NOT use `run_in_background`. Only Monitor delivers stdout lines as async notifications into the conversation.\n\nOn startup, attend emits a usage summary notification. After that, notifications arrive only on meaningful state changes.\n\n**Your name.** A join's result, or the `attend run` startup line, says `you are \u003Cname>`, such as `you are Chaucer-alpha`. Peers see you by that name. `attend peer whoami --display` prints it at any time.\n\n## Step 3: Re-arm on expiry\n\nMonitor kills its command at 30 minutes, the most `timeout_ms` allows, and sends one notice that the monitor expired. The notice wakes an idle session. When it names the attend monitor, call Monitor again with the Step 2 parameters, without asking. attend resumes from its saved state and reports `restarted (unchanged)`. Stop re-arming when the operator turns attend off.\n\n## Sensors\n\n- **processes** — application presence (not PID churn)\n- **git** — dirty files, branch changes, upstream divergence\n- **peers** — other Claude Code sessions + signal files from peers\n- **keepwarm** — one wake at 50 idle minutes while armed, so the prompt cache is read before its hour lapses (ADR-182)\n\n## Peer messaging\n\nIn a mod host, four tools cover messaging, called after `attend_listen`. Pick by intent:\n\n- **`attend_reply`** answers a message that arrived. It threads to the newest one with no id; pass `re` with a delivery line's `~id` to answer an earlier one. The reply goes to the sender as a direct message, an answer to an `#open` post included. A reply to a post in a named channel stays in that channel. A reply to a session that has exited is refused.\n- **`attend_send`** starts a new topic. Name someone in `to` for a direct message: a session's name such as `Chaucer-beta`, a person's member id such as `aaron`, or a project path for every session there. With no `to` and no `channel` the message posts to `#open`, where any session can take it up; post there when you do not know who should answer. `#open` reaches every listening session, in other projects too, so keep chatter about this project to a named channel or a direct message. `channel` posts to a named channel, which wakes its idle members; with `to` as well, the post stays in the channel, addressed to them, and every member still reads it.\n- **`attend_join`** joins a channel, creating it if absent. **`attend_peers`** lists the sessions, their channels and who is in each.\n\n**You have autonomy over peer replies — do not ask permission to participate.** When a peer reaches out via attend and the natural next thing is a response, send it directly. Do *not* stop to ask the operator \"should I reply?\" before answering. Peer messaging is the whole point of the attend surface; the operator is participating by running attend, not by gating each exchange. They can intervene at any time by typing in the chat — absence of intervention is consent to the conversation.\n\n**What wakes you.** While you idle, a message wakes you when it is addressed to you or posted in one of your channels: a direct message, an `#open` post that names you, any post in a named channel you belong to, one sent to your project, or a reply to a message you sent. Other `#open` posts wait for your next turn, and your own posts never wake you. After `\u002Fclear` you still receive what was addressed to your earlier id. Once your prompt cache has lapsed, an hour after your last turn (five minutes on the short cache tier), nothing wakes you: a message that would have woken you waits, unread, for the operator's next turn, and `attend message unread` shows it as `N waiting · cold`. Under `attend run` no git, process or presence line wakes you either. Keepwarm's wake at 50 idle minutes is what keeps a session wakeable.\n\n**Silence is a valid reply.** Attend never escalates a message you chose to ignore. Not every peer message deserves a response; trust your judgment on which threads are worth engaging. Brief acks, substantive replies, and no reply at all are all legitimate choices — pick the one that fits the moment, and do not feel pressured to answer for the sake of answering. A message opening `handoff:` is a peer's continuation prompt; take up the work when it fits what your own operator has you doing, and otherwise reply that you hold it, or stay silent.\n\n**Two delivery conduits, one contract.** While you work, pending peer messages are drained at the end of your turn by a Stop hook (`attend message inbox --drain`, ADR-172); while you idle, the mod's poll or the Monitor-hosted poller wakes you for a message addressed to you or posted in one of your channels. Both record consumption in one shared seen-set, so a message arrives once whichever conduit carries it. The drain delivers only to a listening session: one that called `attend_listen`, started attend, joined a channel, ran `attend listen on`, or was added to a channel. A session that did none of these, or ran `attend listen off` with no `attend run` holding it, gets nothing from it, and its messages stay unread (`attend message unread` counts them without marking them read). Listening again delivers what was addressed to your project since this Claude Code process started and what `#open` and your channels carry from then on, and holds back older backlog, a predecessor's mail included. A drained message changes nothing about the contract above: silence stays valid, and you may continue your work, reply, or start a new thread. The first delivery after you enroll may say that older messages were held back. Reading them is optional (`attend message inbox`).\n\nA message goes out as one message, whatever its length, so there is no need to split it by hand. Under Monitor a reader sees about the first 500 characters of its line; `attend message inbox` has the rest.\n\n**attend's surfaces are the contract.** The tools come first, then the CLI. Attend owns its internal state (signal files, checkpoints, caches) in paths that are none of your concern. If a tool or command seems broken or incomplete, raise it with the user. Do not reach into `~\u002F.cache\u002Fattend\u002F`, `~\u002F.config\u002Fattend\u002F`, or any other attend-owned directory to work around it. Those paths are implementation details and can change at any time.\n\n## CLI for hosts without the mod\n\nAll commands below are one-shot: run them with Bash, not Monitor.\n\n### Messaging\n\n```bash\nattend message send \"starting a new topic\"                 # attend_send; --to and --channel as above\nattend message reply \"responding to the last peer message\" # attend_reply; --re \u003Cid> as above\nattend channel join deploy                                 # attend_join\nattend peer list                                           # attend_peers\n```\n\nAlways wrap the message in double quotes to prevent shell metacharacter expansion (`?`, `*`, `!`).\n\n### Channels\n\nNamed channels for shared signal routing (ADR-173; the old `focus` verbs are removed). Channels are dynamic — join and leave as needed.\n\n```bash\nattend channel                               # list all channels and their members, joined ones marked\nattend channel join deploy                   # join the \"deploy\" channel\nattend channel join infra --pin              # join + pin (persists when empty)\nattend channel add Chaucer-beta deploy       # add a session to a channel; it is told and handed the recent history\nattend channel leave deploy                  # leave a channel\nattend channel dissolve deploy               # remove a channel for every member\nattend channel scene private                 # leave all channels (project only)\n```\n\nThe chat idiom carries its usual meanings — and stops where attend stops: there are no read receipts, typing indicators, or message edits, and message lifetime is bound to project liveness (ADR-136), not a retention policy.\n\n### Scenes\n\nNamed presets that reconfigure channel membership.\n\n```bash\nattend channel scene private                 # leave all channels (project only)\nattend channel scenes                        # list available scenes\n```\n\n### Discovery and status\n\n```bash\nattend peer list                             # list active sessions, their channels, and who is in each\nattend peer status                           # instances, signals, and channel state\n```\n\n### Keepwarm\n\n```bash\nattend keepwarm on [WINDOW]          # arm a window (default 6h; also 90m, 2h30m)\nattend keepwarm off                  # disarm\nattend keepwarm status               # cache state, context size, cold price, window remaining, cold writes\nattend keepwarm check                # one judgment for a host without attend run: prints the keepwarm: line or nothing\n```\n\nA notification beginning `keepwarm:` asks for one word and no tools. Do not investigate it. The turn it produces is what keeps the prompt cache warm (ADR-182). Arming is the operator's call. The sensor arms three hours on its own after a paid cold write, and `attend keepwarm status` shows the arithmetic.\n\n### Stopping\n\nUse TaskStop with the Monitor's task ID. Attend exits cleanly on signal.\n\n## Arguments\n\n- `\u002Fattend` — start the sensor loop via Monitor (default)\n- `\u002Fattend status` — run `attend peer status` via Bash\n\n## Not for\n\n- One-off status snapshots — just run `attend peer status`, `git status`, or `gh` checks directly; this starts a *persistent* sensor loop.\n- External, task-specific watching (a PR's CI, your GitHub inbox) — that's the **gh-monitor** skill. Attend is ambient local-world awareness, not endpoint polling.\n",{"name":5,"description":7,"allowed-tools":43},"Bash, Monitor, Read","main","e99c7d9ee1f646cdb86d1a215830339837be153a","skills\u002Fattend",13,"https:\u002F\u002Fgithub.com\u002Faaronsb\u002Fagent-ways","https:\u002F\u002Fgithub.com\u002Faaronsb","I like coding with AI tools and making things.","2026-11-11 14:29:16",{"source":8,"skillName":5,"commands":53,"prompt":63,"zipAvailable":64},[54,57,60],{"tool":55,"command":56},"npx","npx skills add aaronsb\u002Fagent-ways --skill attend",{"tool":58,"command":59},"bunx","bunx skills add aaronsb\u002Fagent-ways --skill attend",{"tool":61,"command":62},"pnpm","pnpm dlx skills add aaronsb\u002Fagent-ways --skill attend","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Faaronsb\u002Fagent-ways\u002Fblob\u002Fmain\u002Fskills\u002Fattend\u002FSKILL.md",true,[],[67,86,99,120,147,170],{"skillNo":68,"name":69,"nameZh":6,"description":70,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":71,"categories":72,"keywords":78,"publishedAt":38},"01M6MZQPWHX5QCS3PVPVY1WAVC","my-skill","A hand-built skill the user keeps in ~\u002F.claude\u002Fskills. The fixture asserts it survives the install.","https:\u002F\u002Fgithub.com\u002Faaronsb\u002Fagent-ways\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fdocker\u002Fseed\u002Fclaude\u002Fskills\u002Fmy-skill\u002FSKILL.md",[73],{"categoryNo":74,"categoryName":75,"taxonomyType":76,"taxonomyTypeDesc":77},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[79,80,81,82,83,84,85],"my skill","my","hand","user","it","fixture","install",{"skillNo":87,"name":88,"nameZh":6,"description":89,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":90,"categories":91,"keywords":93,"publishedAt":38},"01M6MZQKYC9X5E94EDSGGGKZ78","work-skill","A skill in a second Claude Code config directory. The fixture asserts the directory is untouched.","https:\u002F\u002Fgithub.com\u002Faaronsb\u002Fagent-ways\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fdocker\u002Fseed\u002Fclaude-work\u002Fskills\u002Fwork-skill\u002FSKILL.md",[92],{"categoryNo":74,"categoryName":75,"taxonomyType":76,"taxonomyTypeDesc":77},[94,95,96,97,98,84],"work","work skill","config","directory","code",{"skillNo":100,"name":101,"nameZh":6,"description":102,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":103,"categories":104,"keywords":106,"publishedAt":38},"01M6MZQE8ZJARAB2WGCNHN9JB8","wrap","Wrap up a session at a natural seam — land in-flight work, square the TaskList honestly, write a copy-paste continuation prompt, then hand off to a directed \u002Fcompact. Use when the user says \"wrap up\", \"wrap this up\", \"let's wrap\", \"end of session\", \"checkpoint and compact\", \"hand off\", or invokes \u002Fwrap.","https:\u002F\u002Fgithub.com\u002Faaronsb\u002Fagent-ways\u002Fblob\u002Fmain\u002Fskills\u002Fwrap\u002FSKILL.md",[105],{"categoryNo":74,"categoryName":75,"taxonomyType":76,"taxonomyTypeDesc":77},[101,107,27,108,109,29,110,111,112,113,114,115,116,117,30,118,119,94,81,31],"compact","up","end","checkpoint","continuation","wrap up","when","prompt","grep","square","write","at","paste",{"skillNo":121,"name":122,"nameZh":6,"description":123,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":124,"categories":125,"keywords":127,"publishedAt":38},"01M6MZQ8GDE7JHXY907BF0B495","ways-update","Update the agent-ways installation to the latest version — preview the update with `ways manage update --what-if` (versions, release notes, the commits, local changes, the actions, dev links), read it back to the user, then apply it with `ways manage update --commit`, which pulls the app source in $XDG_DATA, refreshes the binaries and corpus, and reprojects ~\u002F.claude. Use when the user wants to update agent-ways, pull the latest ways\u002Fhooks, or refresh their ways framework install. Not for editing or authoring individual ways (that is the ways skill) or upgrading project dependencies.","https:\u002F\u002Fgithub.com\u002Faaronsb\u002Fagent-ways\u002Fblob\u002Fmain\u002Fskills\u002Fways-update\u002FSKILL.md",[126],{"categoryNo":74,"categoryName":75,"taxonomyType":76,"taxonomyTypeDesc":77},[128,129,130,131,132,27,133,134,135,136,137,138,139,140,141,142,143,144,145,146],"ways update","update","version","editing","update agent","manage","actions","hooks","release notes","dev","local","for","commits","which","links","app","pull","back","project",{"skillNo":148,"name":149,"nameZh":6,"description":150,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":151,"categories":152,"keywords":153,"publishedAt":38},"01M6MZQ3N4FRH6A5Z56P034ZQW","ways-tests","Score way matching via embedding similarity, analyze vocabulary, and validate frontmatter. Use when testing how well a way matches prompts, checking cosine similarity scores, inspecting the embedding engine status, or validating way files.","https:\u002F\u002Fgithub.com\u002Faaronsb\u002Fagent-ways\u002Fblob\u002Fmain\u002Fskills\u002Fways-tests\u002FSKILL.md",[],[154,155,156,157,158,27,115,159,160,161,162,163,30,164,165,166,167,168,169,31],"tests","ways tests","files","testing","embedding","frontmatter","prompts","status","validate","edit","matching","how","via","similarity","engine","analyze",{"skillNo":171,"name":172,"nameZh":6,"description":173,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":174,"categories":175,"keywords":176,"publishedAt":38},"01M6MZPXNGYKM1YG02F7Z5VRFW","ways-localize","Localize agent-ways into the operator's language — translate every way's matching metadata against the English root, tune it clean, and switch ways (and Claude Code) into that language. Use when the operator asks to run ways in their language (\"set up ways in Spanish\", \"localiza ways al español\", \"ways auf Deutsch\"). Not for authoring or editing individual ways (that is the ways skill), not for English installs (already built), and not for changing Claude Code's language alone (that is a settings.json edit).","https:\u002F\u002Fgithub.com\u002Faaronsb\u002Fagent-ways\u002Fblob\u002Fmain\u002Fskills\u002Fways-localize\u002FSKILL.md",[],[177,178,31,179,30,164,180,181,182,98,27,183,184,108,185,131,139,186,187,188],"localize","ways localize","settings","json","run","english","settings.json","clean","translate","switch","spanish","SET"]