원클릭으로 Manus에서 모든 스킬 실행

dev-issues

스타109

포크10

업데이트2026년 6월 11일 09:42

Turn a free-form brain-dump into a clean, ordered set of `notes/issues/*.md` work items. The user tags `/dev-issues` and writes a long stream of everything in their head — features, refactors, bugs, half-formed ideas, product direction. This skill decomposes that stream into discrete, well-shaped, individually-actionable issue files, asks clarifying questions only where a decision is genuinely the user's, collision-checks against the existing `notes/` inbox so it updates rather than duplicates, then commits the batch. The end state: every thought is captured as an issue a downstream agent (or `/dev-loop`) can pick up and execute. USE WHEN the user types `/dev-issues`, says "let me brain-dump", "capture all of this into issues", "break this into issues", "I have a bunch of ideas", "distribute these thoughts", or pastes a long unstructured list of things they want done to Ralphy. DO NOT FIRE for a single scoped change (just do it), for content/video work (that is the routing table), or to capture a one-off idea

설치

Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.

Manus에서 실행

출처

alecs5am

alecs5am/ralphy

GitHub 저장소 열기 Creator 저장소 보기

다운로드

Manus에서 실행

dev-issues — brain-dump → distributed issues

A maintainer skill. It does not touch .ralphy/workspaces/<ws>/projects/ or call media models. It converts an unstructured stream of thoughts into a set of correctly-shaped notes/issues/*.md work items. Pairs with /dev-loop, which executes the issues this skill files.

When it fires

The user tags /dev-issues and then writes a lot — a wall of ideas, gripes, product direction, "and also we should…". The longer and less structured the input, the more this skill earns its keep.
ALSO FIRE when a normal dev conversation produces ≥3 distinct actionable threads the user wants preserved before they evaporate.
DO NOT FIRE for one scoped task (do it, or file a single note via dev-tasks), for content production, or for one-off idea/decision capture into the notes/ inbox (dev-tasks).

Workflow

Read the inputs first. Read notes/README.md (the note shape + the Issues folder layout), docs/developing-ralphy.md (English-only rule, the lint suite), and skim the active backlog (the flat top level of notes/issues/) plus notes/ideas/ so you know what already exists. notes/issues/done/ and notes/issues/deprecated/ are the closed archive — skim them only during collision-check (step 3). dev-tasks is the sibling skill for notes/ inbox capture (ideas / decisions).

Status-by-folder. notes/issues/ is split into the flat top level (the live backlog), done/ (resolved / promoted-and-landed), and deprecated/ (superseded / won't-do). New issues are always filed at the flat top level. Each issue keeps its > **Status:** line in sync with its folder.
Decompose the brain-dump into discrete items. One issue = one coherent unit of work (one verb / file / feature / refactor / bug). Split compound thoughts; merge near-duplicates. Aim for issues a single sub-agent could execute end-to-end.
Collision-check before filing each. Search all of notes/issues/ (active top level + done/ + deprecated/) and notes/ideas/ for an existing entity that already covers the thought. If one exists, update it (or note the overlap) rather than spawning a duplicate. If the match lives in done/, the thought is likely a regression or follow-up — git mv it back to the active top level and reset its > **Status:** line, or file a fresh issue that cross-links it. Never let the same thing live in two places.
Ask clarifying questions only where the answer changes what gets filed — a genuine fork the user must decide (scope, irreversibility, a product direction with no sensible default). Use AskUserQuestion, batch the questions, and offer a recommended option. Do NOT ask about things you can decide from the repo or sensible defaults. If the user wrote in Russian (or any non-English), that is fine in chat — but everything you WRITE to disk is English (translate/paraphrase).
Write each issue at the flat top level as notes/issues/NNN-kebab-slug.md, numbered monotonically across all three locations (fd -e md . notes/issues | rg -o '[0-9]{3}' | sort -n | tail -1, increment — never reuse a number freed by a move into done//deprecated/). Follow the notes/README.md shape (Status / Filed / Folder / Context / What / Why it matters / Notes) plus a concrete ## Scope / acceptance section listing what "done" means — file paths, gates to pass, acceptance criteria — so a downstream agent can execute without re-deriving scope. Add severity + category when useful. Cross-link related issues by number.
Order + dependencies. When the batch has a natural execution order (foundational schema before consumers, a cross-cutting rename before dependent work, plan-only/docs as low-risk), note it — either in a short lead issue or in each issue's Notes ("sequence after #NNN"). /dev-loop reads this ordering.
Commit the batch. git add notes/issues/<new files> and commit with a docs(notes): … message summarizing the set. Run the Cyrillic gate (rg '\p{Cyrillic}' --pcre2 notes/issues/<files>) before committing — empty is the gate. Push only if the user works commit-to-main (this repo does; see the user's memory).
Report back a thought→issue map: for each filed issue, one line (number, slug, the thought it captures), plus the recommended execution order and any item you deliberately dropped or merged.

HARD INVARIANTS

English-only on disk. Translate any non-English brain-dump before writing.
One thought, one home. Collision-check first; update over duplicate.
Every issue is executable. If it lacks a concrete ## Scope / acceptance, it is not ready — sharpen it or ask.
Capture, don't execute. This skill files issues; it does NOT implement them. Hand execution to /dev-loop or a targeted dev session.
Numbering is monotonic across active + done/ + deprecated/. Never reuse a number freed by a move, and never renumber existing issues.
File active issues at the flat top level only. done/ and deprecated/ are written to by /dev-loop (or a manual resolve), never by initial filing.

이 저장소의 다른 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

dev-release

alecs5am/ralphy

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.

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

name	dev-issues
namespace	maintainer
description	Turn a free-form brain-dump into a clean, ordered set of `notes/issues/*.md` work items. The user tags `/dev-issues` and writes a long stream of everything in their head — features, refactors, bugs, half-formed ideas, product direction. This skill decomposes that stream into discrete, well-shaped, individually-actionable issue files, asks clarifying questions only where a decision is genuinely the user's, collision-checks against the existing `notes/` inbox so it updates rather than duplicates, then commits the batch. The end state: every thought is captured as an issue a downstream agent (or `/dev-loop`) can pick up and execute. USE WHEN the user types `/dev-issues`, says "let me brain-dump", "capture all of this into issues", "break this into issues", "I have a bunch of ideas", "distribute these thoughts", or pastes a long unstructured list of things they want done to Ralphy. DO NOT FIRE for a single scoped change (just do it), for content/video work (that is the routing table), or to capture a one-off idea / decision into the `notes/` inbox (that is `dev-tasks`). See body for ALSO FIRE / DO NOT FIRE / HARD INVARIANTS.

dev-issues — brain-dump → distributed issues

When it fires

The user tags /dev-issues and then writes a lot — a wall of ideas, gripes, product direction, "and also we should…". The longer and less structured the input, the more this skill earns its keep.
ALSO FIRE when a normal dev conversation produces ≥3 distinct actionable threads the user wants preserved before they evaporate.
DO NOT FIRE for one scoped task (do it, or file a single note via dev-tasks), for content production, or for one-off idea/decision capture into the notes/ inbox (dev-tasks).

Workflow

Read the inputs first. Read notes/README.md (the note shape + the Issues folder layout), docs/developing-ralphy.md (English-only rule, the lint suite), and skim the active backlog (the flat top level of notes/issues/) plus notes/ideas/ so you know what already exists. notes/issues/done/ and notes/issues/deprecated/ are the closed archive — skim them only during collision-check (step 3). dev-tasks is the sibling skill for notes/ inbox capture (ideas / decisions).

Status-by-folder. notes/issues/ is split into the flat top level (the live backlog), done/ (resolved / promoted-and-landed), and deprecated/ (superseded / won't-do). New issues are always filed at the flat top level. Each issue keeps its > **Status:** line in sync with its folder.
Decompose the brain-dump into discrete items. One issue = one coherent unit of work (one verb / file / feature / refactor / bug). Split compound thoughts; merge near-duplicates. Aim for issues a single sub-agent could execute end-to-end.
Collision-check before filing each. Search all of notes/issues/ (active top level + done/ + deprecated/) and notes/ideas/ for an existing entity that already covers the thought. If one exists, update it (or note the overlap) rather than spawning a duplicate. If the match lives in done/, the thought is likely a regression or follow-up — git mv it back to the active top level and reset its > **Status:** line, or file a fresh issue that cross-links it. Never let the same thing live in two places.
Ask clarifying questions only where the answer changes what gets filed — a genuine fork the user must decide (scope, irreversibility, a product direction with no sensible default). Use AskUserQuestion, batch the questions, and offer a recommended option. Do NOT ask about things you can decide from the repo or sensible defaults. If the user wrote in Russian (or any non-English), that is fine in chat — but everything you WRITE to disk is English (translate/paraphrase).
Write each issue at the flat top level as notes/issues/NNN-kebab-slug.md, numbered monotonically across all three locations (fd -e md . notes/issues | rg -o '[0-9]{3}' | sort -n | tail -1, increment — never reuse a number freed by a move into done//deprecated/). Follow the notes/README.md shape (Status / Filed / Folder / Context / What / Why it matters / Notes) plus a concrete ## Scope / acceptance section listing what "done" means — file paths, gates to pass, acceptance criteria — so a downstream agent can execute without re-deriving scope. Add severity + category when useful. Cross-link related issues by number.
Order + dependencies. When the batch has a natural execution order (foundational schema before consumers, a cross-cutting rename before dependent work, plan-only/docs as low-risk), note it — either in a short lead issue or in each issue's Notes ("sequence after #NNN"). /dev-loop reads this ordering.
Commit the batch. git add notes/issues/<new files> and commit with a docs(notes): … message summarizing the set. Run the Cyrillic gate (rg '\p{Cyrillic}' --pcre2 notes/issues/<files>) before committing — empty is the gate. Push only if the user works commit-to-main (this repo does; see the user's memory).
Report back a thought→issue map: for each filed issue, one line (number, slug, the thought it captures), plus the recommended execution order and any item you deliberately dropped or merged.

HARD INVARIANTS

English-only on disk. Translate any non-English brain-dump before writing.
One thought, one home. Collision-check first; update over duplicate.
Every issue is executable. If it lacks a concrete ## Scope / acceptance, it is not ready — sharpen it or ask.
Capture, don't execute. This skill files issues; it does NOT implement them. Hand execution to /dev-loop or a targeted dev session.
Numbering is monotonic across active + done/ + deprecated/. Never reuse a number freed by a move, and never renumber existing issues.
File active issues at the flat top level only. done/ and deprecated/ are written to by /dev-loop (or a manual resolve), never by initial filing.