一键在 Manus 中运行任何 Skill

flow-address

星标17

分支5

更新时间2026年7月18日 21:23

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

安装

用 Codex 或 Claude 帮你安装复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。

在 Manus 中运行

来源

pmcfadin

pmcfadin/cqlite

打开 GitHub 仓库查看创作者相关仓库

下载

在 Manus 中运行

flow-address — resolve PR review feedback

You are the CQLite delivery lead. The owner (or roborev) left comments on the PR for issue #N. Resolve them in the worktree and reply per thread.

Steps

Resolve the PR for the issue first. The issue number <N> is NOT the PR number — resolve the PR from the issue's branch:
```
PR=$(gh pr list --head "issue-<N>-<slug>" --state open --json number --jq '.[0].number')
```
Use $PR for every PR command below (never <N>).
Gather the feedback. gh pr view "$PR" --comments and the review threads (gh api repos/:owner/:repo/pulls/$PR/comments). List the asks.
Triage each (receiving-code-review discipline — verify, don't perform agreement): a mechanical fix is yours to make; a genuine design/scope question goes to the owner via AskUserQuestion (one at a time). Push back with a reason where a suggestion is wrong, rather than complying blindly.

Fix in the worktree (.claude/worktrees/issue-<N>-<slug>), spawning sstable-developer for non-trivial code changes. Set exactly one lifecycle label (clear the others first):

gh issue edit <N> --remove-label status:in-review --remove-label status:in-progress \
  --remove-label status:spec-review --remove-label status:ready --add-label status:addressing

Re-verify what the change touched: re-run scripts/agent-gate.sh (with CQLITE_DATASETS_ROOT at the main repo) and re-run C (spec-auditor) if requirements/tests changed; roborev again if code changed materially.
Push + reply. git -C <worktree> push, then reply on each $PR thread with what changed (commit ref), and flip back to exactly one lifecycle label:
```
gh issue edit <N> --remove-label status:addressing --add-label status:in-review
```
Re-certify and re-arm merge-on-green (#2667). The owner's comments are input, NOT a merge gate — unless a comment is an explicit HOLD: or raises a product/scope question. After addressing them, re-certify (lite + any diff-relevant targets; a full/delta gate per the gate contract if the certified SHA changed), re-run scripts/flow/premerge-assert.sh <pr> <certified-sha>, then re-arm gh pr merge --auto --squash --delete-branch.

同仓库更多 Skills

同仓库

flow-groom

pmcfadin/cqlite

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.

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-address
description	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

flow-address — resolve PR review feedback

You are the CQLite delivery lead. The owner (or roborev) left comments on the PR for issue #N. Resolve them in the worktree and reply per thread.

Steps

Resolve the PR for the issue first. The issue number <N> is NOT the PR number — resolve the PR from the issue's branch:
```
PR=$(gh pr list --head "issue-<N>-<slug>" --state open --json number --jq '.[0].number')
```
Use $PR for every PR command below (never <N>).
Gather the feedback. gh pr view "$PR" --comments and the review threads (gh api repos/:owner/:repo/pulls/$PR/comments). List the asks.
Triage each (receiving-code-review discipline — verify, don't perform agreement): a mechanical fix is yours to make; a genuine design/scope question goes to the owner via AskUserQuestion (one at a time). Push back with a reason where a suggestion is wrong, rather than complying blindly.

Fix in the worktree (.claude/worktrees/issue-<N>-<slug>), spawning sstable-developer for non-trivial code changes. Set exactly one lifecycle label (clear the others first):

gh issue edit <N> --remove-label status:in-review --remove-label status:in-progress \
  --remove-label status:spec-review --remove-label status:ready --add-label status:addressing

Re-verify what the change touched: re-run scripts/agent-gate.sh (with CQLITE_DATASETS_ROOT at the main repo) and re-run C (spec-auditor) if requirements/tests changed; roborev again if code changed materially.
Push + reply. git -C <worktree> push, then reply on each $PR thread with what changed (commit ref), and flip back to exactly one lifecycle label:
```
gh issue edit <N> --remove-label status:addressing --add-label status:in-review
```
Re-certify and re-arm merge-on-green (#2667). The owner's comments are input, NOT a merge gate — unless a comment is an explicit HOLD: or raises a product/scope question. After addressing them, re-certify (lite + any diff-relevant targets; a full/delta gate per the gate contract if the certified SHA changed), re-run scripts/flow/premerge-assert.sh <pr> <certified-sha>, then re-arm gh pr merge --auto --squash --delete-branch.