@olegkoval/agent-skills 1.22.0 → 1.24.0

package/packages/software-development/pr-description-writer/adapters/claude/skills/pr-description-writer/SKILL.md

@@ -0,0 +1,153 @@
+---
+name: pr-description-writer
+description: >
+  Draft and post a GitHub PR title and body from git diff and commit history. Use when
+  opening a new PR, when the user asks to "write a PR description", "draft a PR", "open
+  a PR for this branch", or after running the git-commit skill and pushing the branch.
+  Chains naturally after git-commit and before qodoloop / coderabbitloop.
+license: MIT
+allowed-tools: Bash, Read, Write
+compatibility: Codex, Claude Code, Cursor, GitHub Copilot, Windsurf, Kiro, and other Agent Skills compatible tools. Requires git and gh (GitHub CLI) authenticated.
+metadata:
+  targets: [_source-only]
+  author: Oleg Koval
+  tags:
+    - git
+    - github
+    - pull-request
+    - description
+    - pr
+    - workflow
+source: weekly-pattern-learner
+source_reason: "qodoloop and coderabbitloop both open with gh pr view — the PR creation/description step was never codified as its own skill"
+source_date: "2026-07-28"
+---
+<!-- Generated by scripts/build-adapters.sh. Do not edit directly. -->
+
+> 🤖 *Auto-generated by **weekly-pattern-learner** · qodoloop and coderabbitloop both open with `gh pr view` — the PR creation/description step was never codified as its own skill*
+
+# PR Description Writer
+
+Draft a GitHub-ready PR title and body from the branch's commit history and diff, then
+create or update the PR so reviewers and AI tools have full context.
+
+## Inputs
+
+- **Base branch** (optional, default: `main` or `master` — detect from `gh repo view`)
+- **Draft mode** (optional, default: off)
+- **Template** (optional): if `.github/pull_request_template.md` exists, use its section headings
+
+## Workflow
+
+### 1. Gather branch context
+
+```bash
+# Current branch
+git rev-parse --abbrev-ref HEAD
+
+# Base branch
+gh repo view --json defaultBranchRef -q '.defaultBranchRef.name'
+
+# Commits since base
+git log <base>..<head> --oneline --no-merges
+
+# Diff summary (full diff for small PRs, stat-only for large)
+git diff <base>..<head> --stat
+git diff <base>..<head>   # only if total changes < ~500 lines
+```
+
+If the diff is large (>500 changed lines), read file-by-file rather than all at once.
+
+### 2. Check for existing PR
+
+```bash
+gh pr view --json number,title,body,state 2>/dev/null
+```
+
+- If a PR exists in `OPEN` state: update it with `gh pr edit`.
+- If no PR exists: create one with `gh pr create`.
+
+### 3. Check for a PR template
+
+```bash
+cat .github/pull_request_template.md 2>/dev/null \
+  || cat .github/PULL_REQUEST_TEMPLATE.md 2>/dev/null \
+  || cat PULL_REQUEST_TEMPLATE.md 2>/dev/null
+```
+
+If a template exists, mirror its section headings and populate them. Skip sections
+that ask for credentials, tokens, internal hostnames, or content unrelated to the diff.
+
+### 4. Draft title and body
+
+**Title rules:**
+- Use Conventional Commits prefix when the branch/commits use it: `feat(scope):`, `fix:`, etc.
+- ≤ 70 characters
+- Imperative mood ("Add X", "Fix Y", not "Added X")
+- Include ticket number if present in branch name (e.g. `LIN-123`, `GH-456`)
+
+**Body sections (use the template if one was found, otherwise use this structure):**
+
+```markdown
+## Summary
+- <bullet: what changed>
+- <bullet: why>
+
+## Changes
+- `<file or subsystem>`: <what changed and why>
+
+## Test plan
+- [ ] <what to run and what result to expect>
+- [ ] <manual steps if automated tests don't cover it>
+
+## Notes
+<optional: anything a reviewer should watch for, known gaps, follow-up issues>
+```
+
+Rules:
+- Describe *intent*, not what the diff already shows line-by-line.
+- If commits already have good conventional messages, use them as the skeleton.
+- Skip any section that has nothing meaningful to say.
+- Reference specific files, functions, or lines only when they aid navigation.
+
+### 5. Create or update the PR
+
+Always pass the body via a heredoc or temp file — never interpolate it into the command
+string (quotes and newlines will break the shell):
+
+```bash
+# Create new PR
+gh pr create \
+  --title "<title>" \
+  --body "$(cat <<'PRBODY'
+<body>
+PRBODY
+)" \
+  --base <base> \
+  [--draft]
+
+# Update existing PR
+gh pr edit <number> \
+  --title "<title>" \
+  --body "$(cat <<'PRBODY'
+<body>
+PRBODY
+)"
+```
+
+### 6. Confirm and report
+
+```bash
+gh pr view --json number,title,url -q '"PR #\(.number): \(.title)\n\(.url)"'
+```
+
+Print the PR number, title, and URL. If the PR was newly created, note whether
+CI triggered automatically.
+
+## Chaining
+
+| Before this skill | After this skill |
+|---|---|
+| `olko:git-commit` + `git push` | `olko:qodoloop` |
+| `git push -u origin <branch>` | `olko:coderabbitloop` |
+| — | `olko:open-source-publisher` (for new repos) |

package/packages/software-development/pr-description-writer/adapters/codex/README.md

@@ -0,0 +1,19 @@
+# Codex Adapter for pr-description-writer
+
+This is a Codex-specific adapter for the `olko:pr-description-writer` skill.
+The canonical skill definition is in `../../SKILL.md`.
+
+## Usage
+
+Invoke in a Codex session:
+
+```text
+Use the olko:pr-description-writer skill to draft a PR description for this branch.
+```
+
+## Workflow
+
+See `../../SKILL.md` for the full workflow: gather branch context (commits since base,
+diff summary), check for an existing PR template, draft a structured title and body, then
+create or update the GitHub PR using `gh pr create` / `gh pr edit`. The procedure is
+plain `git`/`gh` and is agent-agnostic.

package/packages/software-development/pr-description-writer/adapters/cursor/plugin.json

@@ -0,0 +1,6 @@
+{
+  "name": "olko:pr-description-writer",
+  "version": "0.1.0",
+  "description": "Draft and post a GitHub PR title and body from git diff and commit history. Chains after git-commit and before qodoloop / coderabbitloop.",
+  "skills": "skills/"
+}

package/packages/software-development/pr-description-writer/adapters/cursor/skills/pr-description-writer/SKILL.md

@@ -0,0 +1,153 @@
+---
+name: pr-description-writer
+description: >
+  Draft and post a GitHub PR title and body from git diff and commit history. Use when
+  opening a new PR, when the user asks to "write a PR description", "draft a PR", "open
+  a PR for this branch", or after running the git-commit skill and pushing the branch.
+  Chains naturally after git-commit and before qodoloop / coderabbitloop.
+license: MIT
+allowed-tools: Bash, Read, Write
+compatibility: Codex, Claude Code, Cursor, GitHub Copilot, Windsurf, Kiro, and other Agent Skills compatible tools. Requires git and gh (GitHub CLI) authenticated.
+metadata:
+  targets: ["cursor"]
+  author: Oleg Koval
+  tags:
+    - git
+    - github
+    - pull-request
+    - description
+    - pr
+    - workflow
+source: weekly-pattern-learner
+source_reason: "qodoloop and coderabbitloop both open with gh pr view — the PR creation/description step was never codified as its own skill"
+source_date: "2026-07-28"
+---
+<!-- Generated by scripts/build-adapters.sh. Do not edit directly. -->
+
+> 🤖 *Auto-generated by **weekly-pattern-learner** · qodoloop and coderabbitloop both open with `gh pr view` — the PR creation/description step was never codified as its own skill*
+
+# PR Description Writer
+
+Draft a GitHub-ready PR title and body from the branch's commit history and diff, then
+create or update the PR so reviewers and AI tools have full context.
+
+## Inputs
+
+- **Base branch** (optional, default: `main` or `master` — detect from `gh repo view`)
+- **Draft mode** (optional, default: off)
+- **Template** (optional): if `.github/pull_request_template.md` exists, use its section headings
+
+## Workflow
+
+### 1. Gather branch context
+
+```bash
+# Current branch
+git rev-parse --abbrev-ref HEAD
+
+# Base branch
+gh repo view --json defaultBranchRef -q '.defaultBranchRef.name'
+
+# Commits since base
+git log <base>..<head> --oneline --no-merges
+
+# Diff summary (full diff for small PRs, stat-only for large)
+git diff <base>..<head> --stat
+git diff <base>..<head>   # only if total changes < ~500 lines
+```
+
+If the diff is large (>500 changed lines), read file-by-file rather than all at once.
+
+### 2. Check for existing PR
+
+```bash
+gh pr view --json number,title,body,state 2>/dev/null
+```
+
+- If a PR exists in `OPEN` state: update it with `gh pr edit`.
+- If no PR exists: create one with `gh pr create`.
+
+### 3. Check for a PR template
+
+```bash
+cat .github/pull_request_template.md 2>/dev/null \
+  || cat .github/PULL_REQUEST_TEMPLATE.md 2>/dev/null \
+  || cat PULL_REQUEST_TEMPLATE.md 2>/dev/null
+```
+
+If a template exists, mirror its section headings and populate them. Skip sections
+that ask for credentials, tokens, internal hostnames, or content unrelated to the diff.
+
+### 4. Draft title and body
+
+**Title rules:**
+- Use Conventional Commits prefix when the branch/commits use it: `feat(scope):`, `fix:`, etc.
+- ≤ 70 characters
+- Imperative mood ("Add X", "Fix Y", not "Added X")
+- Include ticket number if present in branch name (e.g. `LIN-123`, `GH-456`)
+
+**Body sections (use the template if one was found, otherwise use this structure):**
+
+```markdown
+## Summary
+- <bullet: what changed>
+- <bullet: why>
+
+## Changes
+- `<file or subsystem>`: <what changed and why>
+
+## Test plan
+- [ ] <what to run and what result to expect>
+- [ ] <manual steps if automated tests don't cover it>
+
+## Notes
+<optional: anything a reviewer should watch for, known gaps, follow-up issues>
+```
+
+Rules:
+- Describe *intent*, not what the diff already shows line-by-line.
+- If commits already have good conventional messages, use them as the skeleton.
+- Skip any section that has nothing meaningful to say.
+- Reference specific files, functions, or lines only when they aid navigation.
+
+### 5. Create or update the PR
+
+Always pass the body via a heredoc or temp file — never interpolate it into the command
+string (quotes and newlines will break the shell):
+
+```bash
+# Create new PR
+gh pr create \
+  --title "<title>" \
+  --body "$(cat <<'PRBODY'
+<body>
+PRBODY
+)" \
+  --base <base> \
+  [--draft]
+
+# Update existing PR
+gh pr edit <number> \
+  --title "<title>" \
+  --body "$(cat <<'PRBODY'
+<body>
+PRBODY
+)"
+```
+
+### 6. Confirm and report
+
+```bash
+gh pr view --json number,title,url -q '"PR #\(.number): \(.title)\n\(.url)"'
+```
+
+Print the PR number, title, and URL. If the PR was newly created, note whether
+CI triggered automatically.
+
+## Chaining
+
+| Before this skill | After this skill |
+|---|---|
+| `olko:git-commit` + `git push` | `olko:qodoloop` |
+| `git push -u origin <branch>` | `olko:coderabbitloop` |
+| — | `olko:open-source-publisher` (for new repos) |

package/packages/software-development/pr-description-writer/adapters/grok/plugin.json

@@ -0,0 +1,6 @@
+{
+  "name": "olko:pr-description-writer",
+  "version": "0.1.0",
+  "description": "Draft and post a GitHub PR title and body from git diff and commit history. Chains after git-commit and before qodoloop / coderabbitloop.",
+  "skills": "skills/"
+}

package/packages/software-development/pr-description-writer/adapters/grok/skills/pr-description-writer/SKILL.md

@@ -0,0 +1,153 @@
+---
+name: pr-description-writer
+description: >
+  Draft and post a GitHub PR title and body from git diff and commit history. Use when
+  opening a new PR, when the user asks to "write a PR description", "draft a PR", "open
+  a PR for this branch", or after running the git-commit skill and pushing the branch.
+  Chains naturally after git-commit and before qodoloop / coderabbitloop.
+license: MIT
+allowed-tools: Bash, Read, Write
+compatibility: Codex, Claude Code, Cursor, GitHub Copilot, Windsurf, Kiro, and other Agent Skills compatible tools. Requires git and gh (GitHub CLI) authenticated.
+metadata:
+  targets: [_source-only]
+  author: Oleg Koval
+  tags:
+    - git
+    - github
+    - pull-request
+    - description
+    - pr
+    - workflow
+source: weekly-pattern-learner
+source_reason: "qodoloop and coderabbitloop both open with gh pr view — the PR creation/description step was never codified as its own skill"
+source_date: "2026-07-28"
+---
+<!-- Generated by scripts/build-adapters.sh. Do not edit directly. -->
+
+> 🤖 *Auto-generated by **weekly-pattern-learner** · qodoloop and coderabbitloop both open with `gh pr view` — the PR creation/description step was never codified as its own skill*
+
+# PR Description Writer
+
+Draft a GitHub-ready PR title and body from the branch's commit history and diff, then
+create or update the PR so reviewers and AI tools have full context.
+
+## Inputs
+
+- **Base branch** (optional, default: `main` or `master` — detect from `gh repo view`)
+- **Draft mode** (optional, default: off)
+- **Template** (optional): if `.github/pull_request_template.md` exists, use its section headings
+
+## Workflow
+
+### 1. Gather branch context
+
+```bash
+# Current branch
+git rev-parse --abbrev-ref HEAD
+
+# Base branch
+gh repo view --json defaultBranchRef -q '.defaultBranchRef.name'
+
+# Commits since base
+git log <base>..<head> --oneline --no-merges
+
+# Diff summary (full diff for small PRs, stat-only for large)
+git diff <base>..<head> --stat
+git diff <base>..<head>   # only if total changes < ~500 lines
+```
+
+If the diff is large (>500 changed lines), read file-by-file rather than all at once.
+
+### 2. Check for existing PR
+
+```bash
+gh pr view --json number,title,body,state 2>/dev/null
+```
+
+- If a PR exists in `OPEN` state: update it with `gh pr edit`.
+- If no PR exists: create one with `gh pr create`.
+
+### 3. Check for a PR template
+
+```bash
+cat .github/pull_request_template.md 2>/dev/null \
+  || cat .github/PULL_REQUEST_TEMPLATE.md 2>/dev/null \
+  || cat PULL_REQUEST_TEMPLATE.md 2>/dev/null
+```
+
+If a template exists, mirror its section headings and populate them. Skip sections
+that ask for credentials, tokens, internal hostnames, or content unrelated to the diff.
+
+### 4. Draft title and body
+
+**Title rules:**
+- Use Conventional Commits prefix when the branch/commits use it: `feat(scope):`, `fix:`, etc.
+- ≤ 70 characters
+- Imperative mood ("Add X", "Fix Y", not "Added X")
+- Include ticket number if present in branch name (e.g. `LIN-123`, `GH-456`)
+
+**Body sections (use the template if one was found, otherwise use this structure):**
+
+```markdown
+## Summary
+- <bullet: what changed>
+- <bullet: why>
+
+## Changes
+- `<file or subsystem>`: <what changed and why>
+
+## Test plan
+- [ ] <what to run and what result to expect>
+- [ ] <manual steps if automated tests don't cover it>
+
+## Notes
+<optional: anything a reviewer should watch for, known gaps, follow-up issues>
+```
+
+Rules:
+- Describe *intent*, not what the diff already shows line-by-line.
+- If commits already have good conventional messages, use them as the skeleton.
+- Skip any section that has nothing meaningful to say.
+- Reference specific files, functions, or lines only when they aid navigation.
+
+### 5. Create or update the PR
+
+Always pass the body via a heredoc or temp file — never interpolate it into the command
+string (quotes and newlines will break the shell):
+
+```bash
+# Create new PR
+gh pr create \
+  --title "<title>" \
+  --body "$(cat <<'PRBODY'
+<body>
+PRBODY
+)" \
+  --base <base> \
+  [--draft]
+
+# Update existing PR
+gh pr edit <number> \
+  --title "<title>" \
+  --body "$(cat <<'PRBODY'
+<body>
+PRBODY
+)"
+```
+
+### 6. Confirm and report
+
+```bash
+gh pr view --json number,title,url -q '"PR #\(.number): \(.title)\n\(.url)"'
+```
+
+Print the PR number, title, and URL. If the PR was newly created, note whether
+CI triggered automatically.
+
+## Chaining
+
+| Before this skill | After this skill |
+|---|---|
+| `olko:git-commit` + `git push` | `olko:qodoloop` |
+| `git push -u origin <branch>` | `olko:coderabbitloop` |
+| — | `olko:open-source-publisher` (for new repos) |

package/packages/wearables/garmin-watchface/SKILL.md

@@ -25,6 +25,7 @@ looked like success first.
 | `references/simulator.md` | Screenshots, settings not applying, monkeydo hanging |
 | `references/devices.md` | Adding device support, launcher icons, API levels |
 | `references/store.md` | Publishing, listing copy, IP questions |
+| `references/publishing.md` | Driving the store portal in a browser; upload/update flow, validator rejections |
 
 ## Tools
 
@@ -37,8 +38,14 @@ Run these rather than reinventing them. All are standalone.
 <skill-dir>/scripts/ciq-capture out.png           # calibrated simulator screenshot
 <skill-dir>/scripts/ciq-capture out.png --face --size 260   # cropped + masked to the round display
 <skill-dir>/scripts/ciq-calibrate                 # re-derive the display rect if capture looks wrong
+<skill-dir>/scripts/ciq-release       # pre-submission check: package, screenshots, icon, keys, copy
 ```
 
+`<skill-dir>/scripts/ciq-release` is what you run before opening the store
+portal. Every check in it is something otherwise discovered halfway through the
+submission form -- a stale screenshot set, an icon still copied from the last
+project, or copy containing a character the description validator rejects.
+
 `<skill-dir>/scripts/ciq-capture` exists because `screencapture -R` grabs a screen *region*, not
 a window: without a frontmost check it silently photographs whatever is on top,
 and the window moves between simulator restarts. Both failure modes produce a

package/packages/wearables/garmin-watchface/adapters/claude/skills/garmin-watchface/SKILL.md

@@ -26,6 +26,7 @@ looked like success first.
 | `references/simulator.md` | Screenshots, settings not applying, monkeydo hanging |
 | `references/devices.md` | Adding device support, launcher icons, API levels |
 | `references/store.md` | Publishing, listing copy, IP questions |
+| `references/publishing.md` | Driving the store portal in a browser; upload/update flow, validator rejections |
 
 ## Tools
 
@@ -38,8 +39,14 @@ Run these rather than reinventing them. All are standalone.
 <skill-dir>/scripts/ciq-capture out.png           # calibrated simulator screenshot
 <skill-dir>/scripts/ciq-capture out.png --face --size 260   # cropped + masked to the round display
 <skill-dir>/scripts/ciq-calibrate                 # re-derive the display rect if capture looks wrong
+<skill-dir>/scripts/ciq-release       # pre-submission check: package, screenshots, icon, keys, copy
 ```
 
+`<skill-dir>/scripts/ciq-release` is what you run before opening the store
+portal. Every check in it is something otherwise discovered halfway through the
+submission form -- a stale screenshot set, an icon still copied from the last
+project, or copy containing a character the description validator rejects.
+
 `<skill-dir>/scripts/ciq-capture` exists because `screencapture -R` grabs a screen *region*, not
 a window: without a frontmost check it silently photographs whatever is on top,
 and the window moves between simulator restarts. Both failure modes produce a

package/packages/wearables/garmin-watchface/adapters/claude/skills/garmin-watchface/references/publishing.md

@@ -0,0 +1,145 @@
+# Publishing through the browser
+
+`references/store.md` covers *what* the listing needs. This covers *driving the
+portal*, which is the only way in — Garmin publishes no submission API.
+
+Run `scripts/ciq-release` before opening a browser. Everything it checks is
+something you would otherwise discover halfway through the form.
+
+## The portal is automatable
+
+The obvious conclusion is that it is not: `apps.garmin.com/developer/dashboard`
+sits behind Garmin SSO *and* Cloudflare bot protection, and a headless browser
+lands on a "Performing security verification" interstitial. That is what you see
+if you navigate cold.
+
+It works anyway, because the session is already sitting in your own browser.
+Import the cookies:
+
+```bash
+B=~/.claude/skills/gstack/browse/dist/browse
+
+$B cookie-import-browser comet --domain .garmin.com     # note the LEADING DOT
+$B goto https://apps.garmin.com/                        # host-scoped cookies
+$B cookie-import-browser comet --domain apps.garmin.com #   need you to be on
+$B goto https://sso.garmin.com/                         #   the host first
+$B cookie-import-browser comet --domain sso.garmin.com
+
+$B goto https://apps.garmin.com/developer/dashboard     # no SSO redirect
+```
+
+Three separate traps in that block:
+
+- **`garmin.com` imports nothing. `.garmin.com` imports everything.** The cookie
+  is stored under the dotted domain and the filter is an exact match, so the
+  obvious spelling silently returns `Imported 0 cookies` and looks like "not
+  logged in".
+- **Host-scoped cookies need you on that host first**, or the import refuses
+  with *"does not match current page domain"*. The `.garmin.com` set alone is
+  NOT enough to authenticate — the session only holds once
+  `apps.` and `sso.` are imported too.
+- **Substitute your browser.** `comet`, `chrome`, `brave`, `arc`, `edge`,
+  `chromium` are supported. Whichever one you actually signed into.
+
+Verify by checking the URL after `goto`: an unauthenticated session is bounced
+to `sso.garmin.com/portal/sso/...`, an authenticated one stays put.
+
+## "The Connect IQ store is currently in maintenance mode"
+
+This string is in the DOM of the dashboard and of every app page, next to
+*Upload New Version*, *Edit Details* and *Remove*. Reading the page text makes
+it look like every action is blocked.
+
+**It is pre-rendered hidden markup, not an active block.** Click the button and
+the real form loads. Do not report the store as down on the strength of a text
+dump — click first, then check for a *visible* dialog:
+
+```bash
+$B js "(function(){var o=[];document.querySelectorAll('[role=dialog],.modal').forEach(function(x){if(x.offsetParent!==null)o.push(x.innerText.slice(0,120))});return o.join('|')||'no visible modal'})()"
+```
+
+## The two-step update flow
+
+*Upload New Version* → `/apps/<uuid>/update`, which is two steps.
+
+**Step 1 — attach.** A file input and an *App Version* textbox. Publish stays
+disabled until both are set; the page shows the current version so you can pick
+the next one.
+
+```bash
+$B upload "input[type=file]" "$(pwd)/bin/<name>.iq"
+$B fill "input[id*='version'],input[name*='version']" "2.0"
+$B click "button:has-text('Upload and publish')"
+```
+
+On success the page reports **Status: Verified, Signature: Verified** and
+expands the product list — a manifest naming one product can resolve to several
+store devices (`fenix6pro` becomes fēnix 6 Pro, 6 Pro Dual Power, 6 Pro Solar
+and quatix 6).
+
+**Step 2 — details.** Title, description, What's New, images, category, contact
+email. Ends in *Submit*.
+
+The description arrives pre-filled with the copy from the PREVIOUS version.
+After a redesign it describes a face that no longer exists, and nothing prompts
+you about it. Re-paste from `docs/store/listing.md` every time.
+
+## Image slots, in DOM order
+
+There are seven `input[type=file]` elements and none of them carry a name, id
+or label. Order is the only way to tell them apart, so confirm it before
+uploading rather than trusting this table:
+
+```bash
+$B js "(function(){var f=document.querySelectorAll('input[type=file]');var o=[];f.forEach(function(x,i){var n=x,c='';for(var k=0;k<8&&n;k++){n=n.parentElement;if(n&&n.innerText.trim().length>25){c=n.innerText.replace(/\s+/g,' ').slice(0,60);break}}o.push(i+' >> '+c)});return o.join('\n')})()"
+```
+
+| # | Slot | Size | Limit |
+| --- | --- | --- | --- |
+| 0 | Hero image | **1440×720** | 2048 KB |
+| 1 | Cover image | **500×500** | 300 KB |
+| 2–6 | Screen images | any | **150 KB each** |
+
+Getting the order wrong puts a 260px screenshot where the hero belongs, and the
+form accepts it.
+
+## The description validator
+
+Two rejections, both discovered only after filling the entire form and pressing
+Submit:
+
+- `Illegal characters found: <, >.` — an ASCII `->` arrow is enough to trip it.
+- `The app description is invalid. It should not contain emojis.` — **U+2699
+  GEAR counts**, which is exactly the character you reach for when writing
+  "tap the gear icon". U+2192 RIGHTWARDS ARROW passes today but lives in the
+  same symbol space.
+
+Write settings paths in words: *"Garmin Connect app, then: your device, Connect
+IQ Apps, Watch Faces, the app name, settings"*. `scripts/ciq-release` checks the fenced
+blocks of `listing.md` for both classes before you open a browser.
+
+The error text renders as a leaf node with no `aria-invalid` anywhere, so find
+it by scanning for childless visible elements rather than by form state:
+
+```bash
+$B js "(function(){var o=[];document.querySelectorAll('*').forEach(function(x){if(!x.children.length&&x.offsetParent!==null&&/invalid|illegal/i.test(x.innerText))o.push(x.innerText.trim())});return Array.from(new Set(o)).join(' || ')})()"
+```
+
+Success is a redirect to `apps.garmin.com/apps/<uuid>`. Staying on `/update`
+means a validation failure.
+
+## Things not to click
+
+**Remove** sits between *Edit Details* and *Download* in the same button row.
+Never target buttons by index in that row.
+
+**Upload and publish** and **Submit** are outward-facing: they push to a public
+listing and accept the Developer License Agreement on the account holder's
+behalf. Confirm with the human before either, even when they have asked for the
+release — version number and stale copy are both worth one question.
+
+## Account state
+
+A developer account pending identity verification can still upload; approval
+gates public visibility, not submission. A newly submitted app sits in preview
+mode, visible only to its owner, for up to three days.