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

flow-groom

스타17

포크5

업데이트2026년 7월 18일 21:23

Turn a rough idea into one scoped, labeled GitHub issue (one P0–P3 + status:ready, testable acceptance criteria), and decide oracle-vs-design routing. First stage of the CQLite delivery pipeline. Use when the owner says "groom <idea>", "file an issue for X", or brings a rough idea to scope.

설치

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

Manus에서 실행

출처

pmcfadin

pmcfadin/cqlite

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

다운로드

Manus에서 실행

flow-groom — idea → one scoped issue

You are the CQLite delivery lead. Turn a rough idea into exactly ONE well-scoped GitHub issue.

Steps

Clarify just enough. Ask at most one question (one at a time) only if scope is genuinely ambiguous; otherwise pick a sensible scope and state it.
Decide oracle vs design (record it in the issue body):
- Oracle-driven (SSTable parsing/decode, compaction/tombstone byte-parity, type system) — has a Cassandra/sstabledump source of truth. These get an issue + a pinned parity test and skip OpenSpec; they can go straight to flow-implement.
- Design-driven (bindings/M6, query-engine surface, CLI/REPL UX, perf/M7, process) — real latitude, no oracle. These go through flow-activate (OpenSpec).
Write testable acceptance criteria. Each criterion must map to a check (a test or an sstabledump parity comparison). Note any no-heuristics / public-surface (wiring-evidence) / memory-budget impact.
Create the issue with exactly one priority label and status:ready:
```
gh issue create --title "<concise>" --body "<context + oracle/design + acceptance criteria>" \
  --label "P2" --label "status:ready"
```
(Pick P0–P3 deliberately; confirm priority with the owner if unsure.) The status:* labels are decorative mirrors only — board Status is the sole dispatch authority (Path A, #1886); a label never selects work.

Verify the board add — do NOT trust Project auto-add. Auto-add has been observed missing all new issues, so add the item explicitly and confirm it landed:

gh project item-add 1 --owner pmcfadin --url <issue-url>
gh project item-edit --project-id <id> --id <item-id> --field-id <status-field> \
  --single-select-option-id <Ready-or-Backlog>   # Ready if groomed-ready, else Backlog
gh project item-list 1 --owner pmcfadin --limit 1000 | grep "<issue-#>"   # confirm item + Status

The item MUST appear with the intended Status before you report done.

Report the issue number + a one-line description (#<N> (<slug>)) and whether it's oracle- or design-driven (i.e. whether flow-activate or a direct flow-implement is next).

Do not create worktrees or specs here — that's flow-activate. One idea → one issue.

이 저장소의 다른 Skills

같은 저장소

flow-address

pmcfadin/cqlite

Resolve PR review comments for an in-review issue — fix them in the issue's worktree, re-run the gate + C as needed, push, and reply per thread. Fourth stage of the CQLite delivery pipeline. Use when the owner leaves PR comments and says "address

2026-07-1817

flow-implement

pmcfadin/cqlite

Implement an approved issue — spawn sstable-developer (TDD) in the issue's worktree, run rust-reviewer + roborev on the lite-green diff BEFORE any full gate (review-first is default), open the PR, then hand the endgame (the ONE full gate → C → final roborev → merge-on-green → finalize) to a disposable flow-closer agent so gate/review churn never accretes in the lead session. Third stage of the CQLite delivery pipeline. Requires owner approval of the spec (design-driven) first. Use when the owner says "implement

2026-07-1817

ci-cd-validation-merge-workflow

pmcfadin/cqlite

Pre-push validation checklist (cargo fmt, clippy with zero warnings, feature flag testing, test suite), CI monitoring, merge process, and release quality gates. Use when preparing to push code, validating changes before PR, running CI checks, merging PRs, or preparing releases.

2026-07-1817

flow-board

pmcfadin/cqlite

Report status across all in-flight CQLite delivery work — render the shared GitHub Project claim board (item, status, assignee, priority) with drift + abandoned-claim reconciliation, then surface and drive the single furthest-along item waiting on the owner (a green PR to merge, a spec to approve), or offer a claim-aware pick-list. Use when the owner asks "where do things stand", "what's next", "unblock me", or "what needs me".

2026-07-1817

flow-activate

pmcfadin/cqlite

Activate a groomed design-driven issue — create its worktree + branch (1:1:1:1), run OpenSpec propose to produce proposal/design/specs/tasks, render the spec + recommended design INLINE, then STOP for the owner's approval. This is Seam 1; it never implements. Second stage of the CQLite delivery pipeline. Use when the owner says "activate

2026-07-1817

flow-finalize

pmcfadin/cqlite

Finalize a merged issue — archive its OpenSpec change (sync delta specs into openspec/specs/), remove the worktree + branch, and close the issue with a traceable comment. Fifth stage of the CQLite delivery pipeline. Runs after the PR is merged — workers merge autonomously on green (gate PASS + C PASS + roborev clean), so finalize normally follows the worker's own merge. Use right after a merge (or when the owner says "finalize

2026-07-1817

name	flow-groom
description	Turn a rough idea into one scoped, labeled GitHub issue (one P0–P3 + status:ready, testable acceptance criteria), and decide oracle-vs-design routing. First stage of the CQLite delivery pipeline. Use when the owner says "groom <idea>", "file an issue for X", or brings a rough idea to scope.

flow-groom — idea → one scoped issue

You are the CQLite delivery lead. Turn a rough idea into exactly ONE well-scoped GitHub issue.

Steps

Clarify just enough. Ask at most one question (one at a time) only if scope is genuinely ambiguous; otherwise pick a sensible scope and state it.
Decide oracle vs design (record it in the issue body):
- Oracle-driven (SSTable parsing/decode, compaction/tombstone byte-parity, type system) — has a Cassandra/sstabledump source of truth. These get an issue + a pinned parity test and skip OpenSpec; they can go straight to flow-implement.
- Design-driven (bindings/M6, query-engine surface, CLI/REPL UX, perf/M7, process) — real latitude, no oracle. These go through flow-activate (OpenSpec).
Write testable acceptance criteria. Each criterion must map to a check (a test or an sstabledump parity comparison). Note any no-heuristics / public-surface (wiring-evidence) / memory-budget impact.
Create the issue with exactly one priority label and status:ready:
```
gh issue create --title "<concise>" --body "<context + oracle/design + acceptance criteria>" \
  --label "P2" --label "status:ready"
```
(Pick P0–P3 deliberately; confirm priority with the owner if unsure.) The status:* labels are decorative mirrors only — board Status is the sole dispatch authority (Path A, #1886); a label never selects work.

Verify the board add — do NOT trust Project auto-add. Auto-add has been observed missing all new issues, so add the item explicitly and confirm it landed:

gh project item-add 1 --owner pmcfadin --url <issue-url>
gh project item-edit --project-id <id> --id <item-id> --field-id <status-field> \
  --single-select-option-id <Ready-or-Backlog>   # Ready if groomed-ready, else Backlog
gh project item-list 1 --owner pmcfadin --limit 1000 | grep "<issue-#>"   # confirm item + Status

The item MUST appear with the intended Status before you report done.

Report the issue number + a one-line description (#<N> (<slug>)) and whether it's oracle- or design-driven (i.e. whether flow-activate or a direct flow-implement is next).

Do not create worktrees or specs here — that's flow-activate. One idea → one issue.