メニュー
Log a release from a repo's changelog and optionally finalize the included tickets across backends
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
Capability discovery — the canonical answer to 'what can you do?' and 'what do I say to ...?'
Close skill — draft resolution comment, sync backends, redirect to next task
Start skill — begin task with optional backend sync
End-of-day wrap-up skill — daily summary and status update
Morning brief skill — prioritized daily summary
Reconcile skill — detect wiki/backend drift and let the User resolve it via four moves
SOC 職業分類に基づく
| name | release |
| description | Log a release from a repo's changelog and optionally finalize the included tickets across backends |
| risk_class | hard |
| confirm_action | release.finalize |
Log a release from a repository's changelog, write a release section to the repo's wiki page, and offer to finalize (close) the included tickets across every backend the workspace is connected to.
Trigger on any of:
/release <repo-name> — latest version from the changelog/release <repo-name> <version> — a specific version$ARGUMENTS — the repo name (matches wiki/repos/<name>.md) and an
optional version. Examples: storefront-web, storefront-web 1.38.0.
Parse the argument into <repo-name> and optional <version>. Read
wiki/repos/<repo-name>.md:
rubber-ducky frontmatter get wiki/repos/<repo-name>.md --json
If the file doesn't exist, offer to create it. Ask one question at a time with progress markers:
Question 1 of 2. What's the upstream repo in
owner/repoform? (e.g.,acme/storefront-web.)
Question 2 of 2. Where does this repo store its changelog? (Default:
CHANGELOG.mdon the default branch. Say "default" to accept.)
Then create the page:
rubber-ducky page create repo "<repo-name>" --repo <owner/repo> --changelog-path <path>
Re-read the resulting frontmatter and proceed.
The skill needs to know how ticket references appear in the changelog so it
can extract them. Look at the repo page's release_reference_pattern field.
Run rubber-ducky workspace intake show --json and look at
primary_backend.
Fall back further to rubber-ducky backend list --json if intake is
unset; if there's a single Jira / GitHub backend, use its
ref_pattern.
If multiple backends remain plausible, ask once:
Question 1 of 1. What pattern should I use to extract ticket references from this repo's changelog? Examples:
WEB-\d+(Jira-style),acme/storefront-web#\d+(GitHub-style). Say "skip" to skip extraction and just log the version + notes.
Persist the answer to the repo page's frontmatter so future runs are silent:
rubber-ducky frontmatter set wiki/repos/<repo-name>.md release_reference_pattern "<pattern>"
/release depends on gh independently of the workspace's backend setup —
the changelog lives on GitHub regardless of whether the workspace's
intake is GitHub, Asana, or Jira. Before pulling, verify gh is
installed and authenticated:
gh auth status
If gh is missing or unauthenticated, ask the user to install it and run
gh auth login, then stop. Don't fall back to a raw fetch — the user
might have a private repo.
Then pull the changelog:
gh api repos/<owner>/<repo>/contents/<changelog-path>?ref=<default_branch> --jq '.content' | base64 -d
Parse the changelog into version entries. The expected shape — common across keepachangelog, Changesets, and most hand-rolled formats — is:
## X.Y.Z (YYYY-MM-DD) # or "## X.Y.Z - YYYY-MM-DD"
<section markers>
<body>
$ARGUMENTS named a version, find that entry; if absent, error and
stop.# Changelog heading, or just the first ## block).Apply release_reference_pattern (or whatever was decided in Step 2) as a
regex against the version entry's body. Dedupe matches preserving order.
For each match, locate the corresponding wiki task page:
rubber-ducky wiki search "<ref>" --json
(Or fall back to a grep on wiki/tasks/ looking at the ref, jira_ref,
asana_ref, and gh_ref frontmatter fields.) For each ticket, capture:
References with no wiki page get listed but flagged with ⚠ no wiki page.
Continue — they're real shipments even if the user didn't ingest them.
Read the body of the repo page and look for an existing ### <version>
header under ## Releases. If present, ask:
The repo page already has a section for . Overwrite, skip the write, or rename it? (overwrite / skip / rename)
Don't silently double-write.
### X.Y.Z — YYYY-MM-DD
| Ref | Task | Notes |
| :-------- | :-------------------------------- | :-------------------------- |
| WEB-NNN | [[<wiki page>]] | <one-line from changelog> |
**Notes:**
- <any sub-bullets pulled from the changelog body>
Show it inline and ask:
Write to repo page? (yes / no / edit)
On yes, prepend the new section under ## Releases (newest first) in the
repo page and bump the updated: frontmatter:
rubber-ducky frontmatter set wiki/repos/<repo-name>.md updated "<now-iso>"
(The body edit itself is a direct file write — there's no CLI primitive for "insert section into body", so use Read + Edit + Write the tail of the file preserving structure.)
After the section is written, ask:
This release covered N tickets. Finalize them?
Finalize = close across every backend each ticket is linked to:
- Wiki: status → done, closed = today, activity-log entry
- Linked backends: transition to their "done" / "complete" state
- Single shared closing comment posted to each backend
Options: Finalize all · Finalize some · Skip for now
For each ticket the user chose to finalize, draft a single shared closing comment once and reuse it across backends:
Shipped in <repo-name> <version>. Release included: <list of refs>.
Show the comment + a batch confirmation table:
| Ref | Wiki | <backend-a> | <backend-b> |
| WEB-289 | → done | → Done | → Complete |
The finalize batch is risk_class: hard. There is no single
"finalize all" gate — each ticket's transition and comment is its own
write, and each rides on the primitive CLI verbs (rubber-ducky transition and rubber-ducky comment). That way the batch fails
gracefully per-ticket and every external call passes through the
CLI-enforced gate.
For each ticket the user chose to finalize:
Wiki side first — soft write, no token needed:
rubber-ducky task close <wiki-page>
(sets status: done, closed, logs to daily, appends to activity log).
For each backend ref present in the task's frontmatter, issue a
confirm-token and invoke rubber-ducky transition (target = done),
then a separate token + rubber-ducky comment for the shared closing
line. Each external call goes through the CLI-enforced gate; nothing
is bundled.
TOKEN_T=$(rubber-ducky --no-json confirm request \
--action <backend>.transition \
--preview "Finalize: $REF → done")
rubber-ducky --json transition <wiki-page> \
--backend <backend> --to done --confirm-token "$TOKEN_T"
TOKEN_C=$(rubber-ducky --no-json confirm request \
--action <backend>.comment \
--preview "Closing comment on $REF")
rubber-ducky --json comment <wiki-page> \
--backend <backend> --text "$CLOSING_COMMENT" --confirm-token "$TOKEN_C"
Set confirm.<backend>.transition and confirm.<backend>.comment
to auto in settings.json ahead of time if the user wants a
batch-style "no prompts" finalize.
If any single backend write fails, log the failure but keep going on
the remaining tickets and report all failures at the end. The wiki
side is already updated by task close; partial-finalize across
backends is better than no-finalize.
Add a release block to today's ## Work log section (highlighted, not just a
plain bullet):
- **Release: [[<repo-name>]] <version>** — N tickets shipped:
- [[<task1>]] ✓
- [[<task2>]] ✓
For each finalized ticket, also add a line to today's ## Completed today
section with the shipped in <repo> <version> annotation.
Append to log.md:
rubber-ducky log append "[release] <repo-name> <version> — N tickets shipped, M finalized."
If all active tasks just got closed, ask the user what to work on next.
Otherwise, read active_task on today's daily page and end with the
standard one-line redirect.
## Releases so
the page reads top-down by recency.repo, changelog_path,
release_reference_pattern); on subsequent runs, read and use silently.⚠ no wiki page note so they can ingest later if they want.A confirmation summary: release section written to the repo page, count of tickets finalized vs. skipped vs. failed, optional one-line redirect.