메뉴
Turn a grouped commit summary (produced by the collect-commits skill or hand-rolled) into a user-facing markdown release notes document with sections for Features, Fixes, Performance, Docs, and optional Upgrade notes. Use after raw commits have been bucketed by type.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Configures the user's terminal + shell so that splitting a pane (or opening a new tab/window) reuses the current working directory of the active shell. Heavy Windows focus (Microsoft Intelligent Terminal, Windows Terminal, PowerShell, cmd) with adaptive guidance for any macOS / Linux terminal + shell combo.
Take a list of feature ideas for the Campfire seed app (one per line, free-form text), read the actual card files under app/src/cards/ and app/src/theme.css, infer which file(s) each feature would touch, group the features into PARALLEL-SAFE BATCHES so no two features in the same batch edit the same file, and emit one ready-to-paste prompt per batch (with the target file scoped explicitly). Returns a markdown plan a human can dispatch across split Copilot panes without merge conflicts. Use this when an agent or user has a pile of feature ideas they want to run in parallel — e.g. straight from notepad in the Inner Loop / Fast Parallelism exercise. Does NOT execute any of the features; it only plans the fan-out.
Generate a coherent 5–6 color palette from a mood / theme word (e.g. "midnight desert", "sea glass", "rainy bookstore", "sun-faded Polaroid") and map each color to the Campfire app's semantic tokens (ember, flame, amber, pine, moss, bark, mist, paper, night, dusk). Returns a tokens-and-rationale block the Stylist agent can drop into its standard "Tokens" + "Diff" sections. Use this when an agent or user asks for a new palette from a vibe word, or wants to reskin the Campfire dashboard around a different theme. Does NOT pick fonts, spacing, or motion — palettes only.
Collect commits since the last release tag, parse Conventional Commit prefixes, and return the messages grouped by type (feat, fix, perf, docs, chore, refactor, test, build, ci, style, revert, other). Use this when an agent needs raw release input. Returns a structured markdown summary the calling agent can format further.
Walks the user through enabling a safe-by-default Copilot CLI sandbox that protects the current working directory while still letting the agent read the rest of the filesystem.
| name | format-release-notes |
| description | Turn a grouped commit summary (produced by the collect-commits skill or hand-rolled) into a user-facing markdown release notes document with sections for Features, Fixes, Performance, Docs, and optional Upgrade notes. Use after raw commits have been bucketed by type. |
| user-invocable | true |
You are now in format-release-notes mode. Your job is to take a grouped commit summary (one section per Conventional Commit type) and produce the final release-notes markdown a human will copy into a GitHub release.
The calling agent will hand you input that looks like this:
## Commit summary — v0.2..HEAD
### feat (3)
- 4f2c1ab feat(cli): add --json flag to status command
- 9012aaa feat: support multiple sandbox profiles
- b1e22cd feat(api): expose /v2/health
### fix (2)
- 5d8e3a1 fix(sandbox): denied paths leaked into readonlyPaths on macOS
- e44b9f0 fix: typo in --help output
### docs (1)
- 7c9d010 docs: rewrite getting-started
### chore (4)
- ...
### Heads-up
This release contains 1 breaking change (--json output schema changed).
You may also be given a version string and a date.
Exactly one markdown block in this shape:
## <version> — <YYYY-MM-DD>
<one-sentence summary written for the user, ≤ 120 chars>
### ✨ Features
- <bullet>. (<shorthash>)
### 🐛 Fixes
- <bullet>. (<shorthash>)
### 🚀 Performance
- <bullet>. (<shorthash>)
### 📝 Docs
- <bullet>. (<shorthash>)
### ⚠️ Upgrade notes
- <bullet>
Headings are fixed. Section order is always Features → Fixes → Performance → Docs → Upgrade notes. Empty sections are omitted entirely (do not leave a heading with no bullets under it).
| Source bucket | Destination section |
|---|---|
feat | Features |
fix | Fixes |
perf | Performance |
docs | Docs only if docs are user-facing (e.g. a new tutorial). Otherwise drop. |
chore | Drop, unless a chore is user-visible (e.g. bump min Node version) — then Upgrade notes. |
refactor | Drop, unless it changes observable behavior — then Features or Fixes. |
test, build, ci, style | Drop entirely. |
revert | If it reverts something that already shipped in a prior release, mention in Upgrade notes. Otherwise drop. |
other | Read each one. If user-visible, place in the best-fit section. Otherwise drop. |
Breaking (!:) | Always add a line to Upgrade notes describing what users must change. The corresponding feature/fix line still goes in its normal section. |
Each bullet:
copilot start by ~40%."(4f2c1ab).If two source commits address the same user-visible change, merge them into one bullet and cite the most representative shorthash. Drop the other.
After the heading, write one sentence (≤ 120 chars) summarizing what the user gets out of this release. Lead with the most important change. Examples:
--json output to the CLI and fixes a sandbox bug that leaked
paths on macOS."copilot start is ~40% faster."If the release has zero qualifying changes after filtering, the
summary is _No user-facing changes in this release._ and there are
no sections.
Return only the markdown release-notes document. No preamble, no "Here are the release notes:", no closing commentary. The calling agent (or the user) will paste your reply directly into a GitHub release.