Menü
Release a new version of feather-flow. Enforces changelog, version bump, tag, and publish steps.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
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}