docs: tighten branch and remote handling in create-pr skill

- Guard against running on the default branch (main/master)
- Use git status --porcelain to catch staged/unstaged changes, not
  just unstaged ones
- Handle the case where origin is upstream docker/docs by pushing to a
  separate fork remote, and derive FORK_OWNER from that remote
- Note the docs:/scope title prefix convention

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Author: dvdksn

.agents/skills/create-pr/SKILL.md

@@ -12,23 +12,41 @@ Push the branch and create a properly structured pull request.
 
 ## 1. Verify the branch
 
+Confirm you're on a dedicated branch, not the default branch:
+
+```bash
+git branch --show-current   # must not be main or master
+```
+
+If this returns `main` or `master`, stop. Create a branch and move your
+commits onto it before continuing.
+
+Confirm commits exist and the working tree is clean:
+
 ```bash
 git log --oneline main..HEAD   # confirm commits exist
-git diff --quiet               # confirm no unstaged changes
+git status --porcelain         # must print nothing
 ```
 
+If `git status --porcelain` prints anything, there are uncommitted or
+unstaged changes. Stop and commit them — or unstage stray files like
+`package-lock.json` — before opening a PR. Don't open a PR mid-edit.
+
 ## 2. Push the branch
 
-Confirm origin points to your fork, not upstream:
+Identify the remote that points at your fork. Inspect the remotes:
 
 ```bash
-git remote get-url origin
+git remote -v
 ```
 
-Then push:
+If `origin` is your fork, use it. If `origin` points at canonical
+`docker/docs` (the upstream), push to your separate fork remote instead —
+never push the branch to `docker/docs` directly:
 
 ```bash
-git push -u origin <branch-name>
+FORK_REMOTE=origin   # or the name of your fork remote if origin is upstream
+git push -u "$FORK_REMOTE" <branch-name>
 ```
 
 ## 3. Create the PR
@@ -46,10 +64,10 @@ 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:
+Derive the fork owner dynamically from the same fork remote you pushed to:
 
 ```bash
-FORK_OWNER=$(git remote get-url origin | sed -E 's|.*[:/]([^/]+)/[^/]+(\.git)?$|\1|')
+FORK_OWNER=$(git remote get-url "$FORK_REMOTE" | sed -E 's|.*[:/]([^/]+)/[^/]+(\.git)?$|\1|')
 ```
 
 ```bash
@@ -68,6 +86,10 @@ EOF
 )"
 ```
 
+Prefix the title with the change type to match repo convention — `docs:` for
+documentation changes (or another scope like `hub:` when appropriate), for
+example `docs: fix broken link on install page`.
+
 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.