Best for
- Use when user says "全流程", "full pipeline", "从找idea到投稿", "end-to-end research", or wants the complete autonomous research lifecycle.
wanshuiyin/Auto-claude-code-research-in-sleep/skills/research-pipeline/SKILL.md
Use it for operations and research tasks; the detail page covers purpose, installation, and practical steps.
Decision brief
⏱ External cadence: non-judgmental heartbeat only. An overnight /loop / CronCreate heartbeat may wake, detect a stalled phase (no progress, dead process, blocked on a freed resource) and nudge it forward — it may NEVER decide the work is good (paper good enough, proof holds, cla…
Compatibility matrix
| Platform | Status | Evidence | What to check |
|---|---|---|---|
| Codex | Not declared | No explicit evidence | Portability before use |
| Claude Code | Not declared | No explicit evidence | Portability before use |
| Cursor | Not declared | No explicit evidence | Portability before use |
| Gemini CLI | Not declared | No explicit evidence | Portability before use |
Installation
The source command is displayed only when detected. A safe inspection prompt is always available so your agent can explain every action before execution.
npx skills add https://github.com/wanshuiyin/Auto-claude-code-research-in-sleep --skill "skills/research-pipeline"Inspect the Agent Skill "research-pipeline" from https://github.com/wanshuiyin/Auto-claude-code-research-in-sleep/blob/014c16e0e58198e4230fafd246b0e6203892422f/skills/research-pipeline/SKILL.md at commit 014c16e0e58198e4230fafd246b0e6203892422f. List every install step, command, network request, credential, file read/write, external action, and rollback step. Explain whether it fits my task. Do not install or execute anything until I approve.
Workflow
If RESEARCHBRIEF.md exists in the project root, it will be automatically loaded as detailed context (replaces one-line prompt). See templates/RESEARCHBRIEFTEMPLATE.md.
Once the idea is selected (automatically or by the user), delegate implementation and deployment to /experiment-bridge:
Once initial results are in, start the autonomous improvement loop:
After the auto-review loop completes, prepare the handoff for paper writing.
Skip this stage if AUTOWRITE=false (default). Present the /paper-writing command for manual use:
Permission review
The documentation asks the agent to create, modify, or delete local files.
- **[Output Versioning Protocol](../shared-references/output-versioning.md)** — write timestamped file first, then copy to fixed nameThe documentation asks the agent to create, modify, or delete local files.
**Large file handling**: If the Write tool fails due to file size, immediately retry using Bash (`cat << 'EOF' > file`) to write in chunks. Do NOT ask the user for permission — just do it silently.Evidence record
| Signal | Value | Evidence type | Meaning |
|---|---|---|---|
| Quality score | 93/100 | Computed | Documentation, specificity, maintenance, and trust rules |
| Repository stars | 15,246 | Source | Repository attention, not individual Skill quality |
| Compatibility | 0 platforms | Source | Declared in the catalog source record |
| Usage guide | automated source guide | Editorial | Generated or reviewed according to the visible evidence level |
Pinned source
⏱ External cadence: non-judgmental heartbeat only. An overnight
/loop/CronCreateheartbeat may wake, detect a stalled phase (no progress, dead process, blocked on a freed resource) and nudge it forward — it may NEVER decide the work is good (paper good enough, proof holds, claim supported). Every such verdict stays on its own skill's internal cadence and terminates in the cross-model jury. A heartbeat may say "keep going," never "good enough." Seeshared-references/external-cadence.md(overnight-pipeline rule + stall detection & forced structural pivot). At heartbeat startup, touch the run state first each tick and register this run with the watchdoglooptype (so a silent death surfaces as STALE); unregister on completion. The watchdog only detects — it never acquits. Each tick also record the new-finding count via theiteration_log.pyhelper (resolve through the canonical.aris/tools → tools → $ARIS_REPO/tools → $ARIS_REPO/tools via ~/.aris/repochain, integration-contract §2; warn-and-skip if unresolved):python3 "$ITER_LOG" note <root> <run_id> <phase> <n>. On the returnedpivot=structural(stale ≥ 2) the nudge must change a STRUCTURAL constraint and pick an untried direction; onpivot=human(stale ≥ 4) flag for attention. Counting only — never a quality verdict.
End-to-end autonomous research workflow for: $ARGUMENTS
AUTO_PROCEED = true — When true, every selection checkpoint is informational: report the choice and continue in the same turn. When false, ask for explicit user confirmation and end the turn at the checkpoint.
ARXIV_DOWNLOAD = false — When true, /research-lit downloads the top relevant arXiv PDFs during literature survey. When false (default), only fetches metadata via arXiv API. Passed through to /idea-discovery → /research-lit.
HUMAN_CHECKPOINT = false — When true, the auto-review loops (Stage 3) pause after each round's review to let you see the score and provide custom modification instructions before fixes are implemented. When false (default), loops run fully autonomously. Passed through to /auto-review-loop.
REVIEWER_DIFFICULTY = medium — How adversarial the reviewer is. medium (default): standard MCP review. hard: adds reviewer memory + debate protocol. nightmare: GPT reads repo directly via codex exec + memory + debate. Passed through to /auto-review-loop.
CODE_REVIEW = true — GPT-5.6-Sol xhigh reviews experiment code before deployment. Catches logic bugs before wasting GPU hours. Set false to skip. Passed through to /experiment-bridge.
BASE_REPO = false — GitHub repo URL to use as base codebase. When set, /experiment-bridge clones the repo first and implements experiments on top of it. When false (default), writes code from scratch or reuses existing project files. Passed through to /experiment-bridge.
COMPACT = false — When true, generates compact summary files for short-context models and session recovery. Passed through to /idea-discovery and /experiment-bridge.
AUTO_WRITE = false — When true, automatically invoke Workflow 3 (/paper-writing) after Stage 4. Requires VENUE to be set. When false (default), Stage 4 generates NARRATIVE_REPORT.md and stops — user invokes /paper-writing manually.
VENUE = ICLR — Target venue for paper writing (Stage 5). Only used when AUTO_WRITE=true. Options: ICLR, NeurIPS, ICML, CVPR, ACL, AAAI, ACM, IEEE_CONF, IEEE_JOURNAL.
RENDER_HTML = true — When true (default), auto-render NARRATIVE_REPORT.md to HTML at Stage 4 completion via /render-html. Uses --no-review (this is an internal handoff doc to /paper-writing, not a reviewer-facing final artifact — the upstream Stage 3 auto-review loop already cross-model-reviewed the claims). Set false to skip, or pass — render html: false. Non-blocking: if /render-html fails or Codex MCP is unavailable, log the failure and continue — the HTML view is a nice-to-have, not a Stage 4 prerequisite.
RESUMABLE = true — When true (default), the pipeline records per-stage state to .aris/runs/<run_id>.json so a crashed/interrupted run can resume via /research-pipeline — resume <run_id> instead of restarting. Stage status splits done (executor finished writing) from accepted (the stage's cross-model gate / deterministic verifier passed); resume re-validates any done-but-unaccepted stage. See shared-references/resumable-runs.md.
💡 Override via argument, e.g.,
/research-pipeline "topic" — AUTO_PROCEED: false, human checkpoint: true, difficulty: nightmare, code review: false, base repo: https://github.com/org/project, auto_write: true, venue: NeurIPS.
Resolve AUTO_PROCEED once from $ARGUMENTS before Stage 1 and pass that
resolved value to nested workflows.
AUTO_PROCEED=true is non-blocking. A checkpoint is a progress update,
not a question. State the result and the automatically selected next action,
then continue executing in the same turn. Do not ask for confirmation,
request user input, sleep, wait for silence, or end the turn at a checkpoint.AUTO_PROCEED=false is blocking. Present the options, ask the user, and
end the turn. Resume only after an explicit reply.Never implement auto-proceed as “ask, then continue if there is no response.” Once a turn ends, silence cannot resume the pipeline. The user can still interrupt a non-blocking run at any time.
This rule governs only AUTO_PROCEED-controlled selection checkpoints. If the
user explicitly enables a Feishu interactive gate, that external approval
or reply is an intentional blocking exception; wait for that user-controlled
gate rather than treating it as a silence timeout. Feishu off/push-only modes
remain non-blocking under AUTO_PROCEED=true.
This skill chains the entire research lifecycle into a single pipeline:
/idea-discovery → /experiment-bridge → /auto-review-loop → /paper-writing (optional)
├── Workflow 1 ──┤├── Workflow 1.5 ──┤├── Workflow 2 ───┤ ├── Workflow 3 ──┤
It orchestrates up to four major workflows in sequence. Workflow 3 (paper writing) is optional and controlled by AUTO_WRITE.
— resume <run_id>)This pipeline is long and can fail mid-run; it tracks per-stage state via
run_state.py so you can resume instead of restarting (see
shared-references/resumable-runs.md).
Skip this whole section if RESUMABLE = false.
Resolve the helper via the canonical chain (integration-contract §2):
.aris/tools/run_state.py → tools/run_state.py → $ARIS_REPO/tools/run_state.py
→ $ARIS_REPO/tools/run_state.py via ~/.aris/repo
(warn-and-skip if unresolved — never block the pipeline).
Phases, in order: idea-discovery, experiment-bridge, auto-review-loop, summary, paper-writing.
At start: if — resume <run_id> was passed, run
run_state.py resume <root> <run_id> — it prints the first non-accepted
phase; begin the pipeline at that stage (re-run a running/failed stage;
re-audit a done-but-unaccepted stage). Otherwise derive <run_id> from
the direction slug + date and run_state.py start <root> <run_id> --phases "idea-discovery,experiment-bridge,auto-review-loop,summary,paper-writing".
Per stage: set <run_id> <phase> running on entry; set <run_id> <phase> done --artifact <path> once the stage's artifact is written.
Mark accepted ONLY after the stage's gate passes — never on the executor's
own say-so (run_state.py accept requires a recorded verdict id + reviewer):
| phase | what sets accepted | record as reviewer |
|---|---|---|
idea-discovery | Gate 1 cross-model jury / novelty-check passed | codex-gpt-5.6-sol + thread id |
experiment-bridge | experiments actually ran (jobs completed) — deterministic | deterministic:experiment-bridge |
auto-review-loop | the loop hit its positive STOP (score>=6 AND verdict∈{ready,almost} — codex's verdict) | codex-gpt-5.6-sol + final review trace id |
summary | NARRATIVE_REPORT.md written (+ rendered if RENDER_HTML) — deterministic | deterministic:summary |
paper-writing | submission audits passed (verify_paper_audits.sh exit 0) — deterministic | deterministic:verify_paper_audits.sh |
If AUTO_WRITE = false (default), paper-writing is not part of this run:
after summary is accepted, set <run_id> paper-writing skipped so resume
reports COMPLETE instead of pointing forever at a pending stage. Record each
accept verdict_id as a durable handle — the codex thread/trace id, or the
path/sha of the deterministic verifier's report (e.g. the verify_paper_audits.sh
output JSON) — not just the reviewer label.
A stage left done (gate failed/ambiguous, or the run crashed before the gate)
is re-validated on the next resume — the acceptance obligation is never skipped.
Only when an unattended heartbeat is driving this run (overnight /loop /
CronCreate). Skip otherwise. Doctrine + rationale:
shared-references/external-cadence.md
→ "Stall detection & forced structural pivot". This is a Type-A signal — it counts
findings and changes direction, never judges quality.
Resolve the helper via the canonical chain (integration-contract §2), warn-and-skip if unresolved (never block the run):
ITER_LOG=".aris/tools/iteration_log.py"
[ -f "$ITER_LOG" ] || ITER_LOG="tools/iteration_log.py"
[ -f "$ITER_LOG" ] || ITER_LOG="${ARIS_REPO:-}/tools/iteration_log.py"
[ -f "$ITER_LOG" ] || { [ -z "${ARIS_REPO:-}" ] && [ -f "$HOME/.aris/repo" ] && ARIS_REPO="$(cat "$HOME/.aris/repo" 2>/dev/null)"; } || true
[ -f "$ITER_LOG" ] || ITER_LOG="${ARIS_REPO:-}/tools/iteration_log.py"
[ -f "$ITER_LOG" ] || { echo "WARN: iteration_log.py not resolved; skipping stall detection" >&2; ITER_LOG=""; }
Then, each heartbeat tick, record how many concrete new findings the current
stage produced and read the returned pivot:
[ -n "$ITER_LOG" ] && python3 "$ITER_LOG" note "$ROOT" "$RUN_ID" "$STAGE" "$N_NEW_FINDINGS"
# → {"stale_count": N, "pivot": "none|structural|human"}
Act on pivot:
none — keep going.structural (stale ≥ 2) — the next nudge must change a structural constraint
(frame / objective / data / representation), not a tactical parameter, and pick a
direction different from every one already tried. Record the chosen frame so future
ticks can avoid it: python3 "$ITER_LOG" note "$ROOT" "$RUN_ID" "$STAGE" 0 --direction "<the new frame>".human (stale ≥ 4) — stop nudging blindly; flag for human attention (escalate, do
not silently abandon).The heartbeat may say "keep going / change direction," never "good enough" — every
quality verdict still terminates in the cross-model jury (acceptance-gate.md).
If RESEARCH_BRIEF.md exists in the project root, it will be automatically loaded as detailed context (replaces one-line prompt). See templates/RESEARCH_BRIEF_TEMPLATE.md.
Invoke the idea discovery pipeline:
/idea-discovery "$ARGUMENTS" — AUTO_PROCEED: $AUTO_PROCEED
This internally runs: /research-lit → /idea-creator → /novelty-check → /research-review
Output: idea-stage/IDEA_REPORT.md with ranked, validated, pilot-tested ideas.
🚦 Gate 1 — Idea Selection:
After idea-stage/IDEA_REPORT.md is generated, present the top ideas.
If AUTO_PROCEED=true (non-blocking): report the selection and continue
immediately in the same turn. Do not phrase the update as a question:
📋 Idea Discovery complete. Top ideas:
1. [Idea 1 title] — Pilot: POSITIVE (+X%), Novelty: CONFIRMED
2. [Idea 2 title] — Pilot: WEAK POSITIVE (+Y%), Novelty: CONFIRMED
3. [Idea 3 title] — Pilot: NEGATIVE, eliminated
AUTO_PROCEED: selected Idea 1 — [title]. Continuing to Stage 2.
If AUTO_PROCEED=false (blocking): present the same ranking, ask
Recommended: Idea 1. Shall I proceed with implementation?, then end the turn.
The user may:
/experiment-bridge reads refine-logs/EXPERIMENT_PLAN.md already generated by /idea-discovery./idea-discovery with refined constraints, and present again.idea-stage/IDEA_REPORT.md for future reference.⚠️ This gate waits for user confirmation when AUTO_PROCEED=false. When
true, it auto-proceeds after presenting results. The rest of the pipeline (Stages 2-3) is expensive (GPU time + multiple review rounds), so setAUTO_PROCEED=falseif you want a final review checkpoint before committing GPU resources.
Once the idea is selected (automatically or by the user), delegate implementation and deployment to /experiment-bridge:
/experiment-bridge "$CHOSEN_IDEA_TITLE" — code review: $CODE_REVIEW, base repo: $BASE_REPO, compact: $COMPACT
💡 Queue routing is automatic:
/experiment-bridgePhase 4 routes each milestone by job count — ≤5 jobs →/run-experiment, ≥10 jobs or teacher→student phase dependencies →/experiment-queue(with OOM retry, wave gating, crash-safe state). No manual override is needed.
What this does (fully autonomous):
refine-logs/EXPERIMENT_PLAN.md — extracts milestones, run order, compute budget/codex:rescue fallback)/run-experiment, ≥10 → /experiment-queue with OOM retry, wave gating, crash-safe state)refine-logs/EXPERIMENT_TRACKER.md, runs /training-check if W&B is configured/ablation-planner if main results are positiveOutput:
refine-logs/EXPERIMENT_RESULTS.md — structured results by milestonerefine-logs/EXPERIMENT_TRACKER.md — updated run-by-run statusEXPERIMENT_LOG.md (when COMPACT=true) — session-recovery-friendly logMonitor progress (while experiments run):
/monitor-experiment [server]
Wait for /experiment-bridge to complete and report its handoff summary before proceeding.
Once initial results are in, start the autonomous improvement loop:
/auto-review-loop "$ARGUMENTS — [chosen idea title], difficulty: $REVIEWER_DIFFICULTY"
What this does (up to 4 rounds):
Output: review-stage/AUTO_REVIEW.md with full review history and final assessment.
After the auto-review loop completes, prepare the handoff for paper writing.
Step 1: Write a final research status report (same as before).
Step 2: Generate NARRATIVE_REPORT.md from:
IDEA_REPORT.md (chosen idea, hypothesis, novelty justification)AUTO_REVIEW.md (review history, weaknesses fixed, remaining limitations)The narrative report must contain:
Output: NARRATIVE_REPORT.md + research pipeline report.
# Research Pipeline Report
**Direction**: $ARGUMENTS
**Chosen Idea**: [title]
**Date**: [start] → [end]
**Pipeline**: idea-discovery → experiment-bridge → auto-review-loop
## Journey Summary
- Ideas generated: X → filtered to Y → piloted Z → chose 1
- Implementation: [brief description of what was built]
- Experiments: [number of GPU experiments, total compute time]
- Review rounds: N/4, final score: X/10
## Writing Handoff
- NARRATIVE_REPORT.md: ✅ generated
- Venue: [VENUE or "not set — run /paper-writing manually"]
- Manual figures needed: [list or "none"]
## Remaining TODOs (if any)
- [items flagged by reviewer that weren't addressed]
Skip this stage if AUTO_WRITE=false (default). Present the /paper-writing command for manual use:
📝 Research complete. To write the paper:
/paper-writing "NARRATIVE_REPORT.md" — venue: ICLR, AUTO_PROCEED: $AUTO_PROCEED
If AUTO_WRITE=true:
🚦 Gate 2 — Writing Checkpoint:
📝 Research pipeline complete. Ready for Workflow 3.
- Venue: [VENUE]
- Input: NARRATIVE_REPORT.md
- Manual figures required: [list or none]
- Next step: /paper-writing "NARRATIVE_REPORT.md" — venue: [VENUE], AUTO_PROCEED: $AUTO_PROCEED
Proceeding with paper writing...
Checks before proceeding:
VENUE is missing → stop and ask. Do NOT silently use a default venue.Then invoke:
/paper-writing "NARRATIVE_REPORT.md" — venue: $VENUE, AUTO_PROCEED: $AUTO_PROCEED
Pass the resolved AUTO_PROCEED explicitly so Workflow 3 cannot silently
fall back to its own default mode.
This delegates to Workflow 3 which handles its own phases:
/paper-plan → /paper-figure → /paper-write → /paper-compile → /auto-paper-improvement-loop
When Workflow 3 finishes, update the pipeline report with:
paper/main.pdf)Output: paper/ directory with LaTeX source, compiled PDF, and PAPER_IMPROVEMENT_LOG.md.
RENDER_HTML = true)After Stage 4 finalizes NARRATIVE_REPORT.md (before paper writing branches), invoke /render-html on the narrative report:
/render-html "NARRATIVE_REPORT.md" --no-review
--no-review is intentional: this is an internal handoff doc, not reviewer-facing — the claims it summarizes were already cross-model-reviewed in Stage 3's /auto-review-loop. Output: NARRATIVE_REPORT.html next to the MD, with embedded source SHA256.
Non-blocking: if /render-html fails (helper missing, file write error, etc.), log the failure and continue Stage 4 — the HTML view is a convenience artifact, not a pipeline prerequisite.
Skip this step if RENDER_HTML = false.
Follow these shared protocols for all output files:
- Output Versioning Protocol — write timestamped file first, then copy to fixed name
- Output Manifest Protocol — log every output to MANIFEST.md
- Output Language Protocol — respect the project's language setting
Large file handling: If the Write tool fails due to file size, immediately retry using Bash (cat << 'EOF' > file) to write in chunks. Do NOT ask the user for permission — just do it silently.
The Stage 1 checkpoint is controlled by AUTO_PROCEED. When false, do not proceed without user confirmation. When true, report the top selection and continue in the same turn without asking or waiting.
Stages 2-3 can run autonomously once the idea is selected. This is the "sleep and wake up to results" part.
If Stage 3 ends at round 4 without positive assessment, stop and report remaining issues. Do not loop forever.
Budget awareness: Track total GPU-hours across the pipeline. Flag if approaching user-defined limits.
Documentation: Every stage updates its own output file. The full history should be self-contained.
Fail gracefully: If any stage fails (no good ideas, experiments crash, review loop stuck), report clearly and suggest alternatives rather than forcing forward.
| Stage | Duration | Can sleep? |
|---|---|---|
| 1. Idea Discovery | 30-60 min | Yes if AUTO_PROCEED=true |
| 2. Experiment Bridge | 30-120 min (implement + review + deploy + collect) | Yes ✅ |
| 3. Auto Review | 1-4 hours (depends on experiments) | Yes ✅ |
Sweet spot: Run Stage 1 in the evening, launch Stage 2-3 before bed, wake up to a reviewed paper.
Frequently asked questions
⏱ External cadence: non-judgmental heartbeat only. An overnight /loop / CronCreate heartbeat may wake, detect a stalled phase (no progress, dead process, blocked on a freed resource) and nudge it forward — it may NEVER decide the work is good (paper good enough, proof holds, cla…
The source record exposes this install command: npx skills add https://github.com/wanshuiyin/Auto-claude-code-research-in-sleep --skill "skills/research-pipeline". Inspect the command and pinned source before running it.
Static rules flagged write-files in the source; the page lists the matching lines and excerpts.
Alternatives
wanshuiyin/Auto-claude-code-research-in-sleep
Use it for operations and research tasks; the detail page covers purpose, installation, and practical steps.
alirezarezvani/claude-skills
App Store Optimization (ASO) toolkit for researching keywords, analyzing competitor rankings, generating metadata suggestions, and improving app visibility on Apple App Store and Google Play Store. Use when the user asks about ASO, app store rankings, app metadata, app titles and descriptions, app store listings, app visibility, or mobile app marketing on iOS or Android. Supports keyword research and scoring, competitor keyword analysis, metadata optimization, A/B test planning, launch checklist
wanshuiyin/Auto-claude-code-research-in-sleep
Use it for operations and research tasks; the detail page covers purpose, installation, and practical steps.
prowler-cloud/prowler
PostgreSQL indexing best practices for Prowler: index design, partial indexes, partitioned table indexing, EXPLAIN ANALYZE validation, concurrent operations, monitoring, and maintenance. Trigger: When creating or modifying PostgreSQL indexes, analyzing query performance with EXPLAIN, debugging slow queries, reviewing index usage statistics, reindexing, dropping indexes, or working with partitioned table indexes. Also trigger when discussing index strategies, partial indexes, or index maintenance