{"owner":"wkentaro","repo":"labelme","hasSkills":true,"totalSkillsCount":4,"totalTokensCount":1956,"categories":["subagent-persona","root-instruction"],"hasMcp":false,"mcpConfig":null,"found":["docs/agents/triage-labels.md","docs/agents/domain.md","AGENTS.md","docs/agents/issue-tracker.md"],"skills":{"docs/agents/triage-labels.md":"# Issue and Pull Request Labels\n\nUse labels to record issue type, ownership, and review decisions. Tool-managed\nand repository-specific labels are outside this contract and remain untouched.\n\n## Contract rules\n\n- A triaged issue carries exactly one `type:` label and one triage state. An\n  unlabeled issue is untriaged; `needs-triage` means under evaluation.\n- A non-draft PR with no verdict is the agent's to finalize. The draft flag is\n  the \"still being built\" state; there is no label for it.\n- The agent emits at most one `recommend-*` verdict per head. `recommend-revise`\n  hands the PR back to its author; the other three hand it to the maintainer.\n- Verdicts are recommendations. The agent never merges and never closes. Never\n  rename `recommend-merge` to `ready-to-merge`: merge bots watch that string.\n- `maintainer-approved` is set only on explicit maintainer direction and may\n  coexist with a `recommend-*` label.\n- A new push makes any verdict stale. The authority that set it clears and\n  renews it.\n\n## `/triage` role mapping\n\n| Role | Issue label | PR label |\n| --- | --- | --- |\n| `bug` | `type:bug` | none |\n| `enhancement` | `type:feature` | none |\n| `needs-triage` | `needs-triage` | `recommend-triage` |\n| `needs-info` | `needs-info` | `recommend-revise` |\n| `ready-for-agent` | `ready-for-agent` | none |\n| `ready-for-human` | `ready-for-human` | `recommend-merge` |\n| `wontfix` | `wontfix` | `recommend-close` |\n\n`type:task` is used for maintenance, refactor, documentation, and other work\nthat is neither a bug nor an enhancement. A non-draft PR without a verdict is\nalready ready for an agent, so it needs no PR label.\n\n## Label meanings\n\n### Issue labels\n\n| Label | Meaning |\n| --- | --- |\n| `type:bug` | Reporting a defect to fix |\n| `type:feature` | Requesting a new capability or improvement |\n| `type:task` | Other work: maintenance, refactor, or docs |\n| `needs-triage` | Under evaluation, not yet routed |\n| `needs-info` | Waiting on the reporter for more information |\n| `ready-for-agent` | Fully specified and ready for an AFK agent |\n| `ready-for-human` | Requires human implementation |\n| `wontfix` | Will not be actioned |\n\n### Pull request verdicts\n\n| Label | Meaning |\n| --- | --- |\n| `recommend-merge` | Agent finalized it and endorses maintainer review and merge |\n| `recommend-close` | Agent recommends that the maintainer review and close it |\n| `recommend-triage` | Code is sound; the maintainer must make the product or scope decision |\n| `recommend-revise` | Review found defects or questions; the author must revise and push |\n| `maintainer-approved` | Maintainer reviewed this head and approves merging after required checks pass |\n\nVerdicts record decisions, not merge or close actions. A new commit makes an\napplicable verdict stale: remove it and have the corresponding authority review\nthe new head before renewing it.\n","docs/agents/domain.md":"# Domain Docs\n\nHow the engineering skills should consume this repo's domain documentation when exploring the codebase.\n\nThis repo uses a **single-context** layout: one `GLOSSARY.md` and one `docs/adr/` directory at the repo root.\n\n## Before exploring, read these\n\n- **`GLOSSARY.md`** at the repo root — the project's glossary and domain language.\n- **`docs/adr/`** — read ADRs that touch the area you're about to work in.\n\nIf any of these files don't exist, **proceed silently**. Don't flag their absence; don't suggest creating them upfront. The producer skill (`/domain-modeling`) creates them lazily when terms or decisions actually get resolved.\n\n## File structure\n\n```\n/\n├── GLOSSARY.md         ← glossary, created lazily by /domain-modeling\n├── docs/\n│   └── adr/            ← architectural decisions, created lazily\n│       ├── 0001-...md\n│       └── 0002-...md\n└── labelme/            ← source\n```\n\n## Use the glossary's vocabulary\n\nWhen your output names a domain concept (in an issue title, a refactor proposal, a hypothesis, a test name), use the term as defined in `GLOSSARY.md`. Don't drift to synonyms the glossary explicitly avoids.\n\nIf the concept you need isn't in the glossary yet, that's a signal — either you're inventing language the project doesn't use (reconsider) or there's a real gap (note it for `/domain-modeling`).\n\n## Flag ADR conflicts\n\nIf your output contradicts an existing ADR, surface it explicitly rather than silently overriding:\n\n> _Contradicts ADR-NNNN (short title) — but worth reopening because…_\n","AGENTS.md":"# AGENTS.md\n\n## Changelog\n\nRecord user-facing changes to the packaged application as towncrier fragments, following `changelog.d/README.md`; never edit `CHANGELOG.md` directly. Changes confined to `examples/` are outside the changelog's scope. Prefix `**Breaking:**` for changes that bump the major version.\n\n## Agent skills\n\n### Issue tracker\n\nIssues are tracked as GitHub issues on `wkentaro/labelme` via the `gh` CLI. See `docs/agents/issue-tracker.md`.\n\n### Issue and pull-request labels\n\nFor issue triage and type labels or pull-request verdict labels, follow `docs/agents/triage-labels.md`.\n\n### GUI driving\n\nTo see or drive the real app, follow `docs/agents/gui-driving.md`: e2e tests first, then the harness's own computer use on macOS or Windows, Xvfb on Linux, and hand-driven live desktop last.\n\n### Domain docs\n\nSingle-context layout: `GLOSSARY.md` and `docs/adr/` at the repo root (created lazily by `/domain-modeling`). See `docs/agents/domain.md`.\n\n### AI Assist\n\nTreat AI Assist Setting Controls as proactive guidance. Enforce Prompt Compatibility at runtime before model download or inference, and reject an incompatible prompt without changing the model Setting.\n","docs/agents/issue-tracker.md":"# Issue tracker: GitHub\n\nIssues and PRDs for this repo live as GitHub issues on `wkentaro/labelme`. Use the `gh` CLI for all operations.\n\n## Conventions\n\n- **Create an issue**: `gh issue create --title \"...\" --body \"...\"`. Use a heredoc for multi-line bodies.\n- **Read an issue**: `gh issue view <number> --comments`, filtering comments by `jq` and also fetching labels.\n- **List issues**: `gh issue list --state open --json number,title,body,labels,comments --jq '[.[] | {number, title, body, labels: [.labels[].name], comments: [.comments[].body]}]'` with appropriate `--label` and `--state` filters.\n- **Comment on an issue**: `gh issue comment <number> --body \"...\"`\n- **Apply / remove labels**: `gh issue edit <number> --add-label \"...\"` / `--remove-label \"...\"`\n- **Close**: `gh issue close <number> --comment \"...\"`\n\nInfer the repo from `git remote -v` — `gh` does this automatically when run inside a clone.\n\n## When a skill says \"publish to the issue tracker\"\n\nCreate a GitHub issue.\n\n## When a skill says \"fetch the relevant ticket\"\n\nRun `gh issue view <number> --comments`.\n\n## Wayfinding operations\n\nGitHub's native sub-issue / dependency APIs are not reliably reachable via `gh`, so wayfinder maps use a body convention here:\n\n- **Map**: an issue labelled `wayfinder:map` plus a per-effort topic label `wayfinder:<effort>` (e.g. `wayfinder:config`). Body follows the wayfinder map template.\n\n- **Ticket**: a child issue labelled `wayfinder:<type>` (`research`/`prototype`/`grilling`/`task`) **and** the same `wayfinder:<effort>` topic label. Body ends with a metadata block:\n\n  ```\n  Map: #<map-number>\n  Blocked by: none            # or: #<n>, #<m>\n  ```\n\n- **Claim**: assign the ticket to the effort's dev (here, `wkentaro`) before any work. An open, **unassigned** ticket is unclaimed. The map issue is assigned to the owner from creation; that is ownership, not a claim.\n\n- **Frontier query**: `gh issue list --label wayfinder:<effort> --state open --json number,title,assignees,body` then keep tickets that are unassigned **and** whose every `Blocked by:` issue is closed.\n\n- **Resolve**: post the answer as a comment, `gh issue close`, then append a one-line gist + link to the map's Decisions-so-far.\n"},"files":{"docs/agents/triage-labels.md":"# Issue and Pull Request Labels\n\nUse labels to record issue type, ownership, and review decisions. Tool-managed\nand repository-specific labels are outside this contract and remain untouched.\n\n## Contract rules\n\n- A triaged issue carries exactly one `type:` label and one triage state. An\n  unlabeled issue is untriaged; `needs-triage` means under evaluation.\n- A non-draft PR with no verdict is the agent's to finalize. The draft flag is\n  the \"still being built\" state; there is no label for it.\n- The agent emits at most one `recommend-*` verdict per head. `recommend-revise`\n  hands the PR back to its author; the other three hand it to the maintainer.\n- Verdicts are recommendations. The agent never merges and never closes. Never\n  rename `recommend-merge` to `ready-to-merge`: merge bots watch that string.\n- `maintainer-approved` is set only on explicit maintainer direction and may\n  coexist with a `recommend-*` label.\n- A new push makes any verdict stale. The authority that set it clears and\n  renews it.\n\n## `/triage` role mapping\n\n| Role | Issue label | PR label |\n| --- | --- | --- |\n| `bug` | `type:bug` | none |\n| `enhancement` | `type:feature` | none |\n| `needs-triage` | `needs-triage` | `recommend-triage` |\n| `needs-info` | `needs-info` | `recommend-revise` |\n| `ready-for-agent` | `ready-for-agent` | none |\n| `ready-for-human` | `ready-for-human` | `recommend-merge` |\n| `wontfix` | `wontfix` | `recommend-close` |\n\n`type:task` is used for maintenance, refactor, documentation, and other work\nthat is neither a bug nor an enhancement. A non-draft PR without a verdict is\nalready ready for an agent, so it needs no PR label.\n\n## Label meanings\n\n### Issue labels\n\n| Label | Meaning |\n| --- | --- |\n| `type:bug` | Reporting a defect to fix |\n| `type:feature` | Requesting a new capability or improvement |\n| `type:task` | Other work: maintenance, refactor, or docs |\n| `needs-triage` | Under evaluation, not yet routed |\n| `needs-info` | Waiting on the reporter for more information |\n| `ready-for-agent` | Fully specified and ready for an AFK agent |\n| `ready-for-human` | Requires human implementation |\n| `wontfix` | Will not be actioned |\n\n### Pull request verdicts\n\n| Label | Meaning |\n| --- | --- |\n| `recommend-merge` | Agent finalized it and endorses maintainer review and merge |\n| `recommend-close` | Agent recommends that the maintainer review and close it |\n| `recommend-triage` | Code is sound; the maintainer must make the product or scope decision |\n| `recommend-revise` | Review found defects or questions; the author must revise and push |\n| `maintainer-approved` | Maintainer reviewed this head and approves merging after required checks pass |\n\nVerdicts record decisions, not merge or close actions. A new commit makes an\napplicable verdict stale: remove it and have the corresponding authority review\nthe new head before renewing it.\n","docs/agents/domain.md":"# Domain Docs\n\nHow the engineering skills should consume this repo's domain documentation when exploring the codebase.\n\nThis repo uses a **single-context** layout: one `GLOSSARY.md` and one `docs/adr/` directory at the repo root.\n\n## Before exploring, read these\n\n- **`GLOSSARY.md`** at the repo root — the project's glossary and domain language.\n- **`docs/adr/`** — read ADRs that touch the area you're about to work in.\n\nIf any of these files don't exist, **proceed silently**. Don't flag their absence; don't suggest creating them upfront. The producer skill (`/domain-modeling`) creates them lazily when terms or decisions actually get resolved.\n\n## File structure\n\n```\n/\n├── GLOSSARY.md         ← glossary, created lazily by /domain-modeling\n├── docs/\n│   └── adr/            ← architectural decisions, created lazily\n│       ├── 0001-...md\n│       └── 0002-...md\n└── labelme/            ← source\n```\n\n## Use the glossary's vocabulary\n\nWhen your output names a domain concept (in an issue title, a refactor proposal, a hypothesis, a test name), use the term as defined in `GLOSSARY.md`. Don't drift to synonyms the glossary explicitly avoids.\n\nIf the concept you need isn't in the glossary yet, that's a signal — either you're inventing language the project doesn't use (reconsider) or there's a real gap (note it for `/domain-modeling`).\n\n## Flag ADR conflicts\n\nIf your output contradicts an existing ADR, surface it explicitly rather than silently overriding:\n\n> _Contradicts ADR-NNNN (short title) — but worth reopening because…_\n","AGENTS.md":"# AGENTS.md\n\n## Changelog\n\nRecord user-facing changes to the packaged application as towncrier fragments, following `changelog.d/README.md`; never edit `CHANGELOG.md` directly. Changes confined to `examples/` are outside the changelog's scope. Prefix `**Breaking:**` for changes that bump the major version.\n\n## Agent skills\n\n### Issue tracker\n\nIssues are tracked as GitHub issues on `wkentaro/labelme` via the `gh` CLI. See `docs/agents/issue-tracker.md`.\n\n### Issue and pull-request labels\n\nFor issue triage and type labels or pull-request verdict labels, follow `docs/agents/triage-labels.md`.\n\n### GUI driving\n\nTo see or drive the real app, follow `docs/agents/gui-driving.md`: e2e tests first, then the harness's own computer use on macOS or Windows, Xvfb on Linux, and hand-driven live desktop last.\n\n### Domain docs\n\nSingle-context layout: `GLOSSARY.md` and `docs/adr/` at the repo root (created lazily by `/domain-modeling`). See `docs/agents/domain.md`.\n\n### AI Assist\n\nTreat AI Assist Setting Controls as proactive guidance. Enforce Prompt Compatibility at runtime before model download or inference, and reject an incompatible prompt without changing the model Setting.\n","docs/agents/issue-tracker.md":"# Issue tracker: GitHub\n\nIssues and PRDs for this repo live as GitHub issues on `wkentaro/labelme`. Use the `gh` CLI for all operations.\n\n## Conventions\n\n- **Create an issue**: `gh issue create --title \"...\" --body \"...\"`. Use a heredoc for multi-line bodies.\n- **Read an issue**: `gh issue view <number> --comments`, filtering comments by `jq` and also fetching labels.\n- **List issues**: `gh issue list --state open --json number,title,body,labels,comments --jq '[.[] | {number, title, body, labels: [.labels[].name], comments: [.comments[].body]}]'` with appropriate `--label` and `--state` filters.\n- **Comment on an issue**: `gh issue comment <number> --body \"...\"`\n- **Apply / remove labels**: `gh issue edit <number> --add-label \"...\"` / `--remove-label \"...\"`\n- **Close**: `gh issue close <number> --comment \"...\"`\n\nInfer the repo from `git remote -v` — `gh` does this automatically when run inside a clone.\n\n## When a skill says \"publish to the issue tracker\"\n\nCreate a GitHub issue.\n\n## When a skill says \"fetch the relevant ticket\"\n\nRun `gh issue view <number> --comments`.\n\n## Wayfinding operations\n\nGitHub's native sub-issue / dependency APIs are not reliably reachable via `gh`, so wayfinder maps use a body convention here:\n\n- **Map**: an issue labelled `wayfinder:map` plus a per-effort topic label `wayfinder:<effort>` (e.g. `wayfinder:config`). Body follows the wayfinder map template.\n\n- **Ticket**: a child issue labelled `wayfinder:<type>` (`research`/`prototype`/`grilling`/`task`) **and** the same `wayfinder:<effort>` topic label. Body ends with a metadata block:\n\n  ```\n  Map: #<map-number>\n  Blocked by: none            # or: #<n>, #<m>\n  ```\n\n- **Claim**: assign the ticket to the effort's dev (here, `wkentaro`) before any work. An open, **unassigned** ticket is unclaimed. The map issue is assigned to the owner from creation; that is ownership, not a claim.\n\n- **Frontier query**: `gh issue list --label wayfinder:<effort> --state open --json number,title,assignees,body` then keep tickets that are unassigned **and** whose every `Blocked by:` issue is closed.\n\n- **Resolve**: post the answer as a comment, `gh issue close`, then append a one-line gist + link to the map's Decisions-so-far.\n"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","rawUrl":"https://raw.githubusercontent.com/wkentaro/labelme/HEAD/AGENTS.md","title":"AI Agent Protocol & Instructions","category":"root-instruction","format":"markdown","content":"# AGENTS.md\n\n## Changelog\n\nRecord user-facing changes to the packaged application as towncrier fragments, following `changelog.d/README.md`; never edit `CHANGELOG.md` directly. Changes confined to `examples/` are outside the changelog's scope. Prefix `**Breaking:**` for changes that bump the major version.\n\n## Agent skills\n\n### Issue tracker\n\nIssues are tracked as GitHub issues on `wkentaro/labelme` via the `gh` CLI. See `docs/agents/issue-tracker.md`.\n\n### Issue and pull-request labels\n\nFor issue triage and type labels or pull-request verdict labels, follow `docs/agents/triage-labels.md`.\n\n### GUI driving\n\nTo see or drive the real app, follow `docs/agents/gui-driving.md`: e2e tests first, then the harness's own computer use on macOS or Windows, Xvfb on Linux, and hand-driven live desktop last.\n\n### Domain docs\n\nSingle-context layout: `GLOSSARY.md` and `docs/adr/` at the repo root (created lazily by `/domain-modeling`). See `docs/agents/domain.md`.\n\n### AI Assist\n\nTreat AI Assist Setting Controls as proactive guidance. Enforce Prompt Compatibility at runtime before model download or inference, and reject an incompatible prompt without changing the model Setting.\n","isInternal":false,"tokens":273,"sizeBytes":1181},{"name":"domain.md","path":"docs/agents/domain.md","rawUrl":"https://raw.githubusercontent.com/wkentaro/labelme/HEAD/docs/agents/domain.md","title":"Subagent: domain","category":"subagent-persona","format":"markdown","content":"# Domain Docs\n\nHow the engineering skills should consume this repo's domain documentation when exploring the codebase.\n\nThis repo uses a **single-context** layout: one `GLOSSARY.md` and one `docs/adr/` directory at the repo root.\n\n## Before exploring, read these\n\n- **`GLOSSARY.md`** at the repo root — the project's glossary and domain language.\n- **`docs/adr/`** — read ADRs that touch the area you're about to work in.\n\nIf any of these files don't exist, **proceed silently**. Don't flag their absence; don't suggest creating them upfront. The producer skill (`/domain-modeling`) creates them lazily when terms or decisions actually get resolved.\n\n## File structure\n\n```\n/\n├── GLOSSARY.md         ← glossary, created lazily by /domain-modeling\n├── docs/\n│   └── adr/            ← architectural decisions, created lazily\n│       ├── 0001-...md\n│       └── 0002-...md\n└── labelme/            ← source\n```\n\n## Use the glossary's vocabulary\n\nWhen your output names a domain concept (in an issue title, a refactor proposal, a hypothesis, a test name), use the term as defined in `GLOSSARY.md`. Don't drift to synonyms the glossary explicitly avoids.\n\nIf the concept you need isn't in the glossary yet, that's a signal — either you're inventing language the project doesn't use (reconsider) or there's a real gap (note it for `/domain-modeling`).\n\n## Flag ADR conflicts\n\nIf your output contradicts an existing ADR, surface it explicitly rather than silently overriding:\n\n> _Contradicts ADR-NNNN (short title) — but worth reopening because…_\n","isInternal":false,"tokens":385,"sizeBytes":1596},{"name":"issue-tracker.md","path":"docs/agents/issue-tracker.md","rawUrl":"https://raw.githubusercontent.com/wkentaro/labelme/HEAD/docs/agents/issue-tracker.md","title":"Subagent: issue-tracker","category":"subagent-persona","format":"markdown","content":"# Issue tracker: GitHub\n\nIssues and PRDs for this repo live as GitHub issues on `wkentaro/labelme`. Use the `gh` CLI for all operations.\n\n## Conventions\n\n- **Create an issue**: `gh issue create --title \"...\" --body \"...\"`. Use a heredoc for multi-line bodies.\n- **Read an issue**: `gh issue view <number> --comments`, filtering comments by `jq` and also fetching labels.\n- **List issues**: `gh issue list --state open --json number,title,body,labels,comments --jq '[.[] | {number, title, body, labels: [.labels[].name], comments: [.comments[].body]}]'` with appropriate `--label` and `--state` filters.\n- **Comment on an issue**: `gh issue comment <number> --body \"...\"`\n- **Apply / remove labels**: `gh issue edit <number> --add-label \"...\"` / `--remove-label \"...\"`\n- **Close**: `gh issue close <number> --comment \"...\"`\n\nInfer the repo from `git remote -v` — `gh` does this automatically when run inside a clone.\n\n## When a skill says \"publish to the issue tracker\"\n\nCreate a GitHub issue.\n\n## When a skill says \"fetch the relevant ticket\"\n\nRun `gh issue view <number> --comments`.\n\n## Wayfinding operations\n\nGitHub's native sub-issue / dependency APIs are not reliably reachable via `gh`, so wayfinder maps use a body convention here:\n\n- **Map**: an issue labelled `wayfinder:map` plus a per-effort topic label `wayfinder:<effort>` (e.g. `wayfinder:config`). Body follows the wayfinder map template.\n\n- **Ticket**: a child issue labelled `wayfinder:<type>` (`research`/`prototype`/`grilling`/`task`) **and** the same `wayfinder:<effort>` topic label. Body ends with a metadata block:\n\n  ```\n  Map: #<map-number>\n  Blocked by: none            # or: #<n>, #<m>\n  ```\n\n- **Claim**: assign the ticket to the effort's dev (here, `wkentaro`) before any work. An open, **unassigned** ticket is unclaimed. The map issue is assigned to the owner from creation; that is ownership, not a claim.\n\n- **Frontier query**: `gh issue list --label wayfinder:<effort> --state open --json number,title,assignees,body` then keep tickets that are unassigned **and** whose every `Blocked by:` issue is closed.\n\n- **Resolve**: post the answer as a comment, `gh issue close`, then append a one-line gist + link to the map's Decisions-so-far.\n","isInternal":false,"tokens":579,"sizeBytes":2223},{"name":"triage-labels.md","path":"docs/agents/triage-labels.md","rawUrl":"https://raw.githubusercontent.com/wkentaro/labelme/HEAD/docs/agents/triage-labels.md","title":"Subagent: triage-labels","category":"subagent-persona","format":"markdown","content":"# Issue and Pull Request Labels\n\nUse labels to record issue type, ownership, and review decisions. Tool-managed\nand repository-specific labels are outside this contract and remain untouched.\n\n## Contract rules\n\n- A triaged issue carries exactly one `type:` label and one triage state. An\n  unlabeled issue is untriaged; `needs-triage` means under evaluation.\n- A non-draft PR with no verdict is the agent's to finalize. The draft flag is\n  the \"still being built\" state; there is no label for it.\n- The agent emits at most one `recommend-*` verdict per head. `recommend-revise`\n  hands the PR back to its author; the other three hand it to the maintainer.\n- Verdicts are recommendations. The agent never merges and never closes. Never\n  rename `recommend-merge` to `ready-to-merge`: merge bots watch that string.\n- `maintainer-approved` is set only on explicit maintainer direction and may\n  coexist with a `recommend-*` label.\n- A new push makes any verdict stale. The authority that set it clears and\n  renews it.\n\n## `/triage` role mapping\n\n| Role | Issue label | PR label |\n| --- | --- | --- |\n| `bug` | `type:bug` | none |\n| `enhancement` | `type:feature` | none |\n| `needs-triage` | `needs-triage` | `recommend-triage` |\n| `needs-info` | `needs-info` | `recommend-revise` |\n| `ready-for-agent` | `ready-for-agent` | none |\n| `ready-for-human` | `ready-for-human` | `recommend-merge` |\n| `wontfix` | `wontfix` | `recommend-close` |\n\n`type:task` is used for maintenance, refactor, documentation, and other work\nthat is neither a bug nor an enhancement. A non-draft PR without a verdict is\nalready ready for an agent, so it needs no PR label.\n\n## Label meanings\n\n### Issue labels\n\n| Label | Meaning |\n| --- | --- |\n| `type:bug` | Reporting a defect to fix |\n| `type:feature` | Requesting a new capability or improvement |\n| `type:task` | Other work: maintenance, refactor, or docs |\n| `needs-triage` | Under evaluation, not yet routed |\n| `needs-info` | Waiting on the reporter for more information |\n| `ready-for-agent` | Fully specified and ready for an AFK agent |\n| `ready-for-human` | Requires human implementation |\n| `wontfix` | Will not be actioned |\n\n### Pull request verdicts\n\n| Label | Meaning |\n| --- | --- |\n| `recommend-merge` | Agent finalized it and endorses maintainer review and merge |\n| `recommend-close` | Agent recommends that the maintainer review and close it |\n| `recommend-triage` | Code is sound; the maintainer must make the product or scope decision |\n| `recommend-revise` | Review found defects or questions; the author must revise and push |\n| `maintainer-approved` | Maintainer reviewed this head and approves merging after required checks pass |\n\nVerdicts record decisions, not merge or close actions. A new commit makes an\napplicable verdict stale: remove it and have the corresponding authority review\nthe new head before renewing it.\n","isInternal":false,"tokens":719,"sizeBytes":2873}],"systemPromptSnippet":"<yakaai_skills repo=\"wkentaro/labelme\">\n<!-- File: AGENTS.md (Tokens: ~273 | Category: root-instruction) -->\n# AGENTS.md\n\n## Changelog\n\nRecord user-facing changes to the packaged application as towncrier fragments, following `changelog.d/README.md`; never edit `CHANGELOG.md` directly. Changes confined to `examples/` are outside the changelog's scope. Prefix `**Breaking:**` for changes that bump the major version.\n\n## Agent skills\n\n### Issue tracker\n\nIssues are tracked as GitHub issues on `wkentaro/labelme` via the `gh` CLI. See `docs/agents/issue-tracker.md`.\n\n### Issue and pull-request labels\n\nFor issue triage and type labels or pull-request verdict labels, follow `docs/agents/triage-labels.md`.\n\n### GUI driving\n\nTo see or drive the real app, follow `docs/agents/gui-driving.md`: e2e tests first, then the harness's own computer use on macOS or Windows, Xvfb on Linux, and hand-driven live desktop last.\n\n### Domain docs\n\nSingle-context layout: `GLOSSARY.md` and `docs/adr/` at the repo root (created lazily by `/domain-modeling`). See `docs/agents/domain.md`.\n\n### AI Assist\n\nTreat AI Assist Setting Controls as proactive guidance. Enforce Prompt Compatibility at runtime before model download or inference, and reject an incompatible prompt without changing the model Setting.\n\n<!-- File: docs/agents/domain.md (Tokens: ~385 | Category: subagent-persona) -->\n# Domain Docs\n\nHow the engineering skills should consume this repo's domain documentation when exploring the codebase.\n\nThis repo uses a **single-context** layout: one `GLOSSARY.md` and one `docs/adr/` directory at the repo root.\n\n## Before exploring, read these\n\n- **`GLOSSARY.md`** at the repo root — the project's glossary and domain language.\n- **`docs/adr/`** — read ADRs that touch the area you're about to work in.\n\nIf any of these files don't exist, **proceed silently**. Don't flag their absence; don't suggest creating them upfront. The producer skill (`/domain-modeling`) creates them lazily when terms or decisions actually get resolved.\n\n## File structure\n\n```\n/\n├── GLOSSARY.md         ← glossary, created lazily by /domain-modeling\n├── docs/\n│   └── adr/            ← architectural decisions, created lazily\n│       ├── 0001-...md\n│       └── 0002-...md\n└── labelme/            ← source\n```\n\n## Use the glossary's vocabulary\n\nWhen your output names a domain concept (in an issue title, a refactor proposal, a hypothesis, a test name), use the term as defined in `GLOSSARY.md`. Don't drift to synonyms the glossary explicitly avoids.\n\nIf the concept you need isn't in the glossary yet, that's a signal — either you're inventing language the project doesn't use (reconsider) or there's a real gap (note it for `/domain-modeling`).\n\n## Flag ADR conflicts\n\nIf your output contradicts an existing ADR, surface it explicitly rather than silently overriding:\n\n> _Contradicts ADR-NNNN (short title) — but worth reopening because…_\n\n<!-- File: docs/agents/issue-tracker.md (Tokens: ~579 | Category: subagent-persona) -->\n# Issue tracker: GitHub\n\nIssues and PRDs for this repo live as GitHub issues on `wkentaro/labelme`. Use the `gh` CLI for all operations.\n\n## Conventions\n\n- **Create an issue**: `gh issue create --title \"...\" --body \"...\"`. Use a heredoc for multi-line bodies.\n- **Read an issue**: `gh issue view <number> --comments`, filtering comments by `jq` and also fetching labels.\n- **List issues**: `gh issue list --state open --json number,title,body,labels,comments --jq '[.[] | {number, title, body, labels: [.labels[].name], comments: [.comments[].body]}]'` with appropriate `--label` and `--state` filters.\n- **Comment on an issue**: `gh issue comment <number> --body \"...\"`\n- **Apply / remove labels**: `gh issue edit <number> --add-label \"...\"` / `--remove-label \"...\"`\n- **Close**: `gh issue close <number> --comment \"...\"`\n\nInfer the repo from `git remote -v` — `gh` does this automatically when run inside a clone.\n\n## When a skill says \"publish to the issue tracker\"\n\nCreate a GitHub issue.\n\n## When a skill says \"fetch the relevant ticket\"\n\nRun `gh issue view <number> --comments`.\n\n## Wayfinding operations\n\nGitHub's native sub-issue / dependency APIs are not reliably reachable via `gh`, so wayfinder maps use a body convention here:\n\n- **Map**: an issue labelled `wayfinder:map` plus a per-effort topic label `wayfinder:<effort>` (e.g. `wayfinder:config`). Body follows the wayfinder map template.\n\n- **Ticket**: a child issue labelled `wayfinder:<type>` (`research`/`prototype`/`grilling`/`task`) **and** the same `wayfinder:<effort>` topic label. Body ends with a metadata block:\n\n  ```\n  Map: #<map-number>\n  Blocked by: none            # or: #<n>, #<m>\n  ```\n\n- **Claim**: assign the ticket to the effort's dev (here, `wkentaro`) before any work. An open, **unassigned** ticket is unclaimed. The map issue is assigned to the owner from creation; that is ownership, not a claim.\n\n- **Frontier query**: `gh issue list --label wayfinder:<effort> --state open --json number,title,assignees,body` then keep tickets that are unassigned **and** whose every `Blocked by:` issue is closed.\n\n- **Resolve**: post the answer as a comment, `gh issue close`, then append a one-line gist + link to the map's Decisions-so-far.\n\n<!-- File: docs/agents/triage-labels.md (Tokens: ~719 | Category: subagent-persona) -->\n# Issue and Pull Request Labels\n\nUse labels to record issue type, ownership, and review decisions. Tool-managed\nand repository-specific labels are outside this contract and remain untouched.\n\n## Contract rules\n\n- A triaged issue carries exactly one `type:` label and one triage state. An\n  unlabeled issue is untriaged; `needs-triage` means under evaluation.\n- A non-draft PR with no verdict is the agent's to finalize. The draft flag is\n  the \"still being built\" state; there is no label for it.\n- The agent emits at most one `recommend-*` verdict per head. `recommend-revise`\n  hands the PR back to its author; the other three hand it to the maintainer.\n- Verdicts are recommendations. The agent never merges and never closes. Never\n  rename `recommend-merge` to `ready-to-merge`: merge bots watch that string.\n- `maintainer-approved` is set only on explicit maintainer direction and may\n  coexist with a `recommend-*` label.\n- A new push makes any verdict stale. The authority that set it clears and\n  renews it.\n\n## `/triage` role mapping\n\n| Role | Issue label | PR label |\n| --- | --- | --- |\n| `bug` | `type:bug` | none |\n| `enhancement` | `type:feature` | none |\n| `needs-triage` | `needs-triage` | `recommend-triage` |\n| `needs-info` | `needs-info` | `recommend-revise` |\n| `ready-for-agent` | `ready-for-agent` | none |\n| `ready-for-human` | `ready-for-human` | `recommend-merge` |\n| `wontfix` | `wontfix` | `recommend-close` |\n\n`type:task` is used for maintenance, refactor, documentation, and other work\nthat is neither a bug nor an enhancement. A non-draft PR without a verdict is\nalready ready for an agent, so it needs no PR label.\n\n## Label meanings\n\n### Issue labels\n\n| Label | Meaning |\n| --- | --- |\n| `type:bug` | Reporting a defect to fix |\n| `type:feature` | Requesting a new capability or improvement |\n| `type:task` | Other work: maintenance, refactor, or docs |\n| `needs-triage` | Under evaluation, not yet routed |\n| `needs-info` | Waiting on the reporter for more information |\n| `ready-for-agent` | Fully specified and ready for an AFK agent |\n| `ready-for-human` | Requires human implementation |\n| `wontfix` | Will not be actioned |\n\n### Pull request verdicts\n\n| Label | Meaning |\n| --- | --- |\n| `recommend-merge` | Agent finalized it and endorses maintainer review and merge |\n| `recommend-close` | Agent recommends that the maintainer review and close it |\n| `recommend-triage` | Code is sound; the maintainer must make the product or scope decision |\n| `recommend-revise` | Review found defects or questions; the author must revise and push |\n| `maintainer-approved` | Maintainer reviewed this head and approves merging after required checks pass |\n\nVerdicts record decisions, not merge or close actions. A new commit makes an\napplicable verdict stale: remove it and have the corresponding authority review\nthe new head before renewing it.\n</yakaai_skills>"}