菜单
Maintain a standing day/night GitHub issue pipeline so agents always have planned, reviewed, user-approved work for overnight execution and next-day QA/approval.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/vamseeachanta/workspace-hub --skill continuous-planning-pipeline命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
Write outbound email and external messages in Vamsee Achanta's voice — a subtle offer to help, never bold or rash claims. Load before drafting ANY email, LinkedIn/Collide reply, proposal note, or outreach sent under his name.
Save/publish analysis or computation results from ANY ecosystem repo to Hugging Face as a queryable, viewer-renderable dataset. Use when the user wants to "save results to hugging face", "publish dataset to HF", "hugging face data saving", "save analysis results", "hf dataset", "make results queryable", or "render via datasets-server API". Reshapes nested results into flat parquet tables, writes a dataset card with a viewer `configs:` block and provenance, applies license/public-vs-private routing, enforces a domain data-quality gate (faithful-to-source != correct), publishes to `aceengineer/<repo>-<projection>`, and verifies via the datasets-server API.
Clone, create, fork, configure, and manage GitHub repositories. Manage remotes, secrets, releases, and workflows. Works with gh CLI or falls back to git + GitHub REST API via curl.
正在显示 SKILL.md
基于 SOC 职业分类
| name | continuous-planning-pipeline |
| description | Maintain a standing day/night GitHub issue pipeline so agents always have planned, reviewed, user-approved work for overnight execution and next-day QA/approval. |
| version | 1.0.0 |
| author | Hermes Agent |
| category | coordination |
| triggers | ["User asks for continuous planning or continually working agents","User wants AFK / overnight issue throughput without queue starvation","User references maintaining a buffer of planned/reviewed/approved issues"] |
| related_skills | ["gh-work-planning","overnight-parallel-agent-prompts","github-issues","multi-provider-adversarial-review"] |
| tags | ["github","planning","overnight","afk-agents","issue-pipeline","adversarial-review"] |
Use this when the user wants agents to keep working continuously rather than running a one-off planning or implementation batch.
The core idea: maintain a standing buffer of GitHub issues in distinct readiness lanes so planning, implementation, review, and user approval can proceed in parallel across day/night cycles without violating plan gates.
docs/plans/.Maintain these lanes in reports and prompt packs.
Issues ready for user approval / revision / rejection.
Required evidence:
docs/plans/YYYY-MM-DD-issue-NNN-<slug>.mdstatus:plan-review or otherwise clearly awaiting approvalIssues safe for unattended implementation.
Required evidence:
status:plan-approved.planning/plan-approved/NNN.mdDo not treat GitHub labels alone as sufficient approval. Verify marker evidence from a checkout that is current with the execution base: after , if the active worktree is behind , inspect directly or create/freshen an isolated worktree before declaring a marker missing. A stale governance worktree can undercount committed files and misroute approved work back to approval drift. If a workflow uses revision-bound approval comments/plan branches instead of local numeric markers, treat that as unless/until the repo hooks and approval scripts have an approved policy recognizing that exact schema. Remote routine state or session transcripts never upgrade an issue into Lane B.
git fetchorigin/mainorigin/main.planning/plan-approved/NNN.mdapproval-driftHigh-value issues eligible for planning-only workers.
Typical evidence:
Issues already scheduled or running must be excluded from new implementation dispatch until reconciled. Do not use one overloaded active bucket; track sub-states:
scheduled: routine/cron created but no start evidence yetrunning: start comment or heartbeat existsblocked / failed / no-fire / stale: requires morning-loop decision before requeueEach dispatch needs a durable idempotency key, routine/job id, owner, scheduled/start/last-seen timestamps, dependency gates, lease scope, and expected output. Remote trigger state must be mirrored into GitHub/repo artifacts; it is not source-of-truth by itself.
Implementation output exists but is not done. Sub-states:
open-pr: branch/PR exists but QA handoff is incompletereview-ready: mandatory handoff exists and item is ready for human/provider reviewRequired Lane E handoff fields: issue, PR/branch, dispatch id, routine id, plan path/SHA, approval marker, changed files, tests/CI results, artifacts/screenshots where relevant, risks, blockers, adversarial implementation-review status, recommended human action, estimated review effort, and priority reason.
For workspace-hub-style plan-gated repos, aim to maintain:
If Lane B is empty, do not improvise implementation. Launch Lane C planning-only workers or Lane A approval-pack synthesis.
When the user proposes a new continuous-throughput operating idea:
A durable pipeline issue should include:
When the user asks for confidence in the lane model or approval flow, produce a compact ASCII flowchart and post it to the durable GitHub issue using --body-file.
Recommended sections:
Lane C -> Scope/Resource Intel/Repo Intel/Compliance Fit/Plan/TDD/Plan Review -> Lane A -> user approval -> Lane B -> TDD Implementation/Code Review/Morning QAstatus:plan-approved + local marker + clean/isolated worktreeThis visual artifact helps the user validate the workflow contract before implementation and is useful as a review target in the issue thread.
If the user says the model looks good and asks for the next logical step, start formal planning on the pipeline issue rather than jumping to code. Post a concise planning-intake comment with:
Then proceed through gh-work-planning Step 2 resource intelligence and canonical plan drafting.
Overnight prompt packs should state explicitly whether each worker is:
Each worker still needs:
For continuous-planning issues, do not treat a plan-review fanout run as valid merely because the wrapper exits 0 or writes a disagreement report.
Before moving an issue to status:plan-review, verify:
docs/plans/README.mdscripts/review/results/YYYY-MM-DD-plan-NNN-claude.mdscripts/review/results/YYYY-MM-DD-plan-NNN-codex.mdscripts/review/results/YYYY-MM-DD-plan-NNN-gemini.mdPlan-SHA256: <sha256sum-of-canonical-plan> headerPlan-SHA256Failure mode seen in live use: scripts/review/plan-review-fanout.sh returned success and wrote only YYYY-MM-DD-plan-NNN-disagreement.md, with an empty provider table and no Claude/Codex/Gemini artifacts. Treat that as INVALID / INCOMPLETE REVIEW RUN, preserve that fact in the artifact, and rerun through a side-effect-safe path before applying status:plan-review.
When the fanout path is unreliable, use a manual side-effect-safe rerun pattern:
sha256sum docs/plans/YYYY-MM-DD-issue-NNN-<slug>.md.Plan-SHA256: <sha> and an explicit ## Verdict block to every provider artifact.APPROVE or MINOR before posting the issue update or applying status:plan-review.If file writes appear inconsistent between file tools and shell tools, immediately re-check with shell commands from the repo root before dispatching review:
pwdgit status --shorttest -f docs/plans/YYYY-MM-DD-issue-NNN-<slug>.mdgrep -n 'issue-NNN-<slug>' docs/plans/README.mdWhen a continuous-pipeline plan is materially revised after cross-review or after comparing it with another autonomous-agent workflow, treat all prior approval/readiness state as potentially stale until resynced.
Required closeout pattern:
status:plan-review or approval narrative as if it still applies.## Adversarial Review Summaryscripts/review/results/Reviewed-Plan-SHA256: <sha-reviewed-by-providers>Plan-SHA256: <final-sha-after-summary-sync>status:plan-approved but no valid committed .planning/plan-approved/NNN.md, and the plan has materially changed, remove status:plan-approved and restore status:plan-review. This is approval drift, not execution authority.git status --short -- <files> and ensure no unrelated churn is staged.When the user asks to “create future issues, document, and prepare to exit” after a continuous-pipeline plan-review wave:
gh issue create --body-file; do not post markdown-rich bodies inline.gh issue list --state all --search ..., but do not block creation just because the parent pipeline issue appears in the search results.docs/reports/ summarizing:
--body-file, then immediately re-verify parent labels and marker state. Automation or concurrent agents may re-add status:plan-approved; if no valid committed marker exists after a material revision, restore status:plan-review.When the user asks to revisit repo features/issues to understand capabilities, data completeness, scheduler/source readiness, or what work can run overnight, treat it as a planning/audit batch, not implementation.
Recommended workflow:
git status, gh repo view, gh issue list --state open, labels, existing docs/plans/, review artifacts, and .planning/plan-approved/ markers.docs/reports/, a machine-readable companion artifact when useful, acceptance criteria with explicit evidence paths, and a strict boundary of "no implementation / no unbounded downloads" unless separately approved.docs/reports/ containing:
Important guardrails:
status:plan-approved label without a committed .planning/plan-approved/<issue>.md marker remains approval drift, not unattended execution authority.--help/status/config validation, bounded endpoint HEAD/GET calls, and explicitly time-boxed dry-runs. Prefer a small Python subprocess runner with per-command timeouts and a durable markdown report over one Bash script with a single outer timeout; otherwise the first hung import/CLI call can block the whole evidence pack.uv run python or scheduler import/no-op commands time out, create a blocker issue for local execution/import readiness and keep refresh/implementation work blocked until that is diagnosed. Do not spend overnight cycles on full refreshes while no-op commands hang.When syncing an issue from status:plan-review to status:plan-approved, verify the live and local approval surfaces from the narrowest reliable evidence rather than waiting on broad workspace scans.
Recommended fallback sequence when the normal path is slow or rate-limited:
gh issue view GraphQL is rate-limited:
gh api repos/OWNER/REPO/issues/NNN --jq '{state: .state, labels: [.labels[].name]}'
.planning/plan-approved/NNN.md.docs/plans/README.md row with targeted grep/test -f checks.git status is slow, verify only the target artifact set before staging/committing:
git status --short -- .planning/plan-approved/NNN.md docs/plans/<plan>.md docs/plans/README.md
git diff -- .planning/plan-approved/NNN.md docs/plans/<plan>.md docs/plans/README.md
HEAD equals upstream and post a GitHub handoff comment using --body-file.status:plan-approved labels without local marker and plan evidence.status:plan-review before provider-specific review artifacts exist and contain real verdicts.