export declare const SKILL_MD = "---\nname: auden\ndescription: >-\n  Invoke when the user asks about Auden, evaluation results, or what happened\n  in the last session. Surfaces the current guide cache and pending guide\n  suggestions, and explains where a session's verdicts come from. Do NOT call\n  this automatically before or after actions \u2014 Auden evaluates sessions\n  post-hoc; guides already flow into the agent's context via AGENTS.md and\n  CLAUDE.md.\nuser-invocable: true\n---\n\n# Auden\n\nAuden records what an agent did and has the dashboard grade it. The `auden init` hooks do the recording: a PostToolUse hook logs each tool call locally, a Stop hook runs `auden sync` to upload them, and a SessionEnd hook tells the dashboard the run is over. The dashboard then grades the whole run **once**, against the guides that were actually in the agent's context, and the verdicts appear on the run in your dashboard.\n\nThe CLI does not grade. It has no LLM provider, no API key, and records no verdict of its own \u2014 a verdict comes from one place, so there is only ever one answer to compare against.\n\n## When To Invoke This Skill\n\nOnly when the user explicitly asks. Examples:\n\n- \"What did Auden say about the last session?\"\n- \"Show me the active guides\"\n- \"Did the agent follow the guides?\"\n- \"Run auden suggest\"\n\nFor verdicts on a specific session, point the user at the dashboard \u2014 that is where grading happens and where the result lives.\n\nDo NOT call `auden` commands during normal task execution. Guides already reach you through `AGENTS.md` / `CLAUDE.md` / `.cursorrules` \u2014 Auden's job is to evaluate what happened afterwards, not to gate each action.\n\n## Commands\n\n### `auden guides active`\n\nLists all currently enabled guides for this project, read from the local cache.\n\n```bash\nauden guides active\n```\n\n### `auden guides search <query>`\n\nSearches active guides by keyword.\n\n```bash\nauden guides search \"TypeScript\"\nauden guides search \"testing\"\n```\n\n### `auden suggest`\n\nSurfaces guide suggestions extracted from recent session history.\n\n```bash\nauden suggest\n```\n\n### `auden sync`\n\nUploads the session's logged actions and extracted guide/skill suggestions to the dashboard, and pulls the latest guide bundle. This is what gives the dashboard something to grade; it runs automatically from the Stop and SessionEnd hooks.\n\n```bash\nauden sync\n```\n\n## Notes\n\n- Guides are cached in `~/.auden/guides.json` after `auden sync`. `guides active` and `guides search` read from cache \u2014 no network requests.\n- Actions are logged to `~/.auden/runs/<session>.jsonl` by the PostToolUse hook and uploaded by `auden sync`; `auden status` shows how many are still pending.\n- Verdicts are the dashboard's. To correct one, override it on the action's detail screen \u2014 an override survives re-grading, which a locally-recorded verdict never did.\n";
export declare const AUDEN_CONTEXT_SKILL_MD = "---\nname: auden-context\ndescription: >-\n  Use when the user refers to their notes, context, inbox, or bundles saved in\n  Auden \u2014 e.g. \"pull my notes from Auden\", \"what's in my inbox\", \"save this to\n  my context\", \"sync this back\". Reads and writes the Auden context layer over\n  the Auden MCP server so context follows the user across every repo and agent.\nuser-invocable: true\n---\n\n# Auden Context\n\nAuden's context layer is a portable store of the user's canonical documents,\nnotes, and reference material. It lives on the Auden dashboard and is reachable\nfrom any repo through the **Auden MCP server** (`auden mcp`, configured once per\nagent). Items are *canonical, not copies*: a document can belong to many bundles,\nand editing it once propagates the change everywhere it is a member. Plain\nMarkdown/text is the source of truth.\n\nTwo surfaces sit on top of it:\n\n- **Bundles** \u2014 named collections (`notes`, `travel-log`, \u2026) you pull scoped\n  context from and push canonical results into.\n- **Inbox** \u2014 not a bundle but a view: the user's recent captures that have not\n  been filed into a bundle or archived (from the phone, the app, or a share\n  sheet). Agents pull recent inbox items, transform them, and archive what they\n  consumed. Filing an item into a bundle is what takes it out of the inbox.\n\n## When To Use\n\nInvoke when the user references their own saved context, for example:\n\n- \"Pull my notes from the last day and summarize them.\"\n- \"What context do I have on <topic>?\" / \"Search my Auden bundles for <x>.\"\n- \"Save this document to my `notes` bundle.\" / \"Sync this back to Auden.\"\n- \"Clear my inbox once you've used it.\"\n\nDo NOT use it for guide/verdict inspection \u2014 that is the `auden` skill. This\nskill is about reading and writing *context*, not evaluating sessions.\n\n## Tools (Auden MCP server)\n\nIf these tools are missing, the Auden MCP server is not configured. Tell the user\nto run `auden mcp` and add it to their agent's MCP config (`.mcp.json` / Claude\nCode / Cursor). `auden mcp --read-only` disables the write tools; `auden mcp\n--bundles a,b` restricts which bundles are visible.\n\n| Tool | Input | Use |\n|---|---|---|\n| `list_bundles` | `{}` | Discover which bundles exist before pulling or pushing. |\n| `create_bundle` | `{ name, slug? }` | Create a bundle so context can be separated by project or topic. The slug is derived from `name` unless you pass one; it is what every other tool (and `auden pull <bundle>`) addresses. |\n| `pull_context` | `{ bundle, query?, types?, limit?, writeToDir? }` | Pull *scoped* items from a bundle. Filter with `types` (`document`/`reference`/`asset`/`guide`), a `query` substring, and `limit`. Pass `writeToDir` to also write each item to disk. |\n| `push_context` | `{ bundle, name, content, contentType?, itemId?, origin?, sourceItemIds? }` | Push a canonical item. Omit `itemId` to create; pass `itemId` to update in place (propagates to every bundle it belongs to). `contentType` defaults to `document`. When the item was produced from other context items, cite their ids as `sourceItemIds`. |\n| `file_context` | `{ itemId, itemType?, addTo?, removeFrom? }` | File an item that **already exists** into bundles, and/or remove it from bundles. Membership is by reference, so one item can sit in several bundles and an edit propagates to all of them. Moving out of the inbox is just `addTo: [\"<target>\"]` \u2014 the inbox is a view of unfiled notes, so filing one is what removes it. Detaching never deletes the item. |\n| `list_inbox` | `{ since?, types? }` | List unarchived inbox items. `since` takes an ISO timestamp or a relative window (`\"24h\"`, `\"7d\"`, `\"30m\"`). |\n| `pull_inbox` | `{ since?, types?, writeToDir? }` | Like `list_inbox` but also supports `writeToDir` \u2014 the round-trip entry point. |\n| `archive_inbox` | `{ ids }` | Archive inbox items once consumed so they drop out of future pulls (reversible on the dashboard). |\n\n## How To Use It Well\n\n- **Pull scoped, not everything.** Reach for `query`/`types`/`limit` so you only\n  load what the task needs \u2014 the context layer can be large.\n- **Pushes are canonical and cross-repo.** A pushed document is visible from every\n  other repo, so name it clearly and target the right bundle. When refining\n  something you pulled, pass its `itemId` to `push_context` to update it in place\n  rather than creating a duplicate.\n- **Close the loop on the inbox.** After you turn inbox items into a saved\n  document, call `archive_inbox` with the ids you consumed so the user's inbox\n  reflects that they were processed.\n- **File, don't archive, when the item should live on.** `archive_inbox` means\n  \"this item is gone, everywhere\" \u2014 it hides the item from *every* bundle and\n  from every subscribed repo. To move a capture out of the inbox and into a\n  project, use `file_context` with `addTo` alone: the inbox is a view of your\n  unfiled notes, so filing one anywhere is what removes it from the inbox, and\n  the item stays live where you filed it.\n- **Inbox access is a separate grant.** A server started with an explicit\n  `--bundles` allowlist reaches the inbox only when that list contains the\n  token `@inbox` (an `@` cannot be a bundle slug, so allowlisting a *bundle*\n  named `inbox` never grants the personal inbox by accident). No allowlist\n  means no restriction, as before. If `list_inbox` reports the inbox is not\n  allowlisted, that is the flag to add \u2014 not a reason to work around it.\n- **Archive and file are independent \u2014 there is no ordering to remember.**\n  `archive_inbox` acts on any note you own, wherever it currently sits, so\n  filing something into a project first does not put it beyond reach. Archive\n  when the capture was consumed and should disappear; file when it should live\n  on somewhere; do either in whichever order suits the work.\n- **Cite your sources when transforming.** When a pushed document was produced\n  from other context items (inbox captures, bundle items), pass their ids as\n  `sourceItemIds` on `push_context`. The citation is optional provenance \u2014\n  it records where the document came from and is stored on the item. Cite them\n  again when you update the document from a new source set; an update replaces\n  the stored ids.\n- **Preserve the user's facts.** These are the user's own notes \u2014 never drop or\n  invent detail when you restructure them.\n";
export declare const AUDEN_CLI_SKILL_MD = "---\nname: auden-cli\ndescription: >-\n  Use when the user wants their Auden notes, inbox items, or context bundles\n  from the terminal \u2014 \"pull my notes with the CLI\", \"what's in my inbox\" when\n  the Auden MCP tools are missing, \"refresh the context in this repo\". Covers\n  `auden pull`, `auden sync`, and how bundles land on disk. For MCP-based\n  context read/write use the `auden-context` skill; for guides and\n  grading results use the `auden` skill.\nuser-invocable: true\n---\n\n# Auden CLI\n\nThe `auden` CLI is the terminal path to Auden's context layer. It reads the same\ndashboard REST API the MCP server does, so a repo with no MCP wiring can still\npull the user's notes, bundles, and inbox onto disk.\n\n**Reach for this skill when the MCP tools aren't there.** The `auden-context`\nskill assumes `list_inbox` / `pull_context` / `push_context` are available; when\nthey are not, its advice dead-ends at \"configure `auden mcp`\". The CLI works\ntoday, with gaps that matter \u2014 see *What the CLI can't do*.\n\n## Which Auden skill\n\n| Need | Use |\n|---|---|\n| Read notes/bundles from a terminal, no MCP configured | **this skill** |\n| Read *and write* context, MCP tools present | `auden-context` |\n| Guides, grading results, session alignment | `auden` |\n\n## Credentials\n\nEvery networked command resolves a token in this order: the `--token` flag, then\n`$AUDEN_TOKEN`, then `token` in `~/.auden/config.json`. An env-supplied token is\nnever written to disk, so an ephemeral environment can hold a credential without\nleaving one behind.\n\nWith no token, `auden pull` exits non-zero and points at the dashboard\n(Settings \u2192 Developer \u2192 CLI Token). Surface that message rather than working\naround it.\n\n`auden status` shows what is connected; `auden doctor` diagnoses setup problems.\n\n## Fetching notes\n\n### The inbox\n\n```bash\nauden pull inbox --once --out ./notes\n```\n\n`inbox` is a real bundle slug, so the ordinary pull path reads it. `--out` targets\na directory and implies `--once` (no subscription).\n\nA 404 here means nothing has ever been captured \u2014 the inbox bundle is created\nlazily on first capture, not at signup.\n\n### A named bundle\n\n```bash\nauden pull notes          # \u2192 .auden/context/notes/ and subscribes\nauden pull notes --once   # \u2192 same directory, no subscription\n```\n\nSubscribing records the bundle in the repo's `.auden/config.json` so `auden sync`\nkeeps it fresh. Run bare `auden pull` in an interactive terminal for a picker of\nthe user's bundles; outside a TTY a slug is required.\n\nIf that file carries a `token` field, subscribing strips it and warns \u2014 the file\nis committed, so treat the warning as a signal to rotate that token.\n\n### Scoping a pull\n\n| Flag | Effect |\n|---|---|\n| `--query <text>` | Substring filter over item name + content |\n| `--types <list>` | `guide`, `document`, `reference`, `asset` (comma-separated) |\n| `--limit <n>` | 1\u2013500; server default 100 |\n\nPull scoped rather than everything \u2014 the context layer can be large.\n\n**A scoped pull needs `--once`.** Filters apply to that one command; the\nsubscription records only the bundle slug, so the next `auden sync` re-pulls the\nbundle unfiltered and the narrow set you asked for is replaced by all of it. Pass\n`--once` whenever you scope, or accept the whole bundle later.\n\n## What lands on disk\n\nEach item is written as `<item name>.md`, the name reduced to one safe path\nsegment. Items with no text body (assets, whose bytes live in object storage) are\nskipped and counted in the summary line. Two items with the same name get the\nitem id appended to the second.\n\n**Filenames carry no item ids.** Nothing on disk identifies which file is which\nrecord, which is why the archive step below cannot be driven from a pull alone.\n\n## \"Latest\" means two different things\n\n`auden pull inbox` sorts by **last updated**. The MCP `list_inbox` tool sorts by\n**captured at** and accepts a `since` window; the CLI has no `since`.\n\nSo a note captured last month but edited today comes back *first* from the CLI\nand *buried* over MCP. When the user asks for \"the latest note\", say which sense\nyou used, or read the content for a date rather than trusting position.\n\nBoth paths omit archived items **from the response** \u2014 neither deletes anything\nalready on disk. A one-off `--out` pull writes only what came back, so a note\narchived since the last run stays in that directory and gets read again as if it\nwere live. Point one-off pulls at a fresh or emptied directory. Only the\nsubscribed path reconciles deletions, and only under `auden sync` (below).\n\n## What the CLI can't do\n\n- **Archive inbox items.** There is no `auden archive`. Archiving is\n  `archive_inbox` over MCP only, so a CLI-only workflow can read the inbox but\n  cannot mark notes processed \u2014 they resurface on every pull.\n- **Push or update context.** `push_context` is MCP-only too.\n- **Create bundles or file items into them.** `create_bundle` and `file_context`\n  are MCP-only (or the dashboard). `auden pull <bundle>` can only subscribe a repo\n  to a bundle that already exists.\n- **Filter the inbox by time.** No `since`.\n\nIf the user needs any of these, the fix is to wire the MCP server (`auden mcp` in\nthe agent's MCP config), not to script around the CLI. Say so plainly.\n\n## Keeping a repo fresh\n\n`auden sync` uploads logged actions and suggestions, then pulls every subscribed\nbundle. Control just the context half with `--docs` (force) or `--no-docs` (skip).\n\nThe docs phase reconciles deletions: a note deleted in the dashboard is removed\nfrom `.auden/context/`, **discarding local edits to those files**. Pass\n`--no-prune-docs` to keep them. Removals are always named in the output, and are\nskipped for a bundle whose pull failed or hit the item ceiling.\n\nTreat `.auden/context/` as a cache of the dashboard, not a place to edit.\n";
/**
 * Skills bundled into a repo by \`auden init\` (written under .claude/skills/<name>/SKILL.md).
 * The \`auden\` skill covers guide and grading-result inspection; \`auden-context\` covers
 * the context layer over the Auden MCP server; \`auden-cli\` covers the terminal
 * path to that same context layer, which is the only one that works when the MCP
 * server is not configured.
 *
 * Deliberately mechanics-only: Auden ships the mechanics (pull/push/inbox/
 * grading), users bring the use cases — a concrete transform skill (e.g. notes
 * cleanup) plus the guide with eval criteria that grades it is *user* content.
 * A copy-paste example lives in docs/examples/notes-cleanup-skill.md; a user
 * skill dropped into .claude/skills/ is discovered and graded like anything
 * else they author (L3).
 *
 * KNOWN SHARP EDGE — adding a name here annexes that directory. Ownership is
 * decided by path prefix alone (`rules/bundled-skills.ts`), so a user who
 * already had `.claude/skills/<name>/` sees it silently drop out of discovery
 * and watch on upgrade, with no `auden init` run and no message. `init` leaves
 * their file on disk, which makes the loss quieter, not smaller. The fix is to
 * claim a path by evidence (an install marker) rather than by name — tracked as
 * `bundled-skill-name-collision`; until then, weigh the collision risk of any
 * name added to this list.
 */
export declare const BUNDLED_SKILLS: ReadonlyArray<{
    name: string;
    content: string;
}>;
//# sourceMappingURL=skill-template.d.ts.map