{"owner":"wkentaro","repo":"gdown","hasSkills":true,"totalSkillsCount":3,"totalTokensCount":756,"categories":["subagent-persona","root-instruction"],"hasMcp":false,"mcpConfig":null,"found":["docs/agents/domain.md","docs/agents/issue-tracker.md","AGENTS.md"],"skills":{"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 is **single-context**: one `CONTEXT.md` and one `docs/adr/`, both at the repo root.\n\n## Before exploring, read these\n\n- **`CONTEXT.md`** at the repo root.\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 (`/grill-with-docs`) creates them lazily when terms or decisions actually get resolved.\n\n## File structure\n\n```\n/\n├── CONTEXT.md\n├── docs/adr/\n│   ├── 0001-some-decision.md\n│   └── 0002-another-decision.md\n└── gdown/\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 `CONTEXT.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 `/grill-with-docs`).\n\n## Flag ADR conflicts\n\nIf your output contradicts an existing ADR, surface it explicitly rather than silently overriding:\n\n> _Contradicts ADR-0007 — but worth reopening because…_\n","docs/agents/issue-tracker.md":"# Issue tracker: GitHub\n\nIssues and PRDs for this repo live as GitHub issues. 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","AGENTS.md":"## Changelog\n\nRecord user-facing changes as towncrier fragments, following\n`changelog.d/README.md`; never edit `CHANGELOG.md` directly.\n\n## Agent skills\n\n### Issue tracker\n\nIssues are tracked in GitHub Issues (github.com/wkentaro/gdown) via the `gh` CLI. See `docs/agents/issue-tracker.md`.\n\n### Issue and pull request labels\n\nCanonical issue types, triage roles, and pull-request verdicts are documented in `docs/agents/triage-labels.md`.\n\n### Domain docs\n\nSingle-context: one `CONTEXT.md` + `docs/adr/` at the repo root. See `docs/agents/domain.md`.\n"},"files":{"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 is **single-context**: one `CONTEXT.md` and one `docs/adr/`, both at the repo root.\n\n## Before exploring, read these\n\n- **`CONTEXT.md`** at the repo root.\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 (`/grill-with-docs`) creates them lazily when terms or decisions actually get resolved.\n\n## File structure\n\n```\n/\n├── CONTEXT.md\n├── docs/adr/\n│   ├── 0001-some-decision.md\n│   └── 0002-another-decision.md\n└── gdown/\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 `CONTEXT.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 `/grill-with-docs`).\n\n## Flag ADR conflicts\n\nIf your output contradicts an existing ADR, surface it explicitly rather than silently overriding:\n\n> _Contradicts ADR-0007 — but worth reopening because…_\n","docs/agents/issue-tracker.md":"# Issue tracker: GitHub\n\nIssues and PRDs for this repo live as GitHub issues. 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","AGENTS.md":"## Changelog\n\nRecord user-facing changes as towncrier fragments, following\n`changelog.d/README.md`; never edit `CHANGELOG.md` directly.\n\n## Agent skills\n\n### Issue tracker\n\nIssues are tracked in GitHub Issues (github.com/wkentaro/gdown) via the `gh` CLI. See `docs/agents/issue-tracker.md`.\n\n### Issue and pull request labels\n\nCanonical issue types, triage roles, and pull-request verdicts are documented in `docs/agents/triage-labels.md`.\n\n### Domain docs\n\nSingle-context: one `CONTEXT.md` + `docs/adr/` at the repo root. See `docs/agents/domain.md`.\n"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","rawUrl":"https://raw.githubusercontent.com/wkentaro/gdown/HEAD/AGENTS.md","title":"AI Agent Protocol & Instructions","category":"root-instruction","format":"markdown","content":"## Changelog\n\nRecord user-facing changes as towncrier fragments, following\n`changelog.d/README.md`; never edit `CHANGELOG.md` directly.\n\n## Agent skills\n\n### Issue tracker\n\nIssues are tracked in GitHub Issues (github.com/wkentaro/gdown) via the `gh` CLI. See `docs/agents/issue-tracker.md`.\n\n### Issue and pull request labels\n\nCanonical issue types, triage roles, and pull-request verdicts are documented in `docs/agents/triage-labels.md`.\n\n### Domain docs\n\nSingle-context: one `CONTEXT.md` + `docs/adr/` at the repo root. See `docs/agents/domain.md`.\n","isInternal":false,"tokens":140,"sizeBytes":552},{"name":"domain.md","path":"docs/agents/domain.md","rawUrl":"https://raw.githubusercontent.com/wkentaro/gdown/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 is **single-context**: one `CONTEXT.md` and one `docs/adr/`, both at the repo root.\n\n## Before exploring, read these\n\n- **`CONTEXT.md`** at the repo root.\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 (`/grill-with-docs`) creates them lazily when terms or decisions actually get resolved.\n\n## File structure\n\n```\n/\n├── CONTEXT.md\n├── docs/adr/\n│   ├── 0001-some-decision.md\n│   └── 0002-another-decision.md\n└── gdown/\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 `CONTEXT.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 `/grill-with-docs`).\n\n## Flag ADR conflicts\n\nIf your output contradicts an existing ADR, surface it explicitly rather than silently overriding:\n\n> _Contradicts ADR-0007 — but worth reopening because…_\n","isInternal":false,"tokens":341,"sizeBytes":1380},{"name":"issue-tracker.md","path":"docs/agents/issue-tracker.md","rawUrl":"https://raw.githubusercontent.com/wkentaro/gdown/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. 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","isInternal":false,"tokens":275,"sizeBytes":1065}],"systemPromptSnippet":"<yakaai_skills repo=\"wkentaro/gdown\">\n<!-- File: AGENTS.md (Tokens: ~140 | Category: root-instruction) -->\n## Changelog\n\nRecord user-facing changes as towncrier fragments, following\n`changelog.d/README.md`; never edit `CHANGELOG.md` directly.\n\n## Agent skills\n\n### Issue tracker\n\nIssues are tracked in GitHub Issues (github.com/wkentaro/gdown) via the `gh` CLI. See `docs/agents/issue-tracker.md`.\n\n### Issue and pull request labels\n\nCanonical issue types, triage roles, and pull-request verdicts are documented in `docs/agents/triage-labels.md`.\n\n### Domain docs\n\nSingle-context: one `CONTEXT.md` + `docs/adr/` at the repo root. See `docs/agents/domain.md`.\n\n<!-- File: docs/agents/domain.md (Tokens: ~341 | 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 is **single-context**: one `CONTEXT.md` and one `docs/adr/`, both at the repo root.\n\n## Before exploring, read these\n\n- **`CONTEXT.md`** at the repo root.\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 (`/grill-with-docs`) creates them lazily when terms or decisions actually get resolved.\n\n## File structure\n\n```\n/\n├── CONTEXT.md\n├── docs/adr/\n│   ├── 0001-some-decision.md\n│   └── 0002-another-decision.md\n└── gdown/\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 `CONTEXT.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 `/grill-with-docs`).\n\n## Flag ADR conflicts\n\nIf your output contradicts an existing ADR, surface it explicitly rather than silently overriding:\n\n> _Contradicts ADR-0007 — but worth reopening because…_\n\n<!-- File: docs/agents/issue-tracker.md (Tokens: ~275 | Category: subagent-persona) -->\n# Issue tracker: GitHub\n\nIssues and PRDs for this repo live as GitHub issues. 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</yakaai_skills>"}