ワンクリックで
release-feather-flow
Release a new version of feather-flow. Enforces changelog, version bump, tag, and publish steps.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
メニュー
Release a new version of feather-flow. Enforces changelog, version bump, tag, and publish steps.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Horizon-expansion and structured capture skill. **TRIGGER when the user expresses intent to build, design, or shape a new feature, app, or project** — phrases like "I want to build X", "let's design Y", "thinking about a tool that does Z", "want to brainstorm", or any opening that describes a future feature/app rather than asking to fix or modify existing code. **MUST trigger BEFORE any scaffolding, file creation, or tech-stack discussion** — the brainstorm captures intent before code. Do not ask about frameworks, auth libraries, or deployment in this phase; those belong in feather-spec's design.md. Produces docs/brainstorm.md — a project-level discovery doc capturing workflow, pain points, and decomposition into features. For visual layout decisions, generates HTML mockups in the user's browser. Output feeds into feather-spec, which then specs each feature one at a time. Part of the feather-flow pipeline.
Task execution skill. Use when a capability has a tasks.md and the user is ready to build. Prints orientation based on current state (reads docs/STATE.md, plus tasks.md and plans/ in the active capability). Runs one task at a time: mini-plan → execute → verify → record → ask. Classifies verification findings into six categories. Produces per-task plan files, updates STATE.md every gate cycle, and drafts a PR description when all tasks are complete. On capability completion, updates ROADMAP.md and surfaces the next planned capability. Part of the feather-flow pipeline: runs after feather-spec.
The Feather Flow pipeline overview. **TRIGGER when the user expresses intent to build a new app, feature, or project from scratch** — phrases like "I want to build X", "let's create a Y", "help me make a Z", "want to build/design/sketch a [thing]". Routes to feather-brainstorm for ideation FIRST, then feather-spec for spec authoring, then feather-execute-task for build. **Use this BEFORE any scaffolding, file creation, or tech-choice discussion.** Also use when the user asks about the pipeline as a whole, is unsure where to enter, or needs to re-orient mid-implementation after a pivot. For direct task execution, invoke feather-execute-task. For spec authoring (when a docs/brainstorm.md already exists), invoke feather-spec. For discovery and brainstorming, invoke feather-brainstorm.
The Feather Spec framework reference. Use this skill when authoring spec.md (15-section feature spec), design.md, or tasks.md for any feature. Also the canonical reference for vocabulary, stable IDs, EARS patterns, and change protocol. Invoked directly by feather-brainstorm (to produce spec artifacts from project-level docs/brainstorm.md) and referenced by feather-execute-task (for task structure and test layering). Part of the feather-flow pipeline.
| name | release-feather-flow |
| description | Release a new version of feather-flow. Enforces changelog, version bump, tag, and publish steps. |
package.json has "name": "feather-flow")main branchRun each step in order. Stop if any check fails.
Run silently and verify:
git status --porcelain
git branch --show-current
If working tree is dirty, tell the user and stop.
If not on main, tell the user and stop.
Read the current version from package.json. Ask the user:
Current version: v{current} What version are you releasing? (e.g. 1.2.0)
Read docs/CHANGELOG.md. Check that:
[Unreleased] section has content (not empty)## [{new-version}] sectionIf [Unreleased] is empty, tell the user:
No changes listed under [Unreleased] in CHANGELOG.md. Add changelog entries first.
Stop.
Move entries from [Unreleased] to a new ## [{version}] - {today's date} section.
Keep [Unreleased] as an empty section at the top.
Add/update comparison links at the bottom of the file (following keepachangelog format):
[Unreleased]: https://github.com/siraj-samsudeen/feather-flow/compare/v{version}...HEAD
[{version}]: https://github.com/siraj-samsudeen/feather-flow/releases/tag/v{version}
Commit:
git add docs/CHANGELOG.md
git commit -m "docs: update changelog for v{version}"
Update version in both files:
package.json — the "version" fieldVERSION — the plain text versionCommit (message is just the version number, like get-shit-done style):
git add package.json VERSION
git commit -m "{version}"
Push the changelog + version commits, then create and push the tag. The tag push is what triggers the publish workflow:
git push origin main
git tag v{version}
git push origin v{version}
(As of v2.0.1 the publish workflow triggers on v* tag pushes only —
no auto-bump, no rebase dance. Pushing main alone does not publish.)
The repo uses trusted publishing via GitHub Actions (publish.yml). The
tag push in Step 6 triggers the publish automatically. Do NOT run
npm publish manually.
Wait 30 seconds, then verify:
gh run list --repo siraj-samsudeen/feather-flow --limit 1
If the workflow completed successfully, proceed. If it failed, show the user the error and suggest checking the Actions tab.
Show the user:
Released feather-flow v{version}