{"owner":"docker","repo":"docs","hasSkills":true,"totalSkillsCount":140,"totalTokensCount":58516,"categories":["anthropic-skill","root-instruction","claude-rule","subagent-persona","command-prompt","cursor-rule"],"hasMcp":true,"mcpConfig":{"mcpServers":{"docs":{"command":"npx","args":["-y","@modelcontextprotocol/server-docs"]}}},"found":[".agents/skills/create-pr/SKILL.md",".agents/skills/fix-issue/SKILL.md",".agents/skills/maintain-pr/SKILL.md",".agents/skills/create-lab-guide/SKILL.md",".agents/skills/agent-readiness-audit/SKILL.md",".agents/skills/migrate-content-ia/SKILL.md",".agents/skills/research/SKILL.md",".agents/skills/testcontainers-guides-migrator/SKILL.md",".agents/skills/review-pr/SKILL.md",".agents/skills/review-changes/SKILL.md",".agents/skills/write/SKILL.md","AGENTS.md","CLAUDE.md",".github/agents/docs-scanner.yaml","content/manuals/extensions/_index.md","content/manuals/extensions/marketplace.md","content/manuals/extensions/non-marketplace.md","content/manuals/extensions/private-marketplace.md","content/manuals/extensions/settings-feedback.md",".agents/skills/agent-readiness-audit/references/report-template.md",".agents/skills/agent-readiness-audit/references/rubric.md",".agents/skills/curate-whats-new/agents/openai.yaml",".agents/skills/curate-whats-new/examples/2026-07-13--2026-08-11.json",".agents/skills/curate-whats-new/examples/2026-07-13--2026-08-11.yaml",".agents/skills/maintain-pr/agents/openai.yaml",".agents/skills/review-pr/agents/openai.yaml","content/manuals/ai/skills/_index.md","content/manuals/ai/skills/install.md","content/manuals/dhi/tools/_index.md","content/manuals/dhi/tools/api.md","content/manuals/dhi/tools/cli.md","content/manuals/dhi/tools/hub.md","content/manuals/dhi/tools/mcp.md","content/manuals/dhi/tools/terraform.md","content/manuals/extensions/extensions-sdk/_index.md","content/manuals/extensions/extensions-sdk/process.md","content/manuals/extensions/extensions-sdk/quickstart.md","content/manuals/ai/sandboxes/agents/_index.md","content/manuals/ai/sandboxes/agents/claude-code.md","content/manuals/ai/sandboxes/agents/codex.md","content/manuals/ai/sandboxes/agents/copilot.md","content/manuals/ai/sandboxes/agents/cursor.md","content/manuals/ai/sandboxes/agents/devin.md","content/manuals/ai/sandboxes/agents/docker-agent.md","content/manuals/ai/sandboxes/agents/droid.md","content/manuals/ai/sandboxes/agents/gemini.md","content/manuals/ai/sandboxes/agents/kiro.md","content/manuals/ai/sandboxes/agents/opencode.md","content/manuals/ai/sandboxes/agents/shell.md","content/manuals/extensions/extensions-sdk/architecture/_index.md","content/manuals/extensions/extensions-sdk/architecture/metadata.md","content/manuals/extensions/extensions-sdk/architecture/security.md","content/manuals/extensions/extensions-sdk/build/_index.md","content/manuals/extensions/extensions-sdk/build/backend-extension-tutorial.md","content/manuals/extensions/extensions-sdk/build/frontend-extension-tutorial.md","content/manuals/extensions/extensions-sdk/build/minimal-frontend-extension.md","content/manuals/extensions/extensions-sdk/design/_index.md","content/manuals/extensions/extensions-sdk/design/design-guidelines.md","content/manuals/extensions/extensions-sdk/design/design-principles.md","content/manuals/extensions/extensions-sdk/design/mui-best-practices.md","content/manuals/extensions/extensions-sdk/dev/_index.md","content/manuals/extensions/extensions-sdk/dev/continuous-integration.md","content/manuals/extensions/extensions-sdk/dev/test-debug.md","content/manuals/extensions/extensions-sdk/dev/usage.md","content/manuals/extensions/extensions-sdk/extensions/DISTRIBUTION.md","content/manuals/extensions/extensions-sdk/extensions/_index.md","content/manuals/extensions/extensions-sdk/extensions/labels.md","content/manuals/extensions/extensions-sdk/extensions/multi-arch.md","content/manuals/extensions/extensions-sdk/extensions/publish.md","content/manuals/extensions/extensions-sdk/extensions/share.md","content/manuals/extensions/extensions-sdk/extensions/validate.md","content/manuals/extensions/extensions-sdk/guides/_index.md","content/manuals/extensions/extensions-sdk/guides/invoke-host-binaries.md","content/manuals/extensions/extensions-sdk/guides/kubernetes.md","content/manuals/extensions/extensions-sdk/guides/oauth2-flow.md","content/manuals/extensions/extensions-sdk/guides/use-docker-socket-from-backend.md","_vendor/github.com/docker/docker-agent/docs/tools/_index.md","content/manuals/extensions/extensions-sdk/dev/api/_index.md","content/manuals/extensions/extensions-sdk/dev/api/backend.md","content/manuals/extensions/extensions-sdk/dev/api/dashboard-routes-navigation.md","content/manuals/extensions/extensions-sdk/dev/api/dashboard.md","content/manuals/extensions/extensions-sdk/dev/api/docker.md","content/manuals/extensions/extensions-sdk/dev/api/overview.md","_vendor/github.com/docker/docker-agent/docs/concepts/agents/index.md","_vendor/github.com/docker/docker-agent/docs/concepts/tools/index.md","_vendor/github.com/docker/docker-agent/docs/configuration/agents/index.md","_vendor/github.com/docker/docker-agent/docs/configuration/commands/index.md","_vendor/github.com/docker/docker-agent/docs/configuration/tools/index.md","_vendor/github.com/docker/docker-agent/docs/features/skills/index.md","_vendor/github.com/docker/docker-agent/docs/tools/a2a/index.md","_vendor/github.com/docker/docker-agent/docs/tools/api/index.md","_vendor/github.com/docker/docker-agent/docs/tools/background-agents/index.md","_vendor/github.com/docker/docker-agent/docs/tools/background-jobs/index.md","_vendor/github.com/docker/docker-agent/docs/tools/fetch/index.md","_vendor/github.com/docker/docker-agent/docs/tools/filesystem/index.md","_vendor/github.com/docker/docker-agent/docs/tools/git/index.md","_vendor/github.com/docker/docker-agent/docs/tools/handoff/index.md","_vendor/github.com/docker/docker-agent/docs/tools/lsp/index.md","_vendor/github.com/docker/docker-agent/docs/tools/mcp-catalog/index.md","_vendor/github.com/docker/docker-agent/docs/tools/mcp/index.md","_vendor/github.com/docker/docker-agent/docs/tools/memory/index.md","_vendor/github.com/docker/docker-agent/docs/tools/model-picker/index.md","_vendor/github.com/docker/docker-agent/docs/tools/open-url/index.md","_vendor/github.com/docker/docker-agent/docs/tools/openapi/index.md","_vendor/github.com/docker/docker-agent/docs/tools/plan/index.md","_vendor/github.com/docker/docker-agent/docs/tools/rag/index.md","_vendor/github.com/docker/docker-agent/docs/tools/scheduler/index.md","_vendor/github.com/docker/docker-agent/docs/tools/script/index.md","_vendor/github.com/docker/docker-agent/docs/tools/session_context/index.md","_vendor/github.com/docker/docker-agent/docs/tools/session_plan/index.md","_vendor/github.com/docker/docker-agent/docs/tools/shell/index.md","_vendor/github.com/docker/docker-agent/docs/tools/tasks/index.md","_vendor/github.com/docker/docker-agent/docs/tools/think/index.md","_vendor/github.com/docker/docker-agent/docs/tools/todo/index.md","_vendor/github.com/docker/docker-agent/docs/tools/transfer-task/index.md","_vendor/github.com/docker/docker-agent/docs/tools/user-prompt/index.md","_vendor/github.com/docker/docker-agent/docs/tools/webhook/index.md","_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/_index.md","_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/consistent-instruction-casing.md","_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/copy-ignored-file.md","_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/duplicate-stage-name.md","_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/expose-invalid-format.md","_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/expose-proto-casing.md","_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/from-as-casing.md","_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/from-platform-flag-const-disallowed.md","_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/invalid-default-arg-in-from.md","_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/invalid-definition-description.md","_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/json-args-recommended.md","_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/legacy-key-value-format.md","_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/maintainer-deprecated.md","_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/multiple-instructions-disallowed.md","_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/no-empty-continuation.md","_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/redundant-target-platform.md","_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/reserved-stage-name.md","_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/secrets-used-in-arg-or-env.md","_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/stage-name-casing.md","_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/undefined-arg-in-from.md","_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/undefined-var.md","_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/workdir-relative-path.md",".cursorrules (kubernetes-mkdocs-documentation-cursorrules-prompt.mdc)"],"skills":{".agents/skills/create-pr/SKILL.md":"---\nname: create-pr\ndescription: >\n Push the current branch and create a pull request against docker/docs.\n Use after changes are committed and reviewed. \"create a PR\", \"submit the\n fix\", \"open a pull request for this\".\n---\n\n# Create PR\n\nPush the branch and create a properly structured pull request.\n\n## 1. Verify the branch\n\nConfirm you're on a dedicated branch, not the default branch:\n\n```bash\ngit branch --show-current # must not be main or master\n```\n\nIf this returns `main` or `master`, stop. Create a branch and move your\ncommits onto it before continuing.\n\nConfirm commits exist and the working tree is clean:\n\n```bash\ngit log --oneline main..HEAD # confirm commits exist\ngit status --porcelain # must print nothing\n```\n\nIf `git status --porcelain` prints anything, there are uncommitted or\nunstaged changes. Stop and commit them — or unstage stray files like\n`package-lock.json` — before opening a PR. Don't open a PR mid-edit.\n\n## 2. Push the branch\n\nIdentify the remote that points at your fork. Inspect the remotes:\n\n```bash\ngit remote -v\n```\n\nIf `origin` is your fork, use it. If `origin` points at canonical\n`docker/docs` (the upstream), push to your separate fork remote instead —\nnever push the branch to `docker/docs` directly:\n\n```bash\nFORK_REMOTE=origin # or the name of your fork remote if origin is upstream\ngit push -u \"$FORK_REMOTE\" \n```\n\n## 3. Create the PR\n\nBefore creating a PR for an issue, check whether that issue already has an open\nlinked PR:\n\n```bash\ngh api repos/docker/docs/issues//timeline --paginate \\\n --jq '.[] | select((.event==\"cross-referenced\" or .event==\"connected\" or .event==\"referenced\") and .source.issue.pull_request and .source.issue.state==\"open\") | {url: .source.issue.html_url, title: .source.issue.title}'\n```\n\nIf this returns an open PR that addresses the same issue, stop. Don't open a\nduplicate PR; report the existing PR instead. Only proceed if there is no open\nlinked PR, or if the existing PR clearly does not address the issue and you\nexplain why in the new PR body.\n\nDerive the fork owner dynamically from the same fork remote you pushed to:\n\n```bash\nFORK_OWNER=$(git remote get-url \"$FORK_REMOTE\" | sed -E 's|.*[:/]([^/]+)/[^/]+(\\.git)?$|\\1|')\n```\n\n```bash\ngh pr create --repo docker/docs \\\n --head \"${FORK_OWNER}:\" \\\n --title \"\" \\\n --body \"$(cat <<'EOF'\n## Summary\n\n<1-2 sentences: what was wrong and what was changed>\n\nCloses #NNNN\n\nGenerated by \nEOF\n)\"\n```\n\nPrefix the title with the change type to match repo convention — `docs:` for\ndocumentation changes (or another scope like `hub:` when appropriate), for\nexample `docs: fix broken link on install page`.\n\nKeep the body short. Reviewers need to know what changed and why — nothing\nelse. Do **not** add a \"Test plan\" section — documentation PRs don't need one.\n\nUse an accurate disclosure footer that names the active coding agent, for\nexample `Generated by Codex` or `Generated by Claude Code`.\n\n### Optional: Netlify preview entry path\n\nIf the PR primarily edits a single page or a focused section of pages, add a\n`@netlify` stanza to the PR body (for example, just below the Summary). This\nsets the entry path for the Netlify deploy preview so reviewers land on the\nedited page instead of the site root:\n\n```markdown\n@netlify /desktop/setup/install/\n```\n\nThe stanza takes a single published URL path. Derive it from the source file\npath: drop the `content/` prefix and `.md` suffix, strip the `/manuals`\nsegment, and add a trailing slash. For example,\n`content/manuals/desktop/setup/install/mac-install.md` becomes\n`/desktop/setup/install/mac-install/`.\n\nOnly add this when the change is focused on one page or section. Skip it for\nPRs that touch many unrelated pages — there is no useful single entry path.\n\n### Optional: Preview links\n\nWhen the change is focused, also add direct links to the deploy preview in the\nPR body so reviewers can jump straight to the affected pages. The preview URL\nembeds the PR number:\n\n```\nhttps://deploy-preview---docsdocker.netlify.app/path/to/page/\n```\n\nThe PR number isn't known until `gh pr create` returns, so add these links\nafter creating the PR by updating the body:\n\n```bash\ngh pr edit --repo docker/docs --body \"...\"\n```\n\nUse the same source-path-to-URL mapping as the `@netlify` stanza above.\n\n## 4. Apply labels and request review\n\nUse the Issues API for labels — `gh pr edit --add-label` silently fails:\n\n```bash\ngh api repos/docker/docs/issues//labels \\\n --method POST \\\n --field 'labels[]=status/review'\n```\n\nRequest review:\n\n```bash\ngh pr edit --repo docker/docs --add-reviewer docker/docs-team\n```\n\nVerify the reviewer was assigned:\n\n```bash\ngh pr view --repo docker/docs --json reviewRequests \\\n --jq '.reviewRequests[].slug'\n```\n\nIf the team doesn't appear, use the API directly:\n\n```bash\ngh api repos/docker/docs/pulls//requested_reviewers \\\n --method POST --field 'team_reviewers[]=docs-team'\n```\n\n## 5. Report\n\nPrint the PR URL and current CI state:\n\n```bash\ngh pr view --repo docker/docs --json url,state\ngh pr checks --repo docker/docs --json name,state\n```\n\n## Notes\n\n- Always use `Closes #NNNN` (not \"Fixes\") for GitHub auto-close linkage\n- One issue, one branch, one PR — never combine\n",".agents/skills/fix-issue/SKILL.md":"---\nname: fix-issue\ndescription: >\n Fix a single GitHub issue end-to-end: triage, research, write the fix,\n review, and create a PR. Use when asked to fix an issue: \"fix issue 1234\",\n \"resolve #500\", \"create a PR for issue 200\".\nargument-hint: \"\"\n---\n\n# Fix Issue\n\nGiven GitHub issue **$ARGUMENTS**, decide what to do with it and either\nclose it or fix it. This skill orchestrates the composable skills — it owns\nthe decision tree, not the individual steps.\n\n## 1. Triage\n\nInvoke `/triage-issue $ARGUMENTS` to understand the issue and decide what\nto do. This runs in a forked subagent and returns a verdict.\n\n## 2. Act on the triage result\n\nIf triage says **close it** — comment with the reason and close:\n```bash\ngh issue close $ARGUMENTS --repo docker/docs \\\n --comment \"\n\nGenerated by \"\n```\nDone.\n\nIf triage says **escalate upstream** — comment noting the repo and stop:\n```bash\ngh issue comment $ARGUMENTS --repo docker/docs \\\n --body \"This needs to be fixed in .\n\nGenerated by \"\n```\nDone.\n\nIf triage says **leave it open** — comment explaining what was checked and\nwhat's unclear. Do not close.\nDone.\n\nEnd every issue comment with an accurate agent-disclosure footer that names\nthe active coding agent, for example `Generated by Codex` or `Generated by\nClaude Code`.\n\nIf triage says **fix it** — proceed to step 3.\n\n## 3. Research\n\nInvoke `/research` to locate affected files, verify facts, and identify\nthe fix. The issue context carries over from triage. This runs inline —\nfindings stay in conversation context for the write step.\n\nIf research reveals the issue is upstream or cannot be fixed (e.g.\nunverifiable URLs), comment on the issue and stop.\n\n## 4. Write\n\nInvoke `/write` to create a branch, make the change, format, self-review,\nand commit.\n\n## 5. Review\n\nInvoke `/review-changes` to check the diff for correctness, coherence, and\nmechanical compliance. This runs in a forked subagent with fresh context.\n\nIf issues are found, fix them and re-review until clean.\n\n## 6. Create PR\n\nInvoke `/create-pr` to push the branch and open a pull request.\n\n## 7. Return to main\n\n```bash\ngit checkout main\n```\n\n## 8. Report\n\nSummarize what happened: the issue number, what was done (closed, escalated,\nfixed with a PR link), and why — in a sentence or two.\n",".agents/skills/maintain-pr/SKILL.md":"---\nname: maintain-pr\ndescription: >\n Maintain and follow up on a single Docker documentation pull request that\n you own or are responsible for updating. Check CI and review feedback, fix\n actionable failures, push changes, reply to comments, and report status.\n Use for requests such as \"babysit this PR\", \"check the status of my PR\",\n \"fix CI on my PR\", or \"address review comments on #500\". Do not use for\n maintainer review of an incoming contribution; use review-pr for that.\n---\n\n# Maintain PR\n\nDo one maintenance pass over the specified author-owned PR: inspect its\nstate, fix actionable failures or feedback, reply to reviewers, and report\nthe result. This workflow may modify the branch and GitHub because the user\nis asking to maintain the PR. Do not apply it to an incoming PR merely\nbecause the user asks to review or assess it.\n\n## 1. Gather PR state\n\n```bash\ngh pr view --repo docker/docs --json state,title,url,headRefName,headRepositoryOwner,comments,reviews,reviewDecision\ngh pr checks --repo docker/docs --json name,state,detailsUrl\ngh api repos/docker/docs/pulls//comments \\\n --jq '[.[] | {id, author: .user.login, body, path, line, in_reply_to_id}]'\n```\n\nAlways check both top-level reviews and inline comments. A review with an\nempty body may still contain line-level feedback. Confirm that the PR is one\nthe user owns or is authorized to update before checking out or pushing its\nbranch. If not, stop and use `review-pr`.\n\n## 2. Handle terminal states\n\nIf merged, report the final state and identify unanswered review comments.\nReply only when the user remains responsible for follow-up.\n\nIf closed without merge, read the closing context and report the reason.\nCommon causes include maintainer rejection, supersession, or automation.\n\n## 3. Diagnose CI failures\n\n- Read the failure details.\n- Determine whether the failure comes from the PR or predates it.\n- Fix actionable failures in the PR's changed files.\n- Report pre-existing or upstream failures without changing unrelated files.\n\nFollow repository instructions for formatting, targeted linting, explicit\nstaging, commits, and pushes. Preserve unrelated working-tree changes.\n\n## 4. Address review feedback\n\nTreat every review comment as a claim to verify. Implement it only when the\nevidence supports it; explain any evidence-based disagreement.\n\nAfter each fix:\n\n1. Format and validate the changed files.\n2. Commit and push the focused change.\n3. Reply to every addressed thread with what changed or why no change was\n made.\n4. End replies with an accurate agent-disclosure footer, such as\n `Generated by Codex`.\n5. Resolve threads only after replying.\n6. Re-request review when appropriate.\n\nUse the inline comment endpoint to reply:\n\n```bash\ngh api repos/docker/docs/pulls//comments \\\n --method POST \\\n --field in_reply_to= \\\n --field body=''\n```\n\nUse GraphQL to retrieve unresolved review-thread IDs and resolve only the\nthreads that were addressed. Do not silently fix feedback without replying.\n\n## 5. Report\n\n```markdown\n## PR #: \n\n**State:** <open, merged, or closed>\n**CI:** <passing, failing, or pending>\n**Review:** <approved, changes requested, or pending>\n**Action taken:** <changes, replies, and thread resolution, or none needed>\n```\n",".agents/skills/create-lab-guide/SKILL.md":"---\nname: create-lab-guide\ndescription: \"Clone a dockersamples Labspace repo, extract learning objectives and module structure from labspace.yaml, and produce a Hugo guide page under content/guides/ with correct frontmatter, labspace-launch shortcode, and Docker docs style compliance. Use when asked to create a lab guide, write a Labspace page, add a Docker lab tutorial, migrate a lab to docs, or document a hands-on lab.\"\n---\n\n# Create Lab Guide\n\nCreate a guide page for a Docker Labspace: clone the source repo, extract\nstructure from `labspace.yaml`, write the Hugo markdown page, and validate.\n\n## Inputs\n\n- **REPO_NAME**: GitHub repo in the `dockersamples` org (e.g. `labspace-ai-fundamentals`)\n\n## Step 1: Clone the labspace repo\n\n```bash\nTMPDIR=$(mktemp -d)\ngit clone --depth 1 https://github.com/dockersamples/{REPO_NAME}.git \"$TMPDIR/{REPO_NAME}\"\n```\n\n## Step 2: Extract key information\n\nRead these files from the cloned repo:\n\n| File | Purpose |\n|------|---------|\n| `README.md` | Lab purpose and overview |\n| `labspace/labspace.yaml` | Module structure and content paths |\n| `labspace/*.md` | Module content (only files listed in `labspace.yaml`) |\n| `.github/workflows/*.yml` | Published Compose file URL for the launch command |\n| `compose.override.yaml` | Check for top-level `model` specs (triggers `model-download` param) |\n\nExtract:\n1. A short description for the `description` and `summary` frontmatter fields.\n2. Learning objectives from the module content.\n3. Whether a model download is required (`compose.override.yaml` → top-level `model` key).\n\n## Step 3: Write the guide markdown\n\nPlace the file at `content/guides/lab-{GUIDE_ID}.md`.\n\n```markdown\n---\ntitle: \"Lab: { Short title }\"\nlinkTitle: \"Lab: { Short title }\"\ndescription: |\n A short description of the lab for SEO and social sharing.\nsummary: |\n A short summary of the lab for the guides listing page. 2-3 lines.\nkeywords: AI, Docker, Model Runner, agentic apps, lab, labspace\naliases: # Include only for AI-related labs\n - /labs/docker-for-ai/{REPO_NAME_WITHOUT_LABSPACE_PREFIX}/\nparams:\n tags: [ai, labs]\n time: 20 minutes\n resource_links:\n - title: A resource link pointing to relevant documentation or code\n url: /ai/model-runner/\n - title: Labspace repository\n url: https://github.com/dockersamples/{REPO_NAME}\n---\n\nShort explanation of the lab and what it covers.\n\n## Launch the lab\n\n{{< labspace-launch image=\"dockersamples/{REPO_NAME}\" >}}\n\n## What you'll learn\n\nBy the end of this Labspace, you will have completed the following:\n\n- Objective #1\n- Objective #2\n- Objective #3\n\n## Modules\n\n| # | Module | Description |\n|---|--------|-------------|\n| 1 | Module #1 | Description of module #1 |\n| 2 | Module #2 | Description of module #2 |\n| 3 | Module #3 | Description of module #3 |\n```\n\nConditional rules:\n- All lab guides **must** include `labs` in `params.tags`.\n- AI-related labs: also add `ai` tag and an alias under `/labs/docker-for-ai/`.\n- If a model download is required: add `model-download: true` to the `labspace-launch` shortcode.\n\n## Step 4: Apply Docker docs style rules\n\nFollow STYLE.md and COMPONENTS.md. Key rules:\n\n| Avoid | Use instead |\n|-------|-------------|\n| \"we\", \"let's\" | Imperative voice or \"you\" |\n| \"simply\", \"easily\", \"just\" | Remove the hedge word |\n| \"allows you to\" / \"enables you to\" | \"lets you\" or rephrase |\n| \"click\" | \"select\" |\n| Bold for emphasis / product names | Bold only for UI elements |\n| \"currently\", \"new\", \"recently\" | Remove time-relative language |\n\nUse `console` as the language hint for shell blocks with `$` prompts.\nUse contractions (\"it's\", \"you're\", \"don't\").\n\n## Step 5: Validate\n\n1. Confirm frontmatter has `title`, `description`, `keywords`, and `params.tags` including `labs`.\n2. Run `npx --no-install rumdl fmt <file>` to format.\n3. Run `docker buildx bake lint vale` and fix any errors.\n4. Re-read the file and verify: correct shortcode syntax, objectives match source content, modules match `labspace.yaml`, no vendored paths edited.\n\nDo not proceed to commit until validation passes.\n",".agents/skills/agent-readiness-audit/SKILL.md":"---\nname: agent-readiness-audit\ndescription: >\n Audit a documentation site for agent-friendliness: discovery, markdown\n delivery, crawlability, semantic structure, machine-readable surfaces,\n and content legibility. Use when asked to assess docs.docker.com or any\n docs site for AI/agent readiness, produce a scored report, compare with\n external scanners, or generate a remediation list. Triggers on:\n \"audit docs for agent readiness\", \"how agent-friendly is docs.docker.com\",\n \"score our docs for AI agents\", \"review llms.txt / markdown / crawlability\",\n \"create an agent-readiness remediation plan\".\nargument-hint: \"<base-url>\"\n---\n\n# Agent Readiness Audit\n\nAudit the live site, not the source tree alone. Prefer the same fetch path\nan external agent would use in the wild: direct HTTP requests, sitemap\nsampling, and page-level inspection.\n\nDo not reduce the result to a homepage-only scan or a binary checklist.\n\n## 1. Set scope\n\nUse `$ARGUMENTS` as the base URL when provided. Otherwise infer the base\nURL from context and state the assumption.\n\nDecide whether the host being audited is:\n\n- a docs-only host\n- an app/tool host\n- a mixed host\n\nThis matters for optional checks such as MCP, plugin manifests, or other\ntool discovery files. Do not penalize a docs-only host for missing\ntooling manifests that belong on a separate service.\n\nFor `docs.docker.com`, treat the public docs host as docs-only. Docker's\nMCP server is published separately, so missing MCP files on the docs host\nshould be reported as `N/A`, not as a failure.\n\n## 2. Gather sitewide signals\n\nAlways check these resources first:\n\n- `/llms.txt`\n- `/llms-full.txt`\n- `/robots.txt`\n- `/sitemap.xml`\n\nOnly check host-level tool manifests when the host is an app/tool host,\nmixed host, or explicitly advertises them:\n\n- `/.well-known/ai-plugin.json`\n- `/.well-known/agent.json`\n- `/.well-known/agents.json`\n\nUse the bundled script for a baseline:\n\n```bash\nbash .agents/skills/agent-readiness-audit/scripts/baseline-probes.sh \\\n \"$ARGUMENTS\"\n```\n\nThe script produces baseline evidence only. You still need to interpret\nwhat matters for a docs property and score it with the rubric.\n\nFor docs-only hosts, you may skip tool-manifest probes to reduce noise:\n\n```bash\nCHECK_TOOL_MANIFESTS=0 \\\n bash .agents/skills/agent-readiness-audit/scripts/baseline-probes.sh \\\n \"$ARGUMENTS\"\n```\n\n## 3. Sample representative pages\n\nUse the sitemap when available. Do not rely on the homepage alone.\n\nIf `llms.txt` exists, sample some URLs from it as well. This helps catch\nstale or misleading discovery surfaces that a sitemap-only sample would miss.\n\nSample at least 12 pages when the site is large enough, and cover multiple\npage types:\n\n- homepage or docs landing page\n- section landing pages\n- task guides\n- product manuals\n- reference or API pages\n- tutorial or learning pages\n\nIf the sitemap is missing or unusable, discover pages through internal\nlinks and note the lower confidence.\n\nIf the site has distinct delivery patterns, sample each one. For example:\n\n- normal content pages\n- generated reference pages\n- versioned docs\n- localized docs\n\n## 4. Run fetch-path checks on each sample\n\nFor each sampled page, verify:\n\n- HTML fetch status, content type, and final URL\n- `Accept: text/markdown` behavior\n- direct markdown route behavior such as `<page>.md` or another stable path\n- page-level markdown alternate links and whether they actually resolve\n- whether page actions such as \"Open Markdown\" agree with the working route\n- whether the HTML title or H1 matches the markdown H1 closely enough for\n retrieval parity\n- whether main content is present in the initial HTML\n- redirect chain length and canonical URL consistency\n- obvious chrome/noise in the markdown response\n\nDo not assume a `.md` mirror exists just because another site uses one.\nVerify the actual markdown path the site exposes.\n\nTreat these as separate signals:\n\n- negotiated markdown works\n- a stable direct markdown URL works\n- the page advertises the correct markdown URL\n\nIf the page advertises dead markdown alternates but a working markdown route\nexists, do not fail markdown delivery outright. Score it as a discoverability\nand consistency problem instead.\n\nFor API or generated reference pages, also verify whether a machine-readable\nasset such as OpenAPI YAML is directly linked and fetchable.\n\n## 5. Judge structure and legibility\n\nMeasure structural signals:\n\n- exactly one `h1`\n- sane heading hierarchy\n- `main` and `article` presence where appropriate\n- canonical tags\n- JSON-LD or breadcrumb structured data\n- stable anchors and deep-linkable headings\n\nAlso make a qualitative judgment about agent legibility:\n\n- markdown strips site chrome cleanly\n- headings are specific and task-oriented\n- code blocks stay intelligible without client-side JS\n- the page is not dominated by banners, injected chat, or nav noise\n\nMeasure code block labeling explicitly when code samples are common. A page\ntype with many untagged fenced blocks should lose points even if the prose is\notherwise clean.\n\nFor page types that intentionally render interactive UIs with JavaScript,\njudge them separately from normal docs pages. If the HTML shell is thin,\ncheck whether the page still provides:\n\n- a fetchable markdown summary\n- a directly linked machine-readable asset\n- a usable non-JS fallback\n\n## 6. Score with the rubric\n\nUse [references/rubric.md](references/rubric.md).\n\nRules:\n\n- score only what you verified\n- mark non-applicable checks as `N/A`\n- normalize the final score against applicable points only\n- do not let optional manifest checks dominate the grade\n\nApply the foundational caps from the rubric. A site with broken discovery\nor broken markdown delivery should not earn a high grade because it has\nclean metadata.\n\nDo not average away a weak page type. If one major page type, such as API\nreference, is materially worse than the rest of the corpus, call it out as\nthe weakest segment and reflect it in the category notes.\n\n## 7. Compare with external scanners when useful\n\nIf external scanner results are available, compare them to your live\nfindings. Treat them as secondary evidence.\n\nIf a scanner and the live fetch disagree:\n\n- trust the live fetch\n- report the mismatch explicitly\n- explain whether the scanner is testing a different assumption\n\n## 8. Produce a remediation list\n\nTurn findings into a short backlog:\n\n- `P0`: fetchability or discovery blockers\n- `P1`: recurring structural or parity issues\n- `P2`: polish, optional manifests, or low-impact enhancements\n\nFor each remediation, include:\n\n- the failing signal\n- why it matters to agents\n- a concrete fix\n- whether it is sitewide or page-type-specific\n\n## 9. Report in a stable format\n\nUse [references/report-template.md](references/report-template.md).\n\nAlways include:\n\n- overall score and grade\n- confidence level\n- sampled URLs or sample strategy\n- category scores\n- highest-priority findings\n- remediation backlog\n\n## Notes\n\n- Favor docs-delivery checks over marketing-site heuristics.\n- Do not fail a docs host for lacking MCP or plugin manifests unless the\n host itself is meant to expose tools.\n- Treat raw byte size as supporting evidence, not as a primary scoring input.\n- Prefer short evidence excerpts and commands over long copied page text.\n",".agents/skills/migrate-content-ia/SKILL.md":"---\nname: migrate-content-ia\ndescription: >\n Handle Hugo docs information-architecture moves: discover old vs new URLs,\n add front matter aliases (Phase 1), update in-repo links (Phase 2), interactive\n List 2 resolution and fragment validation (Phase 3; no guessing). Supports\n PR-scoped mapping plus whole-content sweeps for inbound links to that mapping,\n or a full-site follow-up. Triggers on: \"IA migration\", \"redirects for moved\n pages\", \"fix links after content move\", \"PR-scoped link/anchor pass\",\n \"aliases for old URLs\". After branch work, chain the review-changes skill\n (main...HEAD) before a PR. Agents must run the in-file required procedure\n and definition of done, not the phases alone in isolation.\n---\n\n# Migrate content IA (redirects + links + anchors)\n\nUse this skill when pages **move or rename** under `content/` and you must\npreserve old public URLs and/or fix cross-references. Work in **phases**;\nchoose **PR-scoped** vs **full-site** mode per run.\n\n**Read first:** **CLAUDE.md** / **AGENTS.md** (URL rules, vendored areas, external\nlinks, special cases) and **hugo.yaml** (`permalinks`, `refLinksErrorLevel`,\n`disablePathToLower`). For **prose and link text**, follow **STYLE.md**; for\n**components, front matter, and link examples**, follow **COMPONENTS.md**.\n\n**Related skills:** **research** helps map moves and find inbound links; **write**\ncommits minimal edits. Run this skill’s phases after the move is identified (or\nin parallel with research for large IA work).\n\n## Agent: required procedure (do not skip)\n\n**Common mistake (wrong):** use **`git diff main...HEAD` (or the PR’s file\nlist) as the full set of places to fix links** for a migration. That set shows\n**what *moved***; it is **not** the list of every page that **points *to*** a\nmoved page. Inbound stragglers are often in files the PR **never** touched. You\nmust still **sweep the repo** for every string in the **old path and published-URL set**\nfor this run, not only for “files in the diff.”\n\n**Definition of done (when the migration is *finished*):** **Both** of the\nfollowing (unless the user or **AGENTS.md** **explicitly defers** a **List 2**\nitem in **Phase 3**; document the deferral):\n\n1. **`docker buildx bake validate`** passes for the branch, with no new\n build/link errors from this work.\n2. A **sweep of the old path and published-URL set for this run** (see\n [Sweep commands](#sweep-commands) below) finds **no** remaining\n migration-relevant **inbound** reference—**including**:\n - links to an old **source** path (plain `.md` and equivalent `ref` forms),\n - links that use the old path **and** a `#fragment`,\n - and, where your mapping includes them, old **published-style** `link:` /\n `url:` / full-site URL strings, \n **except** intentional entries to keep: for example `aliases` on the **new**\n canonical page, or **redirects.yml** *sources* you must not edit per policy.\n (A hit on a **source** that is only an `alias` line on the new page is\n **expected**—do not “fix” that away; distinguish alias rows from straggler\n links in body or nav config.)\n\n**Chaining (policy):** when this branch’s content work is ready for handoff,\n**run the [review-changes](../review-changes/SKILL.md) skill** on\n**`main...HEAD`** (or **`merge-base`…`HEAD`** for a different target branch) so\nthe **whole branch** is re-read for cross-page issues before opening a PR. Do\nnot treat phases 0–3 alone as the final check.\n\n**Run in order (mandatory for agents):**\n\n1. **Scope the moves (mapping input):** set the Git range like **review-changes**\n (for a PR to `main`: `git diff --name-only main...HEAD`; for another target:\n `BASE=$(git merge-base <target-branch> HEAD)` then\n `git diff --name-only $BASE...HEAD`, as in **Phase 0.5**). Include\n renames; build the **old → new** table (source and published) per **Phase\n 0**.\n2. **Sweep and list:** for every **old** path/URL in that table, run\n [Sweep commands](#sweep-commands) on the **allowed** trees. Record\n every hit as **List 1** (no `#`) or **List 2** (old path with `#...`) per\n **Phase 0.5**.\n3. **Phased edits:** **Phase 1** (`aliases`), then **Phase 2** (List 1), then\n **Phase 3** (List 2) with **no guessing**—as in the sections below.\n4. **Re-sweep** the same old-path set, then run **`docker buildx bake\n validate`**. The **Definition of done** above is met or you have **explicit\n defers** for the remainder.\n5. **review-changes:** run **[review-changes](../review-changes/SKILL.md)**\n on the branch vs **`main`…`HEAD`** (or the correct base) before a PR.\n\n### Sweep commands\n\nUse a **repository** search (e.g. `rg` / your IDE) so **nothing** in the\nallowed scope is only eyeballed.\n\n**Trees to include** (at minimum): all of `content/`, plus **`data/`** and\n**`layouts/`** when a migration can appear in config, `link:`-like fields,\nshortcodes, or hardcoded path strings. Follow **Vendored / generated** rules in\n**AGENTS.md**; do not edit disallowed files.\n\n**What to search for (repeat per row in the old side of the mapping):**\n\n- **Hugo / source form:** path segments that identify the *old* file, e.g.\n `manuals/.../old-segment/...` or `../old-segment/.../page.md` as your tree\n uses; include variants that still appear in the repo.\n- **Published / site form:** e.g. `/admin/.../old-slug/` in front matter, nav\n `url:`, or `https://docs.docker.com/...` in allowed files—**match the\n file’s** established pattern, per **Conventions** below.\n- **Anchors:** search for the **old path string**; matches that also include\n `#...` belong on **List 2** for **Phase 3** unless the whole link is\n a pure path-only case.\n\n[scripts/scope-pr-files.sh](scripts/scope-pr-files.sh) (if present) prints\n**`PR_SCOPE_FILES` only**—it does **not** replace this sweep. Use it to build\nthe **old → new** table, **not** to list where inbound links were fixed.\n\n## Progressive disclosure (optional)\n\nThe procedure below stays in this file. If a run produces a very large\n**old → new** URL table, store that table in **`reference.md`** in this skill\ndirectory and link it from the task summary, so the agent reads the long\nmapping only when needed.\n\n## Modes\n\n- **PR-scoped (typical for a single PR)** \n - **What the PR “owns” (focus):** use `git diff` / `base...HEAD` to know which\n pages and renames the branch actually moves (`PR_SCOPE_FILES`). The **old →\n new** mapping and **List 1 / List 2** for this migration are defined from\n **that** work, not from unrelated areas.\n - **Where to look for stale references (sweep):** search broadly—typically all\n of `content/` (and config, shortcodes, layouts, per Conventions)—for **inbound**\n links and fields whose **target** is an **old** path or URL in **this** PR’s\n mapping. Inbound stragglers are often in files the PR never touched; finding\n them is **in scope** for this migration. \n - **What to edit:** update **any** file in the allowed trees that contains a\n **migration-relevant** reference (target ∈ this PR’s old path set) according\n to the phases below. **Do not** treat `PR_SCOPE_FILES` as a hard limit on\n *which files you may save* for **inbound** link repairs (unless\n project policy for a given PR says otherwise; then follow policy and\n **defer** out-of-PR file fixes).\n - **Out of scope (defer / ignore in this run):** link and anchor problems that\n are **not** about this PR’s old→new map—e.g. a different area’s own slug\n issues, rot unrelated to the remapped path set. *Example:* a PR that only\n remaps `content/strawberry/...` should not “fix the whole site”; it **should**\n still fix a link under `mango/…` that **points at** an old `strawberry/…` path\n in the mapping, and **should not** chase **mango/**-only issues that do\n not involve those old targets.\n\n- **Full-site (complete migration after the PR)** \n - Update stragglers **across the repo** (or all inbound links to moved\n sections), including config-driven `link:` fields if policy allows. \n - Still make **minimal** edits; no drive-by rewrites to **unrelated** targets\n outside the run’s **declared** mapping and lists.\n\n### No guessing\n\n- The agent must **not** guess **replacement paths, published URLs, or fragment\n IDs** (including for consolidated pages, renamed headings, or\n “semantic” remaps of `#anchor` → new `#…`). If the user has not given an\n explicit new target, **ask**, **defer**, or **stop** per **AGENTS.md**; never\n infer, autocomplete, or substitute a plausible fragment from the target page’s\n heading list. That rule applies in **every** phase, including after validation\n in Phase 3.\n\n---\n\n## Conventions (links, anchors, redirects)\n\n### Front matter `aliases` (redirects)\n\n- Per **COMPONENTS.md**, `aliases` are **URLs that redirect to this page**.\n- Add or **merge** on the **new canonical** page; do not drop unrelated\n entries. Match local examples: **published-style paths** (leading `/`), and\n **trailing `/`** when that matches existing pages in the same area.\n- **No** speculative redirects for URLs that were never published.\n- **Collision check** before adding: no other page or redirect may already\n own the same old path.\n- If the site also uses **`data/redirects.yml`**, only add entries when\n project policy requires it; avoid duplicating the same old URL in\n `aliases` **and** `redirects.yml` unless maintainers do.\n\n### Internal links in Markdown (STYLE.md + COMPONENTS.md)\n\n- Use **relative paths to source files** (e.g. `../section/page.md`) with\n **`.md`**, following **COMPONENTS.md** examples, unless the file already\n uses an established pattern (e.g. some `link:` or nav fields use **published**\n paths without `manuals` or `.md` — **match the surrounding file**).\n- Keep **CLAUDE.md** / **AGENTS.md** rules: internal ref targets under\n `content/manuals/...` often use the full **`/manuals/...`** path; published\n URLs omit the `manuals` segment—do not confuse the two when fixing links.\n- **Link text (STYLE.md):** descriptive, ~**5 words**; no “click here” or\n “learn more”; **no** end punctuation **inside** the link text; **no** bold/italic\n on link text unless normal in the sentence.\n- **Headings (STYLE):** **sentence case**; do not rename headings in passing\n unless the migration requires it (heading changes break fragments).\n\n### Shortcodes and layouts (links not only in Markdown)\n\n- **Phase 2–3 scope includes** any **shortcode or layout partial** (under\n **Modes**, search broadly for inbound links to the migration; **edits** follow\n the same file-level rules as for Markdown) that emits links: e.g. `ref` /\n `relref`, `link` fields in shortcode args, or hardcoded\n `docs.docker.com` / path strings. Grep for old paths, slugs, and fragments\n under `layouts/shortcodes/` (and `layouts/_default/` if partials build nav).\n- Match each file’s existing pattern; do not rewrite working shortcode style\n just to “clean up.”\n\n### Fragments / anchors (Phase 3)\n\n- List 1 / List 2: fragment-bearing **cross-references to old paths** are tracked\n on **List 2** in Phase 0.5; do not bulk-rewrite them in the **List 1** pass\n (Phase 2). See Phase 0.5 and Phase 2.\n- **Valid `#fragment` values:** after the user supplies a new fragment, it should\n match the **target** page’s **generated** heading ID (Hugo slugification; see\n **CLAUDE.md** / **AGENTS.md**). The agent still **validates** (see Phase 3) and\n must **not** “pick” a different id from the page to replace a bad answer—**No\n guessing**.\n- Same-page: `[Text](#section-id)`.\n- Cross-page: when user-provided, `#fragment` must still be checked against the\n **target** file. Validate fragments in shortcodes the same way as in body\n Markdown.\n\n### External URLs (**AGENTS.md**)\n\n- Do not commit **guessed** replacement URLs. If a URL cannot be verified,\n treat as blocked or drop the fragment per AGENTS guidance. See also **No\n guessing** above; internal and external link targets are treated the same for\n inference: **none** without user input or a verified source.\n\n### Special cases (**AGENTS.md**)\n\n- **Engine API version** pages: respect coordinated **`/latest/` `aliases`**\n rules—never leave two version files both owning `/latest/`.\n- **Vendored / generated** trees: read-only; see CLAUDE.md. Do not “fix” links\n there if policy forbids.\n\n---\n\n## Phase 0 — Discovery (read-only; may use whole repo)\n\n1. Read **hugo.yaml** (permalinks, `refLinksErrorLevel`, `disablePathToLower`).\n2. From the branch (diff, renames), build a **mapping table**:\n - old source path → new source path \n - old published URL → new published URL (from permalink rules)\n3. **Case:** with `disablePathToLower: true`, filesystem path **case** appears in\n URLs—**directory and link casing must match** (e.g. `setup` vs `Setup`).\n4. When planning **inbound link** fixes, treat old-path references as two\n categories: **no fragment** vs **with `#fragment`**. That split feeds\n **List 1** and **List 2** in Phase 0.5 and drives Phase 2 ordering (see\n there).\n\n---\n\n## Phase 0.5 — PR-scoped evaluation (required before edits in PR mode)\n\n1. **Set `PR_SCOPE_FILES` (Git scope for PR mode)** \n - When the PR **targets `main`**, use the same triple-dot form as\n **review-changes**: \n `git diff --name-only main...HEAD` \n - For a **different target branch** or a custom base, use the merge base: \n `BASE=$(git merge-base <target-branch> HEAD)` \n then: \n `git diff --name-only \"$BASE\"...HEAD` \n - Those paths define **what moved** in the branch; they are the primary input\n to the **old → new** path/URL table. They are **not** a hard cap on *where\n to search* for **inbound** links (see **Modes**): sweeps for links **to** old\n paths usually cover all of `content/` (and other trees per Conventions). \n - If project policy **limits edits** to the diff for a given PR, follow that\n and **defer** link fixes in files outside the diff; note the exception in\n the task if the user relaxes that policy.\n\n2. Build checklists (see **Modes** for sweep vs area-of-work):\n - path/URL mapping this run must honor (old source path → new; old published\n → new, from the **PR’s** moves in PR-scoped mode, or the **declared** full\n migration in full-site mode)\n - **List 1 — old path, no fragment:** every **inbound** reference, found on\n the **sweep** surface, to a moved **old** path that does **not** include a\n `#...` fragment (e.g. `…/banana.md` in the repo’s link style for that\n file).\n - **List 2 — old path with fragment:** every **inbound** reference, found on\n the same sweep, to a moved **old** path that **includes** a `#...` fragment\n (e.g. `…/banana.md#anchor` or the published-style equivalent in context). The\n **same** old path string may appear on **both** List 1 and List 2 for\n different links; duplication across the two lists is OK.\n - **Matching rules:** when recording List 1 / List 2, use **one** consistent\n path representation for comparison (e.g. relative `../path/banana.md` vs\n root-anchored) **per the conventions in this doc** and the **surrounding\n file’s** established pattern. Agents compare and skip List 2 links in the\n List 1 pass using the **same** representation rules.\n3. **Out of scope** for the lists: only include references whose **old** target\n is in this run’s **mapping**. Do not build List 1/2 for unrelated **mango/**\n (or other) problems unless those links also target an **old** path that this\n migration renames. Defer those issues separately (see **Modes**).\n\n---\n\n## Phase 1 — `aliases` (old published URLs)\n\n1. On each **new** canonical page, add or merge **`aliases`** for every **real**\n former public URL.\n2. Do not strip existing unrelated aliases.\n3. **PR-scoped:** add aliases only where the canonical file is in scope or the\n project requires it; otherwise list missing alias targets for follow-up.\n\n---\n\n## Phase 2 — In-repo link reference updates\n\n1. **List 1 first (path only):** update references that belong to **List 1**\n (old path, **no** fragment). Replace old source paths or old published URLs\n with the **new** targets; preserve each file’s link pattern (relative vs\n root-anchored `.md` paths). **Do not** apply the same bulk path replacement to\n links that appear in **List 2** (old path **with** `#...`) during this\n sub-step—**leave** every **List 2** link **unchanged** for now.\n2. **After List 1 is complete:** **re-scan** the **same** **sweep** surface as\n in Phase 0.5 (e.g. all of `content/` plus config) or **print** a clear list of\n all **remaining** **List 2** entries. Those links should still point at the\n **old** path and **old** fragment until Phase 3. \n3. **Full-site (extra sweep):** after steps 1–2, still use **AGENTS “Page\n deletion checklist”**-style thoroughness for **config / front matter**\n `link:` and similar so nav and grids are not left on old slugs. Apply the\n **List 1 / List 2** rules there too: path-only old references first; defer\n fragment-bearing rewrites in line with **List 2** until Phase 3.\n4. **PR-scoped (which files to change):** apply List 1 and later Phase 3 updates\n to **every** file the **sweep** finds with a **migration-relevant** reference\n (inbound to an **old** path in the mapping), including files **not** in\n `PR_SCOPE_FILES`, per **Modes**. **Log** and **defer** (do not “fix”)\n unrelated stragglers. If policy forbids out-of-PR file edits, defer per step 1\n of Phase 0.5. \n5. Include **shortcodes and layout partials** (see Conventions and **Modes** for\n sweep vs focus).\n\n---\n\n## Phase 3 — List 2: interactive path and fragment resolution\n\n**Prerequisites:** Phase 2 has updated **List 1**; **List 2** still lists **old\npath + `#...`** (unchanged) for this migration. See **Modes** for which files\nmay be edited; **No guessing** applies.\n\n1. **Print List 2** to the user: every remaining **old path** + `#anchor` (in the\n agreed representation), so nothing is hidden before the loop.\n2. **For each distinct** `old-path#oldAnchor` (or process in the order the user\n prefers, one at a time): \n - Ask: **What is the new path (and fragment, if any) for this content?** The\n user may give a new source path, published URL, and/or `#newAnchor` per\n project conventions. \n - **Validate** the user’s answer: open the **target** page (or resolve the\n target) and check that `#newAnchor` (if any) **exists** as a real heading\n / generated id on that page, per **CLAUDE.md** / **AGENTS.md** (same rules\n as the rest of the site). **Do not** replace the user’s fragment with a\n “better” one from the file. \n - If validation **fails** (unknown target file, or `#newAnchor` not found on\n the page): **warn** clearly (what failed: path vs missing fragment), then\n **ask again** for a corrected path and/or fragment. **Repeat** until\n validation passes or the user **defers** / **drops** the fragment (per\n **AGENTS.md**). **Never** guess a new fragment to fix the problem. \n - When validation **passes:** update **all** in-repo references that match\n that **same** `old-path#oldAnchor` to the user-approved `new-path#newAnchor`\n (respect each file’s link style; include shortcodes/layouts on the same\n **sweep** surface as Phase 2). \n3. **Repeat** from step 1: **re-print** or **re-scan** for **List 2** until it is\n **empty** or the user defers the remainder. \n4. **PR-scoped / full-site:** the **loop** is the same. **Edits** follow **Modes**:\n migration-relevant **inbound** links may live in any file on the sweep; do\n not expand into **unrelated** link debt from other areas. Defer as in **Modes**\n and Phase 0.5.\n\n---\n\n## Optional: scripts helper\n\nThis skill includes a small **scope helper** so agents do not re-derive Git\nrecipes. See [scripts/scope-pr-files.sh](scripts/scope-pr-files.sh) — it prints\npaths in PR scope for a given target branch (default `main`).\n\n---\n\n## Verification\n\n```bash\ndocker buildx bake validate\n```\n\nUse the **Definition of done** in **Agent: required procedure (do not skip)**\nas the final bar: **validate** must pass, and the **sweep** must be clean for\n**plain** and **`#fragment`** old-path references, **or** the remainder must be\n**explicitly deferred** in **Phase 3** per **AGENTS.md** / the user. Mid-run,\n**Phase 2** may still leave **List 2** links unchanged **until** Phase 3; that\nintermediate state is **not** the finished migration.\n",".agents/skills/research/SKILL.md":"---\nname: research\ndescription: >\n Research a documentation topic — locate affected files, understand the\n problem, identify what to change. Use when investigating an issue, a\n question, or a topic before writing a fix. Triggers on: \"research issue\n 1234\", \"investigate what needs changing for #500\", \"what files are\n affected by #200\", \"where is X documented\", \"is our docs page about Y\n accurate\", \"look into how we document Z\".\n---\n\n# Research\n\nInvestigate the topic and determine whether documentation needs to change.\nWhen an update is warranted, identify exact files, named targets within\nthose files, and the verified content needed.\n\n## 1. Gather context\n\nIf the input is a GitHub issue number, fetch it:\n\n```bash\ngh issue view <number> --repo docker/docs \\\n --json number,title,body,labels,comments\n```\n\nOtherwise, work from what was provided — a description, a URL, a question,\nor prior conversation context. Identify the topic, affected feature, or\npage to investigate.\n\n## 2. Locate affected files\n\nSearch `content/` using the URL or topic from the issue. Remember the\n`/manuals` prefix mapping when converting URLs to file paths.\n\nFor each candidate file, read the relevant section to confirm it contains\nthe reported problem.\n\n## 3. Check vendored ownership\n\nBefore planning any edit, verify the file is editable locally:\n\n- `_vendor/` — read-only, vendored via Hugo modules\n- `data/cli/` — read-only, generated from upstream YAML\n- `content/reference/cli/` — read-only, generated from `data/cli/`\n- Everything else in `content/` — editable\n\nIf the fix requires upstream changes, identify the upstream repo and note\nit as out of scope. See the vendored content table in CLAUDE.md.\n\n## 4. Find related content\n\nLook for pages that may need updating alongside the primary fix:\n\n- Pages that link to the affected content\n- Include files (`content/includes/`) referenced by the page\n- Related pages in the same section describing the same feature\n\n## 5. Verify facts\n\nIf the issue makes a factual claim about how a feature behaves, verify it.\nFollow external links, read upstream source, check release notes. Do not\nplan a fix based on an unverified claim.\n\nIf the fix requires a replacement URL and that URL cannot be verified (e.g.\nnetwork restrictions), report it as a blocker rather than guessing.\n\n## 6. Assess documentation impact\n\nA code change or release-note entry is evidence to investigate, not a reason\nby itself to add documentation. Identify the reader's task and what the\nchange alters about it. Recommend an update when existing guidance becomes\nincorrect, leaves a gap in that task, or omits a capability useful to readers.\nAn implementation fix may need no update if the docs already describe the\nintended behavior.\n\nFor each recommended update, connect the reader's task, the documentation\ngap, the destination page and section, and the proposed treatment. Prefer\ncorrecting existing prose or examples when they serve that task. Check related\npages for contradictions, without assuming each needs the same explanation.\n\nIf there is no clear home, reconsider the value and scope before proposing a\nsection or page. A separate home can be justified by a distinct reader task,\nnot by the need to place a release-note bullet. \"No documentation change\" is\na valid finding; explain it briefly when assessing a set of changes.\n\n## 7. Check the live site (if needed)\n\nFor URL or rendering issues, fetch the live page:\n\n```text\nhttps://docs.docker.com/<path>/\n```\n\n## 8. Report findings\n\nSummarize what you found — files to change, the specific problem in each,\nwhat the fix should be, and any constraints. This context feeds directly\ninto the write step.\n\nBe specific: name the file, the section or element within it, and the\nverified content needed. \"Fix the broken link in networking.md\" is not\nspecific enough. \"In `compose/networking.md`, the 'Custom networks' section,\nremove the note about `driver_opts` being ignored — this was fixed in\nCompose 2.24\" is.\n\n## Notes\n\n- Research quality bounds write quality. Vague research produces broad\n changes; precise research produces minimal ones.\n- Do not create standalone research files — findings stay in conversation\n context for the write step.\n",".agents/skills/testcontainers-guides-migrator/SKILL.md":"---\nname: testcontainers-guide-migrator\ndescription: >\n Migrate a Testcontainers guide from testcontainers.com into the Docker docs site (docs.docker.com).\n Converts AsciiDoc to Hugo Markdown, updates code to the latest Testcontainers API, splits into\n chapters with stepper navigation, verifies code compiles and tests pass, and validates against\n Docker docs style rules. Use when asked to migrate a testcontainers guide, add a TC guide, or\n port content from testcontainers.com to Docker docs.\n---\n\n# Migrate a Testcontainers Guide\n\nYou are migrating guides from https://testcontainers.com/guides/ into the Docker docs Hugo site.\nEach guide lives in its own GitHub repo under `testcontainers/tc-guide-*`, written in AsciiDoc.\nThe source repos are listed in the testcontainers-site build.sh:\nhttps://github.com/testcontainers/testcontainers-site/blob/main/build.sh#L23-L45\n\n## Inputs\n\nThe user provides one or more guides to migrate. Resolve these from the inventory below:\n\n- **REPO_NAME**: GitHub repo (e.g. `tc-guide-getting-started-with-testcontainers-for-java`)\n- **SLUG**: guide slug inside `guide/` dir (e.g. `getting-started-with-testcontainers-for-java`)\n- **LANG**: language identifier (go, java, dotnet, nodejs, python)\n- **GUIDE_ID**: short kebab-case name (e.g. `getting-started`)\n\n## Guide inventory\n\nThese are the 21 guides from testcontainers.com/guides/ and their source repos:\n\n| # | Title | Repo | Lang | GUIDE_ID |\n|---|-------|------|------|----------|\n| 1 | Introduction to Testcontainers | tc-guide-introducing-testcontainers | (none) | introducing |\n| 2 | Getting started for Java | tc-guide-getting-started-with-testcontainers-for-java | java | getting-started |\n| 3 | Testing Spring Boot REST API | tc-guide-testing-spring-boot-rest-api | java | spring-boot-rest-api |\n| 4 | Testcontainers lifecycle (JUnit 5) | tc-guide-testcontainers-lifecycle | java | lifecycle |\n| 5 | Configuration of services in container | tc-guide-configuration-of-services-running-in-container | java | service-configuration |\n| 6 | Replace H2 with real database | tc-guide-replace-h2-with-real-database-for-testing | java | replace-h2 |\n| 7 | Testing ASP.NET Core web app | tc-guide-testing-aspnet-core | dotnet | aspnet-core |\n| 8 | Testing Spring Boot Kafka Listener | tc-guide-testing-spring-boot-kafka-listener | java | spring-boot-kafka |\n| 9 | REST API integrations with MockServer | tc-guide-testing-rest-api-integrations-using-mockserver | java | mockserver |\n| 10 | Getting started for .NET | tc-guide-getting-started-with-testcontainers-for-dotnet | dotnet | getting-started |\n| 11 | AWS integrations with LocalStack | tc-guide-testing-aws-service-integrations-using-localstack | java | aws-localstack |\n| 12 | Testcontainers in Quarkus apps | tc-guide-testcontainers-in-quarkus-applications | java | quarkus |\n| 13 | Getting started for Go | tc-guide-getting-started-with-testcontainers-for-go | go | getting-started |\n| 14 | jOOQ and Flyway with Testcontainers | tc-guide-working-with-jooq-flyway-using-testcontainers | java | jooq-flyway |\n| 15 | Getting started for Node.js | tc-guide-getting-started-with-testcontainers-for-nodejs | nodejs | getting-started |\n| 16 | REST API integrations with WireMock | tc-guide-testing-rest-api-integrations-using-wiremock | java | wiremock |\n| 17 | Local dev with Testcontainers Desktop | tc-guide-simple-local-development-with-testcontainers-desktop | java | local-dev-desktop |\n| 18 | Micronaut REST API with WireMock | tc-guide-testing-rest-api-integrations-in-micronaut-apps-using-wiremock | java | micronaut-wiremock |\n| 19 | Micronaut Kafka Listener | tc-guide-testing-micronaut-kafka-listener | java | micronaut-kafka |\n| 20 | Getting started for Python | tc-guide-getting-started-with-testcontainers-for-python | python | getting-started |\n| 21 | Keycloak with Spring Boot | tc-guide-securing-spring-boot-microservice-using-keycloak-and-testcontainers | java | keycloak-spring-boot |\n\nAlready migrated: **#2 (Java getting-started)**, **#13 (Go getting-started)**, **#20 (Python getting-started)**\n\n## Step 0: Pre-flight\n\n1. Confirm `testing-with-docker` tag exists in `data/tags.yaml`. If not, add:\n ```yaml\n testing-with-docker:\n title: Testing with Docker\n ```\n2. Check if new terms need adding to `_vale/config/vocabularies/Docker/accept.txt`.\n3. Read `STYLE.md` and `COMPONENTS.md` to refresh on Docker docs conventions.\n\n## Step 1: Clone the guide repo\n\nClone the guide repo to a temporary directory. This gives you all source files locally — no HTTP calls needed.\n\n```bash\ngit clone --depth 1 https://github.com/testcontainers/{REPO_NAME}.git <tmpdir>/{REPO_NAME}\n```\n\nWhere `<tmpdir>` is a temporary directory on your system (e.g. the output of `mktemp -d`).\n\nThe repo structure is:\n- `<tmpdir>/{REPO_NAME}/guide/{SLUG}/index.adoc` — the AsciiDoc guide source\n- `<tmpdir>/{REPO_NAME}/src/` — application source code (referenced by `include::` directives)\n- `<tmpdir>/{REPO_NAME}/testdata/` — test data files (SQL scripts, configs, etc.)\n- `<tmpdir>/{REPO_NAME}/pom.xml` or `go.mod` — build config\n\n1. Read `guide/{SLUG}/index.adoc` to get the guide content.\n2. Find all `include::{codebase}/path/to/file[]` directives. The `{codebase}` attribute points to a remote URL, but since you have the repo cloned, read the files directly from disk instead (e.g. `include::{codebase}/src/main/java/Foo.java[]` → read `<tmpdir>/{REPO_NAME}/src/main/java/Foo.java`).\n3. If includes have `[lines=\"X..Y\"]`, extract only those lines from the local file.\n4. Note the `[source,lang]` block preceding each include — that determines the code fence language.\n\nThis cloned repo also serves as the base for Step 6 (code verification) — you can run the tests directly in it to confirm they pass before updating the code to the latest API.\n\n## Step 2: Convert AsciiDoc to Markdown\n\n| AsciiDoc | Markdown |\n|---|---|\n| `== Heading` | `## Heading` |\n| `=== Heading` | `### Heading` |\n| `*bold*` (AsciiDoc bold) | `**bold**` |\n| `https://url[Link text]` | `[Link text](url)` |\n| `[source,lang]\\n----\\ncode\\n----` | `` ```lang\\ncode\\n``` `` |\n| `[source,shell]` with `$` prompts | `` ```console `` |\n| `[NOTE]\\ntext` or `====\\n[NOTE]\\n...\\n====` | `> [!NOTE]\\n> text` |\n| `[TIP]\\ntext` | `> [!TIP]\\n> text` |\n| `:toc:`, `:toclevels:`, `:codebase:` | Remove entirely |\n| `include::{codebase}/path[]` | Replace with fetched code in a code fence |\n| YAML front matter (date, draft, repo) | Remove; transform to Docker docs format |\n\n## Step 3: Apply Docker docs style rules\n\nThese are mandatory (from STYLE.md and AGENTS.md):\n\n- **No \"we\"**: \"We are going to create\" → \"Create\" or \"Start by creating\"\n- **No \"let us\" / \"let's\"**: → imperative voice or \"You can...\"\n- **No hedge words**: remove \"simply\", \"easily\", \"just\", \"seamlessly\"\n- **No meta-commentary**: remove \"it's worth noting\", \"it's important to understand\"\n- **No \"allows you to\" / \"enables you to\"**: → \"lets you\" or rephrase\n- **No \"click\"**: → \"select\"\n- **No bold for emphasis or product names**: only bold UI elements\n- **No time-relative language**: remove \"currently\", \"new\", \"recently\", \"now\"\n- **No exclamations**: remove \"Voila!!!\" etc.\n- Use `console` language hint for interactive shell blocks with `$` prompts\n- Use contractions: \"it's\", \"you're\", \"don't\"\n\n## Step 4: Update code to latest Testcontainers API\n\nResearch the latest API version for the target language before writing code.\n\n**Best practices reference**: The Testcontainers team maintains Claude skills with up-to-date API patterns and best practices for each language at https://github.com/testcontainers/claude-skills/ — check the relevant language skill (testcontainers-go, testcontainers-node, testcontainers-dotnet) for current API signatures, cleanup patterns, wait strategies, and anti-patterns to avoid.\n\nFor each language, check the cloned repo's existing code, then update to the latest API. Key patterns per language:\n\n**Go** (testcontainers-go v0.41.0):\n- `postgres.RunContainer(ctx, opts...)` → `postgres.Run(ctx, \"image\", opts...)`\n- `testcontainers.WithImage(...)` → image is now the 2nd positional param to `Run()`\n- Manual `WithWaitStrategy(wait.ForLog(...))` → `postgres.BasicWaitStrategies()`\n- `t.Cleanup(func() { ctr.Terminate(ctx) })` → `testcontainers.CleanupContainer(t, ctr)`\n- `if err != nil { log.Fatal(err) }` → `require.NoError(t, err)` (use testify require/assert)\n- Helper functions should accept `t *testing.T` as first param, call `t.Helper()`\n- No `TearDownSuite()` needed if `CleanupContainer` is registered in the helper\n- Go version prerequisite: 1.25+\n\n**Java** (testcontainers-java 2.0.4):\n- Artifacts renamed in 2.x: `org.testcontainers:postgresql` → `org.testcontainers:testcontainers-postgresql`\n- Check the latest version at https://java.testcontainers.org/\n- Use `@Testcontainers` and `@Container` annotations for JUnit 5 lifecycle\n- Prefer module-specific containers (e.g. `PostgreSQLContainer`) over `GenericContainer`\n- Use `@DynamicPropertySource` for Spring Boot integration\n\n**.NET** (testcontainers-dotnet):\n- Check the latest NuGet package version\n- Use `IAsyncLifetime` for container lifecycle in xUnit\n- Use builder pattern: `new PostgreSqlBuilder().Build()`\n\n**Node.js** (testcontainers-node):\n- Check the latest npm version\n- Use module-specific packages (e.g. `@testcontainers/postgresql`)\n- Use `GenericContainer` for services without a dedicated module\n\n**Python** (testcontainers-python):\n- Check the latest PyPI version\n- Use context managers (`with PostgresContainer() as postgres:`)\n- Use module-specific containers when available\n\nFor all languages: consult the corresponding Testcontainers skill at https://github.com/testcontainers/claude-skills/ for current best practices and anti-patterns.\n\n## Step 5: Create guide directory structure\n\nDirectory: `content/guides/testcontainers-{LANG}-{GUIDE_ID}/`\n\nEach guide is its own top-level entry under `/guides/`. Do NOT nest guides inside a shared parent section — otherwise they won't appear individually in the tag/language filters on the guides listing page.\n\n### _index.md (landing page)\n\n```yaml\n---\ntitle: {Full guide title}\nlinkTitle: {Short title for guides listing}\ndescription: {One-line description}\nkeywords: testcontainers, {lang}, testing, {technologies used}\nsummary: |\n {2-3 line summary for the guides listing card}\ntoc_min: 1\ntoc_max: 2\ntags: [testing-with-docker]\nlanguages: [{lang}]\nparams:\n time: {estimated} minutes\n---\n\n<!-- Source: https://github.com/testcontainers/{REPO_NAME} -->\n```\n\nContent: what you'll learn (bulleted list), prerequisites, and a NOTE linking to `https://testcontainers.com/getting-started/` for newcomers.\n\n### Sub-pages (chapters)\n\nSplit the guide into logical chapters. Each sub-page:\n\n```yaml\n---\ntitle: {Chapter title}\nlinkTitle: {Short title for stepper}\ndescription: {One-line description}\nweight: {10, 20, 30, ...}\n---\n```\n\n**No `tags`, `languages`, or `params` on sub-pages** — only on `_index.md`.\n\nTypical chapter breakdown:\n| Weight | File | Content |\n|--------|------|---------|\n| 10 | `create-project.md` | Project setup, dependencies, business logic |\n| 20 | `write-tests.md` | First test using testcontainers |\n| 30 | `test-suites.md` | Reusing containers, test helpers, suites |\n| 40 | `run-tests.md` | Running tests, summary, further reading |\n\nAdapt the split to the guide's content — some guides may need fewer or more chapters.\n\n## Step 6: Verify code compiles and tests pass\n\nThis is CRITICAL. The code in the guide MUST compile and all tests MUST pass. Do not skip this step.\n\n### 6a: Use the cloned repo as the verification project\n\nThe repo you cloned in Step 1 (`<tmpdir>/{REPO_NAME}`) already contains a working project with all source files, build config, and tests. Use it as the starting point:\n\n```bash\ncd <tmpdir>/{REPO_NAME}\n```\n\nFirst, verify the **original** code compiles and tests pass before you change anything. This confirms a good baseline.\n\n### 6b: Update the code in the cloned repo\n\nAfter confirming the original works, apply the API updates (from Step 4) directly in the cloned repo's source files. This is the same code you're putting in the guide — keep them in sync.\n\n### 6c: Update dependencies and compile\n\nRun compilation inside a container for reproducibility — no need to install the language toolchain on the host. Use the appropriate language Docker image, mounting the cloned repo:\n\n```bash\ndocker run --rm -v \"<tmpdir>/{REPO_NAME}\":/app -w /app <language-image> sh -c \"<compile command>\"\n```\n\nPick the right image for the language (e.g. `golang:1.25-alpine`, `maven:3-eclipse-temurin-21`, `gradle:jdk21`, `mcr.microsoft.com/dotnet/sdk:9.0`, `node:22-alpine`, `python:3.13-alpine`). Update dependencies to the latest Testcontainers version and compile.\n\nIf compilation fails, fix the code and update the guide markdown to match.\n\n### 6d: Run tests in a container with Docker socket mounted\n\nRun tests in the same kind of container, but **mount the Docker socket** so Testcontainers can create sibling containers.\n\n#### macOS Docker Desktop workarounds\n\nWhen running on macOS with Docker Desktop, these environment variables and flags are **required**:\n\n- **`TESTCONTAINERS_HOST_OVERRIDE=host.docker.internal`** — On macOS, containers can't reach sibling containers via the Docker bridge IP (`172.17.0.x`). This tells Testcontainers (including Ryuk) to connect via `host.docker.internal` instead. **Do NOT disable Ryuk** — it is a core Testcontainers feature and the guides must demonstrate proper usage.\n- **`docker-java.properties`** with `api.version=1.47` — Docker Desktop's minimum API version is 1.44, but docker-java defaults to 1.24. Create this file in the project root and mount it to `/root/.docker-java.properties` inside Java containers.\n- **`-Dspotless.check.skip=true`** — The Spotless Maven plugin in the source repos is incompatible with JDK 21. Skip it since it's a code formatter, not part of the test.\n- **`-Dmicronaut.test.resources.enabled=false`** — Micronaut's Test Resources service starts a separate process that can't connect to Docker from inside a container. The guide tests use Testcontainers directly, not Test Resources. Only needed for Micronaut guides.\n#### Java guide test command\n\n```bash\n# Create docker-java.properties in the project root\necho \"api.version=1.47\" > <tmpdir>/{REPO_NAME}/docker-java.properties\n\ndocker run --rm \\\n -v \"<tmpdir>/{REPO_NAME}\":/app \\\n -v /var/run/docker.sock:/var/run/docker.sock \\\n -v \"<tmpdir>/{REPO_NAME}/docker-java.properties\":/root/.docker-java.properties \\\n -e DOCKER_HOST=unix:///var/run/docker.sock \\\n -e TESTCONTAINERS_HOST_OVERRIDE=host.docker.internal \\\n -w /app \\\n maven:3.9-eclipse-temurin-21 \\\n mvn -B test -Dspotless.check.skip=true -Dspotless.apply.skip=true\n```\n\nFor Quarkus guides, use `maven:3.9-eclipse-temurin-17` instead (Quarkus 3.22.3 compiles for Java 17).\n\n#### Go guide test command\n\n```bash\ndocker run --rm \\\n -v \"<tmpdir>/{REPO_NAME}\":/app \\\n -v /var/run/docker.sock:/var/run/docker.sock \\\n -e DOCKER_HOST=unix:///var/run/docker.sock \\\n -e TESTCONTAINERS_HOST_OVERRIDE=host.docker.internal \\\n -w /app \\\n golang:1.25-alpine \\\n sh -c \"apk add --no-cache gcc musl-dev && go test -v -count=1 ./...\"\n```\n\n#### Python guide test command\n\n```bash\ndocker run --rm \\\n -v \"<tmpdir>/{REPO_NAME}\":/app \\\n -v /var/run/docker.sock:/var/run/docker.sock \\\n -e DOCKER_HOST=unix:///var/run/docker.sock \\\n -e TESTCONTAINERS_HOST_OVERRIDE=host.docker.internal \\\n -w /app \\\n python:3.13-slim \\\n sh -c \"pip install -r requirements.txt && python -m pytest\"\n```\n\n#### .NET guide test command\n\n```bash\ndocker run --rm \\\n -v \"<tmpdir>/{REPO_NAME}\":/app \\\n -v /var/run/docker.sock:/var/run/docker.sock \\\n -e DOCKER_HOST=unix:///var/run/docker.sock \\\n -e TESTCONTAINERS_HOST_OVERRIDE=host.docker.internal \\\n -w /app \\\n mcr.microsoft.com/dotnet/sdk:9.0 \\\n dotnet test\n```\n\n#### Node.js guide test command\n\n```bash\ndocker run --rm \\\n -v \"<tmpdir>/{REPO_NAME}\":/app \\\n -v /var/run/docker.sock:/var/run/docker.sock \\\n -e DOCKER_HOST=unix:///var/run/docker.sock \\\n -e TESTCONTAINERS_HOST_OVERRIDE=host.docker.internal \\\n -w /app \\\n node:22-alpine \\\n sh -c \"npm install && npm test\"\n```\n\n#### Important: run tests sequentially\n\nRun guide tests **one at a time**. Running multiple concurrent DinD or sibling-container tests can overwhelm Docker Desktop's containerd store and cause `meta.db: input/output error` corruption, requiring a Docker Desktop restart.\n\n### 6e: Fix until green\n\nIf any test fails, debug and fix the code in both the temporary project AND the guide markdown. Re-run until all tests pass. Do not proceed until verified.\n\n## Step 7: Update cross-references\n\n1. **`content/manuals/testcontainers.md`**: Add a bullet under the `## Guides` section:\n ```markdown\n - [Guide title](/guides/testcontainers-{LANG}-{GUIDE_ID}/)\n ```\n2. **Do NOT update** `content/guides/testcontainers-cloud/_index.md` — keep its external links.\n3. Link to `https://testcontainers.com/getting-started/` for the Testcontainers overview.\n4. Use internal paths for already-migrated guides; keep `testcontainers.com` links for unmigrated ones.\n\n## Step 8: Validate\n\n**IMPORTANT**: Run ALL validation locally before committing. Vale checks run on CI and will block the PR if they fail — fixing after push wastes CI cycles and review time.\n\n1. `npx --no-install rumdl fmt content/guides/testcontainers-{LANG}-{GUIDE_ID}/`\n2. `npx --no-install rumdl fmt content/manuals/testcontainers.md`\n3. `docker buildx bake lint` — must pass with no errors\n4. `docker buildx bake vale` — then check for errors in the new files:\n ```bash\n grep -A2 \"testcontainers-{LANG}-{GUIDE_ID}\" tmp/vale.out\n ```\n Fix ALL errors before proceeding. Common issues:\n - **Vale.Spelling**: tech terms (library names, tools) not in the dictionary → add to `_vale/config/vocabularies/Docker/accept.txt` (alphabetical order)\n - **Vale.Terms**: wrong casing (e.g. \"python\" → \"Python\") → fix in the markdown. Watch for package names like `testcontainers-python` triggering false positives — rephrase to \"Testcontainers for Python\" in prose.\n - **Docker.Avoid**: hedge words like \"very\", \"simply\" → reword\n - **Docker.We**: first-person plural → rewrite to \"you\" or imperative\n - Info-level suggestions (e.g. \"VS Code\" → \"versus\") are not blocking but review them\n\n Re-run `docker buildx bake vale` after fixes until no errors remain in the new files.\n5. Verify in local dev server (`HUGO_PORT=1314 docker compose watch`):\n - Guide appears when filtering by its language\n - Guide appears when filtering by `Testing with Docker` tag\n - Stepper navigation works across chapters\n - All links resolve (no 404s)\n6. Verify all external URLs return 200:\n ```bash\n curl -s -o /dev/null -w \"%{http_code}\" -L \"{url}\"\n ```\n\n## Step 9: Commit\n\nOne commit per guide. Message format:\n```\nfeat(guides): add testcontainers {lang} {guide-id} guide\n\nMigrated from https://github.com/testcontainers/{REPO_NAME}\nUpdated to testcontainers-{lang} v{version} API.\n```\n\n## Special cases\n\n- **introducing-testcontainers**: Language-agnostic, conceptual. May overlap with `content/manuals/testcontainers.md`. Review for deduplication before migrating.\n- **local-dev-testcontainers-desktop**: About Testcontainers Desktop (now part of Docker Desktop). May need significant rewriting rather than mechanical migration.\n- **Java guides**: Many share the same language. Each still gets its own `testcontainers-java-{GUIDE_ID}` directory.\n\n## Reference: completed migration (Go getting-started)\n\nUse `content/guides/testcontainers-go-getting-started/` as the reference implementation:\n- `_index.md` — landing page with frontmatter, prerequisites, learning objectives\n- `create-project.md` (weight: 10) — project setup and business logic\n- `write-tests.md` (weight: 20) — first test with testcontainers-go\n- `test-suites.md` (weight: 30) — container reuse with testify suites\n- `run-tests.md` (weight: 40) — running tests, summary, further reading\n",".agents/skills/review-pr/SKILL.md":"---\nname: review-pr\ndescription: >\n Review one or more incoming Docker documentation pull requests as a\n maintainer. Independently validate technical claims, assess editorial fit\n and information architecture, choose a verdict, and draft exact inline or\n PR-wide feedback behind a confirmation gate. Use for requests such as\n \"review PR 123\", \"is this PR correct?\", \"does this information belong\n here?\", \"validate this PR\", or \"help review backlog PRs\". Do not use to\n maintain or fix a PR you own; use maintain-pr for that.\n---\n\n# Review PR\n\nReview incoming contributions for factual correctness and whether they make\nthe documentation better as a whole. Treat a technically true addition as\ninsufficient when it is misplaced, overemphasized, redundant, or unhelpful\nto the page's intended reader.\n\n## Preserve the write boundary\n\nPerform the review in two phases:\n\n1. Research the PR, decide a verdict, and present the exact proposed\n comment or review text.\n2. Wait for explicit user confirmation, then post only the confirmed text.\n\nBefore confirmation, do not post comments, submit a GitHub review, approve or\nrequest changes, resolve threads, push commits, edit labels, or otherwise\nmutate GitHub. A request to review or draft feedback is not confirmation to\npost it. Ask `Post these comments?` and stop. Treat revisions to a draft as\nunconfirmed until the user explicitly asks to post them.\n\n## 1. Gather the full context\n\nFor each PR, inspect its metadata, body, commits, changed files, checks,\nconversation, reviews, and linked issues. Always fetch inline comments\nseparately because `gh pr view --json reviews` omits them.\n\n```bash\ngh pr view <PR> --repo docker/docs \\\n --json number,title,url,state,author,body,baseRefName,headRefName,headRefOid,commits,files,comments,reviews,reviewDecision,statusCheckRollup\ngh api repos/docker/docs/pulls/<PR>/comments \\\n --jq '[.[] | {id, author: .user.login, body, path, line, side, commit_id}]'\ngh pr diff <PR> --repo docker/docs\n```\n\nRead linked issues and relevant discussion. An issue is evidence that a\nreader was confused, but it does not establish the reporter's diagnosis or\njustify a new highlighted note by itself. Green CI establishes only that automated\nchecks passed, not that the content is correct.\n\nFetch the PR head when local inspection is useful. Compare it with the\ncanonical upstream base rather than assuming the local branch is fresh.\nRead each changed file in full, not only its diff.\n\n## 2. Research independently\n\nVerify every material claim against authoritative sources such as product\nsource code, upstream documentation, specifications, release notes, or safe\nlocal reproduction. Do not accept the PR description, issue diagnosis, or\nexisting review feedback as fact.\n\nSearch the documentation for related explanations and canonical pages. Read\n`STYLE.md`, `COMPONENTS.md`, and applicable repository instructions. Check\nwhether a changed file is generated or maintained upstream and identify the correct\nupstream repository instead of proposing a local edit.\n\nDistinguish among:\n\n- a wrong fact\n- a correct fact expressed inaccurately\n- a correct fact placed on the wrong page\n- content already explained elsewhere\n- a real discovery problem better addressed with a short signpost and link\n- a request that needs no documentation change.\n\nIf an external claim or replacement URL cannot be verified, report that\nlimitation instead of guessing.\n\n## 3. Assess editorial fit\n\nApply these questions to each addition:\n\n- Does it change a reader's decision or next action on this page?\n- Is this the canonical page for the concept?\n- Is the fact general, or specific to this page, feature, or component?\n- Is the information already documented elsewhere?\n- Would a concise local signpost to canonical coverage solve the discovery\n problem better than duplicating the explanation?\n- Is the visual and textual weight proportional to the information's value?\n- Does it preserve the page's scope, flow, and character?\n\nPrefer one coherent explanation in the canonical location. Add local context\nonly when it helps the reader complete the task at hand. Avoid stray notes,\ncallouts, and exhaustive edge cases whose prominence exceeds their value.\n\n## 4. Choose a decisive verdict\n\nLead with one of these outcomes:\n\n- **Approve**: correct, useful, well placed, and ready to merge.\n- **Approve with optional polish**: ready to merge; suggestions are genuinely\n non-blocking.\n- **Focused rewrite**: the underlying need is valid, but wording, scope,\n placement, or structure should change before merge.\n- **Close / no docs change**: incorrect, redundant, out of scope, or not a\n documentation problem.\n\nExplain the verdict with evidence. When wording is the issue, provide exact\nreplacement text rather than a vague request to improve it.\n\n## 5. Place feedback deliberately\n\nUse an inline comment when the finding is anchored to a narrow changed line\nor range and acting on it is local. Examples include an inaccurate sentence,\nan ambiguous option description, a broken link, or a precise wording\nreplacement.\n\nUse a PR-wide comment for scope, information architecture, overall approach,\nmultiple intertwined edits, or a proposed replacement section. Do not attach\nholistic feedback to an arbitrary line.\n\nUse both when appropriate: put the overall direction in the PR-wide comment\nand line-specific corrections inline. Do not repeat the same point in both.\nConsolidate related feedback so the author receives the fewest comments that\nremain clear and actionable.\n\nFor every proposed inline comment, resolve and display the current changed\nfile path and right-side diff line. If the target line is not part of the\ncurrent diff or cannot be identified reliably, use a PR-wide comment that\nquotes the target text instead. Never guess a line number.\n\nEnd comments posted on the user's behalf with an accurate agent-disclosure\nfooter, such as `Generated by Codex`.\n\n## 6. Present drafts and stop\n\nBefore any GitHub write, show the review in this form, omitting empty\nsections:\n\n```markdown\n## Verdict\n\nFocused rewrite\n\n## Findings\n\n- <finding and evidence>\n\n## Proposed inline comments\n\n1. `path/to/file.md:42`\n > Exact comment text\n\n## Proposed PR-wide comment\n\n> Exact comment text\n\nPost these comments?\n```\n\nFor multiple PRs, give each PR its own verdict and comment set. Make the\nconfirmation scope unambiguous. Do not interpret approval of one PR's drafts\nas approval to post comments on the others.\n\n## 7. Post only confirmed feedback\n\nImmediately before posting, re-fetch the PR head SHA and diff. If either the\nhead or an inline target changed, stop and show the updated draft or\nplacement for confirmation.\n\nPost confirmed inline comments as a single comment-only review when\npractical. Use the current head SHA and right-side diff lines:\n\n```bash\ngh api repos/docker/docs/pulls/<PR>/reviews --method POST --input <payload>\n```\n\nThe JSON payload contains `commit_id`, `event: \"COMMENT\"`, and a `comments`\narray whose entries contain `path`, `line`, `side: \"RIGHT\"`, and `body`.\nSubmitting a review with `APPROVE` or `REQUEST_CHANGES` requires separate,\nexplicit user authorization; a verdict alone does not grant it.\n\nPost confirmed holistic feedback separately:\n\n```bash\ngh pr comment <PR> --repo docker/docs --body-file <file>\n```\n\nUse a safely created temporary file or API input so Markdown, backticks, and\nshell substitutions are preserved literally. Post exactly the confirmed\ntext. Verify the resulting review/comments and report their URLs and\nplacements. If GitHub rejects an inline location, do not silently fall back\nto a PR-wide comment; report the failure and prepare a revised placement for\nconfirmation.\n\n## Definition of done\n\n- Verify technical claims with authoritative evidence.\n- Evaluate usefulness, placement, duplication, and proportionality.\n- Give a decisive verdict and exact actionable wording.\n- Choose inline and PR-wide placement based on the feedback's scope.\n- Show every exact draft and target before any GitHub mutation.\n- Post only after explicit confirmation and verify what was posted.\n",".agents/skills/review-changes/SKILL.md":"---\nname: review-changes\ndescription: >\n Review uncommitted or recently committed documentation changes for\n correctness, coherence, and style compliance. Use before creating a PR\n to catch issues. \"review my changes\", \"review the diff\", \"check the fix\n before submitting\", \"does this look right\".\ncontext: fork\nmodel: opus\n---\n\n# Review Changes\n\nEvaluate whether the changes correctly and completely solve the stated\nproblem, without introducing new issues. Start with no assumptions — the\nchange may contain mistakes. Your job is to catch what the writer missed,\nnot to rubber-stamp the diff.\n\n## 1. Identify what changed\n\nDetermine the scope of changes to review:\n\n```bash\n# Uncommitted changes\ngit diff --name-only\n\n# Last commit\ngit diff --name-only HEAD~1\n\n# Entire branch vs main\ngit diff --name-only main...HEAD\n```\n\nPick the right comparison for what's being reviewed. If reviewing a branch,\nuse `main...HEAD` to see all changes since the branch diverged.\n\n## 2. Read each changed file in full\n\nDo not just read the diff. For every changed file, read the entire file to\nunderstand the full context the change lives in. A diff can look correct in\nisolation but contradict something earlier on the same page.\n\nThen read the diff for the detailed changes:\n\n```bash\n# Adjust the comparison to match step 1\ngit diff --unified=10 # uncommitted\ngit diff --unified=10 HEAD~1 # last commit\ngit diff --unified=10 main...HEAD # branch\n```\n\n## 3. Follow cross-references\n\nFor each changed file, check what links to it and what it links to:\n\n- Search for other pages that reference the changed content (grep for the\n filename, heading anchors, or key phrases)\n- Read linked pages to verify the change doesn't create contradictions\n across pages\n- Check that anchor links in cross-references still match heading IDs\n\nA change that's correct on its own page can break the story told by a\nrelated page.\n\n## 4. Verify factual accuracy\n\nDon't assume the change is factually correct just because it reads well.\n\n- If the change describes how a feature behaves, verify against upstream\n docs or source code\n- If the change includes a URL, check that it resolves\n- If the change references a CLI flag, option, or API field, confirm it\n exists\n\n## 5. Evaluate as a reader\n\nConsider someone landing on this page from a search result, with no prior\ncontext:\n\n- Does the page make sense on its own?\n- Is the changed section clear without having read the issue or diff?\n- Would a reader be confused by anything the change introduces or leaves\n out?\n\nAccuracy alone doesn't justify an addition. For each substantive addition, ask:\n\n- Does it help readers act, choose, or understand a consequence?\n- Does it belong under this heading and at this point in the explanation?\n- Does it interrupt a procedure, example, or explanation already in progress?\n- Is the detail proportional to its value here, or would a link suffice?\n- Would removing it improve the page without losing necessary guidance?\n\nRecommend shortening, moving, or deleting accurate text when it doesn't serve\nthe page's task. When reviewing multiple commits, check both each change in\ncontext and the combined diff for repeated explanations.\n\n## 6. Review code and template changes\n\nFor non-Markdown changes (JS, HTML, CSS, Hugo templates):\n\n- Trace through the common execution path\n- Trace through at least one edge case (no stored preference, Alpine fails\n to load, first visit vs returning visitor)\n- Ask whether the change could produce unexpected browser or runtime\n behavior that no automated tool would catch\n\n## 7. Decision\n\n**Approve** if the change is correct, coherent, complete, and factually\naccurate.\n\n**Request changes** if:\n- The change does not correctly solve the stated problem\n- There is a factual error or contradiction (on-page or cross-page)\n- A cross-reference is broken or misleading\n- A reader would be confused\n- An addition duplicates guidance or disrupts the page without enough reader value\n\nWhen requesting changes, be specific: quote the exact text that is wrong,\nexplain why, and suggest the correct fix.\n",".agents/skills/write/SKILL.md":"# write\n\nPath: `.agents/skills/write/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/.agents/skills/write/SKILL.md)","AGENTS.md":"# AI Agent Protocol & Instructions\n\nPath: `AGENTS.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/AGENTS.md)","CLAUDE.md":"# Claude Agent Guidelines & System Prompt\n\nPath: `CLAUDE.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/CLAUDE.md)",".github/agents/docs-scanner.yaml":"# Agents Skill\n\nPath: `.github/agents/docs-scanner.yaml`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/.github/agents/docs-scanner.yaml)","content/manuals/extensions/_index.md":"# Extensions Skill\n\nPath: `content/manuals/extensions/_index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/_index.md)","content/manuals/extensions/marketplace.md":"# Extensions Skill\n\nPath: `content/manuals/extensions/marketplace.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/marketplace.md)","content/manuals/extensions/non-marketplace.md":"# Extensions Skill\n\nPath: `content/manuals/extensions/non-marketplace.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/non-marketplace.md)","content/manuals/extensions/private-marketplace.md":"# Extensions Skill\n\nPath: `content/manuals/extensions/private-marketplace.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/private-marketplace.md)","content/manuals/extensions/settings-feedback.md":"# Extensions Skill\n\nPath: `content/manuals/extensions/settings-feedback.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/settings-feedback.md)",".agents/skills/agent-readiness-audit/references/report-template.md":"# References Skill\n\nPath: `.agents/skills/agent-readiness-audit/references/report-template.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/.agents/skills/agent-readiness-audit/references/report-template.md)",".agents/skills/agent-readiness-audit/references/rubric.md":"# References Skill\n\nPath: `.agents/skills/agent-readiness-audit/references/rubric.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/.agents/skills/agent-readiness-audit/references/rubric.md)",".agents/skills/curate-whats-new/agents/openai.yaml":"# Agents Skill\n\nPath: `.agents/skills/curate-whats-new/agents/openai.yaml`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/.agents/skills/curate-whats-new/agents/openai.yaml)",".agents/skills/curate-whats-new/examples/2026-07-13--2026-08-11.json":"# Examples Skill\n\nPath: `.agents/skills/curate-whats-new/examples/2026-07-13--2026-08-11.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/.agents/skills/curate-whats-new/examples/2026-07-13--2026-08-11.json)",".agents/skills/curate-whats-new/examples/2026-07-13--2026-08-11.yaml":"# Examples Skill\n\nPath: `.agents/skills/curate-whats-new/examples/2026-07-13--2026-08-11.yaml`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/.agents/skills/curate-whats-new/examples/2026-07-13--2026-08-11.yaml)",".agents/skills/maintain-pr/agents/openai.yaml":"# Agents Skill\n\nPath: `.agents/skills/maintain-pr/agents/openai.yaml`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/.agents/skills/maintain-pr/agents/openai.yaml)",".agents/skills/review-pr/agents/openai.yaml":"# Agents Skill\n\nPath: `.agents/skills/review-pr/agents/openai.yaml`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/.agents/skills/review-pr/agents/openai.yaml)","content/manuals/ai/skills/_index.md":"# Skills Skill\n\nPath: `content/manuals/ai/skills/_index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/ai/skills/_index.md)","content/manuals/ai/skills/install.md":"# Skills Skill\n\nPath: `content/manuals/ai/skills/install.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/ai/skills/install.md)","content/manuals/dhi/tools/_index.md":"# Tools Skill\n\nPath: `content/manuals/dhi/tools/_index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/dhi/tools/_index.md)","content/manuals/dhi/tools/api.md":"# Tools Skill\n\nPath: `content/manuals/dhi/tools/api.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/dhi/tools/api.md)","content/manuals/dhi/tools/cli.md":"# Tools Skill\n\nPath: `content/manuals/dhi/tools/cli.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/dhi/tools/cli.md)","content/manuals/dhi/tools/hub.md":"# Tools Skill\n\nPath: `content/manuals/dhi/tools/hub.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/dhi/tools/hub.md)","content/manuals/dhi/tools/mcp.md":"# Tools Skill\n\nPath: `content/manuals/dhi/tools/mcp.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/dhi/tools/mcp.md)","content/manuals/dhi/tools/terraform.md":"# Tools Skill\n\nPath: `content/manuals/dhi/tools/terraform.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/dhi/tools/terraform.md)","content/manuals/extensions/extensions-sdk/_index.md":"# Extensions-sdk Skill\n\nPath: `content/manuals/extensions/extensions-sdk/_index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/_index.md)","content/manuals/extensions/extensions-sdk/process.md":"# Extensions-sdk Skill\n\nPath: `content/manuals/extensions/extensions-sdk/process.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/process.md)","content/manuals/extensions/extensions-sdk/quickstart.md":"# Extensions-sdk Skill\n\nPath: `content/manuals/extensions/extensions-sdk/quickstart.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/quickstart.md)","content/manuals/ai/sandboxes/agents/_index.md":"# Subagent: index\n\nPath: `content/manuals/ai/sandboxes/agents/_index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/ai/sandboxes/agents/_index.md)","content/manuals/ai/sandboxes/agents/claude-code.md":"# Subagent: claude-code\n\nPath: `content/manuals/ai/sandboxes/agents/claude-code.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/ai/sandboxes/agents/claude-code.md)","content/manuals/ai/sandboxes/agents/codex.md":"# Subagent: codex\n\nPath: `content/manuals/ai/sandboxes/agents/codex.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/ai/sandboxes/agents/codex.md)","content/manuals/ai/sandboxes/agents/copilot.md":"# Subagent: copilot\n\nPath: `content/manuals/ai/sandboxes/agents/copilot.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/ai/sandboxes/agents/copilot.md)","content/manuals/ai/sandboxes/agents/cursor.md":"# Subagent: cursor\n\nPath: `content/manuals/ai/sandboxes/agents/cursor.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/ai/sandboxes/agents/cursor.md)","content/manuals/ai/sandboxes/agents/devin.md":"# Subagent: devin\n\nPath: `content/manuals/ai/sandboxes/agents/devin.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/ai/sandboxes/agents/devin.md)","content/manuals/ai/sandboxes/agents/docker-agent.md":"# Subagent: docker-agent\n\nPath: `content/manuals/ai/sandboxes/agents/docker-agent.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/ai/sandboxes/agents/docker-agent.md)","content/manuals/ai/sandboxes/agents/droid.md":"# Subagent: droid\n\nPath: `content/manuals/ai/sandboxes/agents/droid.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/ai/sandboxes/agents/droid.md)","content/manuals/ai/sandboxes/agents/gemini.md":"# Subagent: gemini\n\nPath: `content/manuals/ai/sandboxes/agents/gemini.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/ai/sandboxes/agents/gemini.md)","content/manuals/ai/sandboxes/agents/kiro.md":"# Subagent: kiro\n\nPath: `content/manuals/ai/sandboxes/agents/kiro.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/ai/sandboxes/agents/kiro.md)","content/manuals/ai/sandboxes/agents/opencode.md":"# Subagent: opencode\n\nPath: `content/manuals/ai/sandboxes/agents/opencode.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/ai/sandboxes/agents/opencode.md)","content/manuals/ai/sandboxes/agents/shell.md":"# Subagent: shell\n\nPath: `content/manuals/ai/sandboxes/agents/shell.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/ai/sandboxes/agents/shell.md)","content/manuals/extensions/extensions-sdk/architecture/_index.md":"# Architecture Skill\n\nPath: `content/manuals/extensions/extensions-sdk/architecture/_index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/architecture/_index.md)","content/manuals/extensions/extensions-sdk/architecture/metadata.md":"# Architecture Skill\n\nPath: `content/manuals/extensions/extensions-sdk/architecture/metadata.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/architecture/metadata.md)","content/manuals/extensions/extensions-sdk/architecture/security.md":"# Architecture Skill\n\nPath: `content/manuals/extensions/extensions-sdk/architecture/security.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/architecture/security.md)","content/manuals/extensions/extensions-sdk/build/_index.md":"# Build Skill\n\nPath: `content/manuals/extensions/extensions-sdk/build/_index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/build/_index.md)","content/manuals/extensions/extensions-sdk/build/backend-extension-tutorial.md":"# Build Skill\n\nPath: `content/manuals/extensions/extensions-sdk/build/backend-extension-tutorial.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/build/backend-extension-tutorial.md)","content/manuals/extensions/extensions-sdk/build/frontend-extension-tutorial.md":"# Build Skill\n\nPath: `content/manuals/extensions/extensions-sdk/build/frontend-extension-tutorial.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/build/frontend-extension-tutorial.md)","content/manuals/extensions/extensions-sdk/build/minimal-frontend-extension.md":"# Build Skill\n\nPath: `content/manuals/extensions/extensions-sdk/build/minimal-frontend-extension.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/build/minimal-frontend-extension.md)","content/manuals/extensions/extensions-sdk/design/_index.md":"# Design Skill\n\nPath: `content/manuals/extensions/extensions-sdk/design/_index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/design/_index.md)","content/manuals/extensions/extensions-sdk/design/design-guidelines.md":"# Design Skill\n\nPath: `content/manuals/extensions/extensions-sdk/design/design-guidelines.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/design/design-guidelines.md)","content/manuals/extensions/extensions-sdk/design/design-principles.md":"# Design Skill\n\nPath: `content/manuals/extensions/extensions-sdk/design/design-principles.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/design/design-principles.md)","content/manuals/extensions/extensions-sdk/design/mui-best-practices.md":"# Design Skill\n\nPath: `content/manuals/extensions/extensions-sdk/design/mui-best-practices.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/design/mui-best-practices.md)","content/manuals/extensions/extensions-sdk/dev/_index.md":"# Dev Skill\n\nPath: `content/manuals/extensions/extensions-sdk/dev/_index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/dev/_index.md)","content/manuals/extensions/extensions-sdk/dev/continuous-integration.md":"# Dev Skill\n\nPath: `content/manuals/extensions/extensions-sdk/dev/continuous-integration.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/dev/continuous-integration.md)","content/manuals/extensions/extensions-sdk/dev/test-debug.md":"# Dev Skill\n\nPath: `content/manuals/extensions/extensions-sdk/dev/test-debug.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/dev/test-debug.md)","content/manuals/extensions/extensions-sdk/dev/usage.md":"# Dev Skill\n\nPath: `content/manuals/extensions/extensions-sdk/dev/usage.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/dev/usage.md)","content/manuals/extensions/extensions-sdk/extensions/DISTRIBUTION.md":"# Extensions Skill\n\nPath: `content/manuals/extensions/extensions-sdk/extensions/DISTRIBUTION.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/extensions/DISTRIBUTION.md)","content/manuals/extensions/extensions-sdk/extensions/_index.md":"# Extensions Skill\n\nPath: `content/manuals/extensions/extensions-sdk/extensions/_index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/extensions/_index.md)","content/manuals/extensions/extensions-sdk/extensions/labels.md":"# Extensions Skill\n\nPath: `content/manuals/extensions/extensions-sdk/extensions/labels.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/extensions/labels.md)","content/manuals/extensions/extensions-sdk/extensions/multi-arch.md":"# Extensions Skill\n\nPath: `content/manuals/extensions/extensions-sdk/extensions/multi-arch.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/extensions/multi-arch.md)","content/manuals/extensions/extensions-sdk/extensions/publish.md":"# Extensions Skill\n\nPath: `content/manuals/extensions/extensions-sdk/extensions/publish.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/extensions/publish.md)","content/manuals/extensions/extensions-sdk/extensions/share.md":"# Extensions Skill\n\nPath: `content/manuals/extensions/extensions-sdk/extensions/share.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/extensions/share.md)","content/manuals/extensions/extensions-sdk/extensions/validate.md":"# Extensions Skill\n\nPath: `content/manuals/extensions/extensions-sdk/extensions/validate.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/extensions/validate.md)","content/manuals/extensions/extensions-sdk/guides/_index.md":"# Guides Skill\n\nPath: `content/manuals/extensions/extensions-sdk/guides/_index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/guides/_index.md)","content/manuals/extensions/extensions-sdk/guides/invoke-host-binaries.md":"# Guides Skill\n\nPath: `content/manuals/extensions/extensions-sdk/guides/invoke-host-binaries.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/guides/invoke-host-binaries.md)","content/manuals/extensions/extensions-sdk/guides/kubernetes.md":"# Guides Skill\n\nPath: `content/manuals/extensions/extensions-sdk/guides/kubernetes.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/guides/kubernetes.md)","content/manuals/extensions/extensions-sdk/guides/oauth2-flow.md":"# Guides Skill\n\nPath: `content/manuals/extensions/extensions-sdk/guides/oauth2-flow.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/guides/oauth2-flow.md)","content/manuals/extensions/extensions-sdk/guides/use-docker-socket-from-backend.md":"# Guides Skill\n\nPath: `content/manuals/extensions/extensions-sdk/guides/use-docker-socket-from-backend.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/guides/use-docker-socket-from-backend.md)","_vendor/github.com/docker/docker-agent/docs/tools/_index.md":"# Tools Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/_index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/_index.md)","content/manuals/extensions/extensions-sdk/dev/api/_index.md":"# Api Skill\n\nPath: `content/manuals/extensions/extensions-sdk/dev/api/_index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/dev/api/_index.md)","content/manuals/extensions/extensions-sdk/dev/api/backend.md":"# Api Skill\n\nPath: `content/manuals/extensions/extensions-sdk/dev/api/backend.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/dev/api/backend.md)","content/manuals/extensions/extensions-sdk/dev/api/dashboard-routes-navigation.md":"# Api Skill\n\nPath: `content/manuals/extensions/extensions-sdk/dev/api/dashboard-routes-navigation.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/dev/api/dashboard-routes-navigation.md)","content/manuals/extensions/extensions-sdk/dev/api/dashboard.md":"# Api Skill\n\nPath: `content/manuals/extensions/extensions-sdk/dev/api/dashboard.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/dev/api/dashboard.md)","content/manuals/extensions/extensions-sdk/dev/api/docker.md":"# Api Skill\n\nPath: `content/manuals/extensions/extensions-sdk/dev/api/docker.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/dev/api/docker.md)","content/manuals/extensions/extensions-sdk/dev/api/overview.md":"# Api Skill\n\nPath: `content/manuals/extensions/extensions-sdk/dev/api/overview.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/dev/api/overview.md)","_vendor/github.com/docker/docker-agent/docs/concepts/agents/index.md":"# Subagent: index\n\nPath: `_vendor/github.com/docker/docker-agent/docs/concepts/agents/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/concepts/agents/index.md)","_vendor/github.com/docker/docker-agent/docs/concepts/tools/index.md":"# Tools Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/concepts/tools/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/concepts/tools/index.md)","_vendor/github.com/docker/docker-agent/docs/configuration/agents/index.md":"# Subagent: index\n\nPath: `_vendor/github.com/docker/docker-agent/docs/configuration/agents/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/configuration/agents/index.md)","_vendor/github.com/docker/docker-agent/docs/configuration/commands/index.md":"# Command: /index\n\nPath: `_vendor/github.com/docker/docker-agent/docs/configuration/commands/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/configuration/commands/index.md)","_vendor/github.com/docker/docker-agent/docs/configuration/tools/index.md":"# Tools Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/configuration/tools/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/configuration/tools/index.md)","_vendor/github.com/docker/docker-agent/docs/features/skills/index.md":"# Skills Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/features/skills/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/features/skills/index.md)","_vendor/github.com/docker/docker-agent/docs/tools/a2a/index.md":"# A2a Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/a2a/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/a2a/index.md)","_vendor/github.com/docker/docker-agent/docs/tools/api/index.md":"# Api Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/api/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/api/index.md)","_vendor/github.com/docker/docker-agent/docs/tools/background-agents/index.md":"# Background-agents Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/background-agents/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/background-agents/index.md)","_vendor/github.com/docker/docker-agent/docs/tools/background-jobs/index.md":"# Background-jobs Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/background-jobs/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/background-jobs/index.md)","_vendor/github.com/docker/docker-agent/docs/tools/fetch/index.md":"# Fetch Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/fetch/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/fetch/index.md)","_vendor/github.com/docker/docker-agent/docs/tools/filesystem/index.md":"# Filesystem Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/filesystem/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/filesystem/index.md)","_vendor/github.com/docker/docker-agent/docs/tools/git/index.md":"# Git Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/git/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/git/index.md)","_vendor/github.com/docker/docker-agent/docs/tools/handoff/index.md":"# Handoff Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/handoff/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/handoff/index.md)","_vendor/github.com/docker/docker-agent/docs/tools/lsp/index.md":"# Lsp Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/lsp/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/lsp/index.md)","_vendor/github.com/docker/docker-agent/docs/tools/mcp-catalog/index.md":"# Mcp-catalog Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/mcp-catalog/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/mcp-catalog/index.md)","_vendor/github.com/docker/docker-agent/docs/tools/mcp/index.md":"# Mcp Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/mcp/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/mcp/index.md)","_vendor/github.com/docker/docker-agent/docs/tools/memory/index.md":"# Memory Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/memory/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/memory/index.md)","_vendor/github.com/docker/docker-agent/docs/tools/model-picker/index.md":"# Model-picker Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/model-picker/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/model-picker/index.md)","_vendor/github.com/docker/docker-agent/docs/tools/open-url/index.md":"# Open-url Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/open-url/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/open-url/index.md)","_vendor/github.com/docker/docker-agent/docs/tools/openapi/index.md":"# Openapi Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/openapi/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/openapi/index.md)","_vendor/github.com/docker/docker-agent/docs/tools/plan/index.md":"# Plan Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/plan/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/plan/index.md)","_vendor/github.com/docker/docker-agent/docs/tools/rag/index.md":"# Rag Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/rag/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/rag/index.md)","_vendor/github.com/docker/docker-agent/docs/tools/scheduler/index.md":"# Scheduler Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/scheduler/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/scheduler/index.md)","_vendor/github.com/docker/docker-agent/docs/tools/script/index.md":"# Script Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/script/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/script/index.md)","_vendor/github.com/docker/docker-agent/docs/tools/session_context/index.md":"# Session_context Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/session_context/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/session_context/index.md)","_vendor/github.com/docker/docker-agent/docs/tools/session_plan/index.md":"# Session_plan Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/session_plan/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/session_plan/index.md)","_vendor/github.com/docker/docker-agent/docs/tools/shell/index.md":"# Shell Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/shell/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/shell/index.md)","_vendor/github.com/docker/docker-agent/docs/tools/tasks/index.md":"# Tasks Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/tasks/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/tasks/index.md)","_vendor/github.com/docker/docker-agent/docs/tools/think/index.md":"# Think Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/think/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/think/index.md)","_vendor/github.com/docker/docker-agent/docs/tools/todo/index.md":"# Todo Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/todo/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/todo/index.md)","_vendor/github.com/docker/docker-agent/docs/tools/transfer-task/index.md":"# Transfer-task Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/transfer-task/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/transfer-task/index.md)","_vendor/github.com/docker/docker-agent/docs/tools/user-prompt/index.md":"# User-prompt Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/user-prompt/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/user-prompt/index.md)","_vendor/github.com/docker/docker-agent/docs/tools/webhook/index.md":"# Webhook Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/webhook/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/webhook/index.md)","_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/_index.md":"# Rules Skill\n\nPath: `_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/_index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/_index.md)","_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/consistent-instruction-casing.md":"# Rules Skill\n\nPath: `_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/consistent-instruction-casing.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/consistent-instruction-casing.md)","_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/copy-ignored-file.md":"# Rules Skill\n\nPath: `_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/copy-ignored-file.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/copy-ignored-file.md)","_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/duplicate-stage-name.md":"# Rules Skill\n\nPath: `_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/duplicate-stage-name.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/duplicate-stage-name.md)","_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/expose-invalid-format.md":"# Rules Skill\n\nPath: `_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/expose-invalid-format.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/expose-invalid-format.md)","_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/expose-proto-casing.md":"# Rules Skill\n\nPath: `_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/expose-proto-casing.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/expose-proto-casing.md)","_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/from-as-casing.md":"# Rules Skill\n\nPath: `_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/from-as-casing.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/from-as-casing.md)","_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/from-platform-flag-const-disallowed.md":"# Rules Skill\n\nPath: `_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/from-platform-flag-const-disallowed.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/from-platform-flag-const-disallowed.md)","_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/invalid-default-arg-in-from.md":"# Rules Skill\n\nPath: `_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/invalid-default-arg-in-from.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/invalid-default-arg-in-from.md)","_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/invalid-definition-description.md":"# Rules Skill\n\nPath: `_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/invalid-definition-description.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/invalid-definition-description.md)","_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/json-args-recommended.md":"# Rules Skill\n\nPath: `_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/json-args-recommended.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/json-args-recommended.md)","_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/legacy-key-value-format.md":"# Rules Skill\n\nPath: `_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/legacy-key-value-format.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/legacy-key-value-format.md)","_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/maintainer-deprecated.md":"# Rules Skill\n\nPath: `_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/maintainer-deprecated.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/maintainer-deprecated.md)","_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/multiple-instructions-disallowed.md":"# Rules Skill\n\nPath: `_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/multiple-instructions-disallowed.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/multiple-instructions-disallowed.md)","_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/no-empty-continuation.md":"# Rules Skill\n\nPath: `_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/no-empty-continuation.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/no-empty-continuation.md)","_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/redundant-target-platform.md":"# Rules Skill\n\nPath: `_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/redundant-target-platform.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/redundant-target-platform.md)","_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/reserved-stage-name.md":"# Rules Skill\n\nPath: `_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/reserved-stage-name.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/reserved-stage-name.md)","_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/secrets-used-in-arg-or-env.md":"# Rules Skill\n\nPath: `_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/secrets-used-in-arg-or-env.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/secrets-used-in-arg-or-env.md)","_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/stage-name-casing.md":"# Rules Skill\n\nPath: `_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/stage-name-casing.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/stage-name-casing.md)","_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/undefined-arg-in-from.md":"# Rules Skill\n\nPath: `_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/undefined-arg-in-from.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/undefined-arg-in-from.md)","_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/undefined-var.md":"# Rules Skill\n\nPath: `_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/undefined-var.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/undefined-var.md)","_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/workdir-relative-path.md":"# Rules Skill\n\nPath: `_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/workdir-relative-path.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/workdir-relative-path.md)",".cursorrules (kubernetes-mkdocs-documentation-cursorrules-prompt.mdc)":"---\ndescription: \"Cursor rules for Kubernetes development with MkDocs documentation integration.\"\nglobs: **/*\nalwaysApply: false\n---\nYou are an expert Technical Writer with a deep understanding of cloud native technologies, Kubernetes, and technical documentation best practices. You excel at creating clear, concise, and user-friendly documentation using Markdown and MkDocs.\n\nYou always use the latest stable versions of Kubernetes, cloud native tools, and MkDocs. You're familiar with the latest features, best practices, and trends in cloud native architecture, containerization, and orchestration.\n\nDocumentation Style and Structure:\n\nCloud Native and Kubernetes Expertise:\n\nMkDocs Usage:\n\nContent Creation:\n\nTechnical Accuracy and Usability:\n\nDocumentation Best Practices:\n\nMetadata and SEO:\n\nCollaboration and Version Control:\n\nOther Rules to follow:\n\nDon't be lazy, provide thorough and accurate documentation for all requested topics and features.\n"},"files":{".agents/skills/create-pr/SKILL.md":"---\nname: create-pr\ndescription: >\n Push the current branch and create a pull request against docker/docs.\n Use after changes are committed and reviewed. \"create a PR\", \"submit the\n fix\", \"open a pull request for this\".\n---\n\n# Create PR\n\nPush the branch and create a properly structured pull request.\n\n## 1. Verify the branch\n\nConfirm you're on a dedicated branch, not the default branch:\n\n```bash\ngit branch --show-current # must not be main or master\n```\n\nIf this returns `main` or `master`, stop. Create a branch and move your\ncommits onto it before continuing.\n\nConfirm commits exist and the working tree is clean:\n\n```bash\ngit log --oneline main..HEAD # confirm commits exist\ngit status --porcelain # must print nothing\n```\n\nIf `git status --porcelain` prints anything, there are uncommitted or\nunstaged changes. Stop and commit them — or unstage stray files like\n`package-lock.json` — before opening a PR. Don't open a PR mid-edit.\n\n## 2. Push the branch\n\nIdentify the remote that points at your fork. Inspect the remotes:\n\n```bash\ngit remote -v\n```\n\nIf `origin` is your fork, use it. If `origin` points at canonical\n`docker/docs` (the upstream), push to your separate fork remote instead —\nnever push the branch to `docker/docs` directly:\n\n```bash\nFORK_REMOTE=origin # or the name of your fork remote if origin is upstream\ngit push -u \"$FORK_REMOTE\" <branch-name>\n```\n\n## 3. Create the PR\n\nBefore creating a PR for an issue, check whether that issue already has an open\nlinked PR:\n\n```bash\ngh api repos/docker/docs/issues/<issue-number>/timeline --paginate \\\n --jq '.[] | select((.event==\"cross-referenced\" or .event==\"connected\" or .event==\"referenced\") and .source.issue.pull_request and .source.issue.state==\"open\") | {url: .source.issue.html_url, title: .source.issue.title}'\n```\n\nIf this returns an open PR that addresses the same issue, stop. Don't open a\nduplicate PR; report the existing PR instead. Only proceed if there is no open\nlinked PR, or if the existing PR clearly does not address the issue and you\nexplain why in the new PR body.\n\nDerive the fork owner dynamically from the same fork remote you pushed to:\n\n```bash\nFORK_OWNER=$(git remote get-url \"$FORK_REMOTE\" | sed -E 's|.*[:/]([^/]+)/[^/]+(\\.git)?$|\\1|')\n```\n\n```bash\ngh pr create --repo docker/docs \\\n --head \"${FORK_OWNER}:<branch-name>\" \\\n --title \"<concise summary under 70 chars>\" \\\n --body \"$(cat <<'EOF'\n## Summary\n\n<1-2 sentences: what was wrong and what was changed>\n\nCloses #NNNN\n\nGenerated by <active coding agent name>\nEOF\n)\"\n```\n\nPrefix the title with the change type to match repo convention — `docs:` for\ndocumentation changes (or another scope like `hub:` when appropriate), for\nexample `docs: fix broken link on install page`.\n\nKeep the body short. Reviewers need to know what changed and why — nothing\nelse. Do **not** add a \"Test plan\" section — documentation PRs don't need one.\n\nUse an accurate disclosure footer that names the active coding agent, for\nexample `Generated by Codex` or `Generated by Claude Code`.\n\n### Optional: Netlify preview entry path\n\nIf the PR primarily edits a single page or a focused section of pages, add a\n`@netlify` stanza to the PR body (for example, just below the Summary). This\nsets the entry path for the Netlify deploy preview so reviewers land on the\nedited page instead of the site root:\n\n```markdown\n@netlify /desktop/setup/install/\n```\n\nThe stanza takes a single published URL path. Derive it from the source file\npath: drop the `content/` prefix and `.md` suffix, strip the `/manuals`\nsegment, and add a trailing slash. For example,\n`content/manuals/desktop/setup/install/mac-install.md` becomes\n`/desktop/setup/install/mac-install/`.\n\nOnly add this when the change is focused on one page or section. Skip it for\nPRs that touch many unrelated pages — there is no useful single entry path.\n\n### Optional: Preview links\n\nWhen the change is focused, also add direct links to the deploy preview in the\nPR body so reviewers can jump straight to the affected pages. The preview URL\nembeds the PR number:\n\n```\nhttps://deploy-preview-<pr-number>--docsdocker.netlify.app/path/to/page/\n```\n\nThe PR number isn't known until `gh pr create` returns, so add these links\nafter creating the PR by updating the body:\n\n```bash\ngh pr edit <pr-number> --repo docker/docs --body \"...\"\n```\n\nUse the same source-path-to-URL mapping as the `@netlify` stanza above.\n\n## 4. Apply labels and request review\n\nUse the Issues API for labels — `gh pr edit --add-label` silently fails:\n\n```bash\ngh api repos/docker/docs/issues/<pr-number>/labels \\\n --method POST \\\n --field 'labels[]=status/review'\n```\n\nRequest review:\n\n```bash\ngh pr edit <pr-number> --repo docker/docs --add-reviewer docker/docs-team\n```\n\nVerify the reviewer was assigned:\n\n```bash\ngh pr view <pr-number> --repo docker/docs --json reviewRequests \\\n --jq '.reviewRequests[].slug'\n```\n\nIf the team doesn't appear, use the API directly:\n\n```bash\ngh api repos/docker/docs/pulls/<pr-number>/requested_reviewers \\\n --method POST --field 'team_reviewers[]=docs-team'\n```\n\n## 5. Report\n\nPrint the PR URL and current CI state:\n\n```bash\ngh pr view <pr-number> --repo docker/docs --json url,state\ngh pr checks <pr-number> --repo docker/docs --json name,state\n```\n\n## Notes\n\n- Always use `Closes #NNNN` (not \"Fixes\") for GitHub auto-close linkage\n- One issue, one branch, one PR — never combine\n",".agents/skills/fix-issue/SKILL.md":"---\nname: fix-issue\ndescription: >\n Fix a single GitHub issue end-to-end: triage, research, write the fix,\n review, and create a PR. Use when asked to fix an issue: \"fix issue 1234\",\n \"resolve #500\", \"create a PR for issue 200\".\nargument-hint: \"<issue-number>\"\n---\n\n# Fix Issue\n\nGiven GitHub issue **$ARGUMENTS**, decide what to do with it and either\nclose it or fix it. This skill orchestrates the composable skills — it owns\nthe decision tree, not the individual steps.\n\n## 1. Triage\n\nInvoke `/triage-issue $ARGUMENTS` to understand the issue and decide what\nto do. This runs in a forked subagent and returns a verdict.\n\n## 2. Act on the triage result\n\nIf triage says **close it** — comment with the reason and close:\n```bash\ngh issue close $ARGUMENTS --repo docker/docs \\\n --comment \"<one sentence explaining why>\n\nGenerated by <active coding agent name>\"\n```\nDone.\n\nIf triage says **escalate upstream** — comment noting the repo and stop:\n```bash\ngh issue comment $ARGUMENTS --repo docker/docs \\\n --body \"This needs to be fixed in <upstream-repo>.\n\nGenerated by <active coding agent name>\"\n```\nDone.\n\nIf triage says **leave it open** — comment explaining what was checked and\nwhat's unclear. Do not close.\nDone.\n\nEnd every issue comment with an accurate agent-disclosure footer that names\nthe active coding agent, for example `Generated by Codex` or `Generated by\nClaude Code`.\n\nIf triage says **fix it** — proceed to step 3.\n\n## 3. Research\n\nInvoke `/research` to locate affected files, verify facts, and identify\nthe fix. The issue context carries over from triage. This runs inline —\nfindings stay in conversation context for the write step.\n\nIf research reveals the issue is upstream or cannot be fixed (e.g.\nunverifiable URLs), comment on the issue and stop.\n\n## 4. Write\n\nInvoke `/write` to create a branch, make the change, format, self-review,\nand commit.\n\n## 5. Review\n\nInvoke `/review-changes` to check the diff for correctness, coherence, and\nmechanical compliance. This runs in a forked subagent with fresh context.\n\nIf issues are found, fix them and re-review until clean.\n\n## 6. Create PR\n\nInvoke `/create-pr` to push the branch and open a pull request.\n\n## 7. Return to main\n\n```bash\ngit checkout main\n```\n\n## 8. Report\n\nSummarize what happened: the issue number, what was done (closed, escalated,\nfixed with a PR link), and why — in a sentence or two.\n",".agents/skills/maintain-pr/SKILL.md":"---\nname: maintain-pr\ndescription: >\n Maintain and follow up on a single Docker documentation pull request that\n you own or are responsible for updating. Check CI and review feedback, fix\n actionable failures, push changes, reply to comments, and report status.\n Use for requests such as \"babysit this PR\", \"check the status of my PR\",\n \"fix CI on my PR\", or \"address review comments on #500\". Do not use for\n maintainer review of an incoming contribution; use review-pr for that.\n---\n\n# Maintain PR\n\nDo one maintenance pass over the specified author-owned PR: inspect its\nstate, fix actionable failures or feedback, reply to reviewers, and report\nthe result. This workflow may modify the branch and GitHub because the user\nis asking to maintain the PR. Do not apply it to an incoming PR merely\nbecause the user asks to review or assess it.\n\n## 1. Gather PR state\n\n```bash\ngh pr view <PR> --repo docker/docs --json state,title,url,headRefName,headRepositoryOwner,comments,reviews,reviewDecision\ngh pr checks <PR> --repo docker/docs --json name,state,detailsUrl\ngh api repos/docker/docs/pulls/<PR>/comments \\\n --jq '[.[] | {id, author: .user.login, body, path, line, in_reply_to_id}]'\n```\n\nAlways check both top-level reviews and inline comments. A review with an\nempty body may still contain line-level feedback. Confirm that the PR is one\nthe user owns or is authorized to update before checking out or pushing its\nbranch. If not, stop and use `review-pr`.\n\n## 2. Handle terminal states\n\nIf merged, report the final state and identify unanswered review comments.\nReply only when the user remains responsible for follow-up.\n\nIf closed without merge, read the closing context and report the reason.\nCommon causes include maintainer rejection, supersession, or automation.\n\n## 3. Diagnose CI failures\n\n- Read the failure details.\n- Determine whether the failure comes from the PR or predates it.\n- Fix actionable failures in the PR's changed files.\n- Report pre-existing or upstream failures without changing unrelated files.\n\nFollow repository instructions for formatting, targeted linting, explicit\nstaging, commits, and pushes. Preserve unrelated working-tree changes.\n\n## 4. Address review feedback\n\nTreat every review comment as a claim to verify. Implement it only when the\nevidence supports it; explain any evidence-based disagreement.\n\nAfter each fix:\n\n1. Format and validate the changed files.\n2. Commit and push the focused change.\n3. Reply to every addressed thread with what changed or why no change was\n made.\n4. End replies with an accurate agent-disclosure footer, such as\n `Generated by Codex`.\n5. Resolve threads only after replying.\n6. Re-request review when appropriate.\n\nUse the inline comment endpoint to reply:\n\n```bash\ngh api repos/docker/docs/pulls/<PR>/comments \\\n --method POST \\\n --field in_reply_to=<COMMENT_ID> \\\n --field body='<RESPONSE>'\n```\n\nUse GraphQL to retrieve unresolved review-thread IDs and resolve only the\nthreads that were addressed. Do not silently fix feedback without replying.\n\n## 5. Report\n\n```markdown\n## PR #<number>: <title>\n\n**State:** <open, merged, or closed>\n**CI:** <passing, failing, or pending>\n**Review:** <approved, changes requested, or pending>\n**Action taken:** <changes, replies, and thread resolution, or none needed>\n```\n",".agents/skills/create-lab-guide/SKILL.md":"---\nname: create-lab-guide\ndescription: \"Clone a dockersamples Labspace repo, extract learning objectives and module structure from labspace.yaml, and produce a Hugo guide page under content/guides/ with correct frontmatter, labspace-launch shortcode, and Docker docs style compliance. Use when asked to create a lab guide, write a Labspace page, add a Docker lab tutorial, migrate a lab to docs, or document a hands-on lab.\"\n---\n\n# Create Lab Guide\n\nCreate a guide page for a Docker Labspace: clone the source repo, extract\nstructure from `labspace.yaml`, write the Hugo markdown page, and validate.\n\n## Inputs\n\n- **REPO_NAME**: GitHub repo in the `dockersamples` org (e.g. `labspace-ai-fundamentals`)\n\n## Step 1: Clone the labspace repo\n\n```bash\nTMPDIR=$(mktemp -d)\ngit clone --depth 1 https://github.com/dockersamples/{REPO_NAME}.git \"$TMPDIR/{REPO_NAME}\"\n```\n\n## Step 2: Extract key information\n\nRead these files from the cloned repo:\n\n| File | Purpose |\n|------|---------|\n| `README.md` | Lab purpose and overview |\n| `labspace/labspace.yaml` | Module structure and content paths |\n| `labspace/*.md` | Module content (only files listed in `labspace.yaml`) |\n| `.github/workflows/*.yml` | Published Compose file URL for the launch command |\n| `compose.override.yaml` | Check for top-level `model` specs (triggers `model-download` param) |\n\nExtract:\n1. A short description for the `description` and `summary` frontmatter fields.\n2. Learning objectives from the module content.\n3. Whether a model download is required (`compose.override.yaml` → top-level `model` key).\n\n## Step 3: Write the guide markdown\n\nPlace the file at `content/guides/lab-{GUIDE_ID}.md`.\n\n```markdown\n---\ntitle: \"Lab: { Short title }\"\nlinkTitle: \"Lab: { Short title }\"\ndescription: |\n A short description of the lab for SEO and social sharing.\nsummary: |\n A short summary of the lab for the guides listing page. 2-3 lines.\nkeywords: AI, Docker, Model Runner, agentic apps, lab, labspace\naliases: # Include only for AI-related labs\n - /labs/docker-for-ai/{REPO_NAME_WITHOUT_LABSPACE_PREFIX}/\nparams:\n tags: [ai, labs]\n time: 20 minutes\n resource_links:\n - title: A resource link pointing to relevant documentation or code\n url: /ai/model-runner/\n - title: Labspace repository\n url: https://github.com/dockersamples/{REPO_NAME}\n---\n\nShort explanation of the lab and what it covers.\n\n## Launch the lab\n\n{{< labspace-launch image=\"dockersamples/{REPO_NAME}\" >}}\n\n## What you'll learn\n\nBy the end of this Labspace, you will have completed the following:\n\n- Objective #1\n- Objective #2\n- Objective #3\n\n## Modules\n\n| # | Module | Description |\n|---|--------|-------------|\n| 1 | Module #1 | Description of module #1 |\n| 2 | Module #2 | Description of module #2 |\n| 3 | Module #3 | Description of module #3 |\n```\n\nConditional rules:\n- All lab guides **must** include `labs` in `params.tags`.\n- AI-related labs: also add `ai` tag and an alias under `/labs/docker-for-ai/`.\n- If a model download is required: add `model-download: true` to the `labspace-launch` shortcode.\n\n## Step 4: Apply Docker docs style rules\n\nFollow STYLE.md and COMPONENTS.md. Key rules:\n\n| Avoid | Use instead |\n|-------|-------------|\n| \"we\", \"let's\" | Imperative voice or \"you\" |\n| \"simply\", \"easily\", \"just\" | Remove the hedge word |\n| \"allows you to\" / \"enables you to\" | \"lets you\" or rephrase |\n| \"click\" | \"select\" |\n| Bold for emphasis / product names | Bold only for UI elements |\n| \"currently\", \"new\", \"recently\" | Remove time-relative language |\n\nUse `console` as the language hint for shell blocks with `$` prompts.\nUse contractions (\"it's\", \"you're\", \"don't\").\n\n## Step 5: Validate\n\n1. Confirm frontmatter has `title`, `description`, `keywords`, and `params.tags` including `labs`.\n2. Run `npx --no-install rumdl fmt <file>` to format.\n3. Run `docker buildx bake lint vale` and fix any errors.\n4. Re-read the file and verify: correct shortcode syntax, objectives match source content, modules match `labspace.yaml`, no vendored paths edited.\n\nDo not proceed to commit until validation passes.\n",".agents/skills/agent-readiness-audit/SKILL.md":"---\nname: agent-readiness-audit\ndescription: >\n Audit a documentation site for agent-friendliness: discovery, markdown\n delivery, crawlability, semantic structure, machine-readable surfaces,\n and content legibility. Use when asked to assess docs.docker.com or any\n docs site for AI/agent readiness, produce a scored report, compare with\n external scanners, or generate a remediation list. Triggers on:\n \"audit docs for agent readiness\", \"how agent-friendly is docs.docker.com\",\n \"score our docs for AI agents\", \"review llms.txt / markdown / crawlability\",\n \"create an agent-readiness remediation plan\".\nargument-hint: \"<base-url>\"\n---\n\n# Agent Readiness Audit\n\nAudit the live site, not the source tree alone. Prefer the same fetch path\nan external agent would use in the wild: direct HTTP requests, sitemap\nsampling, and page-level inspection.\n\nDo not reduce the result to a homepage-only scan or a binary checklist.\n\n## 1. Set scope\n\nUse `$ARGUMENTS` as the base URL when provided. Otherwise infer the base\nURL from context and state the assumption.\n\nDecide whether the host being audited is:\n\n- a docs-only host\n- an app/tool host\n- a mixed host\n\nThis matters for optional checks such as MCP, plugin manifests, or other\ntool discovery files. Do not penalize a docs-only host for missing\ntooling manifests that belong on a separate service.\n\nFor `docs.docker.com`, treat the public docs host as docs-only. Docker's\nMCP server is published separately, so missing MCP files on the docs host\nshould be reported as `N/A`, not as a failure.\n\n## 2. Gather sitewide signals\n\nAlways check these resources first:\n\n- `/llms.txt`\n- `/llms-full.txt`\n- `/robots.txt`\n- `/sitemap.xml`\n\nOnly check host-level tool manifests when the host is an app/tool host,\nmixed host, or explicitly advertises them:\n\n- `/.well-known/ai-plugin.json`\n- `/.well-known/agent.json`\n- `/.well-known/agents.json`\n\nUse the bundled script for a baseline:\n\n```bash\nbash .agents/skills/agent-readiness-audit/scripts/baseline-probes.sh \\\n \"$ARGUMENTS\"\n```\n\nThe script produces baseline evidence only. You still need to interpret\nwhat matters for a docs property and score it with the rubric.\n\nFor docs-only hosts, you may skip tool-manifest probes to reduce noise:\n\n```bash\nCHECK_TOOL_MANIFESTS=0 \\\n bash .agents/skills/agent-readiness-audit/scripts/baseline-probes.sh \\\n \"$ARGUMENTS\"\n```\n\n## 3. Sample representative pages\n\nUse the sitemap when available. Do not rely on the homepage alone.\n\nIf `llms.txt` exists, sample some URLs from it as well. This helps catch\nstale or misleading discovery surfaces that a sitemap-only sample would miss.\n\nSample at least 12 pages when the site is large enough, and cover multiple\npage types:\n\n- homepage or docs landing page\n- section landing pages\n- task guides\n- product manuals\n- reference or API pages\n- tutorial or learning pages\n\nIf the sitemap is missing or unusable, discover pages through internal\nlinks and note the lower confidence.\n\nIf the site has distinct delivery patterns, sample each one. For example:\n\n- normal content pages\n- generated reference pages\n- versioned docs\n- localized docs\n\n## 4. Run fetch-path checks on each sample\n\nFor each sampled page, verify:\n\n- HTML fetch status, content type, and final URL\n- `Accept: text/markdown` behavior\n- direct markdown route behavior such as `<page>.md` or another stable path\n- page-level markdown alternate links and whether they actually resolve\n- whether page actions such as \"Open Markdown\" agree with the working route\n- whether the HTML title or H1 matches the markdown H1 closely enough for\n retrieval parity\n- whether main content is present in the initial HTML\n- redirect chain length and canonical URL consistency\n- obvious chrome/noise in the markdown response\n\nDo not assume a `.md` mirror exists just because another site uses one.\nVerify the actual markdown path the site exposes.\n\nTreat these as separate signals:\n\n- negotiated markdown works\n- a stable direct markdown URL works\n- the page advertises the correct markdown URL\n\nIf the page advertises dead markdown alternates but a working markdown route\nexists, do not fail markdown delivery outright. Score it as a discoverability\nand consistency problem instead.\n\nFor API or generated reference pages, also verify whether a machine-readable\nasset such as OpenAPI YAML is directly linked and fetchable.\n\n## 5. Judge structure and legibility\n\nMeasure structural signals:\n\n- exactly one `h1`\n- sane heading hierarchy\n- `main` and `article` presence where appropriate\n- canonical tags\n- JSON-LD or breadcrumb structured data\n- stable anchors and deep-linkable headings\n\nAlso make a qualitative judgment about agent legibility:\n\n- markdown strips site chrome cleanly\n- headings are specific and task-oriented\n- code blocks stay intelligible without client-side JS\n- the page is not dominated by banners, injected chat, or nav noise\n\nMeasure code block labeling explicitly when code samples are common. A page\ntype with many untagged fenced blocks should lose points even if the prose is\notherwise clean.\n\nFor page types that intentionally render interactive UIs with JavaScript,\njudge them separately from normal docs pages. If the HTML shell is thin,\ncheck whether the page still provides:\n\n- a fetchable markdown summary\n- a directly linked machine-readable asset\n- a usable non-JS fallback\n\n## 6. Score with the rubric\n\nUse [references/rubric.md](references/rubric.md).\n\nRules:\n\n- score only what you verified\n- mark non-applicable checks as `N/A`\n- normalize the final score against applicable points only\n- do not let optional manifest checks dominate the grade\n\nApply the foundational caps from the rubric. A site with broken discovery\nor broken markdown delivery should not earn a high grade because it has\nclean metadata.\n\nDo not average away a weak page type. If one major page type, such as API\nreference, is materially worse than the rest of the corpus, call it out as\nthe weakest segment and reflect it in the category notes.\n\n## 7. Compare with external scanners when useful\n\nIf external scanner results are available, compare them to your live\nfindings. Treat them as secondary evidence.\n\nIf a scanner and the live fetch disagree:\n\n- trust the live fetch\n- report the mismatch explicitly\n- explain whether the scanner is testing a different assumption\n\n## 8. Produce a remediation list\n\nTurn findings into a short backlog:\n\n- `P0`: fetchability or discovery blockers\n- `P1`: recurring structural or parity issues\n- `P2`: polish, optional manifests, or low-impact enhancements\n\nFor each remediation, include:\n\n- the failing signal\n- why it matters to agents\n- a concrete fix\n- whether it is sitewide or page-type-specific\n\n## 9. Report in a stable format\n\nUse [references/report-template.md](references/report-template.md).\n\nAlways include:\n\n- overall score and grade\n- confidence level\n- sampled URLs or sample strategy\n- category scores\n- highest-priority findings\n- remediation backlog\n\n## Notes\n\n- Favor docs-delivery checks over marketing-site heuristics.\n- Do not fail a docs host for lacking MCP or plugin manifests unless the\n host itself is meant to expose tools.\n- Treat raw byte size as supporting evidence, not as a primary scoring input.\n- Prefer short evidence excerpts and commands over long copied page text.\n",".agents/skills/migrate-content-ia/SKILL.md":"---\nname: migrate-content-ia\ndescription: >\n Handle Hugo docs information-architecture moves: discover old vs new URLs,\n add front matter aliases (Phase 1), update in-repo links (Phase 2), interactive\n List 2 resolution and fragment validation (Phase 3; no guessing). Supports\n PR-scoped mapping plus whole-content sweeps for inbound links to that mapping,\n or a full-site follow-up. Triggers on: \"IA migration\", \"redirects for moved\n pages\", \"fix links after content move\", \"PR-scoped link/anchor pass\",\n \"aliases for old URLs\". After branch work, chain the review-changes skill\n (main...HEAD) before a PR. Agents must run the in-file required procedure\n and definition of done, not the phases alone in isolation.\n---\n\n# Migrate content IA (redirects + links + anchors)\n\nUse this skill when pages **move or rename** under `content/` and you must\npreserve old public URLs and/or fix cross-references. Work in **phases**;\nchoose **PR-scoped** vs **full-site** mode per run.\n\n**Read first:** **CLAUDE.md** / **AGENTS.md** (URL rules, vendored areas, external\nlinks, special cases) and **hugo.yaml** (`permalinks`, `refLinksErrorLevel`,\n`disablePathToLower`). For **prose and link text**, follow **STYLE.md**; for\n**components, front matter, and link examples**, follow **COMPONENTS.md**.\n\n**Related skills:** **research** helps map moves and find inbound links; **write**\ncommits minimal edits. Run this skill’s phases after the move is identified (or\nin parallel with research for large IA work).\n\n## Agent: required procedure (do not skip)\n\n**Common mistake (wrong):** use **`git diff main...HEAD` (or the PR’s file\nlist) as the full set of places to fix links** for a migration. That set shows\n**what *moved***; it is **not** the list of every page that **points *to*** a\nmoved page. Inbound stragglers are often in files the PR **never** touched. You\nmust still **sweep the repo** for every string in the **old path and published-URL set**\nfor this run, not only for “files in the diff.”\n\n**Definition of done (when the migration is *finished*):** **Both** of the\nfollowing (unless the user or **AGENTS.md** **explicitly defers** a **List 2**\nitem in **Phase 3**; document the deferral):\n\n1. **`docker buildx bake validate`** passes for the branch, with no new\n build/link errors from this work.\n2. A **sweep of the old path and published-URL set for this run** (see\n [Sweep commands](#sweep-commands) below) finds **no** remaining\n migration-relevant **inbound** reference—**including**:\n - links to an old **source** path (plain `.md` and equivalent `ref` forms),\n - links that use the old path **and** a `#fragment`,\n - and, where your mapping includes them, old **published-style** `link:` /\n `url:` / full-site URL strings, \n **except** intentional entries to keep: for example `aliases` on the **new**\n canonical page, or **redirects.yml** *sources* you must not edit per policy.\n (A hit on a **source** that is only an `alias` line on the new page is\n **expected**—do not “fix” that away; distinguish alias rows from straggler\n links in body or nav config.)\n\n**Chaining (policy):** when this branch’s content work is ready for handoff,\n**run the [review-changes](../review-changes/SKILL.md) skill** on\n**`main...HEAD`** (or **`merge-base`…`HEAD`** for a different target branch) so\nthe **whole branch** is re-read for cross-page issues before opening a PR. Do\nnot treat phases 0–3 alone as the final check.\n\n**Run in order (mandatory for agents):**\n\n1. **Scope the moves (mapping input):** set the Git range like **review-changes**\n (for a PR to `main`: `git diff --name-only main...HEAD`; for another target:\n `BASE=$(git merge-base <target-branch> HEAD)` then\n `git diff --name-only $BASE...HEAD`, as in **Phase 0.5**). Include\n renames; build the **old → new** table (source and published) per **Phase\n 0**.\n2. **Sweep and list:** for every **old** path/URL in that table, run\n [Sweep commands](#sweep-commands) on the **allowed** trees. Record\n every hit as **List 1** (no `#`) or **List 2** (old path with `#...`) per\n **Phase 0.5**.\n3. **Phased edits:** **Phase 1** (`aliases`), then **Phase 2** (List 1), then\n **Phase 3** (List 2) with **no guessing**—as in the sections below.\n4. **Re-sweep** the same old-path set, then run **`docker buildx bake\n validate`**. The **Definition of done** above is met or you have **explicit\n defers** for the remainder.\n5. **review-changes:** run **[review-changes](../review-changes/SKILL.md)**\n on the branch vs **`main`…`HEAD`** (or the correct base) before a PR.\n\n### Sweep commands\n\nUse a **repository** search (e.g. `rg` / your IDE) so **nothing** in the\nallowed scope is only eyeballed.\n\n**Trees to include** (at minimum): all of `content/`, plus **`data/`** and\n**`layouts/`** when a migration can appear in config, `link:`-like fields,\nshortcodes, or hardcoded path strings. Follow **Vendored / generated** rules in\n**AGENTS.md**; do not edit disallowed files.\n\n**What to search for (repeat per row in the old side of the mapping):**\n\n- **Hugo / source form:** path segments that identify the *old* file, e.g.\n `manuals/.../old-segment/...` or `../old-segment/.../page.md` as your tree\n uses; include variants that still appear in the repo.\n- **Published / site form:** e.g. `/admin/.../old-slug/` in front matter, nav\n `url:`, or `https://docs.docker.com/...` in allowed files—**match the\n file’s** established pattern, per **Conventions** below.\n- **Anchors:** search for the **old path string**; matches that also include\n `#...` belong on **List 2** for **Phase 3** unless the whole link is\n a pure path-only case.\n\n[scripts/scope-pr-files.sh](scripts/scope-pr-files.sh) (if present) prints\n**`PR_SCOPE_FILES` only**—it does **not** replace this sweep. Use it to build\nthe **old → new** table, **not** to list where inbound links were fixed.\n\n## Progressive disclosure (optional)\n\nThe procedure below stays in this file. If a run produces a very large\n**old → new** URL table, store that table in **`reference.md`** in this skill\ndirectory and link it from the task summary, so the agent reads the long\nmapping only when needed.\n\n## Modes\n\n- **PR-scoped (typical for a single PR)** \n - **What the PR “owns” (focus):** use `git diff` / `base...HEAD` to know which\n pages and renames the branch actually moves (`PR_SCOPE_FILES`). The **old →\n new** mapping and **List 1 / List 2** for this migration are defined from\n **that** work, not from unrelated areas.\n - **Where to look for stale references (sweep):** search broadly—typically all\n of `content/` (and config, shortcodes, layouts, per Conventions)—for **inbound**\n links and fields whose **target** is an **old** path or URL in **this** PR’s\n mapping. Inbound stragglers are often in files the PR never touched; finding\n them is **in scope** for this migration. \n - **What to edit:** update **any** file in the allowed trees that contains a\n **migration-relevant** reference (target ∈ this PR’s old path set) according\n to the phases below. **Do not** treat `PR_SCOPE_FILES` as a hard limit on\n *which files you may save* for **inbound** link repairs (unless\n project policy for a given PR says otherwise; then follow policy and\n **defer** out-of-PR file fixes).\n - **Out of scope (defer / ignore in this run):** link and anchor problems that\n are **not** about this PR’s old→new map—e.g. a different area’s own slug\n issues, rot unrelated to the remapped path set. *Example:* a PR that only\n remaps `content/strawberry/...` should not “fix the whole site”; it **should**\n still fix a link under `mango/…` that **points at** an old `strawberry/…` path\n in the mapping, and **should not** chase **mango/**-only issues that do\n not involve those old targets.\n\n- **Full-site (complete migration after the PR)** \n - Update stragglers **across the repo** (or all inbound links to moved\n sections), including config-driven `link:` fields if policy allows. \n - Still make **minimal** edits; no drive-by rewrites to **unrelated** targets\n outside the run’s **declared** mapping and lists.\n\n### No guessing\n\n- The agent must **not** guess **replacement paths, published URLs, or fragment\n IDs** (including for consolidated pages, renamed headings, or\n “semantic” remaps of `#anchor` → new `#…`). If the user has not given an\n explicit new target, **ask**, **defer**, or **stop** per **AGENTS.md**; never\n infer, autocomplete, or substitute a plausible fragment from the target page’s\n heading list. That rule applies in **every** phase, including after validation\n in Phase 3.\n\n---\n\n## Conventions (links, anchors, redirects)\n\n### Front matter `aliases` (redirects)\n\n- Per **COMPONENTS.md**, `aliases` are **URLs that redirect to this page**.\n- Add or **merge** on the **new canonical** page; do not drop unrelated\n entries. Match local examples: **published-style paths** (leading `/`), and\n **trailing `/`** when that matches existing pages in the same area.\n- **No** speculative redirects for URLs that were never published.\n- **Collision check** before adding: no other page or redirect may already\n own the same old path.\n- If the site also uses **`data/redirects.yml`**, only add entries when\n project policy requires it; avoid duplicating the same old URL in\n `aliases` **and** `redirects.yml` unless maintainers do.\n\n### Internal links in Markdown (STYLE.md + COMPONENTS.md)\n\n- Use **relative paths to source files** (e.g. `../section/page.md`) with\n **`.md`**, following **COMPONENTS.md** examples, unless the file already\n uses an established pattern (e.g. some `link:` or nav fields use **published**\n paths without `manuals` or `.md` — **match the surrounding file**).\n- Keep **CLAUDE.md** / **AGENTS.md** rules: internal ref targets under\n `content/manuals/...` often use the full **`/manuals/...`** path; published\n URLs omit the `manuals` segment—do not confuse the two when fixing links.\n- **Link text (STYLE.md):** descriptive, ~**5 words**; no “click here” or\n “learn more”; **no** end punctuation **inside** the link text; **no** bold/italic\n on link text unless normal in the sentence.\n- **Headings (STYLE):** **sentence case**; do not rename headings in passing\n unless the migration requires it (heading changes break fragments).\n\n### Shortcodes and layouts (links not only in Markdown)\n\n- **Phase 2–3 scope includes** any **shortcode or layout partial** (under\n **Modes**, search broadly for inbound links to the migration; **edits** follow\n the same file-level rules as for Markdown) that emits links: e.g. `ref` /\n `relref`, `link` fields in shortcode args, or hardcoded\n `docs.docker.com` / path strings. Grep for old paths, slugs, and fragments\n under `layouts/shortcodes/` (and `layouts/_default/` if partials build nav).\n- Match each file’s existing pattern; do not rewrite working shortcode style\n just to “clean up.”\n\n### Fragments / anchors (Phase 3)\n\n- List 1 / List 2: fragment-bearing **cross-references to old paths** are tracked\n on **List 2** in Phase 0.5; do not bulk-rewrite them in the **List 1** pass\n (Phase 2). See Phase 0.5 and Phase 2.\n- **Valid `#fragment` values:** after the user supplies a new fragment, it should\n match the **target** page’s **generated** heading ID (Hugo slugification; see\n **CLAUDE.md** / **AGENTS.md**). The agent still **validates** (see Phase 3) and\n must **not** “pick” a different id from the page to replace a bad answer—**No\n guessing**.\n- Same-page: `[Text](#section-id)`.\n- Cross-page: when user-provided, `#fragment` must still be checked against the\n **target** file. Validate fragments in shortcodes the same way as in body\n Markdown.\n\n### External URLs (**AGENTS.md**)\n\n- Do not commit **guessed** replacement URLs. If a URL cannot be verified,\n treat as blocked or drop the fragment per AGENTS guidance. See also **No\n guessing** above; internal and external link targets are treated the same for\n inference: **none** without user input or a verified source.\n\n### Special cases (**AGENTS.md**)\n\n- **Engine API version** pages: respect coordinated **`/latest/` `aliases`**\n rules—never leave two version files both owning `/latest/`.\n- **Vendored / generated** trees: read-only; see CLAUDE.md. Do not “fix” links\n there if policy forbids.\n\n---\n\n## Phase 0 — Discovery (read-only; may use whole repo)\n\n1. Read **hugo.yaml** (permalinks, `refLinksErrorLevel`, `disablePathToLower`).\n2. From the branch (diff, renames), build a **mapping table**:\n - old source path → new source path \n - old published URL → new published URL (from permalink rules)\n3. **Case:** with `disablePathToLower: true`, filesystem path **case** appears in\n URLs—**directory and link casing must match** (e.g. `setup` vs `Setup`).\n4. When planning **inbound link** fixes, treat old-path references as two\n categories: **no fragment** vs **with `#fragment`**. That split feeds\n **List 1** and **List 2** in Phase 0.5 and drives Phase 2 ordering (see\n there).\n\n---\n\n## Phase 0.5 — PR-scoped evaluation (required before edits in PR mode)\n\n1. **Set `PR_SCOPE_FILES` (Git scope for PR mode)** \n - When the PR **targets `main`**, use the same triple-dot form as\n **review-changes**: \n `git diff --name-only main...HEAD` \n - For a **different target branch** or a custom base, use the merge base: \n `BASE=$(git merge-base <target-branch> HEAD)` \n then: \n `git diff --name-only \"$BASE\"...HEAD` \n - Those paths define **what moved** in the branch; they are the primary input\n to the **old → new** path/URL table. They are **not** a hard cap on *where\n to search* for **inbound** links (see **Modes**): sweeps for links **to** old\n paths usually cover all of `content/` (and other trees per Conventions). \n - If project policy **limits edits** to the diff for a given PR, follow that\n and **defer** link fixes in files outside the diff; note the exception in\n the task if the user relaxes that policy.\n\n2. Build checklists (see **Modes** for sweep vs area-of-work):\n - path/URL mapping this run must honor (old source path → new; old published\n → new, from the **PR’s** moves in PR-scoped mode, or the **declared** full\n migration in full-site mode)\n - **List 1 — old path, no fragment:** every **inbound** reference, found on\n the **sweep** surface, to a moved **old** path that does **not** include a\n `#...` fragment (e.g. `…/banana.md` in the repo’s link style for that\n file).\n - **List 2 — old path with fragment:** every **inbound** reference, found on\n the same sweep, to a moved **old** path that **includes** a `#...` fragment\n (e.g. `…/banana.md#anchor` or the published-style equivalent in context). The\n **same** old path string may appear on **both** List 1 and List 2 for\n different links; duplication across the two lists is OK.\n - **Matching rules:** when recording List 1 / List 2, use **one** consistent\n path representation for comparison (e.g. relative `../path/banana.md` vs\n root-anchored) **per the conventions in this doc** and the **surrounding\n file’s** established pattern. Agents compare and skip List 2 links in the\n List 1 pass using the **same** representation rules.\n3. **Out of scope** for the lists: only include references whose **old** target\n is in this run’s **mapping**. Do not build List 1/2 for unrelated **mango/**\n (or other) problems unless those links also target an **old** path that this\n migration renames. Defer those issues separately (see **Modes**).\n\n---\n\n## Phase 1 — `aliases` (old published URLs)\n\n1. On each **new** canonical page, add or merge **`aliases`** for every **real**\n former public URL.\n2. Do not strip existing unrelated aliases.\n3. **PR-scoped:** add aliases only where the canonical file is in scope or the\n project requires it; otherwise list missing alias targets for follow-up.\n\n---\n\n## Phase 2 — In-repo link reference updates\n\n1. **List 1 first (path only):** update references that belong to **List 1**\n (old path, **no** fragment). Replace old source paths or old published URLs\n with the **new** targets; preserve each file’s link pattern (relative vs\n root-anchored `.md` paths). **Do not** apply the same bulk path replacement to\n links that appear in **List 2** (old path **with** `#...`) during this\n sub-step—**leave** every **List 2** link **unchanged** for now.\n2. **After List 1 is complete:** **re-scan** the **same** **sweep** surface as\n in Phase 0.5 (e.g. all of `content/` plus config) or **print** a clear list of\n all **remaining** **List 2** entries. Those links should still point at the\n **old** path and **old** fragment until Phase 3. \n3. **Full-site (extra sweep):** after steps 1–2, still use **AGENTS “Page\n deletion checklist”**-style thoroughness for **config / front matter**\n `link:` and similar so nav and grids are not left on old slugs. Apply the\n **List 1 / List 2** rules there too: path-only old references first; defer\n fragment-bearing rewrites in line with **List 2** until Phase 3.\n4. **PR-scoped (which files to change):** apply List 1 and later Phase 3 updates\n to **every** file the **sweep** finds with a **migration-relevant** reference\n (inbound to an **old** path in the mapping), including files **not** in\n `PR_SCOPE_FILES`, per **Modes**. **Log** and **defer** (do not “fix”)\n unrelated stragglers. If policy forbids out-of-PR file edits, defer per step 1\n of Phase 0.5. \n5. Include **shortcodes and layout partials** (see Conventions and **Modes** for\n sweep vs focus).\n\n---\n\n## Phase 3 — List 2: interactive path and fragment resolution\n\n**Prerequisites:** Phase 2 has updated **List 1**; **List 2** still lists **old\npath + `#...`** (unchanged) for this migration. See **Modes** for which files\nmay be edited; **No guessing** applies.\n\n1. **Print List 2** to the user: every remaining **old path** + `#anchor` (in the\n agreed representation), so nothing is hidden before the loop.\n2. **For each distinct** `old-path#oldAnchor` (or process in the order the user\n prefers, one at a time): \n - Ask: **What is the new path (and fragment, if any) for this content?** The\n user may give a new source path, published URL, and/or `#newAnchor` per\n project conventions. \n - **Validate** the user’s answer: open the **target** page (or resolve the\n target) and check that `#newAnchor` (if any) **exists** as a real heading\n / generated id on that page, per **CLAUDE.md** / **AGENTS.md** (same rules\n as the rest of the site). **Do not** replace the user’s fragment with a\n “better” one from the file. \n - If validation **fails** (unknown target file, or `#newAnchor` not found on\n the page): **warn** clearly (what failed: path vs missing fragment), then\n **ask again** for a corrected path and/or fragment. **Repeat** until\n validation passes or the user **defers** / **drops** the fragment (per\n **AGENTS.md**). **Never** guess a new fragment to fix the problem. \n - When validation **passes:** update **all** in-repo references that match\n that **same** `old-path#oldAnchor` to the user-approved `new-path#newAnchor`\n (respect each file’s link style; include shortcodes/layouts on the same\n **sweep** surface as Phase 2). \n3. **Repeat** from step 1: **re-print** or **re-scan** for **List 2** until it is\n **empty** or the user defers the remainder. \n4. **PR-scoped / full-site:** the **loop** is the same. **Edits** follow **Modes**:\n migration-relevant **inbound** links may live in any file on the sweep; do\n not expand into **unrelated** link debt from other areas. Defer as in **Modes**\n and Phase 0.5.\n\n---\n\n## Optional: scripts helper\n\nThis skill includes a small **scope helper** so agents do not re-derive Git\nrecipes. See [scripts/scope-pr-files.sh](scripts/scope-pr-files.sh) — it prints\npaths in PR scope for a given target branch (default `main`).\n\n---\n\n## Verification\n\n```bash\ndocker buildx bake validate\n```\n\nUse the **Definition of done** in **Agent: required procedure (do not skip)**\nas the final bar: **validate** must pass, and the **sweep** must be clean for\n**plain** and **`#fragment`** old-path references, **or** the remainder must be\n**explicitly deferred** in **Phase 3** per **AGENTS.md** / the user. Mid-run,\n**Phase 2** may still leave **List 2** links unchanged **until** Phase 3; that\nintermediate state is **not** the finished migration.\n",".agents/skills/research/SKILL.md":"---\nname: research\ndescription: >\n Research a documentation topic — locate affected files, understand the\n problem, identify what to change. Use when investigating an issue, a\n question, or a topic before writing a fix. Triggers on: \"research issue\n 1234\", \"investigate what needs changing for #500\", \"what files are\n affected by #200\", \"where is X documented\", \"is our docs page about Y\n accurate\", \"look into how we document Z\".\n---\n\n# Research\n\nInvestigate the topic and determine whether documentation needs to change.\nWhen an update is warranted, identify exact files, named targets within\nthose files, and the verified content needed.\n\n## 1. Gather context\n\nIf the input is a GitHub issue number, fetch it:\n\n```bash\ngh issue view <number> --repo docker/docs \\\n --json number,title,body,labels,comments\n```\n\nOtherwise, work from what was provided — a description, a URL, a question,\nor prior conversation context. Identify the topic, affected feature, or\npage to investigate.\n\n## 2. Locate affected files\n\nSearch `content/` using the URL or topic from the issue. Remember the\n`/manuals` prefix mapping when converting URLs to file paths.\n\nFor each candidate file, read the relevant section to confirm it contains\nthe reported problem.\n\n## 3. Check vendored ownership\n\nBefore planning any edit, verify the file is editable locally:\n\n- `_vendor/` — read-only, vendored via Hugo modules\n- `data/cli/` — read-only, generated from upstream YAML\n- `content/reference/cli/` — read-only, generated from `data/cli/`\n- Everything else in `content/` — editable\n\nIf the fix requires upstream changes, identify the upstream repo and note\nit as out of scope. See the vendored content table in CLAUDE.md.\n\n## 4. Find related content\n\nLook for pages that may need updating alongside the primary fix:\n\n- Pages that link to the affected content\n- Include files (`content/includes/`) referenced by the page\n- Related pages in the same section describing the same feature\n\n## 5. Verify facts\n\nIf the issue makes a factual claim about how a feature behaves, verify it.\nFollow external links, read upstream source, check release notes. Do not\nplan a fix based on an unverified claim.\n\nIf the fix requires a replacement URL and that URL cannot be verified (e.g.\nnetwork restrictions), report it as a blocker rather than guessing.\n\n## 6. Assess documentation impact\n\nA code change or release-note entry is evidence to investigate, not a reason\nby itself to add documentation. Identify the reader's task and what the\nchange alters about it. Recommend an update when existing guidance becomes\nincorrect, leaves a gap in that task, or omits a capability useful to readers.\nAn implementation fix may need no update if the docs already describe the\nintended behavior.\n\nFor each recommended update, connect the reader's task, the documentation\ngap, the destination page and section, and the proposed treatment. Prefer\ncorrecting existing prose or examples when they serve that task. Check related\npages for contradictions, without assuming each needs the same explanation.\n\nIf there is no clear home, reconsider the value and scope before proposing a\nsection or page. A separate home can be justified by a distinct reader task,\nnot by the need to place a release-note bullet. \"No documentation change\" is\na valid finding; explain it briefly when assessing a set of changes.\n\n## 7. Check the live site (if needed)\n\nFor URL or rendering issues, fetch the live page:\n\n```text\nhttps://docs.docker.com/<path>/\n```\n\n## 8. Report findings\n\nSummarize what you found — files to change, the specific problem in each,\nwhat the fix should be, and any constraints. This context feeds directly\ninto the write step.\n\nBe specific: name the file, the section or element within it, and the\nverified content needed. \"Fix the broken link in networking.md\" is not\nspecific enough. \"In `compose/networking.md`, the 'Custom networks' section,\nremove the note about `driver_opts` being ignored — this was fixed in\nCompose 2.24\" is.\n\n## Notes\n\n- Research quality bounds write quality. Vague research produces broad\n changes; precise research produces minimal ones.\n- Do not create standalone research files — findings stay in conversation\n context for the write step.\n",".agents/skills/testcontainers-guides-migrator/SKILL.md":"---\nname: testcontainers-guide-migrator\ndescription: >\n Migrate a Testcontainers guide from testcontainers.com into the Docker docs site (docs.docker.com).\n Converts AsciiDoc to Hugo Markdown, updates code to the latest Testcontainers API, splits into\n chapters with stepper navigation, verifies code compiles and tests pass, and validates against\n Docker docs style rules. Use when asked to migrate a testcontainers guide, add a TC guide, or\n port content from testcontainers.com to Docker docs.\n---\n\n# Migrate a Testcontainers Guide\n\nYou are migrating guides from https://testcontainers.com/guides/ into the Docker docs Hugo site.\nEach guide lives in its own GitHub repo under `testcontainers/tc-guide-*`, written in AsciiDoc.\nThe source repos are listed in the testcontainers-site build.sh:\nhttps://github.com/testcontainers/testcontainers-site/blob/main/build.sh#L23-L45\n\n## Inputs\n\nThe user provides one or more guides to migrate. Resolve these from the inventory below:\n\n- **REPO_NAME**: GitHub repo (e.g. `tc-guide-getting-started-with-testcontainers-for-java`)\n- **SLUG**: guide slug inside `guide/` dir (e.g. `getting-started-with-testcontainers-for-java`)\n- **LANG**: language identifier (go, java, dotnet, nodejs, python)\n- **GUIDE_ID**: short kebab-case name (e.g. `getting-started`)\n\n## Guide inventory\n\nThese are the 21 guides from testcontainers.com/guides/ and their source repos:\n\n| # | Title | Repo | Lang | GUIDE_ID |\n|---|-------|------|------|----------|\n| 1 | Introduction to Testcontainers | tc-guide-introducing-testcontainers | (none) | introducing |\n| 2 | Getting started for Java | tc-guide-getting-started-with-testcontainers-for-java | java | getting-started |\n| 3 | Testing Spring Boot REST API | tc-guide-testing-spring-boot-rest-api | java | spring-boot-rest-api |\n| 4 | Testcontainers lifecycle (JUnit 5) | tc-guide-testcontainers-lifecycle | java | lifecycle |\n| 5 | Configuration of services in container | tc-guide-configuration-of-services-running-in-container | java | service-configuration |\n| 6 | Replace H2 with real database | tc-guide-replace-h2-with-real-database-for-testing | java | replace-h2 |\n| 7 | Testing ASP.NET Core web app | tc-guide-testing-aspnet-core | dotnet | aspnet-core |\n| 8 | Testing Spring Boot Kafka Listener | tc-guide-testing-spring-boot-kafka-listener | java | spring-boot-kafka |\n| 9 | REST API integrations with MockServer | tc-guide-testing-rest-api-integrations-using-mockserver | java | mockserver |\n| 10 | Getting started for .NET | tc-guide-getting-started-with-testcontainers-for-dotnet | dotnet | getting-started |\n| 11 | AWS integrations with LocalStack | tc-guide-testing-aws-service-integrations-using-localstack | java | aws-localstack |\n| 12 | Testcontainers in Quarkus apps | tc-guide-testcontainers-in-quarkus-applications | java | quarkus |\n| 13 | Getting started for Go | tc-guide-getting-started-with-testcontainers-for-go | go | getting-started |\n| 14 | jOOQ and Flyway with Testcontainers | tc-guide-working-with-jooq-flyway-using-testcontainers | java | jooq-flyway |\n| 15 | Getting started for Node.js | tc-guide-getting-started-with-testcontainers-for-nodejs | nodejs | getting-started |\n| 16 | REST API integrations with WireMock | tc-guide-testing-rest-api-integrations-using-wiremock | java | wiremock |\n| 17 | Local dev with Testcontainers Desktop | tc-guide-simple-local-development-with-testcontainers-desktop | java | local-dev-desktop |\n| 18 | Micronaut REST API with WireMock | tc-guide-testing-rest-api-integrations-in-micronaut-apps-using-wiremock | java | micronaut-wiremock |\n| 19 | Micronaut Kafka Listener | tc-guide-testing-micronaut-kafka-listener | java | micronaut-kafka |\n| 20 | Getting started for Python | tc-guide-getting-started-with-testcontainers-for-python | python | getting-started |\n| 21 | Keycloak with Spring Boot | tc-guide-securing-spring-boot-microservice-using-keycloak-and-testcontainers | java | keycloak-spring-boot |\n\nAlready migrated: **#2 (Java getting-started)**, **#13 (Go getting-started)**, **#20 (Python getting-started)**\n\n## Step 0: Pre-flight\n\n1. Confirm `testing-with-docker` tag exists in `data/tags.yaml`. If not, add:\n ```yaml\n testing-with-docker:\n title: Testing with Docker\n ```\n2. Check if new terms need adding to `_vale/config/vocabularies/Docker/accept.txt`.\n3. Read `STYLE.md` and `COMPONENTS.md` to refresh on Docker docs conventions.\n\n## Step 1: Clone the guide repo\n\nClone the guide repo to a temporary directory. This gives you all source files locally — no HTTP calls needed.\n\n```bash\ngit clone --depth 1 https://github.com/testcontainers/{REPO_NAME}.git <tmpdir>/{REPO_NAME}\n```\n\nWhere `<tmpdir>` is a temporary directory on your system (e.g. the output of `mktemp -d`).\n\nThe repo structure is:\n- `<tmpdir>/{REPO_NAME}/guide/{SLUG}/index.adoc` — the AsciiDoc guide source\n- `<tmpdir>/{REPO_NAME}/src/` — application source code (referenced by `include::` directives)\n- `<tmpdir>/{REPO_NAME}/testdata/` — test data files (SQL scripts, configs, etc.)\n- `<tmpdir>/{REPO_NAME}/pom.xml` or `go.mod` — build config\n\n1. Read `guide/{SLUG}/index.adoc` to get the guide content.\n2. Find all `include::{codebase}/path/to/file[]` directives. The `{codebase}` attribute points to a remote URL, but since you have the repo cloned, read the files directly from disk instead (e.g. `include::{codebase}/src/main/java/Foo.java[]` → read `<tmpdir>/{REPO_NAME}/src/main/java/Foo.java`).\n3. If includes have `[lines=\"X..Y\"]`, extract only those lines from the local file.\n4. Note the `[source,lang]` block preceding each include — that determines the code fence language.\n\nThis cloned repo also serves as the base for Step 6 (code verification) — you can run the tests directly in it to confirm they pass before updating the code to the latest API.\n\n## Step 2: Convert AsciiDoc to Markdown\n\n| AsciiDoc | Markdown |\n|---|---|\n| `== Heading` | `## Heading` |\n| `=== Heading` | `### Heading` |\n| `*bold*` (AsciiDoc bold) | `**bold**` |\n| `https://url[Link text]` | `[Link text](url)` |\n| `[source,lang]\\n----\\ncode\\n----` | `` ```lang\\ncode\\n``` `` |\n| `[source,shell]` with `$` prompts | `` ```console `` |\n| `[NOTE]\\ntext` or `====\\n[NOTE]\\n...\\n====` | `> [!NOTE]\\n> text` |\n| `[TIP]\\ntext` | `> [!TIP]\\n> text` |\n| `:toc:`, `:toclevels:`, `:codebase:` | Remove entirely |\n| `include::{codebase}/path[]` | Replace with fetched code in a code fence |\n| YAML front matter (date, draft, repo) | Remove; transform to Docker docs format |\n\n## Step 3: Apply Docker docs style rules\n\nThese are mandatory (from STYLE.md and AGENTS.md):\n\n- **No \"we\"**: \"We are going to create\" → \"Create\" or \"Start by creating\"\n- **No \"let us\" / \"let's\"**: → imperative voice or \"You can...\"\n- **No hedge words**: remove \"simply\", \"easily\", \"just\", \"seamlessly\"\n- **No meta-commentary**: remove \"it's worth noting\", \"it's important to understand\"\n- **No \"allows you to\" / \"enables you to\"**: → \"lets you\" or rephrase\n- **No \"click\"**: → \"select\"\n- **No bold for emphasis or product names**: only bold UI elements\n- **No time-relative language**: remove \"currently\", \"new\", \"recently\", \"now\"\n- **No exclamations**: remove \"Voila!!!\" etc.\n- Use `console` language hint for interactive shell blocks with `$` prompts\n- Use contractions: \"it's\", \"you're\", \"don't\"\n\n## Step 4: Update code to latest Testcontainers API\n\nResearch the latest API version for the target language before writing code.\n\n**Best practices reference**: The Testcontainers team maintains Claude skills with up-to-date API patterns and best practices for each language at https://github.com/testcontainers/claude-skills/ — check the relevant language skill (testcontainers-go, testcontainers-node, testcontainers-dotnet) for current API signatures, cleanup patterns, wait strategies, and anti-patterns to avoid.\n\nFor each language, check the cloned repo's existing code, then update to the latest API. Key patterns per language:\n\n**Go** (testcontainers-go v0.41.0):\n- `postgres.RunContainer(ctx, opts...)` → `postgres.Run(ctx, \"image\", opts...)`\n- `testcontainers.WithImage(...)` → image is now the 2nd positional param to `Run()`\n- Manual `WithWaitStrategy(wait.ForLog(...))` → `postgres.BasicWaitStrategies()`\n- `t.Cleanup(func() { ctr.Terminate(ctx) })` → `testcontainers.CleanupContainer(t, ctr)`\n- `if err != nil { log.Fatal(err) }` → `require.NoError(t, err)` (use testify require/assert)\n- Helper functions should accept `t *testing.T` as first param, call `t.Helper()`\n- No `TearDownSuite()` needed if `CleanupContainer` is registered in the helper\n- Go version prerequisite: 1.25+\n\n**Java** (testcontainers-java 2.0.4):\n- Artifacts renamed in 2.x: `org.testcontainers:postgresql` → `org.testcontainers:testcontainers-postgresql`\n- Check the latest version at https://java.testcontainers.org/\n- Use `@Testcontainers` and `@Container` annotations for JUnit 5 lifecycle\n- Prefer module-specific containers (e.g. `PostgreSQLContainer`) over `GenericContainer`\n- Use `@DynamicPropertySource` for Spring Boot integration\n\n**.NET** (testcontainers-dotnet):\n- Check the latest NuGet package version\n- Use `IAsyncLifetime` for container lifecycle in xUnit\n- Use builder pattern: `new PostgreSqlBuilder().Build()`\n\n**Node.js** (testcontainers-node):\n- Check the latest npm version\n- Use module-specific packages (e.g. `@testcontainers/postgresql`)\n- Use `GenericContainer` for services without a dedicated module\n\n**Python** (testcontainers-python):\n- Check the latest PyPI version\n- Use context managers (`with PostgresContainer() as postgres:`)\n- Use module-specific containers when available\n\nFor all languages: consult the corresponding Testcontainers skill at https://github.com/testcontainers/claude-skills/ for current best practices and anti-patterns.\n\n## Step 5: Create guide directory structure\n\nDirectory: `content/guides/testcontainers-{LANG}-{GUIDE_ID}/`\n\nEach guide is its own top-level entry under `/guides/`. Do NOT nest guides inside a shared parent section — otherwise they won't appear individually in the tag/language filters on the guides listing page.\n\n### _index.md (landing page)\n\n```yaml\n---\ntitle: {Full guide title}\nlinkTitle: {Short title for guides listing}\ndescription: {One-line description}\nkeywords: testcontainers, {lang}, testing, {technologies used}\nsummary: |\n {2-3 line summary for the guides listing card}\ntoc_min: 1\ntoc_max: 2\ntags: [testing-with-docker]\nlanguages: [{lang}]\nparams:\n time: {estimated} minutes\n---\n\n<!-- Source: https://github.com/testcontainers/{REPO_NAME} -->\n```\n\nContent: what you'll learn (bulleted list), prerequisites, and a NOTE linking to `https://testcontainers.com/getting-started/` for newcomers.\n\n### Sub-pages (chapters)\n\nSplit the guide into logical chapters. Each sub-page:\n\n```yaml\n---\ntitle: {Chapter title}\nlinkTitle: {Short title for stepper}\ndescription: {One-line description}\nweight: {10, 20, 30, ...}\n---\n```\n\n**No `tags`, `languages`, or `params` on sub-pages** — only on `_index.md`.\n\nTypical chapter breakdown:\n| Weight | File | Content |\n|--------|------|---------|\n| 10 | `create-project.md` | Project setup, dependencies, business logic |\n| 20 | `write-tests.md` | First test using testcontainers |\n| 30 | `test-suites.md` | Reusing containers, test helpers, suites |\n| 40 | `run-tests.md` | Running tests, summary, further reading |\n\nAdapt the split to the guide's content — some guides may need fewer or more chapters.\n\n## Step 6: Verify code compiles and tests pass\n\nThis is CRITICAL. The code in the guide MUST compile and all tests MUST pass. Do not skip this step.\n\n### 6a: Use the cloned repo as the verification project\n\nThe repo you cloned in Step 1 (`<tmpdir>/{REPO_NAME}`) already contains a working project with all source files, build config, and tests. Use it as the starting point:\n\n```bash\ncd <tmpdir>/{REPO_NAME}\n```\n\nFirst, verify the **original** code compiles and tests pass before you change anything. This confirms a good baseline.\n\n### 6b: Update the code in the cloned repo\n\nAfter confirming the original works, apply the API updates (from Step 4) directly in the cloned repo's source files. This is the same code you're putting in the guide — keep them in sync.\n\n### 6c: Update dependencies and compile\n\nRun compilation inside a container for reproducibility — no need to install the language toolchain on the host. Use the appropriate language Docker image, mounting the cloned repo:\n\n```bash\ndocker run --rm -v \"<tmpdir>/{REPO_NAME}\":/app -w /app <language-image> sh -c \"<compile command>\"\n```\n\nPick the right image for the language (e.g. `golang:1.25-alpine`, `maven:3-eclipse-temurin-21`, `gradle:jdk21`, `mcr.microsoft.com/dotnet/sdk:9.0`, `node:22-alpine`, `python:3.13-alpine`). Update dependencies to the latest Testcontainers version and compile.\n\nIf compilation fails, fix the code and update the guide markdown to match.\n\n### 6d: Run tests in a container with Docker socket mounted\n\nRun tests in the same kind of container, but **mount the Docker socket** so Testcontainers can create sibling containers.\n\n#### macOS Docker Desktop workarounds\n\nWhen running on macOS with Docker Desktop, these environment variables and flags are **required**:\n\n- **`TESTCONTAINERS_HOST_OVERRIDE=host.docker.internal`** — On macOS, containers can't reach sibling containers via the Docker bridge IP (`172.17.0.x`). This tells Testcontainers (including Ryuk) to connect via `host.docker.internal` instead. **Do NOT disable Ryuk** — it is a core Testcontainers feature and the guides must demonstrate proper usage.\n- **`docker-java.properties`** with `api.version=1.47` — Docker Desktop's minimum API version is 1.44, but docker-java defaults to 1.24. Create this file in the project root and mount it to `/root/.docker-java.properties` inside Java containers.\n- **`-Dspotless.check.skip=true`** — The Spotless Maven plugin in the source repos is incompatible with JDK 21. Skip it since it's a code formatter, not part of the test.\n- **`-Dmicronaut.test.resources.enabled=false`** — Micronaut's Test Resources service starts a separate process that can't connect to Docker from inside a container. The guide tests use Testcontainers directly, not Test Resources. Only needed for Micronaut guides.\n#### Java guide test command\n\n```bash\n# Create docker-java.properties in the project root\necho \"api.version=1.47\" > <tmpdir>/{REPO_NAME}/docker-java.properties\n\ndocker run --rm \\\n -v \"<tmpdir>/{REPO_NAME}\":/app \\\n -v /var/run/docker.sock:/var/run/docker.sock \\\n -v \"<tmpdir>/{REPO_NAME}/docker-java.properties\":/root/.docker-java.properties \\\n -e DOCKER_HOST=unix:///var/run/docker.sock \\\n -e TESTCONTAINERS_HOST_OVERRIDE=host.docker.internal \\\n -w /app \\\n maven:3.9-eclipse-temurin-21 \\\n mvn -B test -Dspotless.check.skip=true -Dspotless.apply.skip=true\n```\n\nFor Quarkus guides, use `maven:3.9-eclipse-temurin-17` instead (Quarkus 3.22.3 compiles for Java 17).\n\n#### Go guide test command\n\n```bash\ndocker run --rm \\\n -v \"<tmpdir>/{REPO_NAME}\":/app \\\n -v /var/run/docker.sock:/var/run/docker.sock \\\n -e DOCKER_HOST=unix:///var/run/docker.sock \\\n -e TESTCONTAINERS_HOST_OVERRIDE=host.docker.internal \\\n -w /app \\\n golang:1.25-alpine \\\n sh -c \"apk add --no-cache gcc musl-dev && go test -v -count=1 ./...\"\n```\n\n#### Python guide test command\n\n```bash\ndocker run --rm \\\n -v \"<tmpdir>/{REPO_NAME}\":/app \\\n -v /var/run/docker.sock:/var/run/docker.sock \\\n -e DOCKER_HOST=unix:///var/run/docker.sock \\\n -e TESTCONTAINERS_HOST_OVERRIDE=host.docker.internal \\\n -w /app \\\n python:3.13-slim \\\n sh -c \"pip install -r requirements.txt && python -m pytest\"\n```\n\n#### .NET guide test command\n\n```bash\ndocker run --rm \\\n -v \"<tmpdir>/{REPO_NAME}\":/app \\\n -v /var/run/docker.sock:/var/run/docker.sock \\\n -e DOCKER_HOST=unix:///var/run/docker.sock \\\n -e TESTCONTAINERS_HOST_OVERRIDE=host.docker.internal \\\n -w /app \\\n mcr.microsoft.com/dotnet/sdk:9.0 \\\n dotnet test\n```\n\n#### Node.js guide test command\n\n```bash\ndocker run --rm \\\n -v \"<tmpdir>/{REPO_NAME}\":/app \\\n -v /var/run/docker.sock:/var/run/docker.sock \\\n -e DOCKER_HOST=unix:///var/run/docker.sock \\\n -e TESTCONTAINERS_HOST_OVERRIDE=host.docker.internal \\\n -w /app \\\n node:22-alpine \\\n sh -c \"npm install && npm test\"\n```\n\n#### Important: run tests sequentially\n\nRun guide tests **one at a time**. Running multiple concurrent DinD or sibling-container tests can overwhelm Docker Desktop's containerd store and cause `meta.db: input/output error` corruption, requiring a Docker Desktop restart.\n\n### 6e: Fix until green\n\nIf any test fails, debug and fix the code in both the temporary project AND the guide markdown. Re-run until all tests pass. Do not proceed until verified.\n\n## Step 7: Update cross-references\n\n1. **`content/manuals/testcontainers.md`**: Add a bullet under the `## Guides` section:\n ```markdown\n - [Guide title](/guides/testcontainers-{LANG}-{GUIDE_ID}/)\n ```\n2. **Do NOT update** `content/guides/testcontainers-cloud/_index.md` — keep its external links.\n3. Link to `https://testcontainers.com/getting-started/` for the Testcontainers overview.\n4. Use internal paths for already-migrated guides; keep `testcontainers.com` links for unmigrated ones.\n\n## Step 8: Validate\n\n**IMPORTANT**: Run ALL validation locally before committing. Vale checks run on CI and will block the PR if they fail — fixing after push wastes CI cycles and review time.\n\n1. `npx --no-install rumdl fmt content/guides/testcontainers-{LANG}-{GUIDE_ID}/`\n2. `npx --no-install rumdl fmt content/manuals/testcontainers.md`\n3. `docker buildx bake lint` — must pass with no errors\n4. `docker buildx bake vale` — then check for errors in the new files:\n ```bash\n grep -A2 \"testcontainers-{LANG}-{GUIDE_ID}\" tmp/vale.out\n ```\n Fix ALL errors before proceeding. Common issues:\n - **Vale.Spelling**: tech terms (library names, tools) not in the dictionary → add to `_vale/config/vocabularies/Docker/accept.txt` (alphabetical order)\n - **Vale.Terms**: wrong casing (e.g. \"python\" → \"Python\") → fix in the markdown. Watch for package names like `testcontainers-python` triggering false positives — rephrase to \"Testcontainers for Python\" in prose.\n - **Docker.Avoid**: hedge words like \"very\", \"simply\" → reword\n - **Docker.We**: first-person plural → rewrite to \"you\" or imperative\n - Info-level suggestions (e.g. \"VS Code\" → \"versus\") are not blocking but review them\n\n Re-run `docker buildx bake vale` after fixes until no errors remain in the new files.\n5. Verify in local dev server (`HUGO_PORT=1314 docker compose watch`):\n - Guide appears when filtering by its language\n - Guide appears when filtering by `Testing with Docker` tag\n - Stepper navigation works across chapters\n - All links resolve (no 404s)\n6. Verify all external URLs return 200:\n ```bash\n curl -s -o /dev/null -w \"%{http_code}\" -L \"{url}\"\n ```\n\n## Step 9: Commit\n\nOne commit per guide. Message format:\n```\nfeat(guides): add testcontainers {lang} {guide-id} guide\n\nMigrated from https://github.com/testcontainers/{REPO_NAME}\nUpdated to testcontainers-{lang} v{version} API.\n```\n\n## Special cases\n\n- **introducing-testcontainers**: Language-agnostic, conceptual. May overlap with `content/manuals/testcontainers.md`. Review for deduplication before migrating.\n- **local-dev-testcontainers-desktop**: About Testcontainers Desktop (now part of Docker Desktop). May need significant rewriting rather than mechanical migration.\n- **Java guides**: Many share the same language. Each still gets its own `testcontainers-java-{GUIDE_ID}` directory.\n\n## Reference: completed migration (Go getting-started)\n\nUse `content/guides/testcontainers-go-getting-started/` as the reference implementation:\n- `_index.md` — landing page with frontmatter, prerequisites, learning objectives\n- `create-project.md` (weight: 10) — project setup and business logic\n- `write-tests.md` (weight: 20) — first test with testcontainers-go\n- `test-suites.md` (weight: 30) — container reuse with testify suites\n- `run-tests.md` (weight: 40) — running tests, summary, further reading\n",".agents/skills/review-pr/SKILL.md":"---\nname: review-pr\ndescription: >\n Review one or more incoming Docker documentation pull requests as a\n maintainer. Independently validate technical claims, assess editorial fit\n and information architecture, choose a verdict, and draft exact inline or\n PR-wide feedback behind a confirmation gate. Use for requests such as\n \"review PR 123\", \"is this PR correct?\", \"does this information belong\n here?\", \"validate this PR\", or \"help review backlog PRs\". Do not use to\n maintain or fix a PR you own; use maintain-pr for that.\n---\n\n# Review PR\n\nReview incoming contributions for factual correctness and whether they make\nthe documentation better as a whole. Treat a technically true addition as\ninsufficient when it is misplaced, overemphasized, redundant, or unhelpful\nto the page's intended reader.\n\n## Preserve the write boundary\n\nPerform the review in two phases:\n\n1. Research the PR, decide a verdict, and present the exact proposed\n comment or review text.\n2. Wait for explicit user confirmation, then post only the confirmed text.\n\nBefore confirmation, do not post comments, submit a GitHub review, approve or\nrequest changes, resolve threads, push commits, edit labels, or otherwise\nmutate GitHub. A request to review or draft feedback is not confirmation to\npost it. Ask `Post these comments?` and stop. Treat revisions to a draft as\nunconfirmed until the user explicitly asks to post them.\n\n## 1. Gather the full context\n\nFor each PR, inspect its metadata, body, commits, changed files, checks,\nconversation, reviews, and linked issues. Always fetch inline comments\nseparately because `gh pr view --json reviews` omits them.\n\n```bash\ngh pr view <PR> --repo docker/docs \\\n --json number,title,url,state,author,body,baseRefName,headRefName,headRefOid,commits,files,comments,reviews,reviewDecision,statusCheckRollup\ngh api repos/docker/docs/pulls/<PR>/comments \\\n --jq '[.[] | {id, author: .user.login, body, path, line, side, commit_id}]'\ngh pr diff <PR> --repo docker/docs\n```\n\nRead linked issues and relevant discussion. An issue is evidence that a\nreader was confused, but it does not establish the reporter's diagnosis or\njustify a new highlighted note by itself. Green CI establishes only that automated\nchecks passed, not that the content is correct.\n\nFetch the PR head when local inspection is useful. Compare it with the\ncanonical upstream base rather than assuming the local branch is fresh.\nRead each changed file in full, not only its diff.\n\n## 2. Research independently\n\nVerify every material claim against authoritative sources such as product\nsource code, upstream documentation, specifications, release notes, or safe\nlocal reproduction. Do not accept the PR description, issue diagnosis, or\nexisting review feedback as fact.\n\nSearch the documentation for related explanations and canonical pages. Read\n`STYLE.md`, `COMPONENTS.md`, and applicable repository instructions. Check\nwhether a changed file is generated or maintained upstream and identify the correct\nupstream repository instead of proposing a local edit.\n\nDistinguish among:\n\n- a wrong fact\n- a correct fact expressed inaccurately\n- a correct fact placed on the wrong page\n- content already explained elsewhere\n- a real discovery problem better addressed with a short signpost and link\n- a request that needs no documentation change.\n\nIf an external claim or replacement URL cannot be verified, report that\nlimitation instead of guessing.\n\n## 3. Assess editorial fit\n\nApply these questions to each addition:\n\n- Does it change a reader's decision or next action on this page?\n- Is this the canonical page for the concept?\n- Is the fact general, or specific to this page, feature, or component?\n- Is the information already documented elsewhere?\n- Would a concise local signpost to canonical coverage solve the discovery\n problem better than duplicating the explanation?\n- Is the visual and textual weight proportional to the information's value?\n- Does it preserve the page's scope, flow, and character?\n\nPrefer one coherent explanation in the canonical location. Add local context\nonly when it helps the reader complete the task at hand. Avoid stray notes,\ncallouts, and exhaustive edge cases whose prominence exceeds their value.\n\n## 4. Choose a decisive verdict\n\nLead with one of these outcomes:\n\n- **Approve**: correct, useful, well placed, and ready to merge.\n- **Approve with optional polish**: ready to merge; suggestions are genuinely\n non-blocking.\n- **Focused rewrite**: the underlying need is valid, but wording, scope,\n placement, or structure should change before merge.\n- **Close / no docs change**: incorrect, redundant, out of scope, or not a\n documentation problem.\n\nExplain the verdict with evidence. When wording is the issue, provide exact\nreplacement text rather than a vague request to improve it.\n\n## 5. Place feedback deliberately\n\nUse an inline comment when the finding is anchored to a narrow changed line\nor range and acting on it is local. Examples include an inaccurate sentence,\nan ambiguous option description, a broken link, or a precise wording\nreplacement.\n\nUse a PR-wide comment for scope, information architecture, overall approach,\nmultiple intertwined edits, or a proposed replacement section. Do not attach\nholistic feedback to an arbitrary line.\n\nUse both when appropriate: put the overall direction in the PR-wide comment\nand line-specific corrections inline. Do not repeat the same point in both.\nConsolidate related feedback so the author receives the fewest comments that\nremain clear and actionable.\n\nFor every proposed inline comment, resolve and display the current changed\nfile path and right-side diff line. If the target line is not part of the\ncurrent diff or cannot be identified reliably, use a PR-wide comment that\nquotes the target text instead. Never guess a line number.\n\nEnd comments posted on the user's behalf with an accurate agent-disclosure\nfooter, such as `Generated by Codex`.\n\n## 6. Present drafts and stop\n\nBefore any GitHub write, show the review in this form, omitting empty\nsections:\n\n```markdown\n## Verdict\n\nFocused rewrite\n\n## Findings\n\n- <finding and evidence>\n\n## Proposed inline comments\n\n1. `path/to/file.md:42`\n > Exact comment text\n\n## Proposed PR-wide comment\n\n> Exact comment text\n\nPost these comments?\n```\n\nFor multiple PRs, give each PR its own verdict and comment set. Make the\nconfirmation scope unambiguous. Do not interpret approval of one PR's drafts\nas approval to post comments on the others.\n\n## 7. Post only confirmed feedback\n\nImmediately before posting, re-fetch the PR head SHA and diff. If either the\nhead or an inline target changed, stop and show the updated draft or\nplacement for confirmation.\n\nPost confirmed inline comments as a single comment-only review when\npractical. Use the current head SHA and right-side diff lines:\n\n```bash\ngh api repos/docker/docs/pulls/<PR>/reviews --method POST --input <payload>\n```\n\nThe JSON payload contains `commit_id`, `event: \"COMMENT\"`, and a `comments`\narray whose entries contain `path`, `line`, `side: \"RIGHT\"`, and `body`.\nSubmitting a review with `APPROVE` or `REQUEST_CHANGES` requires separate,\nexplicit user authorization; a verdict alone does not grant it.\n\nPost confirmed holistic feedback separately:\n\n```bash\ngh pr comment <PR> --repo docker/docs --body-file <file>\n```\n\nUse a safely created temporary file or API input so Markdown, backticks, and\nshell substitutions are preserved literally. Post exactly the confirmed\ntext. Verify the resulting review/comments and report their URLs and\nplacements. If GitHub rejects an inline location, do not silently fall back\nto a PR-wide comment; report the failure and prepare a revised placement for\nconfirmation.\n\n## Definition of done\n\n- Verify technical claims with authoritative evidence.\n- Evaluate usefulness, placement, duplication, and proportionality.\n- Give a decisive verdict and exact actionable wording.\n- Choose inline and PR-wide placement based on the feedback's scope.\n- Show every exact draft and target before any GitHub mutation.\n- Post only after explicit confirmation and verify what was posted.\n",".agents/skills/review-changes/SKILL.md":"---\nname: review-changes\ndescription: >\n Review uncommitted or recently committed documentation changes for\n correctness, coherence, and style compliance. Use before creating a PR\n to catch issues. \"review my changes\", \"review the diff\", \"check the fix\n before submitting\", \"does this look right\".\ncontext: fork\nmodel: opus\n---\n\n# Review Changes\n\nEvaluate whether the changes correctly and completely solve the stated\nproblem, without introducing new issues. Start with no assumptions — the\nchange may contain mistakes. Your job is to catch what the writer missed,\nnot to rubber-stamp the diff.\n\n## 1. Identify what changed\n\nDetermine the scope of changes to review:\n\n```bash\n# Uncommitted changes\ngit diff --name-only\n\n# Last commit\ngit diff --name-only HEAD~1\n\n# Entire branch vs main\ngit diff --name-only main...HEAD\n```\n\nPick the right comparison for what's being reviewed. If reviewing a branch,\nuse `main...HEAD` to see all changes since the branch diverged.\n\n## 2. Read each changed file in full\n\nDo not just read the diff. For every changed file, read the entire file to\nunderstand the full context the change lives in. A diff can look correct in\nisolation but contradict something earlier on the same page.\n\nThen read the diff for the detailed changes:\n\n```bash\n# Adjust the comparison to match step 1\ngit diff --unified=10 # uncommitted\ngit diff --unified=10 HEAD~1 # last commit\ngit diff --unified=10 main...HEAD # branch\n```\n\n## 3. Follow cross-references\n\nFor each changed file, check what links to it and what it links to:\n\n- Search for other pages that reference the changed content (grep for the\n filename, heading anchors, or key phrases)\n- Read linked pages to verify the change doesn't create contradictions\n across pages\n- Check that anchor links in cross-references still match heading IDs\n\nA change that's correct on its own page can break the story told by a\nrelated page.\n\n## 4. Verify factual accuracy\n\nDon't assume the change is factually correct just because it reads well.\n\n- If the change describes how a feature behaves, verify against upstream\n docs or source code\n- If the change includes a URL, check that it resolves\n- If the change references a CLI flag, option, or API field, confirm it\n exists\n\n## 5. Evaluate as a reader\n\nConsider someone landing on this page from a search result, with no prior\ncontext:\n\n- Does the page make sense on its own?\n- Is the changed section clear without having read the issue or diff?\n- Would a reader be confused by anything the change introduces or leaves\n out?\n\nAccuracy alone doesn't justify an addition. For each substantive addition, ask:\n\n- Does it help readers act, choose, or understand a consequence?\n- Does it belong under this heading and at this point in the explanation?\n- Does it interrupt a procedure, example, or explanation already in progress?\n- Is the detail proportional to its value here, or would a link suffice?\n- Would removing it improve the page without losing necessary guidance?\n\nRecommend shortening, moving, or deleting accurate text when it doesn't serve\nthe page's task. When reviewing multiple commits, check both each change in\ncontext and the combined diff for repeated explanations.\n\n## 6. Review code and template changes\n\nFor non-Markdown changes (JS, HTML, CSS, Hugo templates):\n\n- Trace through the common execution path\n- Trace through at least one edge case (no stored preference, Alpine fails\n to load, first visit vs returning visitor)\n- Ask whether the change could produce unexpected browser or runtime\n behavior that no automated tool would catch\n\n## 7. Decision\n\n**Approve** if the change is correct, coherent, complete, and factually\naccurate.\n\n**Request changes** if:\n- The change does not correctly solve the stated problem\n- There is a factual error or contradiction (on-page or cross-page)\n- A cross-reference is broken or misleading\n- A reader would be confused\n- An addition duplicates guidance or disrupts the page without enough reader value\n\nWhen requesting changes, be specific: quote the exact text that is wrong,\nexplain why, and suggest the correct fix.\n",".agents/skills/write/SKILL.md":"# write\n\nPath: `.agents/skills/write/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/.agents/skills/write/SKILL.md)","AGENTS.md":"# AI Agent Protocol & Instructions\n\nPath: `AGENTS.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/AGENTS.md)","CLAUDE.md":"# Claude Agent Guidelines & System Prompt\n\nPath: `CLAUDE.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/CLAUDE.md)",".github/agents/docs-scanner.yaml":"# Agents Skill\n\nPath: `.github/agents/docs-scanner.yaml`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/.github/agents/docs-scanner.yaml)","content/manuals/extensions/_index.md":"# Extensions Skill\n\nPath: `content/manuals/extensions/_index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/_index.md)","content/manuals/extensions/marketplace.md":"# Extensions Skill\n\nPath: `content/manuals/extensions/marketplace.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/marketplace.md)","content/manuals/extensions/non-marketplace.md":"# Extensions Skill\n\nPath: `content/manuals/extensions/non-marketplace.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/non-marketplace.md)","content/manuals/extensions/private-marketplace.md":"# Extensions Skill\n\nPath: `content/manuals/extensions/private-marketplace.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/private-marketplace.md)","content/manuals/extensions/settings-feedback.md":"# Extensions Skill\n\nPath: `content/manuals/extensions/settings-feedback.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/settings-feedback.md)",".agents/skills/agent-readiness-audit/references/report-template.md":"# References Skill\n\nPath: `.agents/skills/agent-readiness-audit/references/report-template.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/.agents/skills/agent-readiness-audit/references/report-template.md)",".agents/skills/agent-readiness-audit/references/rubric.md":"# References Skill\n\nPath: `.agents/skills/agent-readiness-audit/references/rubric.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/.agents/skills/agent-readiness-audit/references/rubric.md)",".agents/skills/curate-whats-new/agents/openai.yaml":"# Agents Skill\n\nPath: `.agents/skills/curate-whats-new/agents/openai.yaml`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/.agents/skills/curate-whats-new/agents/openai.yaml)",".agents/skills/curate-whats-new/examples/2026-07-13--2026-08-11.json":"# Examples Skill\n\nPath: `.agents/skills/curate-whats-new/examples/2026-07-13--2026-08-11.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/.agents/skills/curate-whats-new/examples/2026-07-13--2026-08-11.json)",".agents/skills/curate-whats-new/examples/2026-07-13--2026-08-11.yaml":"# Examples Skill\n\nPath: `.agents/skills/curate-whats-new/examples/2026-07-13--2026-08-11.yaml`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/.agents/skills/curate-whats-new/examples/2026-07-13--2026-08-11.yaml)",".agents/skills/maintain-pr/agents/openai.yaml":"# Agents Skill\n\nPath: `.agents/skills/maintain-pr/agents/openai.yaml`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/.agents/skills/maintain-pr/agents/openai.yaml)",".agents/skills/review-pr/agents/openai.yaml":"# Agents Skill\n\nPath: `.agents/skills/review-pr/agents/openai.yaml`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/.agents/skills/review-pr/agents/openai.yaml)","content/manuals/ai/skills/_index.md":"# Skills Skill\n\nPath: `content/manuals/ai/skills/_index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/ai/skills/_index.md)","content/manuals/ai/skills/install.md":"# Skills Skill\n\nPath: `content/manuals/ai/skills/install.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/ai/skills/install.md)","content/manuals/dhi/tools/_index.md":"# Tools Skill\n\nPath: `content/manuals/dhi/tools/_index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/dhi/tools/_index.md)","content/manuals/dhi/tools/api.md":"# Tools Skill\n\nPath: `content/manuals/dhi/tools/api.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/dhi/tools/api.md)","content/manuals/dhi/tools/cli.md":"# Tools Skill\n\nPath: `content/manuals/dhi/tools/cli.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/dhi/tools/cli.md)","content/manuals/dhi/tools/hub.md":"# Tools Skill\n\nPath: `content/manuals/dhi/tools/hub.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/dhi/tools/hub.md)","content/manuals/dhi/tools/mcp.md":"# Tools Skill\n\nPath: `content/manuals/dhi/tools/mcp.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/dhi/tools/mcp.md)","content/manuals/dhi/tools/terraform.md":"# Tools Skill\n\nPath: `content/manuals/dhi/tools/terraform.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/dhi/tools/terraform.md)","content/manuals/extensions/extensions-sdk/_index.md":"# Extensions-sdk Skill\n\nPath: `content/manuals/extensions/extensions-sdk/_index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/_index.md)","content/manuals/extensions/extensions-sdk/process.md":"# Extensions-sdk Skill\n\nPath: `content/manuals/extensions/extensions-sdk/process.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/process.md)","content/manuals/extensions/extensions-sdk/quickstart.md":"# Extensions-sdk Skill\n\nPath: `content/manuals/extensions/extensions-sdk/quickstart.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/quickstart.md)","content/manuals/ai/sandboxes/agents/_index.md":"# Subagent: index\n\nPath: `content/manuals/ai/sandboxes/agents/_index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/ai/sandboxes/agents/_index.md)","content/manuals/ai/sandboxes/agents/claude-code.md":"# Subagent: claude-code\n\nPath: `content/manuals/ai/sandboxes/agents/claude-code.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/ai/sandboxes/agents/claude-code.md)","content/manuals/ai/sandboxes/agents/codex.md":"# Subagent: codex\n\nPath: `content/manuals/ai/sandboxes/agents/codex.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/ai/sandboxes/agents/codex.md)","content/manuals/ai/sandboxes/agents/copilot.md":"# Subagent: copilot\n\nPath: `content/manuals/ai/sandboxes/agents/copilot.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/ai/sandboxes/agents/copilot.md)","content/manuals/ai/sandboxes/agents/cursor.md":"# Subagent: cursor\n\nPath: `content/manuals/ai/sandboxes/agents/cursor.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/ai/sandboxes/agents/cursor.md)","content/manuals/ai/sandboxes/agents/devin.md":"# Subagent: devin\n\nPath: `content/manuals/ai/sandboxes/agents/devin.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/ai/sandboxes/agents/devin.md)","content/manuals/ai/sandboxes/agents/docker-agent.md":"# Subagent: docker-agent\n\nPath: `content/manuals/ai/sandboxes/agents/docker-agent.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/ai/sandboxes/agents/docker-agent.md)","content/manuals/ai/sandboxes/agents/droid.md":"# Subagent: droid\n\nPath: `content/manuals/ai/sandboxes/agents/droid.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/ai/sandboxes/agents/droid.md)","content/manuals/ai/sandboxes/agents/gemini.md":"# Subagent: gemini\n\nPath: `content/manuals/ai/sandboxes/agents/gemini.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/ai/sandboxes/agents/gemini.md)","content/manuals/ai/sandboxes/agents/kiro.md":"# Subagent: kiro\n\nPath: `content/manuals/ai/sandboxes/agents/kiro.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/ai/sandboxes/agents/kiro.md)","content/manuals/ai/sandboxes/agents/opencode.md":"# Subagent: opencode\n\nPath: `content/manuals/ai/sandboxes/agents/opencode.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/ai/sandboxes/agents/opencode.md)","content/manuals/ai/sandboxes/agents/shell.md":"# Subagent: shell\n\nPath: `content/manuals/ai/sandboxes/agents/shell.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/ai/sandboxes/agents/shell.md)","content/manuals/extensions/extensions-sdk/architecture/_index.md":"# Architecture Skill\n\nPath: `content/manuals/extensions/extensions-sdk/architecture/_index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/architecture/_index.md)","content/manuals/extensions/extensions-sdk/architecture/metadata.md":"# Architecture Skill\n\nPath: `content/manuals/extensions/extensions-sdk/architecture/metadata.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/architecture/metadata.md)","content/manuals/extensions/extensions-sdk/architecture/security.md":"# Architecture Skill\n\nPath: `content/manuals/extensions/extensions-sdk/architecture/security.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/architecture/security.md)","content/manuals/extensions/extensions-sdk/build/_index.md":"# Build Skill\n\nPath: `content/manuals/extensions/extensions-sdk/build/_index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/build/_index.md)","content/manuals/extensions/extensions-sdk/build/backend-extension-tutorial.md":"# Build Skill\n\nPath: `content/manuals/extensions/extensions-sdk/build/backend-extension-tutorial.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/build/backend-extension-tutorial.md)","content/manuals/extensions/extensions-sdk/build/frontend-extension-tutorial.md":"# Build Skill\n\nPath: `content/manuals/extensions/extensions-sdk/build/frontend-extension-tutorial.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/build/frontend-extension-tutorial.md)","content/manuals/extensions/extensions-sdk/build/minimal-frontend-extension.md":"# Build Skill\n\nPath: `content/manuals/extensions/extensions-sdk/build/minimal-frontend-extension.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/build/minimal-frontend-extension.md)","content/manuals/extensions/extensions-sdk/design/_index.md":"# Design Skill\n\nPath: `content/manuals/extensions/extensions-sdk/design/_index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/design/_index.md)","content/manuals/extensions/extensions-sdk/design/design-guidelines.md":"# Design Skill\n\nPath: `content/manuals/extensions/extensions-sdk/design/design-guidelines.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/design/design-guidelines.md)","content/manuals/extensions/extensions-sdk/design/design-principles.md":"# Design Skill\n\nPath: `content/manuals/extensions/extensions-sdk/design/design-principles.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/design/design-principles.md)","content/manuals/extensions/extensions-sdk/design/mui-best-practices.md":"# Design Skill\n\nPath: `content/manuals/extensions/extensions-sdk/design/mui-best-practices.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/design/mui-best-practices.md)","content/manuals/extensions/extensions-sdk/dev/_index.md":"# Dev Skill\n\nPath: `content/manuals/extensions/extensions-sdk/dev/_index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/dev/_index.md)","content/manuals/extensions/extensions-sdk/dev/continuous-integration.md":"# Dev Skill\n\nPath: `content/manuals/extensions/extensions-sdk/dev/continuous-integration.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/dev/continuous-integration.md)","content/manuals/extensions/extensions-sdk/dev/test-debug.md":"# Dev Skill\n\nPath: `content/manuals/extensions/extensions-sdk/dev/test-debug.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/dev/test-debug.md)","content/manuals/extensions/extensions-sdk/dev/usage.md":"# Dev Skill\n\nPath: `content/manuals/extensions/extensions-sdk/dev/usage.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/dev/usage.md)","content/manuals/extensions/extensions-sdk/extensions/DISTRIBUTION.md":"# Extensions Skill\n\nPath: `content/manuals/extensions/extensions-sdk/extensions/DISTRIBUTION.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/extensions/DISTRIBUTION.md)","content/manuals/extensions/extensions-sdk/extensions/_index.md":"# Extensions Skill\n\nPath: `content/manuals/extensions/extensions-sdk/extensions/_index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/extensions/_index.md)","content/manuals/extensions/extensions-sdk/extensions/labels.md":"# Extensions Skill\n\nPath: `content/manuals/extensions/extensions-sdk/extensions/labels.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/extensions/labels.md)","content/manuals/extensions/extensions-sdk/extensions/multi-arch.md":"# Extensions Skill\n\nPath: `content/manuals/extensions/extensions-sdk/extensions/multi-arch.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/extensions/multi-arch.md)","content/manuals/extensions/extensions-sdk/extensions/publish.md":"# Extensions Skill\n\nPath: `content/manuals/extensions/extensions-sdk/extensions/publish.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/extensions/publish.md)","content/manuals/extensions/extensions-sdk/extensions/share.md":"# Extensions Skill\n\nPath: `content/manuals/extensions/extensions-sdk/extensions/share.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/extensions/share.md)","content/manuals/extensions/extensions-sdk/extensions/validate.md":"# Extensions Skill\n\nPath: `content/manuals/extensions/extensions-sdk/extensions/validate.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/extensions/validate.md)","content/manuals/extensions/extensions-sdk/guides/_index.md":"# Guides Skill\n\nPath: `content/manuals/extensions/extensions-sdk/guides/_index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/guides/_index.md)","content/manuals/extensions/extensions-sdk/guides/invoke-host-binaries.md":"# Guides Skill\n\nPath: `content/manuals/extensions/extensions-sdk/guides/invoke-host-binaries.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/guides/invoke-host-binaries.md)","content/manuals/extensions/extensions-sdk/guides/kubernetes.md":"# Guides Skill\n\nPath: `content/manuals/extensions/extensions-sdk/guides/kubernetes.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/guides/kubernetes.md)","content/manuals/extensions/extensions-sdk/guides/oauth2-flow.md":"# Guides Skill\n\nPath: `content/manuals/extensions/extensions-sdk/guides/oauth2-flow.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/guides/oauth2-flow.md)","content/manuals/extensions/extensions-sdk/guides/use-docker-socket-from-backend.md":"# Guides Skill\n\nPath: `content/manuals/extensions/extensions-sdk/guides/use-docker-socket-from-backend.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/guides/use-docker-socket-from-backend.md)","_vendor/github.com/docker/docker-agent/docs/tools/_index.md":"# Tools Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/_index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/_index.md)","content/manuals/extensions/extensions-sdk/dev/api/_index.md":"# Api Skill\n\nPath: `content/manuals/extensions/extensions-sdk/dev/api/_index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/dev/api/_index.md)","content/manuals/extensions/extensions-sdk/dev/api/backend.md":"# Api Skill\n\nPath: `content/manuals/extensions/extensions-sdk/dev/api/backend.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/dev/api/backend.md)","content/manuals/extensions/extensions-sdk/dev/api/dashboard-routes-navigation.md":"# Api Skill\n\nPath: `content/manuals/extensions/extensions-sdk/dev/api/dashboard-routes-navigation.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/dev/api/dashboard-routes-navigation.md)","content/manuals/extensions/extensions-sdk/dev/api/dashboard.md":"# Api Skill\n\nPath: `content/manuals/extensions/extensions-sdk/dev/api/dashboard.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/dev/api/dashboard.md)","content/manuals/extensions/extensions-sdk/dev/api/docker.md":"# Api Skill\n\nPath: `content/manuals/extensions/extensions-sdk/dev/api/docker.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/dev/api/docker.md)","content/manuals/extensions/extensions-sdk/dev/api/overview.md":"# Api Skill\n\nPath: `content/manuals/extensions/extensions-sdk/dev/api/overview.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/dev/api/overview.md)","_vendor/github.com/docker/docker-agent/docs/concepts/agents/index.md":"# Subagent: index\n\nPath: `_vendor/github.com/docker/docker-agent/docs/concepts/agents/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/concepts/agents/index.md)","_vendor/github.com/docker/docker-agent/docs/concepts/tools/index.md":"# Tools Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/concepts/tools/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/concepts/tools/index.md)","_vendor/github.com/docker/docker-agent/docs/configuration/agents/index.md":"# Subagent: index\n\nPath: `_vendor/github.com/docker/docker-agent/docs/configuration/agents/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/configuration/agents/index.md)","_vendor/github.com/docker/docker-agent/docs/configuration/commands/index.md":"# Command: /index\n\nPath: `_vendor/github.com/docker/docker-agent/docs/configuration/commands/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/configuration/commands/index.md)","_vendor/github.com/docker/docker-agent/docs/configuration/tools/index.md":"# Tools Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/configuration/tools/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/configuration/tools/index.md)","_vendor/github.com/docker/docker-agent/docs/features/skills/index.md":"# Skills Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/features/skills/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/features/skills/index.md)","_vendor/github.com/docker/docker-agent/docs/tools/a2a/index.md":"# A2a Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/a2a/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/a2a/index.md)","_vendor/github.com/docker/docker-agent/docs/tools/api/index.md":"# Api Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/api/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/api/index.md)","_vendor/github.com/docker/docker-agent/docs/tools/background-agents/index.md":"# Background-agents Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/background-agents/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/background-agents/index.md)","_vendor/github.com/docker/docker-agent/docs/tools/background-jobs/index.md":"# Background-jobs Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/background-jobs/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/background-jobs/index.md)","_vendor/github.com/docker/docker-agent/docs/tools/fetch/index.md":"# Fetch Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/fetch/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/fetch/index.md)","_vendor/github.com/docker/docker-agent/docs/tools/filesystem/index.md":"# Filesystem Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/filesystem/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/filesystem/index.md)","_vendor/github.com/docker/docker-agent/docs/tools/git/index.md":"# Git Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/git/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/git/index.md)","_vendor/github.com/docker/docker-agent/docs/tools/handoff/index.md":"# Handoff Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/handoff/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/handoff/index.md)","_vendor/github.com/docker/docker-agent/docs/tools/lsp/index.md":"# Lsp Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/lsp/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/lsp/index.md)","_vendor/github.com/docker/docker-agent/docs/tools/mcp-catalog/index.md":"# Mcp-catalog Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/mcp-catalog/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/mcp-catalog/index.md)","_vendor/github.com/docker/docker-agent/docs/tools/mcp/index.md":"# Mcp Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/mcp/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/mcp/index.md)","_vendor/github.com/docker/docker-agent/docs/tools/memory/index.md":"# Memory Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/memory/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/memory/index.md)","_vendor/github.com/docker/docker-agent/docs/tools/model-picker/index.md":"# Model-picker Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/model-picker/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/model-picker/index.md)","_vendor/github.com/docker/docker-agent/docs/tools/open-url/index.md":"# Open-url Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/open-url/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/open-url/index.md)","_vendor/github.com/docker/docker-agent/docs/tools/openapi/index.md":"# Openapi Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/openapi/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/openapi/index.md)","_vendor/github.com/docker/docker-agent/docs/tools/plan/index.md":"# Plan Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/plan/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/plan/index.md)","_vendor/github.com/docker/docker-agent/docs/tools/rag/index.md":"# Rag Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/rag/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/rag/index.md)","_vendor/github.com/docker/docker-agent/docs/tools/scheduler/index.md":"# Scheduler Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/scheduler/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/scheduler/index.md)","_vendor/github.com/docker/docker-agent/docs/tools/script/index.md":"# Script Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/script/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/script/index.md)","_vendor/github.com/docker/docker-agent/docs/tools/session_context/index.md":"# Session_context Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/session_context/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/session_context/index.md)","_vendor/github.com/docker/docker-agent/docs/tools/session_plan/index.md":"# Session_plan Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/session_plan/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/session_plan/index.md)","_vendor/github.com/docker/docker-agent/docs/tools/shell/index.md":"# Shell Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/shell/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/shell/index.md)","_vendor/github.com/docker/docker-agent/docs/tools/tasks/index.md":"# Tasks Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/tasks/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/tasks/index.md)","_vendor/github.com/docker/docker-agent/docs/tools/think/index.md":"# Think Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/think/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/think/index.md)","_vendor/github.com/docker/docker-agent/docs/tools/todo/index.md":"# Todo Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/todo/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/todo/index.md)","_vendor/github.com/docker/docker-agent/docs/tools/transfer-task/index.md":"# Transfer-task Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/transfer-task/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/transfer-task/index.md)","_vendor/github.com/docker/docker-agent/docs/tools/user-prompt/index.md":"# User-prompt Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/user-prompt/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/user-prompt/index.md)","_vendor/github.com/docker/docker-agent/docs/tools/webhook/index.md":"# Webhook Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/webhook/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/webhook/index.md)","_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/_index.md":"# Rules Skill\n\nPath: `_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/_index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/_index.md)","_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/consistent-instruction-casing.md":"# Rules Skill\n\nPath: `_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/consistent-instruction-casing.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/consistent-instruction-casing.md)","_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/copy-ignored-file.md":"# Rules Skill\n\nPath: `_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/copy-ignored-file.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/copy-ignored-file.md)","_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/duplicate-stage-name.md":"# Rules Skill\n\nPath: `_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/duplicate-stage-name.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/duplicate-stage-name.md)","_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/expose-invalid-format.md":"# Rules Skill\n\nPath: `_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/expose-invalid-format.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/expose-invalid-format.md)","_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/expose-proto-casing.md":"# Rules Skill\n\nPath: `_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/expose-proto-casing.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/expose-proto-casing.md)","_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/from-as-casing.md":"# Rules Skill\n\nPath: `_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/from-as-casing.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/from-as-casing.md)","_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/from-platform-flag-const-disallowed.md":"# Rules Skill\n\nPath: `_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/from-platform-flag-const-disallowed.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/from-platform-flag-const-disallowed.md)","_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/invalid-default-arg-in-from.md":"# Rules Skill\n\nPath: `_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/invalid-default-arg-in-from.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/invalid-default-arg-in-from.md)","_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/invalid-definition-description.md":"# Rules Skill\n\nPath: `_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/invalid-definition-description.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/invalid-definition-description.md)","_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/json-args-recommended.md":"# Rules Skill\n\nPath: `_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/json-args-recommended.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/json-args-recommended.md)","_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/legacy-key-value-format.md":"# Rules Skill\n\nPath: `_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/legacy-key-value-format.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/legacy-key-value-format.md)","_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/maintainer-deprecated.md":"# Rules Skill\n\nPath: `_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/maintainer-deprecated.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/maintainer-deprecated.md)","_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/multiple-instructions-disallowed.md":"# Rules Skill\n\nPath: `_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/multiple-instructions-disallowed.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/multiple-instructions-disallowed.md)","_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/no-empty-continuation.md":"# Rules Skill\n\nPath: `_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/no-empty-continuation.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/no-empty-continuation.md)","_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/redundant-target-platform.md":"# Rules Skill\n\nPath: `_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/redundant-target-platform.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/redundant-target-platform.md)","_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/reserved-stage-name.md":"# Rules Skill\n\nPath: `_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/reserved-stage-name.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/reserved-stage-name.md)","_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/secrets-used-in-arg-or-env.md":"# Rules Skill\n\nPath: `_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/secrets-used-in-arg-or-env.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/secrets-used-in-arg-or-env.md)","_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/stage-name-casing.md":"# Rules Skill\n\nPath: `_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/stage-name-casing.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/stage-name-casing.md)","_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/undefined-arg-in-from.md":"# Rules Skill\n\nPath: `_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/undefined-arg-in-from.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/undefined-arg-in-from.md)","_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/undefined-var.md":"# Rules Skill\n\nPath: `_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/undefined-var.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/undefined-var.md)","_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/workdir-relative-path.md":"# Rules Skill\n\nPath: `_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/workdir-relative-path.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/workdir-relative-path.md)",".cursorrules (kubernetes-mkdocs-documentation-cursorrules-prompt.mdc)":"---\ndescription: \"Cursor rules for Kubernetes development with MkDocs documentation integration.\"\nglobs: **/*\nalwaysApply: false\n---\nYou are an expert Technical Writer with a deep understanding of cloud native technologies, Kubernetes, and technical documentation best practices. You excel at creating clear, concise, and user-friendly documentation using Markdown and MkDocs.\n\nYou always use the latest stable versions of Kubernetes, cloud native tools, and MkDocs. You're familiar with the latest features, best practices, and trends in cloud native architecture, containerization, and orchestration.\n\nDocumentation Style and Structure:\n\nCloud Native and Kubernetes Expertise:\n\nMkDocs Usage:\n\nContent Creation:\n\nTechnical Accuracy and Usability:\n\nDocumentation Best Practices:\n\nMetadata and SEO:\n\nCollaboration and Version Control:\n\nOther Rules to follow:\n\nDon't be lazy, provide thorough and accurate documentation for all requested topics and features.\n"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/AGENTS.md","title":"AI Agent Protocol & Instructions","category":"root-instruction","format":"markdown","content":"# AI Agent Protocol & Instructions\n\nPath: `AGENTS.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/AGENTS.md)","tokens":300,"sizeBytes":145},{"name":"index.md","path":"_vendor/github.com/docker/docker-agent/docs/concepts/tools/index.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/concepts/tools/index.md","title":"Tools Skill","category":"anthropic-skill","format":"markdown","content":"# Tools Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/concepts/tools/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/concepts/tools/index.md)","tokens":300,"sizeBytes":240},{"name":"index.md","path":"_vendor/github.com/docker/docker-agent/docs/configuration/tools/index.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/configuration/tools/index.md","title":"Tools Skill","category":"anthropic-skill","format":"markdown","content":"# Tools Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/configuration/tools/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/configuration/tools/index.md)","tokens":300,"sizeBytes":250},{"name":"index.md","path":"_vendor/github.com/docker/docker-agent/docs/features/skills/index.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/features/skills/index.md","title":"Skills Skill","category":"anthropic-skill","format":"markdown","content":"# Skills Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/features/skills/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/features/skills/index.md)","tokens":300,"sizeBytes":243},{"name":"_index.md","path":"_vendor/github.com/docker/docker-agent/docs/tools/_index.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/_index.md","title":"Tools Skill","category":"anthropic-skill","format":"markdown","content":"# Tools Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/_index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/_index.md)","tokens":300,"sizeBytes":224},{"name":"index.md","path":"_vendor/github.com/docker/docker-agent/docs/tools/a2a/index.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/a2a/index.md","title":"A2a Skill","category":"anthropic-skill","format":"markdown","content":"# A2a Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/a2a/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/a2a/index.md)","tokens":300,"sizeBytes":228},{"name":"index.md","path":"_vendor/github.com/docker/docker-agent/docs/tools/api/index.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/api/index.md","title":"Api Skill","category":"anthropic-skill","format":"markdown","content":"# Api Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/api/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/api/index.md)","tokens":300,"sizeBytes":228},{"name":"index.md","path":"_vendor/github.com/docker/docker-agent/docs/tools/background-agents/index.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/background-agents/index.md","title":"Background-agents Skill","category":"anthropic-skill","format":"markdown","content":"# Background-agents Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/background-agents/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/background-agents/index.md)","tokens":300,"sizeBytes":270},{"name":"index.md","path":"_vendor/github.com/docker/docker-agent/docs/tools/background-jobs/index.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/background-jobs/index.md","title":"Background-jobs Skill","category":"anthropic-skill","format":"markdown","content":"# Background-jobs Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/background-jobs/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/background-jobs/index.md)","tokens":300,"sizeBytes":264},{"name":"index.md","path":"_vendor/github.com/docker/docker-agent/docs/tools/fetch/index.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/fetch/index.md","title":"Fetch Skill","category":"anthropic-skill","format":"markdown","content":"# Fetch Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/fetch/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/fetch/index.md)","tokens":300,"sizeBytes":234},{"name":"index.md","path":"_vendor/github.com/docker/docker-agent/docs/tools/filesystem/index.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/filesystem/index.md","title":"Filesystem Skill","category":"anthropic-skill","format":"markdown","content":"# Filesystem Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/filesystem/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/filesystem/index.md)","tokens":300,"sizeBytes":249},{"name":"index.md","path":"_vendor/github.com/docker/docker-agent/docs/tools/git/index.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/git/index.md","title":"Git Skill","category":"anthropic-skill","format":"markdown","content":"# Git Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/git/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/git/index.md)","tokens":300,"sizeBytes":228},{"name":"index.md","path":"_vendor/github.com/docker/docker-agent/docs/tools/handoff/index.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/handoff/index.md","title":"Handoff Skill","category":"anthropic-skill","format":"markdown","content":"# Handoff Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/handoff/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/handoff/index.md)","tokens":300,"sizeBytes":240},{"name":"index.md","path":"_vendor/github.com/docker/docker-agent/docs/tools/lsp/index.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/lsp/index.md","title":"Lsp Skill","category":"anthropic-skill","format":"markdown","content":"# Lsp Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/lsp/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/lsp/index.md)","tokens":300,"sizeBytes":228},{"name":"index.md","path":"_vendor/github.com/docker/docker-agent/docs/tools/mcp-catalog/index.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/mcp-catalog/index.md","title":"Mcp-catalog Skill","category":"anthropic-skill","format":"markdown","content":"# Mcp-catalog Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/mcp-catalog/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/mcp-catalog/index.md)","tokens":300,"sizeBytes":252},{"name":"index.md","path":"_vendor/github.com/docker/docker-agent/docs/tools/mcp/index.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/mcp/index.md","title":"Mcp Skill","category":"anthropic-skill","format":"markdown","content":"# Mcp Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/mcp/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/mcp/index.md)","tokens":300,"sizeBytes":228},{"name":"index.md","path":"_vendor/github.com/docker/docker-agent/docs/tools/memory/index.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/memory/index.md","title":"Memory Skill","category":"anthropic-skill","format":"markdown","content":"# Memory Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/memory/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/memory/index.md)","tokens":300,"sizeBytes":237},{"name":"index.md","path":"_vendor/github.com/docker/docker-agent/docs/tools/model-picker/index.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/model-picker/index.md","title":"Model-picker Skill","category":"anthropic-skill","format":"markdown","content":"# Model-picker Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/model-picker/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/model-picker/index.md)","tokens":300,"sizeBytes":255},{"name":"index.md","path":"_vendor/github.com/docker/docker-agent/docs/tools/open-url/index.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/open-url/index.md","title":"Open-url Skill","category":"anthropic-skill","format":"markdown","content":"# Open-url Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/open-url/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/open-url/index.md)","tokens":300,"sizeBytes":243},{"name":"index.md","path":"_vendor/github.com/docker/docker-agent/docs/tools/openapi/index.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/openapi/index.md","title":"Openapi Skill","category":"anthropic-skill","format":"markdown","content":"# Openapi Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/openapi/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/openapi/index.md)","tokens":300,"sizeBytes":240},{"name":"index.md","path":"_vendor/github.com/docker/docker-agent/docs/tools/plan/index.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/plan/index.md","title":"Plan Skill","category":"anthropic-skill","format":"markdown","content":"# Plan Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/plan/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/plan/index.md)","tokens":300,"sizeBytes":231},{"name":"index.md","path":"_vendor/github.com/docker/docker-agent/docs/tools/rag/index.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/rag/index.md","title":"Rag Skill","category":"anthropic-skill","format":"markdown","content":"# Rag Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/rag/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/rag/index.md)","tokens":300,"sizeBytes":228},{"name":"index.md","path":"_vendor/github.com/docker/docker-agent/docs/tools/scheduler/index.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/scheduler/index.md","title":"Scheduler Skill","category":"anthropic-skill","format":"markdown","content":"# Scheduler Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/scheduler/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/scheduler/index.md)","tokens":300,"sizeBytes":246},{"name":"index.md","path":"_vendor/github.com/docker/docker-agent/docs/tools/script/index.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/script/index.md","title":"Script Skill","category":"anthropic-skill","format":"markdown","content":"# Script Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/script/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/script/index.md)","tokens":300,"sizeBytes":237},{"name":"index.md","path":"_vendor/github.com/docker/docker-agent/docs/tools/session_context/index.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/session_context/index.md","title":"Session_context Skill","category":"anthropic-skill","format":"markdown","content":"# Session_context Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/session_context/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/session_context/index.md)","tokens":300,"sizeBytes":264},{"name":"index.md","path":"_vendor/github.com/docker/docker-agent/docs/tools/session_plan/index.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/session_plan/index.md","title":"Session_plan Skill","category":"anthropic-skill","format":"markdown","content":"# Session_plan Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/session_plan/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/session_plan/index.md)","tokens":300,"sizeBytes":255},{"name":"index.md","path":"_vendor/github.com/docker/docker-agent/docs/tools/shell/index.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/shell/index.md","title":"Shell Skill","category":"anthropic-skill","format":"markdown","content":"# Shell Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/shell/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/shell/index.md)","tokens":300,"sizeBytes":234},{"name":"index.md","path":"_vendor/github.com/docker/docker-agent/docs/tools/tasks/index.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/tasks/index.md","title":"Tasks Skill","category":"anthropic-skill","format":"markdown","content":"# Tasks Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/tasks/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/tasks/index.md)","tokens":300,"sizeBytes":234},{"name":"index.md","path":"_vendor/github.com/docker/docker-agent/docs/tools/think/index.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/think/index.md","title":"Think Skill","category":"anthropic-skill","format":"markdown","content":"# Think Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/think/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/think/index.md)","tokens":300,"sizeBytes":234},{"name":"index.md","path":"_vendor/github.com/docker/docker-agent/docs/tools/todo/index.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/todo/index.md","title":"Todo Skill","category":"anthropic-skill","format":"markdown","content":"# Todo Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/todo/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/todo/index.md)","tokens":300,"sizeBytes":231},{"name":"index.md","path":"_vendor/github.com/docker/docker-agent/docs/tools/transfer-task/index.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/transfer-task/index.md","title":"Transfer-task Skill","category":"anthropic-skill","format":"markdown","content":"# Transfer-task Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/transfer-task/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/transfer-task/index.md)","tokens":300,"sizeBytes":258},{"name":"index.md","path":"_vendor/github.com/docker/docker-agent/docs/tools/user-prompt/index.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/user-prompt/index.md","title":"User-prompt Skill","category":"anthropic-skill","format":"markdown","content":"# User-prompt Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/user-prompt/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/user-prompt/index.md)","tokens":300,"sizeBytes":252},{"name":"index.md","path":"_vendor/github.com/docker/docker-agent/docs/tools/webhook/index.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/webhook/index.md","title":"Webhook Skill","category":"anthropic-skill","format":"markdown","content":"# Webhook Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/webhook/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/webhook/index.md)","tokens":300,"sizeBytes":240},{"name":"_index.md","path":"_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/_index.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/_index.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"# Rules Skill\n\nPath: `_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/_index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/_index.md)","tokens":300,"sizeBytes":252},{"name":"consistent-instruction-casing.md","path":"_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/consistent-instruction-casing.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/consistent-instruction-casing.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"# Rules Skill\n\nPath: `_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/consistent-instruction-casing.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/consistent-instruction-casing.md)","tokens":300,"sizeBytes":298},{"name":"copy-ignored-file.md","path":"_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/copy-ignored-file.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/copy-ignored-file.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"# Rules Skill\n\nPath: `_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/copy-ignored-file.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/copy-ignored-file.md)","tokens":300,"sizeBytes":274},{"name":"duplicate-stage-name.md","path":"_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/duplicate-stage-name.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/duplicate-stage-name.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"# Rules Skill\n\nPath: `_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/duplicate-stage-name.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/duplicate-stage-name.md)","tokens":300,"sizeBytes":280},{"name":"expose-invalid-format.md","path":"_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/expose-invalid-format.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/expose-invalid-format.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"# Rules Skill\n\nPath: `_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/expose-invalid-format.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/expose-invalid-format.md)","tokens":300,"sizeBytes":282},{"name":"expose-proto-casing.md","path":"_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/expose-proto-casing.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/expose-proto-casing.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"# Rules Skill\n\nPath: `_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/expose-proto-casing.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/expose-proto-casing.md)","tokens":300,"sizeBytes":278},{"name":"from-as-casing.md","path":"_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/from-as-casing.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/from-as-casing.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"# Rules Skill\n\nPath: `_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/from-as-casing.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/from-as-casing.md)","tokens":300,"sizeBytes":268},{"name":"from-platform-flag-const-disallowed.md","path":"_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/from-platform-flag-const-disallowed.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/from-platform-flag-const-disallowed.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"# Rules Skill\n\nPath: `_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/from-platform-flag-const-disallowed.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/from-platform-flag-const-disallowed.md)","tokens":300,"sizeBytes":310},{"name":"invalid-default-arg-in-from.md","path":"_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/invalid-default-arg-in-from.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/invalid-default-arg-in-from.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"# Rules Skill\n\nPath: `_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/invalid-default-arg-in-from.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/invalid-default-arg-in-from.md)","tokens":300,"sizeBytes":294},{"name":"invalid-definition-description.md","path":"_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/invalid-definition-description.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/invalid-definition-description.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"# Rules Skill\n\nPath: `_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/invalid-definition-description.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/invalid-definition-description.md)","tokens":300,"sizeBytes":300},{"name":"json-args-recommended.md","path":"_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/json-args-recommended.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/json-args-recommended.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"# Rules Skill\n\nPath: `_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/json-args-recommended.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/json-args-recommended.md)","tokens":300,"sizeBytes":282},{"name":"legacy-key-value-format.md","path":"_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/legacy-key-value-format.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/legacy-key-value-format.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"# Rules Skill\n\nPath: `_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/legacy-key-value-format.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/legacy-key-value-format.md)","tokens":300,"sizeBytes":286},{"name":"maintainer-deprecated.md","path":"_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/maintainer-deprecated.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/maintainer-deprecated.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"# Rules Skill\n\nPath: `_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/maintainer-deprecated.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/maintainer-deprecated.md)","tokens":300,"sizeBytes":282},{"name":"multiple-instructions-disallowed.md","path":"_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/multiple-instructions-disallowed.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/multiple-instructions-disallowed.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"# Rules Skill\n\nPath: `_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/multiple-instructions-disallowed.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/multiple-instructions-disallowed.md)","tokens":300,"sizeBytes":304},{"name":"no-empty-continuation.md","path":"_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/no-empty-continuation.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/no-empty-continuation.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"# Rules Skill\n\nPath: `_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/no-empty-continuation.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/no-empty-continuation.md)","tokens":300,"sizeBytes":282},{"name":"redundant-target-platform.md","path":"_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/redundant-target-platform.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/redundant-target-platform.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"# Rules Skill\n\nPath: `_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/redundant-target-platform.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/redundant-target-platform.md)","tokens":300,"sizeBytes":290},{"name":"reserved-stage-name.md","path":"_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/reserved-stage-name.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/reserved-stage-name.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"# Rules Skill\n\nPath: `_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/reserved-stage-name.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/reserved-stage-name.md)","tokens":300,"sizeBytes":278},{"name":"secrets-used-in-arg-or-env.md","path":"_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/secrets-used-in-arg-or-env.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/secrets-used-in-arg-or-env.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"# Rules Skill\n\nPath: `_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/secrets-used-in-arg-or-env.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/secrets-used-in-arg-or-env.md)","tokens":300,"sizeBytes":292},{"name":"stage-name-casing.md","path":"_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/stage-name-casing.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/stage-name-casing.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"# Rules Skill\n\nPath: `_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/stage-name-casing.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/stage-name-casing.md)","tokens":300,"sizeBytes":274},{"name":"undefined-arg-in-from.md","path":"_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/undefined-arg-in-from.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/undefined-arg-in-from.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"# Rules Skill\n\nPath: `_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/undefined-arg-in-from.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/undefined-arg-in-from.md)","tokens":300,"sizeBytes":282},{"name":"undefined-var.md","path":"_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/undefined-var.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/undefined-var.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"# Rules Skill\n\nPath: `_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/undefined-var.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/undefined-var.md)","tokens":300,"sizeBytes":266},{"name":"workdir-relative-path.md","path":"_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/workdir-relative-path.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/workdir-relative-path.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"# Rules Skill\n\nPath: `_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/workdir-relative-path.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/workdir-relative-path.md)","tokens":300,"sizeBytes":282},{"name":"report-template.md","path":".agents/skills/agent-readiness-audit/references/report-template.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/.agents/skills/agent-readiness-audit/references/report-template.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `.agents/skills/agent-readiness-audit/references/report-template.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/.agents/skills/agent-readiness-audit/references/report-template.md)","tokens":300,"sizeBytes":243},{"name":"rubric.md","path":".agents/skills/agent-readiness-audit/references/rubric.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/.agents/skills/agent-readiness-audit/references/rubric.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `.agents/skills/agent-readiness-audit/references/rubric.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/.agents/skills/agent-readiness-audit/references/rubric.md)","tokens":300,"sizeBytes":225},{"name":"SKILL.md","path":".agents/skills/agent-readiness-audit/SKILL.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/.agents/skills/agent-readiness-audit/SKILL.md","title":"agent-readiness-audit","category":"anthropic-skill","format":"markdown","content":"---\nname: agent-readiness-audit\ndescription: >\n Audit a documentation site for agent-friendliness: discovery, markdown\n delivery, crawlability, semantic structure, machine-readable surfaces,\n and content legibility. Use when asked to assess docs.docker.com or any\n docs site for AI/agent readiness, produce a scored report, compare with\n external scanners, or generate a remediation list. Triggers on:\n \"audit docs for agent readiness\", \"how agent-friendly is docs.docker.com\",\n \"score our docs for AI agents\", \"review llms.txt / markdown / crawlability\",\n \"create an agent-readiness remediation plan\".\nargument-hint: \"<base-url>\"\n---\n\n# Agent Readiness Audit\n\nAudit the live site, not the source tree alone. Prefer the same fetch path\nan external agent would use in the wild: direct HTTP requests, sitemap\nsampling, and page-level inspection.\n\nDo not reduce the result to a homepage-only scan or a binary checklist.\n\n## 1. Set scope\n\nUse `$ARGUMENTS` as the base URL when provided. Otherwise infer the base\nURL from context and state the assumption.\n\nDecide whether the host being audited is:\n\n- a docs-only host\n- an app/tool host\n- a mixed host\n\nThis matters for optional checks such as MCP, plugin manifests, or other\ntool discovery files. Do not penalize a docs-only host for missing\ntooling manifests that belong on a separate service.\n\nFor `docs.docker.com`, treat the public docs host as docs-only. Docker's\nMCP server is published separately, so missing MCP files on the docs host\nshould be reported as `N/A`, not as a failure.\n\n## 2. Gather sitewide signals\n\nAlways check these resources first:\n\n- `/llms.txt`\n- `/llms-full.txt`\n- `/robots.txt`\n- `/sitemap.xml`\n\nOnly check host-level tool manifests when the host is an app/tool host,\nmixed host, or explicitly advertises them:\n\n- `/.well-known/ai-plugin.json`\n- `/.well-known/agent.json`\n- `/.well-known/agents.json`\n\nUse the bundled script for a baseline:\n\n```bash\nbash .agents/skills/agent-readiness-audit/scripts/baseline-probes.sh \\\n \"$ARGUMENTS\"\n```\n\nThe script produces baseline evidence only. You still need to interpret\nwhat matters for a docs property and score it with the rubric.\n\nFor docs-only hosts, you may skip tool-manifest probes to reduce noise:\n\n```bash\nCHECK_TOOL_MANIFESTS=0 \\\n bash .agents/skills/agent-readiness-audit/scripts/baseline-probes.sh \\\n \"$ARGUMENTS\"\n```\n\n## 3. Sample representative pages\n\nUse the sitemap when available. Do not rely on the homepage alone.\n\nIf `llms.txt` exists, sample some URLs from it as well. This helps catch\nstale or misleading discovery surfaces that a sitemap-only sample would miss.\n\nSample at least 12 pages when the site is large enough, and cover multiple\npage types:\n\n- homepage or docs landing page\n- section landing pages\n- task guides\n- product manuals\n- reference or API pages\n- tutorial or learning pages\n\nIf the sitemap is missing or unusable, discover pages through internal\nlinks and note the lower confidence.\n\nIf the site has distinct delivery patterns, sample each one. For example:\n\n- normal content pages\n- generated reference pages\n- versioned docs\n- localized docs\n\n## 4. Run fetch-path checks on each sample\n\nFor each sampled page, verify:\n\n- HTML fetch status, content type, and final URL\n- `Accept: text/markdown` behavior\n- direct markdown route behavior such as `<page>.md` or another stable path\n- page-level markdown alternate links and whether they actually resolve\n- whether page actions such as \"Open Markdown\" agree with the working route\n- whether the HTML title or H1 matches the markdown H1 closely enough for\n retrieval parity\n- whether main content is present in the initial HTML\n- redirect chain length and canonical URL consistency\n- obvious chrome/noise in the markdown response\n\nDo not assume a `.md` mirror exists just because another site uses one.\nVerify the actual markdown path the site exposes.\n\nTreat these as separate signals:\n\n- negotiated markdown works\n- a stable direct markdown URL works\n- the page advertises the correct markdown URL\n\nIf the page advertises dead markdown alternates but a working markdown route\nexists, do not fail markdown delivery outright. Score it as a discoverability\nand consistency problem instead.\n\nFor API or generated reference pages, also verify whether a machine-readable\nasset such as OpenAPI YAML is directly linked and fetchable.\n\n## 5. Judge structure and legibility\n\nMeasure structural signals:\n\n- exactly one `h1`\n- sane heading hierarchy\n- `main` and `article` presence where appropriate\n- canonical tags\n- JSON-LD or breadcrumb structured data\n- stable anchors and deep-linkable headings\n\nAlso make a qualitative judgment about agent legibility:\n\n- markdown strips site chrome cleanly\n- headings are specific and task-oriented\n- code blocks stay intelligible without client-side JS\n- the page is not dominated by banners, injected chat, or nav noise\n\nMeasure code block labeling explicitly when code samples are common. A page\ntype with many untagged fenced blocks should lose points even if the prose is\notherwise clean.\n\nFor page types that intentionally render interactive UIs with JavaScript,\njudge them separately from normal docs pages. If the HTML shell is thin,\ncheck whether the page still provides:\n\n- a fetchable markdown summary\n- a directly linked machine-readable asset\n- a usable non-JS fallback\n\n## 6. Score with the rubric\n\nUse [references/rubric.md](references/rubric.md).\n\nRules:\n\n- score only what you verified\n- mark non-applicable checks as `N/A`\n- normalize the final score against applicable points only\n- do not let optional manifest checks dominate the grade\n\nApply the foundational caps from the rubric. A site with broken discovery\nor broken markdown delivery should not earn a high grade because it has\nclean metadata.\n\nDo not average away a weak page type. If one major page type, such as API\nreference, is materially worse than the rest of the corpus, call it out as\nthe weakest segment and reflect it in the category notes.\n\n## 7. Compare with external scanners when useful\n\nIf external scanner results are available, compare them to your live\nfindings. Treat them as secondary evidence.\n\nIf a scanner and the live fetch disagree:\n\n- trust the live fetch\n- report the mismatch explicitly\n- explain whether the scanner is testing a different assumption\n\n## 8. Produce a remediation list\n\nTurn findings into a short backlog:\n\n- `P0`: fetchability or discovery blockers\n- `P1`: recurring structural or parity issues\n- `P2`: polish, optional manifests, or low-impact enhancements\n\nFor each remediation, include:\n\n- the failing signal\n- why it matters to agents\n- a concrete fix\n- whether it is sitewide or page-type-specific\n\n## 9. Report in a stable format\n\nUse [references/report-template.md](references/report-template.md).\n\nAlways include:\n\n- overall score and grade\n- confidence level\n- sampled URLs or sample strategy\n- category scores\n- highest-priority findings\n- remediation backlog\n\n## Notes\n\n- Favor docs-delivery checks over marketing-site heuristics.\n- Do not fail a docs host for lacking MCP or plugin manifests unless the\n host itself is meant to expose tools.\n- Treat raw byte size as supporting evidence, not as a primary scoring input.\n- Prefer short evidence excerpts and commands over long copied page text.\n","frontmatter":{"name":"agent-readiness-audit","description":"Audit a documentation site for agent-friendliness: discovery, markdown delivery, crawlability, semantic structure, machine-readable surfaces, and content legibility. Use when asked to assess docs.docker.com or any docs site for AI/agent readiness, produce a scored report, compare with external scanners, or generate a remediation list. Triggers on: \"audit docs for agent readiness\", \"how agent-friendly is docs.docker.com\", \"score our docs for AI agents\", \"review llms.txt / markdown / crawlability\", \"create an agent-readiness remediation plan\".\n","argument-hint":"<base-url>"},"isInternal":false,"tokens":1614,"sizeBytes":7280},{"name":"SKILL.md","path":".agents/skills/create-lab-guide/SKILL.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/.agents/skills/create-lab-guide/SKILL.md","title":"create-lab-guide","category":"anthropic-skill","format":"markdown","content":"---\nname: create-lab-guide\ndescription: \"Clone a dockersamples Labspace repo, extract learning objectives and module structure from labspace.yaml, and produce a Hugo guide page under content/guides/ with correct frontmatter, labspace-launch shortcode, and Docker docs style compliance. Use when asked to create a lab guide, write a Labspace page, add a Docker lab tutorial, migrate a lab to docs, or document a hands-on lab.\"\n---\n\n# Create Lab Guide\n\nCreate a guide page for a Docker Labspace: clone the source repo, extract\nstructure from `labspace.yaml`, write the Hugo markdown page, and validate.\n\n## Inputs\n\n- **REPO_NAME**: GitHub repo in the `dockersamples` org (e.g. `labspace-ai-fundamentals`)\n\n## Step 1: Clone the labspace repo\n\n```bash\nTMPDIR=$(mktemp -d)\ngit clone --depth 1 https://github.com/dockersamples/{REPO_NAME}.git \"$TMPDIR/{REPO_NAME}\"\n```\n\n## Step 2: Extract key information\n\nRead these files from the cloned repo:\n\n| File | Purpose |\n|------|---------|\n| `README.md` | Lab purpose and overview |\n| `labspace/labspace.yaml` | Module structure and content paths |\n| `labspace/*.md` | Module content (only files listed in `labspace.yaml`) |\n| `.github/workflows/*.yml` | Published Compose file URL for the launch command |\n| `compose.override.yaml` | Check for top-level `model` specs (triggers `model-download` param) |\n\nExtract:\n1. A short description for the `description` and `summary` frontmatter fields.\n2. Learning objectives from the module content.\n3. Whether a model download is required (`compose.override.yaml` → top-level `model` key).\n\n## Step 3: Write the guide markdown\n\nPlace the file at `content/guides/lab-{GUIDE_ID}.md`.\n\n```markdown\n---\ntitle: \"Lab: { Short title }\"\nlinkTitle: \"Lab: { Short title }\"\ndescription: |\n A short description of the lab for SEO and social sharing.\nsummary: |\n A short summary of the lab for the guides listing page. 2-3 lines.\nkeywords: AI, Docker, Model Runner, agentic apps, lab, labspace\naliases: # Include only for AI-related labs\n - /labs/docker-for-ai/{REPO_NAME_WITHOUT_LABSPACE_PREFIX}/\nparams:\n tags: [ai, labs]\n time: 20 minutes\n resource_links:\n - title: A resource link pointing to relevant documentation or code\n url: /ai/model-runner/\n - title: Labspace repository\n url: https://github.com/dockersamples/{REPO_NAME}\n---\n\nShort explanation of the lab and what it covers.\n\n## Launch the lab\n\n{{< labspace-launch image=\"dockersamples/{REPO_NAME}\" >}}\n\n## What you'll learn\n\nBy the end of this Labspace, you will have completed the following:\n\n- Objective #1\n- Objective #2\n- Objective #3\n\n## Modules\n\n| # | Module | Description |\n|---|--------|-------------|\n| 1 | Module #1 | Description of module #1 |\n| 2 | Module #2 | Description of module #2 |\n| 3 | Module #3 | Description of module #3 |\n```\n\nConditional rules:\n- All lab guides **must** include `labs` in `params.tags`.\n- AI-related labs: also add `ai` tag and an alias under `/labs/docker-for-ai/`.\n- If a model download is required: add `model-download: true` to the `labspace-launch` shortcode.\n\n## Step 4: Apply Docker docs style rules\n\nFollow STYLE.md and COMPONENTS.md. Key rules:\n\n| Avoid | Use instead |\n|-------|-------------|\n| \"we\", \"let's\" | Imperative voice or \"you\" |\n| \"simply\", \"easily\", \"just\" | Remove the hedge word |\n| \"allows you to\" / \"enables you to\" | \"lets you\" or rephrase |\n| \"click\" | \"select\" |\n| Bold for emphasis / product names | Bold only for UI elements |\n| \"currently\", \"new\", \"recently\" | Remove time-relative language |\n\nUse `console` as the language hint for shell blocks with `$` prompts.\nUse contractions (\"it's\", \"you're\", \"don't\").\n\n## Step 5: Validate\n\n1. Confirm frontmatter has `title`, `description`, `keywords`, and `params.tags` including `labs`.\n2. Run `npx --no-install rumdl fmt <file>` to format.\n3. Run `docker buildx bake lint vale` and fix any errors.\n4. Re-read the file and verify: correct shortcode syntax, objectives match source content, modules match `labspace.yaml`, no vendored paths edited.\n\nDo not proceed to commit until validation passes.\n","frontmatter":{"name":"create-lab-guide","description":"Clone a dockersamples Labspace repo, extract learning objectives and module structure from labspace.yaml, and produce a Hugo guide page under content/guides/ with correct frontmatter, labspace-launch shortcode, and Docker docs style compliance. Use when asked to create a lab guide, write a Labspace page, add a Docker lab tutorial, migrate a lab to docs, or document a hands-on lab."},"isInternal":false,"tokens":1054,"sizeBytes":4069},{"name":"SKILL.md","path":".agents/skills/create-pr/SKILL.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/.agents/skills/create-pr/SKILL.md","title":"create-pr","category":"anthropic-skill","format":"markdown","content":"---\nname: create-pr\ndescription: >\n Push the current branch and create a pull request against docker/docs.\n Use after changes are committed and reviewed. \"create a PR\", \"submit the\n fix\", \"open a pull request for this\".\n---\n\n# Create PR\n\nPush the branch and create a properly structured pull request.\n\n## 1. Verify the branch\n\nConfirm you're on a dedicated branch, not the default branch:\n\n```bash\ngit branch --show-current # must not be main or master\n```\n\nIf this returns `main` or `master`, stop. Create a branch and move your\ncommits onto it before continuing.\n\nConfirm commits exist and the working tree is clean:\n\n```bash\ngit log --oneline main..HEAD # confirm commits exist\ngit status --porcelain # must print nothing\n```\n\nIf `git status --porcelain` prints anything, there are uncommitted or\nunstaged changes. Stop and commit them — or unstage stray files like\n`package-lock.json` — before opening a PR. Don't open a PR mid-edit.\n\n## 2. Push the branch\n\nIdentify the remote that points at your fork. Inspect the remotes:\n\n```bash\ngit remote -v\n```\n\nIf `origin` is your fork, use it. If `origin` points at canonical\n`docker/docs` (the upstream), push to your separate fork remote instead —\nnever push the branch to `docker/docs` directly:\n\n```bash\nFORK_REMOTE=origin # or the name of your fork remote if origin is upstream\ngit push -u \"$FORK_REMOTE\" <branch-name>\n```\n\n## 3. Create the PR\n\nBefore creating a PR for an issue, check whether that issue already has an open\nlinked PR:\n\n```bash\ngh api repos/docker/docs/issues/<issue-number>/timeline --paginate \\\n --jq '.[] | select((.event==\"cross-referenced\" or .event==\"connected\" or .event==\"referenced\") and .source.issue.pull_request and .source.issue.state==\"open\") | {url: .source.issue.html_url, title: .source.issue.title}'\n```\n\nIf this returns an open PR that addresses the same issue, stop. Don't open a\nduplicate PR; report the existing PR instead. Only proceed if there is no open\nlinked PR, or if the existing PR clearly does not address the issue and you\nexplain why in the new PR body.\n\nDerive the fork owner dynamically from the same fork remote you pushed to:\n\n```bash\nFORK_OWNER=$(git remote get-url \"$FORK_REMOTE\" | sed -E 's|.*[:/]([^/]+)/[^/]+(\\.git)?$|\\1|')\n```\n\n```bash\ngh pr create --repo docker/docs \\\n --head \"${FORK_OWNER}:<branch-name>\" \\\n --title \"<concise summary under 70 chars>\" \\\n --body \"$(cat <<'EOF'\n## Summary\n\n<1-2 sentences: what was wrong and what was changed>\n\nCloses #NNNN\n\nGenerated by <active coding agent name>\nEOF\n)\"\n```\n\nPrefix the title with the change type to match repo convention — `docs:` for\ndocumentation changes (or another scope like `hub:` when appropriate), for\nexample `docs: fix broken link on install page`.\n\nKeep the body short. Reviewers need to know what changed and why — nothing\nelse. Do **not** add a \"Test plan\" section — documentation PRs don't need one.\n\nUse an accurate disclosure footer that names the active coding agent, for\nexample `Generated by Codex` or `Generated by Claude Code`.\n\n### Optional: Netlify preview entry path\n\nIf the PR primarily edits a single page or a focused section of pages, add a\n`@netlify` stanza to the PR body (for example, just below the Summary). This\nsets the entry path for the Netlify deploy preview so reviewers land on the\nedited page instead of the site root:\n\n```markdown\n@netlify /desktop/setup/install/\n```\n\nThe stanza takes a single published URL path. Derive it from the source file\npath: drop the `content/` prefix and `.md` suffix, strip the `/manuals`\nsegment, and add a trailing slash. For example,\n`content/manuals/desktop/setup/install/mac-install.md` becomes\n`/desktop/setup/install/mac-install/`.\n\nOnly add this when the change is focused on one page or section. Skip it for\nPRs that touch many unrelated pages — there is no useful single entry path.\n\n### Optional: Preview links\n\nWhen the change is focused, also add direct links to the deploy preview in the\nPR body so reviewers can jump straight to the affected pages. The preview URL\nembeds the PR number:\n\n```\nhttps://deploy-preview-<pr-number>--docsdocker.netlify.app/path/to/page/\n```\n\nThe PR number isn't known until `gh pr create` returns, so add these links\nafter creating the PR by updating the body:\n\n```bash\ngh pr edit <pr-number> --repo docker/docs --body \"...\"\n```\n\nUse the same source-path-to-URL mapping as the `@netlify` stanza above.\n\n## 4. Apply labels and request review\n\nUse the Issues API for labels — `gh pr edit --add-label` silently fails:\n\n```bash\ngh api repos/docker/docs/issues/<pr-number>/labels \\\n --method POST \\\n --field 'labels[]=status/review'\n```\n\nRequest review:\n\n```bash\ngh pr edit <pr-number> --repo docker/docs --add-reviewer docker/docs-team\n```\n\nVerify the reviewer was assigned:\n\n```bash\ngh pr view <pr-number> --repo docker/docs --json reviewRequests \\\n --jq '.reviewRequests[].slug'\n```\n\nIf the team doesn't appear, use the API directly:\n\n```bash\ngh api repos/docker/docs/pulls/<pr-number>/requested_reviewers \\\n --method POST --field 'team_reviewers[]=docs-team'\n```\n\n## 5. Report\n\nPrint the PR URL and current CI state:\n\n```bash\ngh pr view <pr-number> --repo docker/docs --json url,state\ngh pr checks <pr-number> --repo docker/docs --json name,state\n```\n\n## Notes\n\n- Always use `Closes #NNNN` (not \"Fixes\") for GitHub auto-close linkage\n- One issue, one branch, one PR — never combine\n","frontmatter":{"name":"create-pr","description":"Push the current branch and create a pull request against docker/docs. Use after changes are committed and reviewed. \"create a PR\", \"submit the fix\", \"open a pull request for this\".\n"},"isInternal":false,"tokens":1346,"sizeBytes":5403},{"name":"openai.yaml","path":".agents/skills/curate-whats-new/agents/openai.yaml","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/.agents/skills/curate-whats-new/agents/openai.yaml","title":"Agents Skill","category":"anthropic-skill","format":"yaml","content":"# Agents Skill\n\nPath: `.agents/skills/curate-whats-new/agents/openai.yaml`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/.agents/skills/curate-whats-new/agents/openai.yaml)","tokens":300,"sizeBytes":207},{"name":"2026-07-13--2026-08-11.json","path":".agents/skills/curate-whats-new/examples/2026-07-13--2026-08-11.json","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/.agents/skills/curate-whats-new/examples/2026-07-13--2026-08-11.json","title":"Examples Skill","category":"anthropic-skill","format":"json","content":"# Examples Skill\n\nPath: `.agents/skills/curate-whats-new/examples/2026-07-13--2026-08-11.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/.agents/skills/curate-whats-new/examples/2026-07-13--2026-08-11.json)","tokens":300,"sizeBytes":245},{"name":"2026-07-13--2026-08-11.yaml","path":".agents/skills/curate-whats-new/examples/2026-07-13--2026-08-11.yaml","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/.agents/skills/curate-whats-new/examples/2026-07-13--2026-08-11.yaml","title":"Examples Skill","category":"anthropic-skill","format":"yaml","content":"# Examples Skill\n\nPath: `.agents/skills/curate-whats-new/examples/2026-07-13--2026-08-11.yaml`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/.agents/skills/curate-whats-new/examples/2026-07-13--2026-08-11.yaml)","tokens":300,"sizeBytes":245},{"name":"SKILL.md","path":".agents/skills/fix-issue/SKILL.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/.agents/skills/fix-issue/SKILL.md","title":"fix-issue","category":"anthropic-skill","format":"markdown","content":"---\nname: fix-issue\ndescription: >\n Fix a single GitHub issue end-to-end: triage, research, write the fix,\n review, and create a PR. Use when asked to fix an issue: \"fix issue 1234\",\n \"resolve #500\", \"create a PR for issue 200\".\nargument-hint: \"<issue-number>\"\n---\n\n# Fix Issue\n\nGiven GitHub issue **$ARGUMENTS**, decide what to do with it and either\nclose it or fix it. This skill orchestrates the composable skills — it owns\nthe decision tree, not the individual steps.\n\n## 1. Triage\n\nInvoke `/triage-issue $ARGUMENTS` to understand the issue and decide what\nto do. This runs in a forked subagent and returns a verdict.\n\n## 2. Act on the triage result\n\nIf triage says **close it** — comment with the reason and close:\n```bash\ngh issue close $ARGUMENTS --repo docker/docs \\\n --comment \"<one sentence explaining why>\n\nGenerated by <active coding agent name>\"\n```\nDone.\n\nIf triage says **escalate upstream** — comment noting the repo and stop:\n```bash\ngh issue comment $ARGUMENTS --repo docker/docs \\\n --body \"This needs to be fixed in <upstream-repo>.\n\nGenerated by <active coding agent name>\"\n```\nDone.\n\nIf triage says **leave it open** — comment explaining what was checked and\nwhat's unclear. Do not close.\nDone.\n\nEnd every issue comment with an accurate agent-disclosure footer that names\nthe active coding agent, for example `Generated by Codex` or `Generated by\nClaude Code`.\n\nIf triage says **fix it** — proceed to step 3.\n\n## 3. Research\n\nInvoke `/research` to locate affected files, verify facts, and identify\nthe fix. The issue context carries over from triage. This runs inline —\nfindings stay in conversation context for the write step.\n\nIf research reveals the issue is upstream or cannot be fixed (e.g.\nunverifiable URLs), comment on the issue and stop.\n\n## 4. Write\n\nInvoke `/write` to create a branch, make the change, format, self-review,\nand commit.\n\n## 5. Review\n\nInvoke `/review-changes` to check the diff for correctness, coherence, and\nmechanical compliance. This runs in a forked subagent with fresh context.\n\nIf issues are found, fix them and re-review until clean.\n\n## 6. Create PR\n\nInvoke `/create-pr` to push the branch and open a pull request.\n\n## 7. Return to main\n\n```bash\ngit checkout main\n```\n\n## 8. Report\n\nSummarize what happened: the issue number, what was done (closed, escalated,\nfixed with a PR link), and why — in a sentence or two.\n","frontmatter":{"name":"fix-issue","description":"Fix a single GitHub issue end-to-end: triage, research, write the fix, review, and create a PR. Use when asked to fix an issue: \"fix issue 1234\", \"resolve #500\", \"create a PR for issue 200\".\n","argument-hint":"<issue-number>"},"isInternal":false,"tokens":600,"sizeBytes":2391},{"name":"openai.yaml","path":".agents/skills/maintain-pr/agents/openai.yaml","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/.agents/skills/maintain-pr/agents/openai.yaml","title":"Agents Skill","category":"anthropic-skill","format":"yaml","content":"# Agents Skill\n\nPath: `.agents/skills/maintain-pr/agents/openai.yaml`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/.agents/skills/maintain-pr/agents/openai.yaml)","tokens":300,"sizeBytes":197},{"name":"SKILL.md","path":".agents/skills/maintain-pr/SKILL.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/.agents/skills/maintain-pr/SKILL.md","title":"maintain-pr","category":"anthropic-skill","format":"markdown","content":"---\nname: maintain-pr\ndescription: >\n Maintain and follow up on a single Docker documentation pull request that\n you own or are responsible for updating. Check CI and review feedback, fix\n actionable failures, push changes, reply to comments, and report status.\n Use for requests such as \"babysit this PR\", \"check the status of my PR\",\n \"fix CI on my PR\", or \"address review comments on #500\". Do not use for\n maintainer review of an incoming contribution; use review-pr for that.\n---\n\n# Maintain PR\n\nDo one maintenance pass over the specified author-owned PR: inspect its\nstate, fix actionable failures or feedback, reply to reviewers, and report\nthe result. This workflow may modify the branch and GitHub because the user\nis asking to maintain the PR. Do not apply it to an incoming PR merely\nbecause the user asks to review or assess it.\n\n## 1. Gather PR state\n\n```bash\ngh pr view <PR> --repo docker/docs --json state,title,url,headRefName,headRepositoryOwner,comments,reviews,reviewDecision\ngh pr checks <PR> --repo docker/docs --json name,state,detailsUrl\ngh api repos/docker/docs/pulls/<PR>/comments \\\n --jq '[.[] | {id, author: .user.login, body, path, line, in_reply_to_id}]'\n```\n\nAlways check both top-level reviews and inline comments. A review with an\nempty body may still contain line-level feedback. Confirm that the PR is one\nthe user owns or is authorized to update before checking out or pushing its\nbranch. If not, stop and use `review-pr`.\n\n## 2. Handle terminal states\n\nIf merged, report the final state and identify unanswered review comments.\nReply only when the user remains responsible for follow-up.\n\nIf closed without merge, read the closing context and report the reason.\nCommon causes include maintainer rejection, supersession, or automation.\n\n## 3. Diagnose CI failures\n\n- Read the failure details.\n- Determine whether the failure comes from the PR or predates it.\n- Fix actionable failures in the PR's changed files.\n- Report pre-existing or upstream failures without changing unrelated files.\n\nFollow repository instructions for formatting, targeted linting, explicit\nstaging, commits, and pushes. Preserve unrelated working-tree changes.\n\n## 4. Address review feedback\n\nTreat every review comment as a claim to verify. Implement it only when the\nevidence supports it; explain any evidence-based disagreement.\n\nAfter each fix:\n\n1. Format and validate the changed files.\n2. Commit and push the focused change.\n3. Reply to every addressed thread with what changed or why no change was\n made.\n4. End replies with an accurate agent-disclosure footer, such as\n `Generated by Codex`.\n5. Resolve threads only after replying.\n6. Re-request review when appropriate.\n\nUse the inline comment endpoint to reply:\n\n```bash\ngh api repos/docker/docs/pulls/<PR>/comments \\\n --method POST \\\n --field in_reply_to=<COMMENT_ID> \\\n --field body='<RESPONSE>'\n```\n\nUse GraphQL to retrieve unresolved review-thread IDs and resolve only the\nthreads that were addressed. Do not silently fix feedback without replying.\n\n## 5. Report\n\n```markdown\n## PR #<number>: <title>\n\n**State:** <open, merged, or closed>\n**CI:** <passing, failing, or pending>\n**Review:** <approved, changes requested, or pending>\n**Action taken:** <changes, replies, and thread resolution, or none needed>\n```\n","frontmatter":{"name":"maintain-pr","description":"Maintain and follow up on a single Docker documentation pull request that you own or are responsible for updating. Check CI and review feedback, fix actionable failures, push changes, reply to comments, and report status. Use for requests such as \"babysit this PR\", \"check the status of my PR\", \"fix CI on my PR\", or \"address review comments on #500\". Do not use for maintainer review of an incoming contribution; use review-pr for that.\n"},"isInternal":false,"tokens":751,"sizeBytes":3299},{"name":"SKILL.md","path":".agents/skills/migrate-content-ia/SKILL.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/.agents/skills/migrate-content-ia/SKILL.md","title":"migrate-content-ia","category":"anthropic-skill","format":"markdown","content":"---\nname: migrate-content-ia\ndescription: >\n Handle Hugo docs information-architecture moves: discover old vs new URLs,\n add front matter aliases (Phase 1), update in-repo links (Phase 2), interactive\n List 2 resolution and fragment validation (Phase 3; no guessing). Supports\n PR-scoped mapping plus whole-content sweeps for inbound links to that mapping,\n or a full-site follow-up. Triggers on: \"IA migration\", \"redirects for moved\n pages\", \"fix links after content move\", \"PR-scoped link/anchor pass\",\n \"aliases for old URLs\". After branch work, chain the review-changes skill\n (main...HEAD) before a PR. Agents must run the in-file required procedure\n and definition of done, not the phases alone in isolation.\n---\n\n# Migrate content IA (redirects + links + anchors)\n\nUse this skill when pages **move or rename** under `content/` and you must\npreserve old public URLs and/or fix cross-references. Work in **phases**;\nchoose **PR-scoped** vs **full-site** mode per run.\n\n**Read first:** **CLAUDE.md** / **AGENTS.md** (URL rules, vendored areas, external\nlinks, special cases) and **hugo.yaml** (`permalinks`, `refLinksErrorLevel`,\n`disablePathToLower`). For **prose and link text**, follow **STYLE.md**; for\n**components, front matter, and link examples**, follow **COMPONENTS.md**.\n\n**Related skills:** **research** helps map moves and find inbound links; **write**\ncommits minimal edits. Run this skill’s phases after the move is identified (or\nin parallel with research for large IA work).\n\n## Agent: required procedure (do not skip)\n\n**Common mistake (wrong):** use **`git diff main...HEAD` (or the PR’s file\nlist) as the full set of places to fix links** for a migration. That set shows\n**what *moved***; it is **not** the list of every page that **points *to*** a\nmoved page. Inbound stragglers are often in files the PR **never** touched. You\nmust still **sweep the repo** for every string in the **old path and published-URL set**\nfor this run, not only for “files in the diff.”\n\n**Definition of done (when the migration is *finished*):** **Both** of the\nfollowing (unless the user or **AGENTS.md** **explicitly defers** a **List 2**\nitem in **Phase 3**; document the deferral):\n\n1. **`docker buildx bake validate`** passes for the branch, with no new\n build/link errors from this work.\n2. A **sweep of the old path and published-URL set for this run** (see\n [Sweep commands](#sweep-commands) below) finds **no** remaining\n migration-relevant **inbound** reference—**including**:\n - links to an old **source** path (plain `.md` and equivalent `ref` forms),\n - links that use the old path **and** a `#fragment`,\n - and, where your mapping includes them, old **published-style** `link:` /\n `url:` / full-site URL strings, \n **except** intentional entries to keep: for example `aliases` on the **new**\n canonical page, or **redirects.yml** *sources* you must not edit per policy.\n (A hit on a **source** that is only an `alias` line on the new page is\n **expected**—do not “fix” that away; distinguish alias rows from straggler\n links in body or nav config.)\n\n**Chaining (policy):** when this branch’s content work is ready for handoff,\n**run the [review-changes](../review-changes/SKILL.md) skill** on\n**`main...HEAD`** (or **`merge-base`…`HEAD`** for a different target branch) so\nthe **whole branch** is re-read for cross-page issues before opening a PR. Do\nnot treat phases 0–3 alone as the final check.\n\n**Run in order (mandatory for agents):**\n\n1. **Scope the moves (mapping input):** set the Git range like **review-changes**\n (for a PR to `main`: `git diff --name-only main...HEAD`; for another target:\n `BASE=$(git merge-base <target-branch> HEAD)` then\n `git diff --name-only $BASE...HEAD`, as in **Phase 0.5**). Include\n renames; build the **old → new** table (source and published) per **Phase\n 0**.\n2. **Sweep and list:** for every **old** path/URL in that table, run\n [Sweep commands](#sweep-commands) on the **allowed** trees. Record\n every hit as **List 1** (no `#`) or **List 2** (old path with `#...`) per\n **Phase 0.5**.\n3. **Phased edits:** **Phase 1** (`aliases`), then **Phase 2** (List 1), then\n **Phase 3** (List 2) with **no guessing**—as in the sections below.\n4. **Re-sweep** the same old-path set, then run **`docker buildx bake\n validate`**. The **Definition of done** above is met or you have **explicit\n defers** for the remainder.\n5. **review-changes:** run **[review-changes](../review-changes/SKILL.md)**\n on the branch vs **`main`…`HEAD`** (or the correct base) before a PR.\n\n### Sweep commands\n\nUse a **repository** search (e.g. `rg` / your IDE) so **nothing** in the\nallowed scope is only eyeballed.\n\n**Trees to include** (at minimum): all of `content/`, plus **`data/`** and\n**`layouts/`** when a migration can appear in config, `link:`-like fields,\nshortcodes, or hardcoded path strings. Follow **Vendored / generated** rules in\n**AGENTS.md**; do not edit disallowed files.\n\n**What to search for (repeat per row in the old side of the mapping):**\n\n- **Hugo / source form:** path segments that identify the *old* file, e.g.\n `manuals/.../old-segment/...` or `../old-segment/.../page.md` as your tree\n uses; include variants that still appear in the repo.\n- **Published / site form:** e.g. `/admin/.../old-slug/` in front matter, nav\n `url:`, or `https://docs.docker.com/...` in allowed files—**match the\n file’s** established pattern, per **Conventions** below.\n- **Anchors:** search for the **old path string**; matches that also include\n `#...` belong on **List 2** for **Phase 3** unless the whole link is\n a pure path-only case.\n\n[scripts/scope-pr-files.sh](scripts/scope-pr-files.sh) (if present) prints\n**`PR_SCOPE_FILES` only**—it does **not** replace this sweep. Use it to build\nthe **old → new** table, **not** to list where inbound links were fixed.\n\n## Progressive disclosure (optional)\n\nThe procedure below stays in this file. If a run produces a very large\n**old → new** URL table, store that table in **`reference.md`** in this skill\ndirectory and link it from the task summary, so the agent reads the long\nmapping only when needed.\n\n## Modes\n\n- **PR-scoped (typical for a single PR)** \n - **What the PR “owns” (focus):** use `git diff` / `base...HEAD` to know which\n pages and renames the branch actually moves (`PR_SCOPE_FILES`). The **old →\n new** mapping and **List 1 / List 2** for this migration are defined from\n **that** work, not from unrelated areas.\n - **Where to look for stale references (sweep):** search broadly—typically all\n of `content/` (and config, shortcodes, layouts, per Conventions)—for **inbound**\n links and fields whose **target** is an **old** path or URL in **this** PR’s\n mapping. Inbound stragglers are often in files the PR never touched; finding\n them is **in scope** for this migration. \n - **What to edit:** update **any** file in the allowed trees that contains a\n **migration-relevant** reference (target ∈ this PR’s old path set) according\n to the phases below. **Do not** treat `PR_SCOPE_FILES` as a hard limit on\n *which files you may save* for **inbound** link repairs (unless\n project policy for a given PR says otherwise; then follow policy and\n **defer** out-of-PR file fixes).\n - **Out of scope (defer / ignore in this run):** link and anchor problems that\n are **not** about this PR’s old→new map—e.g. a different area’s own slug\n issues, rot unrelated to the remapped path set. *Example:* a PR that only\n remaps `content/strawberry/...` should not “fix the whole site”; it **should**\n still fix a link under `mango/…` that **points at** an old `strawberry/…` path\n in the mapping, and **should not** chase **mango/**-only issues that do\n not involve those old targets.\n\n- **Full-site (complete migration after the PR)** \n - Update stragglers **across the repo** (or all inbound links to moved\n sections), including config-driven `link:` fields if policy allows. \n - Still make **minimal** edits; no drive-by rewrites to **unrelated** targets\n outside the run’s **declared** mapping and lists.\n\n### No guessing\n\n- The agent must **not** guess **replacement paths, published URLs, or fragment\n IDs** (including for consolidated pages, renamed headings, or\n “semantic” remaps of `#anchor` → new `#…`). If the user has not given an\n explicit new target, **ask**, **defer**, or **stop** per **AGENTS.md**; never\n infer, autocomplete, or substitute a plausible fragment from the target page’s\n heading list. That rule applies in **every** phase, including after validation\n in Phase 3.\n\n---\n\n## Conventions (links, anchors, redirects)\n\n### Front matter `aliases` (redirects)\n\n- Per **COMPONENTS.md**, `aliases` are **URLs that redirect to this page**.\n- Add or **merge** on the **new canonical** page; do not drop unrelated\n entries. Match local examples: **published-style paths** (leading `/`), and\n **trailing `/`** when that matches existing pages in the same area.\n- **No** speculative redirects for URLs that were never published.\n- **Collision check** before adding: no other page or redirect may already\n own the same old path.\n- If the site also uses **`data/redirects.yml`**, only add entries when\n project policy requires it; avoid duplicating the same old URL in\n `aliases` **and** `redirects.yml` unless maintainers do.\n\n### Internal links in Markdown (STYLE.md + COMPONENTS.md)\n\n- Use **relative paths to source files** (e.g. `../section/page.md`) with\n **`.md`**, following **COMPONENTS.md** examples, unless the file already\n uses an established pattern (e.g. some `link:` or nav fields use **published**\n paths without `manuals` or `.md` — **match the surrounding file**).\n- Keep **CLAUDE.md** / **AGENTS.md** rules: internal ref targets under\n `content/manuals/...` often use the full **`/manuals/...`** path; published\n URLs omit the `manuals` segment—do not confuse the two when fixing links.\n- **Link text (STYLE.md):** descriptive, ~**5 words**; no “click here” or\n “learn more”; **no** end punctuation **inside** the link text; **no** bold/italic\n on link text unless normal in the sentence.\n- **Headings (STYLE):** **sentence case**; do not rename headings in passing\n unless the migration requires it (heading changes break fragments).\n\n### Shortcodes and layouts (links not only in Markdown)\n\n- **Phase 2–3 scope includes** any **shortcode or layout partial** (under\n **Modes**, search broadly for inbound links to the migration; **edits** follow\n the same file-level rules as for Markdown) that emits links: e.g. `ref` /\n `relref`, `link` fields in shortcode args, or hardcoded\n `docs.docker.com` / path strings. Grep for old paths, slugs, and fragments\n under `layouts/shortcodes/` (and `layouts/_default/` if partials build nav).\n- Match each file’s existing pattern; do not rewrite working shortcode style\n just to “clean up.”\n\n### Fragments / anchors (Phase 3)\n\n- List 1 / List 2: fragment-bearing **cross-references to old paths** are tracked\n on **List 2** in Phase 0.5; do not bulk-rewrite them in the **List 1** pass\n (Phase 2). See Phase 0.5 and Phase 2.\n- **Valid `#fragment` values:** after the user supplies a new fragment, it should\n match the **target** page’s **generated** heading ID (Hugo slugification; see\n **CLAUDE.md** / **AGENTS.md**). The agent still **validates** (see Phase 3) and\n must **not** “pick” a different id from the page to replace a bad answer—**No\n guessing**.\n- Same-page: `[Text](#section-id)`.\n- Cross-page: when user-provided, `#fragment` must still be checked against the\n **target** file. Validate fragments in shortcodes the same way as in body\n Markdown.\n\n### External URLs (**AGENTS.md**)\n\n- Do not commit **guessed** replacement URLs. If a URL cannot be verified,\n treat as blocked or drop the fragment per AGENTS guidance. See also **No\n guessing** above; internal and external link targets are treated the same for\n inference: **none** without user input or a verified source.\n\n### Special cases (**AGENTS.md**)\n\n- **Engine API version** pages: respect coordinated **`/latest/` `aliases`**\n rules—never leave two version files both owning `/latest/`.\n- **Vendored / generated** trees: read-only; see CLAUDE.md. Do not “fix” links\n there if policy forbids.\n\n---\n\n## Phase 0 — Discovery (read-only; may use whole repo)\n\n1. Read **hugo.yaml** (permalinks, `refLinksErrorLevel`, `disablePathToLower`).\n2. From the branch (diff, renames), build a **mapping table**:\n - old source path → new source path \n - old published URL → new published URL (from permalink rules)\n3. **Case:** with `disablePathToLower: true`, filesystem path **case** appears in\n URLs—**directory and link casing must match** (e.g. `setup` vs `Setup`).\n4. When planning **inbound link** fixes, treat old-path references as two\n categories: **no fragment** vs **with `#fragment`**. That split feeds\n **List 1** and **List 2** in Phase 0.5 and drives Phase 2 ordering (see\n there).\n\n---\n\n## Phase 0.5 — PR-scoped evaluation (required before edits in PR mode)\n\n1. **Set `PR_SCOPE_FILES` (Git scope for PR mode)** \n - When the PR **targets `main`**, use the same triple-dot form as\n **review-changes**: \n `git diff --name-only main...HEAD` \n - For a **different target branch** or a custom base, use the merge base: \n `BASE=$(git merge-base <target-branch> HEAD)` \n then: \n `git diff --name-only \"$BASE\"...HEAD` \n - Those paths define **what moved** in the branch; they are the primary input\n to the **old → new** path/URL table. They are **not** a hard cap on *where\n to search* for **inbound** links (see **Modes**): sweeps for links **to** old\n paths usually cover all of `content/` (and other trees per Conventions). \n - If project policy **limits edits** to the diff for a given PR, follow that\n and **defer** link fixes in files outside the diff; note the exception in\n the task if the user relaxes that policy.\n\n2. Build checklists (see **Modes** for sweep vs area-of-work):\n - path/URL mapping this run must honor (old source path → new; old published\n → new, from the **PR’s** moves in PR-scoped mode, or the **declared** full\n migration in full-site mode)\n - **List 1 — old path, no fragment:** every **inbound** reference, found on\n the **sweep** surface, to a moved **old** path that does **not** include a\n `#...` fragment (e.g. `…/banana.md` in the repo’s link style for that\n file).\n - **List 2 — old path with fragment:** every **inbound** reference, found on\n the same sweep, to a moved **old** path that **includes** a `#...` fragment\n (e.g. `…/banana.md#anchor` or the published-style equivalent in context). The\n **same** old path string may appear on **both** List 1 and List 2 for\n different links; duplication across the two lists is OK.\n - **Matching rules:** when recording List 1 / List 2, use **one** consistent\n path representation for comparison (e.g. relative `../path/banana.md` vs\n root-anchored) **per the conventions in this doc** and the **surrounding\n file’s** established pattern. Agents compare and skip List 2 links in the\n List 1 pass using the **same** representation rules.\n3. **Out of scope** for the lists: only include references whose **old** target\n is in this run’s **mapping**. Do not build List 1/2 for unrelated **mango/**\n (or other) problems unless those links also target an **old** path that this\n migration renames. Defer those issues separately (see **Modes**).\n\n---\n\n## Phase 1 — `aliases` (old published URLs)\n\n1. On each **new** canonical page, add or merge **`aliases`** for every **real**\n former public URL.\n2. Do not strip existing unrelated aliases.\n3. **PR-scoped:** add aliases only where the canonical file is in scope or the\n project requires it; otherwise list missing alias targets for follow-up.\n\n---\n\n## Phase 2 — In-repo link reference updates\n\n1. **List 1 first (path only):** update references that belong to **List 1**\n (old path, **no** fragment). Replace old source paths or old published URLs\n with the **new** targets; preserve each file’s link pattern (relative vs\n root-anchored `.md` paths). **Do not** apply the same bulk path replacement to\n links that appear in **List 2** (old path **with** `#...`) during this\n sub-step—**leave** every **List 2** link **unchanged** for now.\n2. **After List 1 is complete:** **re-scan** the **same** **sweep** surface as\n in Phase 0.5 (e.g. all of `content/` plus config) or **print** a clear list of\n all **remaining** **List 2** entries. Those links should still point at the\n **old** path and **old** fragment until Phase 3. \n3. **Full-site (extra sweep):** after steps 1–2, still use **AGENTS “Page\n deletion checklist”**-style thoroughness for **config / front matter**\n `link:` and similar so nav and grids are not left on old slugs. Apply the\n **List 1 / List 2** rules there too: path-only old references first; defer\n fragment-bearing rewrites in line with **List 2** until Phase 3.\n4. **PR-scoped (which files to change):** apply List 1 and later Phase 3 updates\n to **every** file the **sweep** finds with a **migration-relevant** reference\n (inbound to an **old** path in the mapping), including files **not** in\n `PR_SCOPE_FILES`, per **Modes**. **Log** and **defer** (do not “fix”)\n unrelated stragglers. If policy forbids out-of-PR file edits, defer per step 1\n of Phase 0.5. \n5. Include **shortcodes and layout partials** (see Conventions and **Modes** for\n sweep vs focus).\n\n---\n\n## Phase 3 — List 2: interactive path and fragment resolution\n\n**Prerequisites:** Phase 2 has updated **List 1**; **List 2** still lists **old\npath + `#...`** (unchanged) for this migration. See **Modes** for which files\nmay be edited; **No guessing** applies.\n\n1. **Print List 2** to the user: every remaining **old path** + `#anchor` (in the\n agreed representation), so nothing is hidden before the loop.\n2. **For each distinct** `old-path#oldAnchor` (or process in the order the user\n prefers, one at a time): \n - Ask: **What is the new path (and fragment, if any) for this content?** The\n user may give a new source path, published URL, and/or `#newAnchor` per\n project conventions. \n - **Validate** the user’s answer: open the **target** page (or resolve the\n target) and check that `#newAnchor` (if any) **exists** as a real heading\n / generated id on that page, per **CLAUDE.md** / **AGENTS.md** (same rules\n as the rest of the site). **Do not** replace the user’s fragment with a\n “better” one from the file. \n - If validation **fails** (unknown target file, or `#newAnchor` not found on\n the page): **warn** clearly (what failed: path vs missing fragment), then\n **ask again** for a corrected path and/or fragment. **Repeat** until\n validation passes or the user **defers** / **drops** the fragment (per\n **AGENTS.md**). **Never** guess a new fragment to fix the problem. \n - When validation **passes:** update **all** in-repo references that match\n that **same** `old-path#oldAnchor` to the user-approved `new-path#newAnchor`\n (respect each file’s link style; include shortcodes/layouts on the same\n **sweep** surface as Phase 2). \n3. **Repeat** from step 1: **re-print** or **re-scan** for **List 2** until it is\n **empty** or the user defers the remainder. \n4. **PR-scoped / full-site:** the **loop** is the same. **Edits** follow **Modes**:\n migration-relevant **inbound** links may live in any file on the sweep; do\n not expand into **unrelated** link debt from other areas. Defer as in **Modes**\n and Phase 0.5.\n\n---\n\n## Optional: scripts helper\n\nThis skill includes a small **scope helper** so agents do not re-derive Git\nrecipes. See [scripts/scope-pr-files.sh](scripts/scope-pr-files.sh) — it prints\npaths in PR scope for a given target branch (default `main`).\n\n---\n\n## Verification\n\n```bash\ndocker buildx bake validate\n```\n\nUse the **Definition of done** in **Agent: required procedure (do not skip)**\nas the final bar: **validate** must pass, and the **sweep** must be clean for\n**plain** and **`#fragment`** old-path references, **or** the remainder must be\n**explicitly deferred** in **Phase 3** per **AGENTS.md** / the user. Mid-run,\n**Phase 2** may still leave **List 2** links unchanged **until** Phase 3; that\nintermediate state is **not** the finished migration.\n","frontmatter":{"name":"migrate-content-ia","description":"Handle Hugo docs information-architecture moves: discover old vs new URLs, add front matter aliases (Phase 1), update in-repo links (Phase 2), interactive List 2 resolution and fragment validation (Phase 3; no guessing). Supports PR-scoped mapping plus whole-content sweeps for inbound links to that mapping, or a full-site follow-up. Triggers on: \"IA migration\", \"redirects for moved pages\", \"fix links after content move\", \"PR-scoped link/anchor pass\", \"aliases for old URLs\". After branch work, chain the review-changes skill (main...HEAD) before a PR. Agents must run the in-file required procedure and definition of done, not the phases alone in isolation.\n"},"isInternal":false,"tokens":5530,"sizeBytes":20656},{"name":"SKILL.md","path":".agents/skills/research/SKILL.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/.agents/skills/research/SKILL.md","title":"research","category":"anthropic-skill","format":"markdown","content":"---\nname: research\ndescription: >\n Research a documentation topic — locate affected files, understand the\n problem, identify what to change. Use when investigating an issue, a\n question, or a topic before writing a fix. Triggers on: \"research issue\n 1234\", \"investigate what needs changing for #500\", \"what files are\n affected by #200\", \"where is X documented\", \"is our docs page about Y\n accurate\", \"look into how we document Z\".\n---\n\n# Research\n\nInvestigate the topic and determine whether documentation needs to change.\nWhen an update is warranted, identify exact files, named targets within\nthose files, and the verified content needed.\n\n## 1. Gather context\n\nIf the input is a GitHub issue number, fetch it:\n\n```bash\ngh issue view <number> --repo docker/docs \\\n --json number,title,body,labels,comments\n```\n\nOtherwise, work from what was provided — a description, a URL, a question,\nor prior conversation context. Identify the topic, affected feature, or\npage to investigate.\n\n## 2. Locate affected files\n\nSearch `content/` using the URL or topic from the issue. Remember the\n`/manuals` prefix mapping when converting URLs to file paths.\n\nFor each candidate file, read the relevant section to confirm it contains\nthe reported problem.\n\n## 3. Check vendored ownership\n\nBefore planning any edit, verify the file is editable locally:\n\n- `_vendor/` — read-only, vendored via Hugo modules\n- `data/cli/` — read-only, generated from upstream YAML\n- `content/reference/cli/` — read-only, generated from `data/cli/`\n- Everything else in `content/` — editable\n\nIf the fix requires upstream changes, identify the upstream repo and note\nit as out of scope. See the vendored content table in CLAUDE.md.\n\n## 4. Find related content\n\nLook for pages that may need updating alongside the primary fix:\n\n- Pages that link to the affected content\n- Include files (`content/includes/`) referenced by the page\n- Related pages in the same section describing the same feature\n\n## 5. Verify facts\n\nIf the issue makes a factual claim about how a feature behaves, verify it.\nFollow external links, read upstream source, check release notes. Do not\nplan a fix based on an unverified claim.\n\nIf the fix requires a replacement URL and that URL cannot be verified (e.g.\nnetwork restrictions), report it as a blocker rather than guessing.\n\n## 6. Assess documentation impact\n\nA code change or release-note entry is evidence to investigate, not a reason\nby itself to add documentation. Identify the reader's task and what the\nchange alters about it. Recommend an update when existing guidance becomes\nincorrect, leaves a gap in that task, or omits a capability useful to readers.\nAn implementation fix may need no update if the docs already describe the\nintended behavior.\n\nFor each recommended update, connect the reader's task, the documentation\ngap, the destination page and section, and the proposed treatment. Prefer\ncorrecting existing prose or examples when they serve that task. Check related\npages for contradictions, without assuming each needs the same explanation.\n\nIf there is no clear home, reconsider the value and scope before proposing a\nsection or page. A separate home can be justified by a distinct reader task,\nnot by the need to place a release-note bullet. \"No documentation change\" is\na valid finding; explain it briefly when assessing a set of changes.\n\n## 7. Check the live site (if needed)\n\nFor URL or rendering issues, fetch the live page:\n\n```text\nhttps://docs.docker.com/<path>/\n```\n\n## 8. Report findings\n\nSummarize what you found — files to change, the specific problem in each,\nwhat the fix should be, and any constraints. This context feeds directly\ninto the write step.\n\nBe specific: name the file, the section or element within it, and the\nverified content needed. \"Fix the broken link in networking.md\" is not\nspecific enough. \"In `compose/networking.md`, the 'Custom networks' section,\nremove the note about `driver_opts` being ignored — this was fixed in\nCompose 2.24\" is.\n\n## Notes\n\n- Research quality bounds write quality. Vague research produces broad\n changes; precise research produces minimal ones.\n- Do not create standalone research files — findings stay in conversation\n context for the write step.\n","frontmatter":{"name":"research","description":"Research a documentation topic — locate affected files, understand the problem, identify what to change. Use when investigating an issue, a question, or a topic before writing a fix. Triggers on: \"research issue 1234\", \"investigate what needs changing for #500\", \"what files are affected by #200\", \"where is X documented\", \"is our docs page about Y accurate\", \"look into how we document Z\".\n"},"isInternal":false,"tokens":936,"sizeBytes":4245},{"name":"SKILL.md","path":".agents/skills/review-changes/SKILL.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/.agents/skills/review-changes/SKILL.md","title":"review-changes","category":"anthropic-skill","format":"markdown","content":"---\nname: review-changes\ndescription: >\n Review uncommitted or recently committed documentation changes for\n correctness, coherence, and style compliance. Use before creating a PR\n to catch issues. \"review my changes\", \"review the diff\", \"check the fix\n before submitting\", \"does this look right\".\ncontext: fork\nmodel: opus\n---\n\n# Review Changes\n\nEvaluate whether the changes correctly and completely solve the stated\nproblem, without introducing new issues. Start with no assumptions — the\nchange may contain mistakes. Your job is to catch what the writer missed,\nnot to rubber-stamp the diff.\n\n## 1. Identify what changed\n\nDetermine the scope of changes to review:\n\n```bash\n# Uncommitted changes\ngit diff --name-only\n\n# Last commit\ngit diff --name-only HEAD~1\n\n# Entire branch vs main\ngit diff --name-only main...HEAD\n```\n\nPick the right comparison for what's being reviewed. If reviewing a branch,\nuse `main...HEAD` to see all changes since the branch diverged.\n\n## 2. Read each changed file in full\n\nDo not just read the diff. For every changed file, read the entire file to\nunderstand the full context the change lives in. A diff can look correct in\nisolation but contradict something earlier on the same page.\n\nThen read the diff for the detailed changes:\n\n```bash\n# Adjust the comparison to match step 1\ngit diff --unified=10 # uncommitted\ngit diff --unified=10 HEAD~1 # last commit\ngit diff --unified=10 main...HEAD # branch\n```\n\n## 3. Follow cross-references\n\nFor each changed file, check what links to it and what it links to:\n\n- Search for other pages that reference the changed content (grep for the\n filename, heading anchors, or key phrases)\n- Read linked pages to verify the change doesn't create contradictions\n across pages\n- Check that anchor links in cross-references still match heading IDs\n\nA change that's correct on its own page can break the story told by a\nrelated page.\n\n## 4. Verify factual accuracy\n\nDon't assume the change is factually correct just because it reads well.\n\n- If the change describes how a feature behaves, verify against upstream\n docs or source code\n- If the change includes a URL, check that it resolves\n- If the change references a CLI flag, option, or API field, confirm it\n exists\n\n## 5. Evaluate as a reader\n\nConsider someone landing on this page from a search result, with no prior\ncontext:\n\n- Does the page make sense on its own?\n- Is the changed section clear without having read the issue or diff?\n- Would a reader be confused by anything the change introduces or leaves\n out?\n\nAccuracy alone doesn't justify an addition. For each substantive addition, ask:\n\n- Does it help readers act, choose, or understand a consequence?\n- Does it belong under this heading and at this point in the explanation?\n- Does it interrupt a procedure, example, or explanation already in progress?\n- Is the detail proportional to its value here, or would a link suffice?\n- Would removing it improve the page without losing necessary guidance?\n\nRecommend shortening, moving, or deleting accurate text when it doesn't serve\nthe page's task. When reviewing multiple commits, check both each change in\ncontext and the combined diff for repeated explanations.\n\n## 6. Review code and template changes\n\nFor non-Markdown changes (JS, HTML, CSS, Hugo templates):\n\n- Trace through the common execution path\n- Trace through at least one edge case (no stored preference, Alpine fails\n to load, first visit vs returning visitor)\n- Ask whether the change could produce unexpected browser or runtime\n behavior that no automated tool would catch\n\n## 7. Decision\n\n**Approve** if the change is correct, coherent, complete, and factually\naccurate.\n\n**Request changes** if:\n- The change does not correctly solve the stated problem\n- There is a factual error or contradiction (on-page or cross-page)\n- A cross-reference is broken or misleading\n- A reader would be confused\n- An addition duplicates guidance or disrupts the page without enough reader value\n\nWhen requesting changes, be specific: quote the exact text that is wrong,\nexplain why, and suggest the correct fix.\n","frontmatter":{"name":"review-changes","description":"Review uncommitted or recently committed documentation changes for correctness, coherence, and style compliance. Use before creating a PR to catch issues. \"review my changes\", \"review the diff\", \"check the fix before submitting\", \"does this look right\".\n","context":"fork","model":"opus"},"isInternal":false,"tokens":910,"sizeBytes":4118},{"name":"openai.yaml","path":".agents/skills/review-pr/agents/openai.yaml","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/.agents/skills/review-pr/agents/openai.yaml","title":"Agents Skill","category":"anthropic-skill","format":"yaml","content":"# Agents Skill\n\nPath: `.agents/skills/review-pr/agents/openai.yaml`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/.agents/skills/review-pr/agents/openai.yaml)","tokens":300,"sizeBytes":193},{"name":"SKILL.md","path":".agents/skills/review-pr/SKILL.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/.agents/skills/review-pr/SKILL.md","title":"review-pr","category":"anthropic-skill","format":"markdown","content":"---\nname: review-pr\ndescription: >\n Review one or more incoming Docker documentation pull requests as a\n maintainer. Independently validate technical claims, assess editorial fit\n and information architecture, choose a verdict, and draft exact inline or\n PR-wide feedback behind a confirmation gate. Use for requests such as\n \"review PR 123\", \"is this PR correct?\", \"does this information belong\n here?\", \"validate this PR\", or \"help review backlog PRs\". Do not use to\n maintain or fix a PR you own; use maintain-pr for that.\n---\n\n# Review PR\n\nReview incoming contributions for factual correctness and whether they make\nthe documentation better as a whole. Treat a technically true addition as\ninsufficient when it is misplaced, overemphasized, redundant, or unhelpful\nto the page's intended reader.\n\n## Preserve the write boundary\n\nPerform the review in two phases:\n\n1. Research the PR, decide a verdict, and present the exact proposed\n comment or review text.\n2. Wait for explicit user confirmation, then post only the confirmed text.\n\nBefore confirmation, do not post comments, submit a GitHub review, approve or\nrequest changes, resolve threads, push commits, edit labels, or otherwise\nmutate GitHub. A request to review or draft feedback is not confirmation to\npost it. Ask `Post these comments?` and stop. Treat revisions to a draft as\nunconfirmed until the user explicitly asks to post them.\n\n## 1. Gather the full context\n\nFor each PR, inspect its metadata, body, commits, changed files, checks,\nconversation, reviews, and linked issues. Always fetch inline comments\nseparately because `gh pr view --json reviews` omits them.\n\n```bash\ngh pr view <PR> --repo docker/docs \\\n --json number,title,url,state,author,body,baseRefName,headRefName,headRefOid,commits,files,comments,reviews,reviewDecision,statusCheckRollup\ngh api repos/docker/docs/pulls/<PR>/comments \\\n --jq '[.[] | {id, author: .user.login, body, path, line, side, commit_id}]'\ngh pr diff <PR> --repo docker/docs\n```\n\nRead linked issues and relevant discussion. An issue is evidence that a\nreader was confused, but it does not establish the reporter's diagnosis or\njustify a new highlighted note by itself. Green CI establishes only that automated\nchecks passed, not that the content is correct.\n\nFetch the PR head when local inspection is useful. Compare it with the\ncanonical upstream base rather than assuming the local branch is fresh.\nRead each changed file in full, not only its diff.\n\n## 2. Research independently\n\nVerify every material claim against authoritative sources such as product\nsource code, upstream documentation, specifications, release notes, or safe\nlocal reproduction. Do not accept the PR description, issue diagnosis, or\nexisting review feedback as fact.\n\nSearch the documentation for related explanations and canonical pages. Read\n`STYLE.md`, `COMPONENTS.md`, and applicable repository instructions. Check\nwhether a changed file is generated or maintained upstream and identify the correct\nupstream repository instead of proposing a local edit.\n\nDistinguish among:\n\n- a wrong fact\n- a correct fact expressed inaccurately\n- a correct fact placed on the wrong page\n- content already explained elsewhere\n- a real discovery problem better addressed with a short signpost and link\n- a request that needs no documentation change.\n\nIf an external claim or replacement URL cannot be verified, report that\nlimitation instead of guessing.\n\n## 3. Assess editorial fit\n\nApply these questions to each addition:\n\n- Does it change a reader's decision or next action on this page?\n- Is this the canonical page for the concept?\n- Is the fact general, or specific to this page, feature, or component?\n- Is the information already documented elsewhere?\n- Would a concise local signpost to canonical coverage solve the discovery\n problem better than duplicating the explanation?\n- Is the visual and textual weight proportional to the information's value?\n- Does it preserve the page's scope, flow, and character?\n\nPrefer one coherent explanation in the canonical location. Add local context\nonly when it helps the reader complete the task at hand. Avoid stray notes,\ncallouts, and exhaustive edge cases whose prominence exceeds their value.\n\n## 4. Choose a decisive verdict\n\nLead with one of these outcomes:\n\n- **Approve**: correct, useful, well placed, and ready to merge.\n- **Approve with optional polish**: ready to merge; suggestions are genuinely\n non-blocking.\n- **Focused rewrite**: the underlying need is valid, but wording, scope,\n placement, or structure should change before merge.\n- **Close / no docs change**: incorrect, redundant, out of scope, or not a\n documentation problem.\n\nExplain the verdict with evidence. When wording is the issue, provide exact\nreplacement text rather than a vague request to improve it.\n\n## 5. Place feedback deliberately\n\nUse an inline comment when the finding is anchored to a narrow changed line\nor range and acting on it is local. Examples include an inaccurate sentence,\nan ambiguous option description, a broken link, or a precise wording\nreplacement.\n\nUse a PR-wide comment for scope, information architecture, overall approach,\nmultiple intertwined edits, or a proposed replacement section. Do not attach\nholistic feedback to an arbitrary line.\n\nUse both when appropriate: put the overall direction in the PR-wide comment\nand line-specific corrections inline. Do not repeat the same point in both.\nConsolidate related feedback so the author receives the fewest comments that\nremain clear and actionable.\n\nFor every proposed inline comment, resolve and display the current changed\nfile path and right-side diff line. If the target line is not part of the\ncurrent diff or cannot be identified reliably, use a PR-wide comment that\nquotes the target text instead. Never guess a line number.\n\nEnd comments posted on the user's behalf with an accurate agent-disclosure\nfooter, such as `Generated by Codex`.\n\n## 6. Present drafts and stop\n\nBefore any GitHub write, show the review in this form, omitting empty\nsections:\n\n```markdown\n## Verdict\n\nFocused rewrite\n\n## Findings\n\n- <finding and evidence>\n\n## Proposed inline comments\n\n1. `path/to/file.md:42`\n > Exact comment text\n\n## Proposed PR-wide comment\n\n> Exact comment text\n\nPost these comments?\n```\n\nFor multiple PRs, give each PR its own verdict and comment set. Make the\nconfirmation scope unambiguous. Do not interpret approval of one PR's drafts\nas approval to post comments on the others.\n\n## 7. Post only confirmed feedback\n\nImmediately before posting, re-fetch the PR head SHA and diff. If either the\nhead or an inline target changed, stop and show the updated draft or\nplacement for confirmation.\n\nPost confirmed inline comments as a single comment-only review when\npractical. Use the current head SHA and right-side diff lines:\n\n```bash\ngh api repos/docker/docs/pulls/<PR>/reviews --method POST --input <payload>\n```\n\nThe JSON payload contains `commit_id`, `event: \"COMMENT\"`, and a `comments`\narray whose entries contain `path`, `line`, `side: \"RIGHT\"`, and `body`.\nSubmitting a review with `APPROVE` or `REQUEST_CHANGES` requires separate,\nexplicit user authorization; a verdict alone does not grant it.\n\nPost confirmed holistic feedback separately:\n\n```bash\ngh pr comment <PR> --repo docker/docs --body-file <file>\n```\n\nUse a safely created temporary file or API input so Markdown, backticks, and\nshell substitutions are preserved literally. Post exactly the confirmed\ntext. Verify the resulting review/comments and report their URLs and\nplacements. If GitHub rejects an inline location, do not silently fall back\nto a PR-wide comment; report the failure and prepare a revised placement for\nconfirmation.\n\n## Definition of done\n\n- Verify technical claims with authoritative evidence.\n- Evaluate usefulness, placement, duplication, and proportionality.\n- Give a decisive verdict and exact actionable wording.\n- Choose inline and PR-wide placement based on the feedback's scope.\n- Show every exact draft and target before any GitHub mutation.\n- Post only after explicit confirmation and verify what was posted.\n","frontmatter":{"name":"review-pr","description":"Review one or more incoming Docker documentation pull requests as a maintainer. Independently validate technical claims, assess editorial fit and information architecture, choose a verdict, and draft exact inline or PR-wide feedback behind a confirmation gate. Use for requests such as \"review PR 123\", \"is this PR correct?\", \"does this information belong here?\", \"validate this PR\", or \"help review backlog PRs\". Do not use to maintain or fix a PR you own; use maintain-pr for that.\n"},"isInternal":false,"tokens":1722,"sizeBytes":8109},{"name":"SKILL.md","path":".agents/skills/testcontainers-guides-migrator/SKILL.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/.agents/skills/testcontainers-guides-migrator/SKILL.md","title":"testcontainers-guide-migrator","category":"anthropic-skill","format":"markdown","content":"---\nname: testcontainers-guide-migrator\ndescription: >\n Migrate a Testcontainers guide from testcontainers.com into the Docker docs site (docs.docker.com).\n Converts AsciiDoc to Hugo Markdown, updates code to the latest Testcontainers API, splits into\n chapters with stepper navigation, verifies code compiles and tests pass, and validates against\n Docker docs style rules. Use when asked to migrate a testcontainers guide, add a TC guide, or\n port content from testcontainers.com to Docker docs.\n---\n\n# Migrate a Testcontainers Guide\n\nYou are migrating guides from https://testcontainers.com/guides/ into the Docker docs Hugo site.\nEach guide lives in its own GitHub repo under `testcontainers/tc-guide-*`, written in AsciiDoc.\nThe source repos are listed in the testcontainers-site build.sh:\nhttps://github.com/testcontainers/testcontainers-site/blob/main/build.sh#L23-L45\n\n## Inputs\n\nThe user provides one or more guides to migrate. Resolve these from the inventory below:\n\n- **REPO_NAME**: GitHub repo (e.g. `tc-guide-getting-started-with-testcontainers-for-java`)\n- **SLUG**: guide slug inside `guide/` dir (e.g. `getting-started-with-testcontainers-for-java`)\n- **LANG**: language identifier (go, java, dotnet, nodejs, python)\n- **GUIDE_ID**: short kebab-case name (e.g. `getting-started`)\n\n## Guide inventory\n\nThese are the 21 guides from testcontainers.com/guides/ and their source repos:\n\n| # | Title | Repo | Lang | GUIDE_ID |\n|---|-------|------|------|----------|\n| 1 | Introduction to Testcontainers | tc-guide-introducing-testcontainers | (none) | introducing |\n| 2 | Getting started for Java | tc-guide-getting-started-with-testcontainers-for-java | java | getting-started |\n| 3 | Testing Spring Boot REST API | tc-guide-testing-spring-boot-rest-api | java | spring-boot-rest-api |\n| 4 | Testcontainers lifecycle (JUnit 5) | tc-guide-testcontainers-lifecycle | java | lifecycle |\n| 5 | Configuration of services in container | tc-guide-configuration-of-services-running-in-container | java | service-configuration |\n| 6 | Replace H2 with real database | tc-guide-replace-h2-with-real-database-for-testing | java | replace-h2 |\n| 7 | Testing ASP.NET Core web app | tc-guide-testing-aspnet-core | dotnet | aspnet-core |\n| 8 | Testing Spring Boot Kafka Listener | tc-guide-testing-spring-boot-kafka-listener | java | spring-boot-kafka |\n| 9 | REST API integrations with MockServer | tc-guide-testing-rest-api-integrations-using-mockserver | java | mockserver |\n| 10 | Getting started for .NET | tc-guide-getting-started-with-testcontainers-for-dotnet | dotnet | getting-started |\n| 11 | AWS integrations with LocalStack | tc-guide-testing-aws-service-integrations-using-localstack | java | aws-localstack |\n| 12 | Testcontainers in Quarkus apps | tc-guide-testcontainers-in-quarkus-applications | java | quarkus |\n| 13 | Getting started for Go | tc-guide-getting-started-with-testcontainers-for-go | go | getting-started |\n| 14 | jOOQ and Flyway with Testcontainers | tc-guide-working-with-jooq-flyway-using-testcontainers | java | jooq-flyway |\n| 15 | Getting started for Node.js | tc-guide-getting-started-with-testcontainers-for-nodejs | nodejs | getting-started |\n| 16 | REST API integrations with WireMock | tc-guide-testing-rest-api-integrations-using-wiremock | java | wiremock |\n| 17 | Local dev with Testcontainers Desktop | tc-guide-simple-local-development-with-testcontainers-desktop | java | local-dev-desktop |\n| 18 | Micronaut REST API with WireMock | tc-guide-testing-rest-api-integrations-in-micronaut-apps-using-wiremock | java | micronaut-wiremock |\n| 19 | Micronaut Kafka Listener | tc-guide-testing-micronaut-kafka-listener | java | micronaut-kafka |\n| 20 | Getting started for Python | tc-guide-getting-started-with-testcontainers-for-python | python | getting-started |\n| 21 | Keycloak with Spring Boot | tc-guide-securing-spring-boot-microservice-using-keycloak-and-testcontainers | java | keycloak-spring-boot |\n\nAlready migrated: **#2 (Java getting-started)**, **#13 (Go getting-started)**, **#20 (Python getting-started)**\n\n## Step 0: Pre-flight\n\n1. Confirm `testing-with-docker` tag exists in `data/tags.yaml`. If not, add:\n ```yaml\n testing-with-docker:\n title: Testing with Docker\n ```\n2. Check if new terms need adding to `_vale/config/vocabularies/Docker/accept.txt`.\n3. Read `STYLE.md` and `COMPONENTS.md` to refresh on Docker docs conventions.\n\n## Step 1: Clone the guide repo\n\nClone the guide repo to a temporary directory. This gives you all source files locally — no HTTP calls needed.\n\n```bash\ngit clone --depth 1 https://github.com/testcontainers/{REPO_NAME}.git <tmpdir>/{REPO_NAME}\n```\n\nWhere `<tmpdir>` is a temporary directory on your system (e.g. the output of `mktemp -d`).\n\nThe repo structure is:\n- `<tmpdir>/{REPO_NAME}/guide/{SLUG}/index.adoc` — the AsciiDoc guide source\n- `<tmpdir>/{REPO_NAME}/src/` — application source code (referenced by `include::` directives)\n- `<tmpdir>/{REPO_NAME}/testdata/` — test data files (SQL scripts, configs, etc.)\n- `<tmpdir>/{REPO_NAME}/pom.xml` or `go.mod` — build config\n\n1. Read `guide/{SLUG}/index.adoc` to get the guide content.\n2. Find all `include::{codebase}/path/to/file[]` directives. The `{codebase}` attribute points to a remote URL, but since you have the repo cloned, read the files directly from disk instead (e.g. `include::{codebase}/src/main/java/Foo.java[]` → read `<tmpdir>/{REPO_NAME}/src/main/java/Foo.java`).\n3. If includes have `[lines=\"X..Y\"]`, extract only those lines from the local file.\n4. Note the `[source,lang]` block preceding each include — that determines the code fence language.\n\nThis cloned repo also serves as the base for Step 6 (code verification) — you can run the tests directly in it to confirm they pass before updating the code to the latest API.\n\n## Step 2: Convert AsciiDoc to Markdown\n\n| AsciiDoc | Markdown |\n|---|---|\n| `== Heading` | `## Heading` |\n| `=== Heading` | `### Heading` |\n| `*bold*` (AsciiDoc bold) | `**bold**` |\n| `https://url[Link text]` | `[Link text](url)` |\n| `[source,lang]\\n----\\ncode\\n----` | `` ```lang\\ncode\\n``` `` |\n| `[source,shell]` with `$` prompts | `` ```console `` |\n| `[NOTE]\\ntext` or `====\\n[NOTE]\\n...\\n====` | `> [!NOTE]\\n> text` |\n| `[TIP]\\ntext` | `> [!TIP]\\n> text` |\n| `:toc:`, `:toclevels:`, `:codebase:` | Remove entirely |\n| `include::{codebase}/path[]` | Replace with fetched code in a code fence |\n| YAML front matter (date, draft, repo) | Remove; transform to Docker docs format |\n\n## Step 3: Apply Docker docs style rules\n\nThese are mandatory (from STYLE.md and AGENTS.md):\n\n- **No \"we\"**: \"We are going to create\" → \"Create\" or \"Start by creating\"\n- **No \"let us\" / \"let's\"**: → imperative voice or \"You can...\"\n- **No hedge words**: remove \"simply\", \"easily\", \"just\", \"seamlessly\"\n- **No meta-commentary**: remove \"it's worth noting\", \"it's important to understand\"\n- **No \"allows you to\" / \"enables you to\"**: → \"lets you\" or rephrase\n- **No \"click\"**: → \"select\"\n- **No bold for emphasis or product names**: only bold UI elements\n- **No time-relative language**: remove \"currently\", \"new\", \"recently\", \"now\"\n- **No exclamations**: remove \"Voila!!!\" etc.\n- Use `console` language hint for interactive shell blocks with `$` prompts\n- Use contractions: \"it's\", \"you're\", \"don't\"\n\n## Step 4: Update code to latest Testcontainers API\n\nResearch the latest API version for the target language before writing code.\n\n**Best practices reference**: The Testcontainers team maintains Claude skills with up-to-date API patterns and best practices for each language at https://github.com/testcontainers/claude-skills/ — check the relevant language skill (testcontainers-go, testcontainers-node, testcontainers-dotnet) for current API signatures, cleanup patterns, wait strategies, and anti-patterns to avoid.\n\nFor each language, check the cloned repo's existing code, then update to the latest API. Key patterns per language:\n\n**Go** (testcontainers-go v0.41.0):\n- `postgres.RunContainer(ctx, opts...)` → `postgres.Run(ctx, \"image\", opts...)`\n- `testcontainers.WithImage(...)` → image is now the 2nd positional param to `Run()`\n- Manual `WithWaitStrategy(wait.ForLog(...))` → `postgres.BasicWaitStrategies()`\n- `t.Cleanup(func() { ctr.Terminate(ctx) })` → `testcontainers.CleanupContainer(t, ctr)`\n- `if err != nil { log.Fatal(err) }` → `require.NoError(t, err)` (use testify require/assert)\n- Helper functions should accept `t *testing.T` as first param, call `t.Helper()`\n- No `TearDownSuite()` needed if `CleanupContainer` is registered in the helper\n- Go version prerequisite: 1.25+\n\n**Java** (testcontainers-java 2.0.4):\n- Artifacts renamed in 2.x: `org.testcontainers:postgresql` → `org.testcontainers:testcontainers-postgresql`\n- Check the latest version at https://java.testcontainers.org/\n- Use `@Testcontainers` and `@Container` annotations for JUnit 5 lifecycle\n- Prefer module-specific containers (e.g. `PostgreSQLContainer`) over `GenericContainer`\n- Use `@DynamicPropertySource` for Spring Boot integration\n\n**.NET** (testcontainers-dotnet):\n- Check the latest NuGet package version\n- Use `IAsyncLifetime` for container lifecycle in xUnit\n- Use builder pattern: `new PostgreSqlBuilder().Build()`\n\n**Node.js** (testcontainers-node):\n- Check the latest npm version\n- Use module-specific packages (e.g. `@testcontainers/postgresql`)\n- Use `GenericContainer` for services without a dedicated module\n\n**Python** (testcontainers-python):\n- Check the latest PyPI version\n- Use context managers (`with PostgresContainer() as postgres:`)\n- Use module-specific containers when available\n\nFor all languages: consult the corresponding Testcontainers skill at https://github.com/testcontainers/claude-skills/ for current best practices and anti-patterns.\n\n## Step 5: Create guide directory structure\n\nDirectory: `content/guides/testcontainers-{LANG}-{GUIDE_ID}/`\n\nEach guide is its own top-level entry under `/guides/`. Do NOT nest guides inside a shared parent section — otherwise they won't appear individually in the tag/language filters on the guides listing page.\n\n### _index.md (landing page)\n\n```yaml\n---\ntitle: {Full guide title}\nlinkTitle: {Short title for guides listing}\ndescription: {One-line description}\nkeywords: testcontainers, {lang}, testing, {technologies used}\nsummary: |\n {2-3 line summary for the guides listing card}\ntoc_min: 1\ntoc_max: 2\ntags: [testing-with-docker]\nlanguages: [{lang}]\nparams:\n time: {estimated} minutes\n---\n\n<!-- Source: https://github.com/testcontainers/{REPO_NAME} -->\n```\n\nContent: what you'll learn (bulleted list), prerequisites, and a NOTE linking to `https://testcontainers.com/getting-started/` for newcomers.\n\n### Sub-pages (chapters)\n\nSplit the guide into logical chapters. Each sub-page:\n\n```yaml\n---\ntitle: {Chapter title}\nlinkTitle: {Short title for stepper}\ndescription: {One-line description}\nweight: {10, 20, 30, ...}\n---\n```\n\n**No `tags`, `languages`, or `params` on sub-pages** — only on `_index.md`.\n\nTypical chapter breakdown:\n| Weight | File | Content |\n|--------|------|---------|\n| 10 | `create-project.md` | Project setup, dependencies, business logic |\n| 20 | `write-tests.md` | First test using testcontainers |\n| 30 | `test-suites.md` | Reusing containers, test helpers, suites |\n| 40 | `run-tests.md` | Running tests, summary, further reading |\n\nAdapt the split to the guide's content — some guides may need fewer or more chapters.\n\n## Step 6: Verify code compiles and tests pass\n\nThis is CRITICAL. The code in the guide MUST compile and all tests MUST pass. Do not skip this step.\n\n### 6a: Use the cloned repo as the verification project\n\nThe repo you cloned in Step 1 (`<tmpdir>/{REPO_NAME}`) already contains a working project with all source files, build config, and tests. Use it as the starting point:\n\n```bash\ncd <tmpdir>/{REPO_NAME}\n```\n\nFirst, verify the **original** code compiles and tests pass before you change anything. This confirms a good baseline.\n\n### 6b: Update the code in the cloned repo\n\nAfter confirming the original works, apply the API updates (from Step 4) directly in the cloned repo's source files. This is the same code you're putting in the guide — keep them in sync.\n\n### 6c: Update dependencies and compile\n\nRun compilation inside a container for reproducibility — no need to install the language toolchain on the host. Use the appropriate language Docker image, mounting the cloned repo:\n\n```bash\ndocker run --rm -v \"<tmpdir>/{REPO_NAME}\":/app -w /app <language-image> sh -c \"<compile command>\"\n```\n\nPick the right image for the language (e.g. `golang:1.25-alpine`, `maven:3-eclipse-temurin-21`, `gradle:jdk21`, `mcr.microsoft.com/dotnet/sdk:9.0`, `node:22-alpine`, `python:3.13-alpine`). Update dependencies to the latest Testcontainers version and compile.\n\nIf compilation fails, fix the code and update the guide markdown to match.\n\n### 6d: Run tests in a container with Docker socket mounted\n\nRun tests in the same kind of container, but **mount the Docker socket** so Testcontainers can create sibling containers.\n\n#### macOS Docker Desktop workarounds\n\nWhen running on macOS with Docker Desktop, these environment variables and flags are **required**:\n\n- **`TESTCONTAINERS_HOST_OVERRIDE=host.docker.internal`** — On macOS, containers can't reach sibling containers via the Docker bridge IP (`172.17.0.x`). This tells Testcontainers (including Ryuk) to connect via `host.docker.internal` instead. **Do NOT disable Ryuk** — it is a core Testcontainers feature and the guides must demonstrate proper usage.\n- **`docker-java.properties`** with `api.version=1.47` — Docker Desktop's minimum API version is 1.44, but docker-java defaults to 1.24. Create this file in the project root and mount it to `/root/.docker-java.properties` inside Java containers.\n- **`-Dspotless.check.skip=true`** — The Spotless Maven plugin in the source repos is incompatible with JDK 21. Skip it since it's a code formatter, not part of the test.\n- **`-Dmicronaut.test.resources.enabled=false`** — Micronaut's Test Resources service starts a separate process that can't connect to Docker from inside a container. The guide tests use Testcontainers directly, not Test Resources. Only needed for Micronaut guides.\n#### Java guide test command\n\n```bash\n# Create docker-java.properties in the project root\necho \"api.version=1.47\" > <tmpdir>/{REPO_NAME}/docker-java.properties\n\ndocker run --rm \\\n -v \"<tmpdir>/{REPO_NAME}\":/app \\\n -v /var/run/docker.sock:/var/run/docker.sock \\\n -v \"<tmpdir>/{REPO_NAME}/docker-java.properties\":/root/.docker-java.properties \\\n -e DOCKER_HOST=unix:///var/run/docker.sock \\\n -e TESTCONTAINERS_HOST_OVERRIDE=host.docker.internal \\\n -w /app \\\n maven:3.9-eclipse-temurin-21 \\\n mvn -B test -Dspotless.check.skip=true -Dspotless.apply.skip=true\n```\n\nFor Quarkus guides, use `maven:3.9-eclipse-temurin-17` instead (Quarkus 3.22.3 compiles for Java 17).\n\n#### Go guide test command\n\n```bash\ndocker run --rm \\\n -v \"<tmpdir>/{REPO_NAME}\":/app \\\n -v /var/run/docker.sock:/var/run/docker.sock \\\n -e DOCKER_HOST=unix:///var/run/docker.sock \\\n -e TESTCONTAINERS_HOST_OVERRIDE=host.docker.internal \\\n -w /app \\\n golang:1.25-alpine \\\n sh -c \"apk add --no-cache gcc musl-dev && go test -v -count=1 ./...\"\n```\n\n#### Python guide test command\n\n```bash\ndocker run --rm \\\n -v \"<tmpdir>/{REPO_NAME}\":/app \\\n -v /var/run/docker.sock:/var/run/docker.sock \\\n -e DOCKER_HOST=unix:///var/run/docker.sock \\\n -e TESTCONTAINERS_HOST_OVERRIDE=host.docker.internal \\\n -w /app \\\n python:3.13-slim \\\n sh -c \"pip install -r requirements.txt && python -m pytest\"\n```\n\n#### .NET guide test command\n\n```bash\ndocker run --rm \\\n -v \"<tmpdir>/{REPO_NAME}\":/app \\\n -v /var/run/docker.sock:/var/run/docker.sock \\\n -e DOCKER_HOST=unix:///var/run/docker.sock \\\n -e TESTCONTAINERS_HOST_OVERRIDE=host.docker.internal \\\n -w /app \\\n mcr.microsoft.com/dotnet/sdk:9.0 \\\n dotnet test\n```\n\n#### Node.js guide test command\n\n```bash\ndocker run --rm \\\n -v \"<tmpdir>/{REPO_NAME}\":/app \\\n -v /var/run/docker.sock:/var/run/docker.sock \\\n -e DOCKER_HOST=unix:///var/run/docker.sock \\\n -e TESTCONTAINERS_HOST_OVERRIDE=host.docker.internal \\\n -w /app \\\n node:22-alpine \\\n sh -c \"npm install && npm test\"\n```\n\n#### Important: run tests sequentially\n\nRun guide tests **one at a time**. Running multiple concurrent DinD or sibling-container tests can overwhelm Docker Desktop's containerd store and cause `meta.db: input/output error` corruption, requiring a Docker Desktop restart.\n\n### 6e: Fix until green\n\nIf any test fails, debug and fix the code in both the temporary project AND the guide markdown. Re-run until all tests pass. Do not proceed until verified.\n\n## Step 7: Update cross-references\n\n1. **`content/manuals/testcontainers.md`**: Add a bullet under the `## Guides` section:\n ```markdown\n - [Guide title](/guides/testcontainers-{LANG}-{GUIDE_ID}/)\n ```\n2. **Do NOT update** `content/guides/testcontainers-cloud/_index.md` — keep its external links.\n3. Link to `https://testcontainers.com/getting-started/` for the Testcontainers overview.\n4. Use internal paths for already-migrated guides; keep `testcontainers.com` links for unmigrated ones.\n\n## Step 8: Validate\n\n**IMPORTANT**: Run ALL validation locally before committing. Vale checks run on CI and will block the PR if they fail — fixing after push wastes CI cycles and review time.\n\n1. `npx --no-install rumdl fmt content/guides/testcontainers-{LANG}-{GUIDE_ID}/`\n2. `npx --no-install rumdl fmt content/manuals/testcontainers.md`\n3. `docker buildx bake lint` — must pass with no errors\n4. `docker buildx bake vale` — then check for errors in the new files:\n ```bash\n grep -A2 \"testcontainers-{LANG}-{GUIDE_ID}\" tmp/vale.out\n ```\n Fix ALL errors before proceeding. Common issues:\n - **Vale.Spelling**: tech terms (library names, tools) not in the dictionary → add to `_vale/config/vocabularies/Docker/accept.txt` (alphabetical order)\n - **Vale.Terms**: wrong casing (e.g. \"python\" → \"Python\") → fix in the markdown. Watch for package names like `testcontainers-python` triggering false positives — rephrase to \"Testcontainers for Python\" in prose.\n - **Docker.Avoid**: hedge words like \"very\", \"simply\" → reword\n - **Docker.We**: first-person plural → rewrite to \"you\" or imperative\n - Info-level suggestions (e.g. \"VS Code\" → \"versus\") are not blocking but review them\n\n Re-run `docker buildx bake vale` after fixes until no errors remain in the new files.\n5. Verify in local dev server (`HUGO_PORT=1314 docker compose watch`):\n - Guide appears when filtering by its language\n - Guide appears when filtering by `Testing with Docker` tag\n - Stepper navigation works across chapters\n - All links resolve (no 404s)\n6. Verify all external URLs return 200:\n ```bash\n curl -s -o /dev/null -w \"%{http_code}\" -L \"{url}\"\n ```\n\n## Step 9: Commit\n\nOne commit per guide. Message format:\n```\nfeat(guides): add testcontainers {lang} {guide-id} guide\n\nMigrated from https://github.com/testcontainers/{REPO_NAME}\nUpdated to testcontainers-{lang} v{version} API.\n```\n\n## Special cases\n\n- **introducing-testcontainers**: Language-agnostic, conceptual. May overlap with `content/manuals/testcontainers.md`. Review for deduplication before migrating.\n- **local-dev-testcontainers-desktop**: About Testcontainers Desktop (now part of Docker Desktop). May need significant rewriting rather than mechanical migration.\n- **Java guides**: Many share the same language. Each still gets its own `testcontainers-java-{GUIDE_ID}` directory.\n\n## Reference: completed migration (Go getting-started)\n\nUse `content/guides/testcontainers-go-getting-started/` as the reference implementation:\n- `_index.md` — landing page with frontmatter, prerequisites, learning objectives\n- `create-project.md` (weight: 10) — project setup and business logic\n- `write-tests.md` (weight: 20) — first test with testcontainers-go\n- `test-suites.md` (weight: 30) — container reuse with testify suites\n- `run-tests.md` (weight: 40) — running tests, summary, further reading\n","frontmatter":{"name":"testcontainers-guide-migrator","description":"Migrate a Testcontainers guide from testcontainers.com into the Docker docs site (docs.docker.com). Converts AsciiDoc to Hugo Markdown, updates code to the latest Testcontainers API, splits into chapters with stepper navigation, verifies code compiles and tests pass, and validates against Docker docs style rules. Use when asked to migrate a testcontainers guide, add a TC guide, or port content from testcontainers.com to Docker docs.\n"},"isInternal":false,"tokens":5180,"sizeBytes":20104},{"name":"SKILL.md","path":".agents/skills/write/SKILL.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/.agents/skills/write/SKILL.md","title":"write","category":"anthropic-skill","format":"markdown","content":"# write\n\nPath: `.agents/skills/write/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/.agents/skills/write/SKILL.md)","tokens":300,"sizeBytes":158},{"name":"docs-scanner.yaml","path":".github/agents/docs-scanner.yaml","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/.github/agents/docs-scanner.yaml","title":"Agents Skill","category":"anthropic-skill","format":"yaml","content":"# Agents Skill\n\nPath: `.github/agents/docs-scanner.yaml`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/.github/agents/docs-scanner.yaml)","tokens":300,"sizeBytes":171},{"name":"_index.md","path":"content/manuals/ai/skills/_index.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/ai/skills/_index.md","title":"Skills Skill","category":"anthropic-skill","format":"markdown","content":"# Skills Skill\n\nPath: `content/manuals/ai/skills/_index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/ai/skills/_index.md)","tokens":300,"sizeBytes":177},{"name":"install.md","path":"content/manuals/ai/skills/install.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/ai/skills/install.md","title":"Skills Skill","category":"anthropic-skill","format":"markdown","content":"# Skills Skill\n\nPath: `content/manuals/ai/skills/install.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/ai/skills/install.md)","tokens":300,"sizeBytes":179},{"name":"_index.md","path":"content/manuals/dhi/tools/_index.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/dhi/tools/_index.md","title":"Tools Skill","category":"anthropic-skill","format":"markdown","content":"# Tools Skill\n\nPath: `content/manuals/dhi/tools/_index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/dhi/tools/_index.md)","tokens":300,"sizeBytes":176},{"name":"api.md","path":"content/manuals/dhi/tools/api.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/dhi/tools/api.md","title":"Tools Skill","category":"anthropic-skill","format":"markdown","content":"# Tools Skill\n\nPath: `content/manuals/dhi/tools/api.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/dhi/tools/api.md)","tokens":300,"sizeBytes":170},{"name":"cli.md","path":"content/manuals/dhi/tools/cli.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/dhi/tools/cli.md","title":"Tools Skill","category":"anthropic-skill","format":"markdown","content":"# Tools Skill\n\nPath: `content/manuals/dhi/tools/cli.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/dhi/tools/cli.md)","tokens":300,"sizeBytes":170},{"name":"hub.md","path":"content/manuals/dhi/tools/hub.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/dhi/tools/hub.md","title":"Tools Skill","category":"anthropic-skill","format":"markdown","content":"# Tools Skill\n\nPath: `content/manuals/dhi/tools/hub.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/dhi/tools/hub.md)","tokens":300,"sizeBytes":170},{"name":"mcp.md","path":"content/manuals/dhi/tools/mcp.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/dhi/tools/mcp.md","title":"Tools Skill","category":"anthropic-skill","format":"markdown","content":"# Tools Skill\n\nPath: `content/manuals/dhi/tools/mcp.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/dhi/tools/mcp.md)","tokens":300,"sizeBytes":170},{"name":"terraform.md","path":"content/manuals/dhi/tools/terraform.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/dhi/tools/terraform.md","title":"Tools Skill","category":"anthropic-skill","format":"markdown","content":"# Tools Skill\n\nPath: `content/manuals/dhi/tools/terraform.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/dhi/tools/terraform.md)","tokens":300,"sizeBytes":182},{"name":"_index.md","path":"content/manuals/extensions/_index.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/_index.md","title":"Extensions Skill","category":"anthropic-skill","format":"markdown","content":"# Extensions Skill\n\nPath: `content/manuals/extensions/_index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/_index.md)","tokens":300,"sizeBytes":183},{"name":"_index.md","path":"content/manuals/extensions/extensions-sdk/_index.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/_index.md","title":"Extensions-sdk Skill","category":"anthropic-skill","format":"markdown","content":"# Extensions-sdk Skill\n\nPath: `content/manuals/extensions/extensions-sdk/_index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/_index.md)","tokens":300,"sizeBytes":217},{"name":"_index.md","path":"content/manuals/extensions/extensions-sdk/architecture/_index.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/architecture/_index.md","title":"Architecture Skill","category":"anthropic-skill","format":"markdown","content":"# Architecture Skill\n\nPath: `content/manuals/extensions/extensions-sdk/architecture/_index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/architecture/_index.md)","tokens":300,"sizeBytes":241},{"name":"metadata.md","path":"content/manuals/extensions/extensions-sdk/architecture/metadata.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/architecture/metadata.md","title":"Architecture Skill","category":"anthropic-skill","format":"markdown","content":"# Architecture Skill\n\nPath: `content/manuals/extensions/extensions-sdk/architecture/metadata.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/architecture/metadata.md)","tokens":300,"sizeBytes":245},{"name":"security.md","path":"content/manuals/extensions/extensions-sdk/architecture/security.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/architecture/security.md","title":"Architecture Skill","category":"anthropic-skill","format":"markdown","content":"# Architecture Skill\n\nPath: `content/manuals/extensions/extensions-sdk/architecture/security.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/architecture/security.md)","tokens":300,"sizeBytes":245},{"name":"_index.md","path":"content/manuals/extensions/extensions-sdk/build/_index.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/build/_index.md","title":"Build Skill","category":"anthropic-skill","format":"markdown","content":"# Build Skill\n\nPath: `content/manuals/extensions/extensions-sdk/build/_index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/build/_index.md)","tokens":300,"sizeBytes":220},{"name":"backend-extension-tutorial.md","path":"content/manuals/extensions/extensions-sdk/build/backend-extension-tutorial.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/build/backend-extension-tutorial.md","title":"Build Skill","category":"anthropic-skill","format":"markdown","content":"# Build Skill\n\nPath: `content/manuals/extensions/extensions-sdk/build/backend-extension-tutorial.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/build/backend-extension-tutorial.md)","tokens":300,"sizeBytes":260},{"name":"frontend-extension-tutorial.md","path":"content/manuals/extensions/extensions-sdk/build/frontend-extension-tutorial.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/build/frontend-extension-tutorial.md","title":"Build Skill","category":"anthropic-skill","format":"markdown","content":"# Build Skill\n\nPath: `content/manuals/extensions/extensions-sdk/build/frontend-extension-tutorial.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/build/frontend-extension-tutorial.md)","tokens":300,"sizeBytes":262},{"name":"minimal-frontend-extension.md","path":"content/manuals/extensions/extensions-sdk/build/minimal-frontend-extension.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/build/minimal-frontend-extension.md","title":"Build Skill","category":"anthropic-skill","format":"markdown","content":"# Build Skill\n\nPath: `content/manuals/extensions/extensions-sdk/build/minimal-frontend-extension.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/build/minimal-frontend-extension.md)","tokens":300,"sizeBytes":260},{"name":"_index.md","path":"content/manuals/extensions/extensions-sdk/design/_index.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/design/_index.md","title":"Design Skill","category":"anthropic-skill","format":"markdown","content":"# Design Skill\n\nPath: `content/manuals/extensions/extensions-sdk/design/_index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/design/_index.md)","tokens":300,"sizeBytes":223},{"name":"design-guidelines.md","path":"content/manuals/extensions/extensions-sdk/design/design-guidelines.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/design/design-guidelines.md","title":"Design Skill","category":"anthropic-skill","format":"markdown","content":"# Design Skill\n\nPath: `content/manuals/extensions/extensions-sdk/design/design-guidelines.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/design/design-guidelines.md)","tokens":300,"sizeBytes":245},{"name":"design-principles.md","path":"content/manuals/extensions/extensions-sdk/design/design-principles.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/design/design-principles.md","title":"Design Skill","category":"anthropic-skill","format":"markdown","content":"# Design Skill\n\nPath: `content/manuals/extensions/extensions-sdk/design/design-principles.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/design/design-principles.md)","tokens":300,"sizeBytes":245},{"name":"mui-best-practices.md","path":"content/manuals/extensions/extensions-sdk/design/mui-best-practices.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/design/mui-best-practices.md","title":"Design Skill","category":"anthropic-skill","format":"markdown","content":"# Design Skill\n\nPath: `content/manuals/extensions/extensions-sdk/design/mui-best-practices.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/design/mui-best-practices.md)","tokens":300,"sizeBytes":247},{"name":"_index.md","path":"content/manuals/extensions/extensions-sdk/dev/_index.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/dev/_index.md","title":"Dev Skill","category":"anthropic-skill","format":"markdown","content":"# Dev Skill\n\nPath: `content/manuals/extensions/extensions-sdk/dev/_index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/dev/_index.md)","tokens":300,"sizeBytes":214},{"name":"_index.md","path":"content/manuals/extensions/extensions-sdk/dev/api/_index.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/dev/api/_index.md","title":"Api Skill","category":"anthropic-skill","format":"markdown","content":"# Api Skill\n\nPath: `content/manuals/extensions/extensions-sdk/dev/api/_index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/dev/api/_index.md)","tokens":300,"sizeBytes":222},{"name":"backend.md","path":"content/manuals/extensions/extensions-sdk/dev/api/backend.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/dev/api/backend.md","title":"Api Skill","category":"anthropic-skill","format":"markdown","content":"# Api Skill\n\nPath: `content/manuals/extensions/extensions-sdk/dev/api/backend.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/dev/api/backend.md)","tokens":300,"sizeBytes":224},{"name":"dashboard-routes-navigation.md","path":"content/manuals/extensions/extensions-sdk/dev/api/dashboard-routes-navigation.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/dev/api/dashboard-routes-navigation.md","title":"Api Skill","category":"anthropic-skill","format":"markdown","content":"# Api Skill\n\nPath: `content/manuals/extensions/extensions-sdk/dev/api/dashboard-routes-navigation.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/dev/api/dashboard-routes-navigation.md)","tokens":300,"sizeBytes":264},{"name":"dashboard.md","path":"content/manuals/extensions/extensions-sdk/dev/api/dashboard.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/dev/api/dashboard.md","title":"Api Skill","category":"anthropic-skill","format":"markdown","content":"# Api Skill\n\nPath: `content/manuals/extensions/extensions-sdk/dev/api/dashboard.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/dev/api/dashboard.md)","tokens":300,"sizeBytes":228},{"name":"docker.md","path":"content/manuals/extensions/extensions-sdk/dev/api/docker.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/dev/api/docker.md","title":"Api Skill","category":"anthropic-skill","format":"markdown","content":"# Api Skill\n\nPath: `content/manuals/extensions/extensions-sdk/dev/api/docker.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/dev/api/docker.md)","tokens":300,"sizeBytes":222},{"name":"overview.md","path":"content/manuals/extensions/extensions-sdk/dev/api/overview.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/dev/api/overview.md","title":"Api Skill","category":"anthropic-skill","format":"markdown","content":"# Api Skill\n\nPath: `content/manuals/extensions/extensions-sdk/dev/api/overview.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/dev/api/overview.md)","tokens":300,"sizeBytes":226},{"name":"continuous-integration.md","path":"content/manuals/extensions/extensions-sdk/dev/continuous-integration.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/dev/continuous-integration.md","title":"Dev Skill","category":"anthropic-skill","format":"markdown","content":"# Dev Skill\n\nPath: `content/manuals/extensions/extensions-sdk/dev/continuous-integration.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/dev/continuous-integration.md)","tokens":300,"sizeBytes":246},{"name":"test-debug.md","path":"content/manuals/extensions/extensions-sdk/dev/test-debug.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/dev/test-debug.md","title":"Dev Skill","category":"anthropic-skill","format":"markdown","content":"# Dev Skill\n\nPath: `content/manuals/extensions/extensions-sdk/dev/test-debug.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/dev/test-debug.md)","tokens":300,"sizeBytes":222},{"name":"usage.md","path":"content/manuals/extensions/extensions-sdk/dev/usage.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/dev/usage.md","title":"Dev Skill","category":"anthropic-skill","format":"markdown","content":"# Dev Skill\n\nPath: `content/manuals/extensions/extensions-sdk/dev/usage.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/dev/usage.md)","tokens":300,"sizeBytes":212},{"name":"_index.md","path":"content/manuals/extensions/extensions-sdk/extensions/_index.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/extensions/_index.md","title":"Extensions Skill","category":"anthropic-skill","format":"markdown","content":"# Extensions Skill\n\nPath: `content/manuals/extensions/extensions-sdk/extensions/_index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/extensions/_index.md)","tokens":300,"sizeBytes":235},{"name":"DISTRIBUTION.md","path":"content/manuals/extensions/extensions-sdk/extensions/DISTRIBUTION.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/extensions/DISTRIBUTION.md","title":"Extensions Skill","category":"anthropic-skill","format":"markdown","content":"# Extensions Skill\n\nPath: `content/manuals/extensions/extensions-sdk/extensions/DISTRIBUTION.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/extensions/DISTRIBUTION.md)","tokens":300,"sizeBytes":247},{"name":"labels.md","path":"content/manuals/extensions/extensions-sdk/extensions/labels.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/extensions/labels.md","title":"Extensions Skill","category":"anthropic-skill","format":"markdown","content":"# Extensions Skill\n\nPath: `content/manuals/extensions/extensions-sdk/extensions/labels.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/extensions/labels.md)","tokens":300,"sizeBytes":235},{"name":"multi-arch.md","path":"content/manuals/extensions/extensions-sdk/extensions/multi-arch.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/extensions/multi-arch.md","title":"Extensions Skill","category":"anthropic-skill","format":"markdown","content":"# Extensions Skill\n\nPath: `content/manuals/extensions/extensions-sdk/extensions/multi-arch.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/extensions/multi-arch.md)","tokens":300,"sizeBytes":243},{"name":"publish.md","path":"content/manuals/extensions/extensions-sdk/extensions/publish.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/extensions/publish.md","title":"Extensions Skill","category":"anthropic-skill","format":"markdown","content":"# Extensions Skill\n\nPath: `content/manuals/extensions/extensions-sdk/extensions/publish.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/extensions/publish.md)","tokens":300,"sizeBytes":237},{"name":"share.md","path":"content/manuals/extensions/extensions-sdk/extensions/share.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/extensions/share.md","title":"Extensions Skill","category":"anthropic-skill","format":"markdown","content":"# Extensions Skill\n\nPath: `content/manuals/extensions/extensions-sdk/extensions/share.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/extensions/share.md)","tokens":300,"sizeBytes":233},{"name":"validate.md","path":"content/manuals/extensions/extensions-sdk/extensions/validate.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/extensions/validate.md","title":"Extensions Skill","category":"anthropic-skill","format":"markdown","content":"# Extensions Skill\n\nPath: `content/manuals/extensions/extensions-sdk/extensions/validate.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/extensions/validate.md)","tokens":300,"sizeBytes":239},{"name":"_index.md","path":"content/manuals/extensions/extensions-sdk/guides/_index.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/guides/_index.md","title":"Guides Skill","category":"anthropic-skill","format":"markdown","content":"# Guides Skill\n\nPath: `content/manuals/extensions/extensions-sdk/guides/_index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/guides/_index.md)","tokens":300,"sizeBytes":223},{"name":"invoke-host-binaries.md","path":"content/manuals/extensions/extensions-sdk/guides/invoke-host-binaries.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/guides/invoke-host-binaries.md","title":"Guides Skill","category":"anthropic-skill","format":"markdown","content":"# Guides Skill\n\nPath: `content/manuals/extensions/extensions-sdk/guides/invoke-host-binaries.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/guides/invoke-host-binaries.md)","tokens":300,"sizeBytes":251},{"name":"kubernetes.md","path":"content/manuals/extensions/extensions-sdk/guides/kubernetes.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/guides/kubernetes.md","title":"Guides Skill","category":"anthropic-skill","format":"markdown","content":"# Guides Skill\n\nPath: `content/manuals/extensions/extensions-sdk/guides/kubernetes.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/guides/kubernetes.md)","tokens":300,"sizeBytes":231},{"name":"oauth2-flow.md","path":"content/manuals/extensions/extensions-sdk/guides/oauth2-flow.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/guides/oauth2-flow.md","title":"Guides Skill","category":"anthropic-skill","format":"markdown","content":"# Guides Skill\n\nPath: `content/manuals/extensions/extensions-sdk/guides/oauth2-flow.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/guides/oauth2-flow.md)","tokens":300,"sizeBytes":233},{"name":"use-docker-socket-from-backend.md","path":"content/manuals/extensions/extensions-sdk/guides/use-docker-socket-from-backend.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/guides/use-docker-socket-from-backend.md","title":"Guides Skill","category":"anthropic-skill","format":"markdown","content":"# Guides Skill\n\nPath: `content/manuals/extensions/extensions-sdk/guides/use-docker-socket-from-backend.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/guides/use-docker-socket-from-backend.md)","tokens":300,"sizeBytes":271},{"name":"process.md","path":"content/manuals/extensions/extensions-sdk/process.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/process.md","title":"Extensions-sdk Skill","category":"anthropic-skill","format":"markdown","content":"# Extensions-sdk Skill\n\nPath: `content/manuals/extensions/extensions-sdk/process.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/process.md)","tokens":300,"sizeBytes":219},{"name":"quickstart.md","path":"content/manuals/extensions/extensions-sdk/quickstart.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/quickstart.md","title":"Extensions-sdk Skill","category":"anthropic-skill","format":"markdown","content":"# Extensions-sdk Skill\n\nPath: `content/manuals/extensions/extensions-sdk/quickstart.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/extensions-sdk/quickstart.md)","tokens":300,"sizeBytes":225},{"name":"marketplace.md","path":"content/manuals/extensions/marketplace.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/marketplace.md","title":"Extensions Skill","category":"anthropic-skill","format":"markdown","content":"# Extensions Skill\n\nPath: `content/manuals/extensions/marketplace.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/marketplace.md)","tokens":300,"sizeBytes":193},{"name":"non-marketplace.md","path":"content/manuals/extensions/non-marketplace.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/non-marketplace.md","title":"Extensions Skill","category":"anthropic-skill","format":"markdown","content":"# Extensions Skill\n\nPath: `content/manuals/extensions/non-marketplace.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/non-marketplace.md)","tokens":300,"sizeBytes":201},{"name":"private-marketplace.md","path":"content/manuals/extensions/private-marketplace.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/private-marketplace.md","title":"Extensions Skill","category":"anthropic-skill","format":"markdown","content":"# Extensions Skill\n\nPath: `content/manuals/extensions/private-marketplace.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/private-marketplace.md)","tokens":300,"sizeBytes":209},{"name":"settings-feedback.md","path":"content/manuals/extensions/settings-feedback.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/settings-feedback.md","title":"Extensions Skill","category":"anthropic-skill","format":"markdown","content":"# Extensions Skill\n\nPath: `content/manuals/extensions/settings-feedback.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/extensions/settings-feedback.md)","tokens":300,"sizeBytes":205},{"name":"CLAUDE.md","path":"CLAUDE.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/CLAUDE.md","title":"Claude Agent Guidelines & System Prompt","category":"claude-rule","format":"markdown","content":"# Claude Agent Guidelines & System Prompt\n\nPath: `CLAUDE.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/CLAUDE.md)","tokens":300,"sizeBytes":152},{"name":"index.md","path":"_vendor/github.com/docker/docker-agent/docs/concepts/agents/index.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/concepts/agents/index.md","title":"Subagent: index","category":"subagent-persona","format":"markdown","content":"# Subagent: index\n\nPath: `_vendor/github.com/docker/docker-agent/docs/concepts/agents/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/concepts/agents/index.md)","tokens":300,"sizeBytes":246},{"name":"index.md","path":"_vendor/github.com/docker/docker-agent/docs/configuration/agents/index.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/configuration/agents/index.md","title":"Subagent: index","category":"subagent-persona","format":"markdown","content":"# Subagent: index\n\nPath: `_vendor/github.com/docker/docker-agent/docs/configuration/agents/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/configuration/agents/index.md)","tokens":300,"sizeBytes":256},{"name":"index.md","path":"_vendor/github.com/docker/docker-agent/docs/configuration/commands/index.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/configuration/commands/index.md","title":"Command: /index","category":"command-prompt","format":"markdown","content":"# Command: /index\n\nPath: `_vendor/github.com/docker/docker-agent/docs/configuration/commands/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/configuration/commands/index.md)","tokens":300,"sizeBytes":260},{"name":"_index.md","path":"content/manuals/ai/sandboxes/agents/_index.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/ai/sandboxes/agents/_index.md","title":"Subagent: index","category":"subagent-persona","format":"markdown","content":"# Subagent: index\n\nPath: `content/manuals/ai/sandboxes/agents/_index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/ai/sandboxes/agents/_index.md)","tokens":300,"sizeBytes":200},{"name":"claude-code.md","path":"content/manuals/ai/sandboxes/agents/claude-code.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/ai/sandboxes/agents/claude-code.md","title":"Subagent: claude-code","category":"subagent-persona","format":"markdown","content":"# Subagent: claude-code\n\nPath: `content/manuals/ai/sandboxes/agents/claude-code.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/ai/sandboxes/agents/claude-code.md)","tokens":300,"sizeBytes":216},{"name":"codex.md","path":"content/manuals/ai/sandboxes/agents/codex.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/ai/sandboxes/agents/codex.md","title":"Subagent: codex","category":"subagent-persona","format":"markdown","content":"# Subagent: codex\n\nPath: `content/manuals/ai/sandboxes/agents/codex.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/ai/sandboxes/agents/codex.md)","tokens":300,"sizeBytes":198},{"name":"copilot.md","path":"content/manuals/ai/sandboxes/agents/copilot.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/ai/sandboxes/agents/copilot.md","title":"Subagent: copilot","category":"subagent-persona","format":"markdown","content":"# Subagent: copilot\n\nPath: `content/manuals/ai/sandboxes/agents/copilot.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/ai/sandboxes/agents/copilot.md)","tokens":300,"sizeBytes":204},{"name":"cursor.md","path":"content/manuals/ai/sandboxes/agents/cursor.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/ai/sandboxes/agents/cursor.md","title":"Subagent: cursor","category":"subagent-persona","format":"markdown","content":"# Subagent: cursor\n\nPath: `content/manuals/ai/sandboxes/agents/cursor.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/ai/sandboxes/agents/cursor.md)","tokens":300,"sizeBytes":201},{"name":"devin.md","path":"content/manuals/ai/sandboxes/agents/devin.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/ai/sandboxes/agents/devin.md","title":"Subagent: devin","category":"subagent-persona","format":"markdown","content":"# Subagent: devin\n\nPath: `content/manuals/ai/sandboxes/agents/devin.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/ai/sandboxes/agents/devin.md)","tokens":300,"sizeBytes":198},{"name":"docker-agent.md","path":"content/manuals/ai/sandboxes/agents/docker-agent.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/ai/sandboxes/agents/docker-agent.md","title":"Subagent: docker-agent","category":"subagent-persona","format":"markdown","content":"# Subagent: docker-agent\n\nPath: `content/manuals/ai/sandboxes/agents/docker-agent.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/ai/sandboxes/agents/docker-agent.md)","tokens":300,"sizeBytes":219},{"name":"droid.md","path":"content/manuals/ai/sandboxes/agents/droid.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/ai/sandboxes/agents/droid.md","title":"Subagent: droid","category":"subagent-persona","format":"markdown","content":"# Subagent: droid\n\nPath: `content/manuals/ai/sandboxes/agents/droid.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/ai/sandboxes/agents/droid.md)","tokens":300,"sizeBytes":198},{"name":"gemini.md","path":"content/manuals/ai/sandboxes/agents/gemini.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/ai/sandboxes/agents/gemini.md","title":"Subagent: gemini","category":"subagent-persona","format":"markdown","content":"# Subagent: gemini\n\nPath: `content/manuals/ai/sandboxes/agents/gemini.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/ai/sandboxes/agents/gemini.md)","tokens":300,"sizeBytes":201},{"name":"kiro.md","path":"content/manuals/ai/sandboxes/agents/kiro.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/ai/sandboxes/agents/kiro.md","title":"Subagent: kiro","category":"subagent-persona","format":"markdown","content":"# Subagent: kiro\n\nPath: `content/manuals/ai/sandboxes/agents/kiro.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/ai/sandboxes/agents/kiro.md)","tokens":300,"sizeBytes":195},{"name":"opencode.md","path":"content/manuals/ai/sandboxes/agents/opencode.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/ai/sandboxes/agents/opencode.md","title":"Subagent: opencode","category":"subagent-persona","format":"markdown","content":"# Subagent: opencode\n\nPath: `content/manuals/ai/sandboxes/agents/opencode.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/ai/sandboxes/agents/opencode.md)","tokens":300,"sizeBytes":207},{"name":"shell.md","path":"content/manuals/ai/sandboxes/agents/shell.md","rawUrl":"https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/ai/sandboxes/agents/shell.md","title":"Subagent: shell","category":"subagent-persona","format":"markdown","content":"# Subagent: shell\n\nPath: `content/manuals/ai/sandboxes/agents/shell.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/content/manuals/ai/sandboxes/agents/shell.md)","tokens":300,"sizeBytes":198},{"name":".cursorrules","path":".cursorrules (kubernetes-mkdocs-documentation-cursorrules-prompt.mdc)","rawUrl":"https://raw.githubusercontent.com/PatrickJS/awesome-cursorrules/main/rules/kubernetes-mkdocs-documentation-cursorrules-prompt.mdc","title":"Awesome Cursorrules: kubernetes mkdocs documentation cursorrules prompt","category":"cursor-rule","format":"markdown","content":"---\ndescription: \"Cursor rules for Kubernetes development with MkDocs documentation integration.\"\nglobs: **/*\nalwaysApply: false\n---\nYou are an expert Technical Writer with a deep understanding of cloud native technologies, Kubernetes, and technical documentation best practices. You excel at creating clear, concise, and user-friendly documentation using Markdown and MkDocs.\n\nYou always use the latest stable versions of Kubernetes, cloud native tools, and MkDocs. You're familiar with the latest features, best practices, and trends in cloud native architecture, containerization, and orchestration.\n\nDocumentation Style and Structure:\n\nCloud Native and Kubernetes Expertise:\n\nMkDocs Usage:\n\nContent Creation:\n\nTechnical Accuracy and Usability:\n\nDocumentation Best Practices:\n\nMetadata and SEO:\n\nCollaboration and Version Control:\n\nOther Rules to follow:\n\nDon't be lazy, provide thorough and accurate documentation for all requested topics and features.\n","tokens":173,"sizeBytes":957}],"systemPromptSnippet":"<yakaai_skills repo=\"docker/docs\">\n<!-- File: AGENTS.md (Tokens: ~300 | Category: root-instruction) -->\n# AI Agent Protocol & Instructions\n\nPath: `AGENTS.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/AGENTS.md)\n\n<!-- File: _vendor/github.com/docker/docker-agent/docs/concepts/tools/index.md (Tokens: ~300 | Category: anthropic-skill) -->\n# Tools Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/concepts/tools/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/concepts/tools/index.md)\n\n<!-- File: _vendor/github.com/docker/docker-agent/docs/configuration/tools/index.md (Tokens: ~300 | Category: anthropic-skill) -->\n# Tools Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/configuration/tools/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/configuration/tools/index.md)\n\n<!-- File: _vendor/github.com/docker/docker-agent/docs/features/skills/index.md (Tokens: ~300 | Category: anthropic-skill) -->\n# Skills Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/features/skills/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/features/skills/index.md)\n\n<!-- File: _vendor/github.com/docker/docker-agent/docs/tools/_index.md (Tokens: ~300 | Category: anthropic-skill) -->\n# Tools Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/_index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/_index.md)\n\n<!-- File: _vendor/github.com/docker/docker-agent/docs/tools/a2a/index.md (Tokens: ~300 | Category: anthropic-skill) -->\n# A2a Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/a2a/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/a2a/index.md)\n\n<!-- File: _vendor/github.com/docker/docker-agent/docs/tools/api/index.md (Tokens: ~300 | Category: anthropic-skill) -->\n# Api Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/api/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/api/index.md)\n\n<!-- File: _vendor/github.com/docker/docker-agent/docs/tools/background-agents/index.md (Tokens: ~300 | Category: anthropic-skill) -->\n# Background-agents Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/background-agents/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/background-agents/index.md)\n\n<!-- File: _vendor/github.com/docker/docker-agent/docs/tools/background-jobs/index.md (Tokens: ~300 | Category: anthropic-skill) -->\n# Background-jobs Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/background-jobs/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/background-jobs/index.md)\n\n<!-- File: _vendor/github.com/docker/docker-agent/docs/tools/fetch/index.md (Tokens: ~300 | Category: anthropic-skill) -->\n# Fetch Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/fetch/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/fetch/index.md)\n\n<!-- File: _vendor/github.com/docker/docker-agent/docs/tools/filesystem/index.md (Tokens: ~300 | Category: anthropic-skill) -->\n# Filesystem Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/filesystem/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/filesystem/index.md)\n\n<!-- File: _vendor/github.com/docker/docker-agent/docs/tools/git/index.md (Tokens: ~300 | Category: anthropic-skill) -->\n# Git Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/git/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/git/index.md)\n\n<!-- File: _vendor/github.com/docker/docker-agent/docs/tools/handoff/index.md (Tokens: ~300 | Category: anthropic-skill) -->\n# Handoff Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/handoff/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/handoff/index.md)\n\n<!-- File: _vendor/github.com/docker/docker-agent/docs/tools/lsp/index.md (Tokens: ~300 | Category: anthropic-skill) -->\n# Lsp Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/lsp/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/lsp/index.md)\n\n<!-- File: _vendor/github.com/docker/docker-agent/docs/tools/mcp-catalog/index.md (Tokens: ~300 | Category: anthropic-skill) -->\n# Mcp-catalog Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/mcp-catalog/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/mcp-catalog/index.md)\n\n<!-- File: _vendor/github.com/docker/docker-agent/docs/tools/mcp/index.md (Tokens: ~300 | Category: anthropic-skill) -->\n# Mcp Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/mcp/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/mcp/index.md)\n\n<!-- File: _vendor/github.com/docker/docker-agent/docs/tools/memory/index.md (Tokens: ~300 | Category: anthropic-skill) -->\n# Memory Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/memory/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/memory/index.md)\n\n<!-- File: _vendor/github.com/docker/docker-agent/docs/tools/model-picker/index.md (Tokens: ~300 | Category: anthropic-skill) -->\n# Model-picker Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/model-picker/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/model-picker/index.md)\n\n<!-- File: _vendor/github.com/docker/docker-agent/docs/tools/open-url/index.md (Tokens: ~300 | Category: anthropic-skill) -->\n# Open-url Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/open-url/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/open-url/index.md)\n\n<!-- File: _vendor/github.com/docker/docker-agent/docs/tools/openapi/index.md (Tokens: ~300 | Category: anthropic-skill) -->\n# Openapi Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/openapi/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/openapi/index.md)\n\n<!-- File: _vendor/github.com/docker/docker-agent/docs/tools/plan/index.md (Tokens: ~300 | Category: anthropic-skill) -->\n# Plan Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/plan/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/plan/index.md)\n\n<!-- File: _vendor/github.com/docker/docker-agent/docs/tools/rag/index.md (Tokens: ~300 | Category: anthropic-skill) -->\n# Rag Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/rag/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/rag/index.md)\n\n<!-- File: _vendor/github.com/docker/docker-agent/docs/tools/scheduler/index.md (Tokens: ~300 | Category: anthropic-skill) -->\n# Scheduler Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/scheduler/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/scheduler/index.md)\n\n<!-- File: _vendor/github.com/docker/docker-agent/docs/tools/script/index.md (Tokens: ~300 | Category: anthropic-skill) -->\n# Script Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/script/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/script/index.md)\n\n<!-- File: _vendor/github.com/docker/docker-agent/docs/tools/session_context/index.md (Tokens: ~300 | Category: anthropic-skill) -->\n# Session_context Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/session_context/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/session_context/index.md)\n\n<!-- File: _vendor/github.com/docker/docker-agent/docs/tools/session_plan/index.md (Tokens: ~300 | Category: anthropic-skill) -->\n# Session_plan Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/session_plan/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/session_plan/index.md)\n\n<!-- File: _vendor/github.com/docker/docker-agent/docs/tools/shell/index.md (Tokens: ~300 | Category: anthropic-skill) -->\n# Shell Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/shell/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/shell/index.md)\n\n<!-- File: _vendor/github.com/docker/docker-agent/docs/tools/tasks/index.md (Tokens: ~300 | Category: anthropic-skill) -->\n# Tasks Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/tasks/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/tasks/index.md)\n\n<!-- File: _vendor/github.com/docker/docker-agent/docs/tools/think/index.md (Tokens: ~300 | Category: anthropic-skill) -->\n# Think Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/think/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/think/index.md)\n\n<!-- File: _vendor/github.com/docker/docker-agent/docs/tools/todo/index.md (Tokens: ~300 | Category: anthropic-skill) -->\n# Todo Skill\n\nPath: `_vendor/github.com/docker/docker-agent/docs/tools/todo/index.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docker/docs/HEAD/_vendor/github.com/docker/docker-agent/docs/tools/todo/index.md)\n\n<!-- ... +110 more modular skills available via /api/skills/docker/docs?path={path} -->\n</yakaai_skills>"}