// 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".
Write a documentation fix on a branch. Makes the minimal change, formats, self-reviews, and commits. Use after research has identified what to change. "write the fix", "make the changes", "implement the fix for #1234".
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.
Analyze a single GitHub issue for docker/docs — check whether the problem still exists, determine a verdict, and report findings. Use when asked to triage, assess, or review an issue, even if the user doesn't say "triage" explicitly: "triage issue 1234", "is issue 500 still valid", "should we close #200", "look at this issue", "what's going on with #200".
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.
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".
Check a single PR's CI status, review comments, and requested changes. Fix actionable failures and address feedback. "check PR 1234", "what's the status of my PR", "address review comments on #500".
| 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". |
Push the branch and create a properly structured pull request.
git log --oneline main..HEAD # confirm commits exist
git diff --quiet # confirm no unstaged changes
Confirm origin points to your fork, not upstream:
git remote get-url origin
Then push:
git push -u origin <branch-name>
Before creating a PR for an issue, check whether that issue already has an open linked PR:
gh api repos/docker/docs/issues/<issue-number>/timeline --paginate \
--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}'
If this returns an open PR that addresses the same issue, stop. Don't open a duplicate PR; report the existing PR instead. Only proceed if there is no open linked PR, or if the existing PR clearly does not address the issue and you explain why in the new PR body.
Derive the fork owner dynamically:
FORK_OWNER=$(git remote get-url origin | sed -E 's|.*[:/]([^/]+)/[^/]+(\.git)?$|\1|')
gh pr create --repo docker/docs \
--head "${FORK_OWNER}:<branch-name>" \
--title "<concise summary under 70 chars>" \
--body "$(cat <<'EOF'
## Summary
<1-2 sentences: what was wrong and what was changed>
Closes #NNNN
Generated by <active coding agent name>
EOF
)"
Keep the body short. Reviewers need to know what changed and why — nothing else. Do not add a "Test plan" section — documentation PRs don't need one.
Use an accurate disclosure footer that names the active coding agent, for
example Generated by Codex or Generated by Claude Code.
If while working on this PR you discovered something non-obvious about the repo — a convention not documented in AGENTS.md, a gotcha that tripped you up, a pattern that should be codified — add a Learnings section to the PR body:
## Learnings
- <what you learned and why it matters>
Add this section between the Summary and the Closes line. Only include
learnings that would help future contributors avoid the same issue. Do not
include things already documented in AGENTS.md or STYLE.md.
The weekly PR learnings scanner reads these sections to surface recurring patterns for the team to codify.
Use the Issues API for labels — gh pr edit --add-label silently fails:
gh api repos/docker/docs/issues/<pr-number>/labels \
--method POST \
--field 'labels[]=status/review'
Request review:
gh pr edit <pr-number> --repo docker/docs --add-reviewer docker/docs-team
Verify the reviewer was assigned:
gh pr view <pr-number> --repo docker/docs --json reviewRequests \
--jq '.reviewRequests[].slug'
If the team doesn't appear, use the API directly:
gh api repos/docker/docs/pulls/<pr-number>/requested_reviewers \
--method POST --field 'team_reviewers[]=docs-team'
Print the PR URL and current CI state:
gh pr view <pr-number> --repo docker/docs --json url,state
gh pr checks <pr-number> --repo docker/docs --json name,state
Closes #NNNN (not "Fixes") for GitHub auto-close linkage