ワンクリックでManusで任意のスキルを実行

dev-release

スター109

フォーク10

更新日2026年7月13日 14:51

Cut a Ralphy CLI release across GitHub Releases, Homebrew, and npm. Use when the user asks to release, tag, publish, or prepare release notes for the CLI. Public documentation and the marketing site live in sibling repositories and are synchronized separately when their content is affected.

インストール

Codex または Claude でインストールこの Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。

Manusで実行

ソース

alecs5am

alecs5am/ralphy

GitHub リポジトリを開く Creator のリポジトリを見る

ダウンロード

Manusで実行

Release the Ralphy CLI

This skill ships the agent-facing CLI in this repository. It never releases the marketing site, public docs site, desktop app, or unattended farm runtime.

Repositories

CLI: current repository, alecs5am/ralphy.
Public docs: sibling ../ralphy-docs, alecs5am/ralphy-docs.
Marketing and library: sibling ../ralphy-web, alecs5am/ralphy-web.
Desktop: sibling ../ralphy-desktop, alecs5am/ralphy-desktop.
Unattended automation: sibling ../ralphy-farm, alecs5am/ralphy-farm.

Only the CLI repository receives the vX.Y.Z release tag. If a CLI change affects public documentation, update and push ralphy-docs before tagging the CLI. Web, desktop, and farm changes follow their own release processes.

Release contract

One version must reach all three CLI channels:

GitHub Release with platform binaries and SHA256SUMS.
alecs5am/homebrew-tap formula.
@alecs5am/ralphy on npm.

Never amend or replace an existing release. Never publish only one channel.

Procedure

Confirm the current branch is main, the worktree is clean, and gh auth status plus npm whoami identify the expected maintainer.
Read scripts/release/last-release-commit, the latest v* tag, and commits since that baseline. Propose the semver bump and grouped release notes.
Inspect the diff for public-doc impact. If needed, update ../ralphy-docs, validate docs.json, commit, and push that repository separately.

Run the CLI verification suite:

bun run lint
bun test --timeout 45000 tests/unit tests/integration
bun run build:bin:current
gitleaks detect --source .

After explicit user approval, update these version sources in lockstep:
- package.json
- cli/lib/version.ts
- npm/package.json
- the current-version line in AGENTS.md
Commit chore(release): vX.Y.Z, tag that commit vX.Y.Z, and push the commit and tag. Do not create the GitHub Release manually; the release workflow owns binaries, checksums, and the release object.
Watch the GitHub Actions release workflow to success.
Run scripts/release/update-brew-tap.sh vX.Y.Z and scripts/release/publish-npm.sh X.Y.Z, then verify both registries resolve the new version.
Update scripts/release/last-release-commit in a separate trailing commit so the next release has an exact baseline.

Stop conditions

Stop before tagging when tests fail, versions disagree, credentials are wrong, there are no releasable commits, or the user has not approved the proposed version. Documentation-only changes in ralphy-docs do not require a CLI tag.

このリポジトリの他の Skills

同じリポジトリ

social-publish

alecs5am/ralphy

Publish or schedule a finished Ralphy Unit through the active workspace's saved Postiz connection. Prepares the target-shaped title, description, body, CTA, hashtags, thread parts, and required Postiz settings, then calls `ralphy publish` and records provenance for later analytics. USE WHEN the user asks to "publish this", "post it now", "schedule this post", "send this to Telegram", "post this thread to X", "publish the reel", or "put this on YouTube/Instagram". DO NOT FIRE for copy-only requests with no posting intent; use social-copy instead.

2026-07-13109

dev-loop

alecs5am/ralphy

Run an autonomous, issue-driven development loop over Ralphy itself — the same cadence as a focused maintainer session: pick the open `notes/issues/`, order them by dependency, then for each issue dispatch a scoped sub-agent, review its diff, run the real gates, and commit + push to main before moving to the next. Sequential by default (one agent at a time) so changes never collide on shared files. Default scope is ALL open issues with a safety limit of 25; the user can widen the scope or raise the limit in their prompt. Pauses for the user only at genuine decision forks and before any paid generation or irreversible/outward-facing action. USE WHEN the user types `/dev-loop`, says "work through the issues", "run the dev loop", "grind the backlog", "implement all the open issues", "keep going through notes/issues until done", or after `/dev-issues` has filed a batch they now want executed. DO NOT FIRE for a single issue (just implement it), for content/video production, or when there are no open issues to exec

2026-07-13109

dev-publish-template

alecs5am/ralphy

Publish a finished Ralphy unit and its reusable blocks to the public library. Use when the user asks to publish a template, unit, style, recipe, or asset to the library. The CLI prepares the entity bundle; the sibling ralphy-web repository owns the committed library and upload script.

2026-07-13109

fixer

alecs5am/ralphy

The eval-to-repair loop — the consumer of the evaluator's report (#409). Reads the eval output (eval-deep-vision.json's `what_to_redo` first, else eval.json `findings[]`), runs `ralphy project repair-plan <id>` to classify every finding by owner (art-director / scenarist / editor) and order it by severity, presents the ordered plan grouped by owner, gets the user's approval, then applies targeted fixes through the EXISTING `ralphy` verbs (art-director regen / scenarist rewrite / editor recut), re-renders, re-evals, and compares the old vs new verdict. HARD GATE: no paid model regeneration runs until the user approves the plan (or previously opted into batch repair). The deterministic `repair-plan` step itself makes ZERO model calls and is safe to run unprompted. USE WHEN the user says "fix the eval", "repair this render", "make it shippable", "fix the issues / problems / findings", "address the eval", "now fix it", "make the fixes", or hands off a failed / warn eval and asks what's next. ALSO FIRE right after

2026-07-13109

templater

alecs5am/ralphy

The full extract → classify → blueprint → de-dup → publish pipeline for a finished `.ralphy/workspaces/<ws>/projects/<id>/`. Reads its `units/*/unit.json` (#069) as the Unit source of truth, then factors the project into ALL FIVE entities — Unit + the four typed blocks Template (structure), Style (look), Recipe (effect/treatment), Asset (reusable media). Applies the recipe-vs-tag split (#082/#083): a candidate is a Recipe only if it carries an extractable artifact (ffmpeg filtergraph / HyperFrames snippet / encode recipe / prompt technique); otherwise it is a Tag on the Unit. Captures a per-unit Blueprint (#080), de-dups every block against the live library FIRST, then prints the exact ordered `publish-entity.ts` commands (dry-run → --push). Publishing itself is the #056 path. USE WHEN the user says any of: "save this as a template", "turn the project into a template", "templatify <project-id>", "extract a template from <project>", "decompose this project into blocks", "what units/blocks did this project prod

2026-07-13109

universe-studio

alecs5am/ralphy

Studio mode for a tagged workspace — the one-tag, four-approvals orchestrator (#474). Given an idea and an active workspace (`ralphy workspace use <ws>`), it runs production end-to-end as FOUR stages, each auto-assembled and auto-repaired against that workspace's own eval rubric before you see it: (1) location/cast → phase `style-lock`; (2) scenario → phase `scenario`; (3) scene anchors → phase `assets`; (4) final montage → phase `eval`. Each stage: assemble → `ralphy workspace eval <id>` → read the per-criterion scorecard → the #473 bounded repair loop (FREE editor fixes auto-loop; PAID regeneration STOPS for your approval) → present ONLY when the stage's criteria clear → wait for your stage approval before advancing. You make four decisions; everything else repairs itself against the universe's hard bar. GENERIC: parameterized by the ACTIVE workspace — works for ANY workspace with an `evaluators.json` + `stageGates`. It SEQUENCES the per-role playbooks (scenarist / art-director / editor) under the eval gate

2026-07-13109

name	dev-release
namespace	maintainer
description	Cut a Ralphy CLI release across GitHub Releases, Homebrew, and npm. Use when the user asks to release, tag, publish, or prepare release notes for the CLI. Public documentation and the marketing site live in sibling repositories and are synchronized separately when their content is affected.

Release the Ralphy CLI

This skill ships the agent-facing CLI in this repository. It never releases the marketing site, public docs site, desktop app, or unattended farm runtime.

Repositories

CLI: current repository, alecs5am/ralphy.
Public docs: sibling ../ralphy-docs, alecs5am/ralphy-docs.
Marketing and library: sibling ../ralphy-web, alecs5am/ralphy-web.
Desktop: sibling ../ralphy-desktop, alecs5am/ralphy-desktop.
Unattended automation: sibling ../ralphy-farm, alecs5am/ralphy-farm.

Release contract

One version must reach all three CLI channels:

GitHub Release with platform binaries and SHA256SUMS.
alecs5am/homebrew-tap formula.
@alecs5am/ralphy on npm.

Never amend or replace an existing release. Never publish only one channel.

Procedure

Confirm the current branch is main, the worktree is clean, and gh auth status plus npm whoami identify the expected maintainer.
Read scripts/release/last-release-commit, the latest v* tag, and commits since that baseline. Propose the semver bump and grouped release notes.
Inspect the diff for public-doc impact. If needed, update ../ralphy-docs, validate docs.json, commit, and push that repository separately.

Run the CLI verification suite:

bun run lint
bun test --timeout 45000 tests/unit tests/integration
bun run build:bin:current
gitleaks detect --source .

After explicit user approval, update these version sources in lockstep:
- package.json
- cli/lib/version.ts
- npm/package.json
- the current-version line in AGENTS.md
Commit chore(release): vX.Y.Z, tag that commit vX.Y.Z, and push the commit and tag. Do not create the GitHub Release manually; the release workflow owns binaries, checksums, and the release object.
Watch the GitHub Actions release workflow to success.
Run scripts/release/update-brew-tap.sh vX.Y.Z and scripts/release/publish-npm.sh X.Y.Z, then verify both registries resolve the new version.
Update scripts/release/last-release-commit in a separate trailing commit so the next release has an exact baseline.