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

research-question

스타133

포크15

업데이트2026년 6월 22일 01:42

Use when the user has a vague topic or area of interest and wants it sharpened into a few strong, novel, feasible research questions. Drafts candidate questions, scores each against a fixed rubric (Specific, Answerable, Novel, Feasible, Significant) with a light literature/web novelty check, and revises the weakest axis until enough questions clear the bar. Not for grading a full written proposal (use the research-proposal loop), and not for turning a question into testable predictions (use the hypothesis-generation loop).

설치

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

Manus에서 실행

출처

gaasher

gaasher/Agent-Loop-Skills

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

다운로드

Manus에서 실행

관련 직업SOC

SOC 직업 분류 기준

파일 탐색기

2 개 파일

SKILL.md

readonly

이 저장소의 다른 Skills

같은 저장소

swe-loop

gaasher/Agent-Loop-Skills

Use when the user has a coding prompt — a feature, bug fix, or refactor — and wants it implemented end to end by a self-checking software loop, not a single pass. It refines the prompt into an executable plan (running the plan-loop internally), then executes the plan task by task: an Engineer subagent implements each PR-sized task editing only source, a separate QA subagent authors the tests that prove the task's acceptance criteria (or grades quality only when tests already cover them), runs the task's tests plus the full accumulated regression suite, and grades the code against a strict conciseness/readability/style-match rubric; the Engineer and QA loop on each task until the tests pass and the quality gate holds, then it commits and opens a pull request for the task — stacked PRs (one per task, each based on the prior) by default, or one combined PR — and moves to the next task. Author and critic have disjoint write scopes (Engineer owns source, QA owns tests) so neither can game the gate. Not for produci

2026-06-30133

plan-loop

gaasher/Agent-Loop-Skills

Use when the user has a coding or engineering prompt and wants it refined into a detailed, executable plan before any code is written — the planning stage of a prompt → plan → execute → debug pipeline. It decomposes the prompt from first principles (objective, end state, environment, building blocks, tools, packages), breaks the work into PR-sized tasks each tied to a component with its files, tests, and dependencies, orders them topologically, splits each into atomic subtasks, then a separate principal-engineer agent critiques the plan for alignment, coverage, sizing, and executability; it revises until the critique passes, emitting a plan.md layout and a structured tasks.json that a junior engineer or a smaller model can execute correctly. Not for executing, scaffolding, or debugging the plan (those are downstream loops), and not for research proposals or experiment plans.

2026-06-29133

blue-team

gaasher/Agent-Loop-Skills

Use when the user has concrete failing cases in code or a guardrail/classifier/filter/prompt/API they own — a red-team failure catalogue OR a CI/CD test-failure report (failing pytest/JUnit tests) — and wants the target patched until those failures are closed without breaking what already works. It points straight at the failed cases (normalize any source with tools/ingest.py), fixes one root-cause class per iteration, and re-checks with tools/verify.py — oracle mode against a red-team oracle, or tests mode against the test suite — keeping a patch only if it closes a class while nothing that passed before regresses, else reverting; loops until every class is closed (dry) or the budget runs out, then opens a pull request with the patch set. The defensive fixer half of a find→fix setup. Not for discovering new failures (that is red-team), and not for editing the oracle, tests, or holdout that define ground truth.

2026-06-28133

purple-team

gaasher/Agent-Loop-Skills

Use when the user wants to automatically harden a guardrail, classifier, content filter, prompt, or API they own by running attack and defense together as a closed loop, not just one or the other. It orchestrates the red-team and blue-team loops as independent agents: red finds distinct failure classes against the frozen target, blue patches the target to close them under a regression gate, then a fresh red pass re-verifies — confirming each class is closed and surfacing any new ones the fix introduced. The find→fix→re-verify cycle repeats until a fresh attack pass stays dry (the target is hardened) or a cycle budget is hit, then it opens a pull request with the patch set. Not for attacking a system the user is not authorized to test, and not for a one-shot scan — use red-team alone to only find, or blue-team alone to only fix.

2026-06-28133

scientific-figure

gaasher/Agent-Loop-Skills

Use when the user has scientific data (or a prompt alluding to scientific data) and wants a publication-quality figure made from it. A generator drafts and renders a figure that lands a frozen communication goal; an adversarial critic critiques it hard and grades it 1-5 per axis against a fixed rubric (message, aesthetic, clarity, integrity, and a conditional domain-completeness axis), aggregates to 0-100, and decides pass; the generator revises against the critic's findings until the grade clears a threshold or the budget is hit. Both roles may consult the literature (Semantic Scholar + arXiv) to verify domain content (e.g. a pathway figure's gene set, or a benchmark's reported numbers), and conform to / grade against a named journal's figure spec fetched via web search. Not for writing a paper or analyzing a dataset, and not for editing an existing finished image — this renders a figure from data/brief and iterates on it.

2026-06-23133

ml-autoresearch

gaasher/Agent-Loop-Skills

Use when the user wants an autonomous ML research loop that does more than blindly try changes. After every training run the agent analyses what actually happened inside the model — gradients, activations, embeddings, errors, data — and grounds the next change in that evidence. A `<literature>` on/off dial adds scientific-literature grounding: off behaves as a pure analysis-first loop; on searches papers, grades the evidence, and implements only what prior work supports. One change per run; loops forever until interrupted. Not for one-off training runs or hyperparameter sweeps.

2026-06-22133

name	research-question
description	Use when the user has a vague topic or area of interest and wants it sharpened into a few strong, novel, feasible research questions. Drafts candidate questions, scores each against a fixed rubric (Specific, Answerable, Novel, Feasible, Significant) with a light literature/web novelty check, and revises the weakest axis until enough questions clear the bar. Not for grading a full written proposal (use the research-proposal loop), and not for turning a question into testable predictions (use the hypothesis-generation loop).
compatibility	Requires Python 3.9+
metadata	{"version":"0.1.0"}

Research Question Loop

A sharpen → score → revise loop for the framing stage of research. The artifact is a small set of research questions; the feedback signal is how many clear the bar — each scored 0-5 on five fixed axes (Specific, Answerable, Novel, Feasible, Significant). You start from a vague topic, draft candidates, score each against the rubric (with a light novelty check against the literature), and rewrite the weakest axis of the promising ones until enough are strong.

A good research question is the hard part of research: too broad and it cannot be answered; too narrow and it does not matter; already settled and there is no point. The goal is a few excellent questions, not many mediocre ones — this loop drives toward the narrow band that is answerable, novel, and worth answering.

Scope & limitations

This loop produces and refines questions, grounded by a light novelty check (a few searches), not a full survey — for an exhaustive map use the literature-survey loop, and to turn a question into testable predictions use the hypothesis-generation loop. The novelty check needs web or literature access; without it (novelty_check: none), novelty is the loop's best judgment and must be labeled unverified.

When to use

Use when the user has a topic, area, or rough curiosity and wants it turned into concrete questions worth pursuing. Default: run the full draft→score→revise loop below. Escape hatch: if the user only wants candidates rated (no rewriting), score the set once and report the rubric breakdown. Not for grading a finished proposal, and not for generating hypotheses or experimental designs.

Setup

Resolve bindings interactively. If loop.run.yaml exists in the working dir, load it, confirm the values in one line, and skip to the loop. Otherwise: on Claude Code (the AskUserQuestion tool is available) infer a likely value for each binding and present it as the recommended option; on other hosts ask each as a quoted plain-text prompt. Then write loop.run.yaml (format: examples/run.example.yaml) and confirm the values before creating any other files.

binding	meaning	default	how to infer
`<topic>`	the area of interest (field, population, scope, what the user already cares about)	—	ask the user
`<n_questions>`	how many strong questions to deliver	3	—
`<pass_threshold>`	rubric score (0-100) a question must clear to count as strong	75	a solid question without demanding perfection
`<novelty_check>`	how to check whether a question is already answered: `lit` \| `web` \| `none`	`lit` if the sibling skill is installed, else `web`	probe for the literature-search skill (below)
`<report>`	output question set	`<sandbox_root>/questions.md`	—
`<sandbox_root>`	where the ledger and report live	`./sandbox`	—
`<budget>`	max iterations	8	—

Novelty toolchain (only for novelty_check: lit). Paper search goes through the sibling literature-search skill (<lit> = <lit_skill_dir>/tools/lit_search.py, with <lit_py> = python3 and <lit_skill_dir> its installed location, e.g. ~/.claude/skills/literature-search/); the relevant moves are <lit> search "<q>" (is a direct answer already published?) and <lit> snippet "<q>" (pinpoint the answering passage). Confirm <lit> --help works at setup; if the skill is absent, tell the user and either install it (copy the repo's loops/literature-search folder into ~/.claude/skills/) or degrade to web (host WebSearch/WebFetch) or none. Record the resolved choice in <novelty_check> so re-runs are non-interactive.

The loop

The rubric (a fresh Grader scores each question 0-5 per axis — see grading below):

Axis	5	3	1
Specific	one clear construct/relationship, well-scoped	direction clear, scope loose	broad/ambiguous topic, not a question
Answerable	a concrete study/analysis could resolve it; the answer-shape is clear	resolvable in principle, approach unclear	not empirically/analytically decidable
Novel	open per the novelty check; closest work cited	partly addressed; a real twist remains	already answered (check found a direct answer)
Feasible	data/methods/access plausibly exist	feasible with effort	needs unavailable data or impossible measurement
Significant	answering it changes understanding or practice	a useful increment	marginal even if answered

Grading — spawn a fresh Grader per iteration (spawn-or-degrade). Each iteration, spawn a freshly instantiated Grader subagent — separate from whoever drafted or revised the questions, so the score is independent and not self-graded — and give it each candidate plus its novelty evidence. It returns the five raw 0-5 per-axis points (no weights). On Claude Code spawn it as a real Agent; otherwise adopt the Grader role inline in a clean pass. The orchestrator sums to a raw score out of 25, then converts to the 0-100 score used everywhere:

total = 100 × raw / 25 (e.g. raw 20/25 → total 80).

A question is strong when total ≥ <pass_threshold> and no axis scored 1 (a single fatal axis sinks it regardless of total).

Copy this checklist and tick items off:

Iteration 0 — restate <topic> and what is interesting about it; draft 3-5 candidate questions spanning different angles (mechanism, comparison, condition/boundary, application). Record nothing as strong yet.
Gather novelty evidence per candidate via <novelty_check> (<lit> search/snippet, or WebSearch, or skip).
Score — spawn a fresh Grader with each candidate + its evidence; it returns raw 0-5 per axis; convert raw/25 → total/100.
Diagnose each promising question's lowest axis — the one thing keeping it from strong.
Revise that one axis (one focused move per question); drop a fatally-flawed question revision cannot save; add a fresh candidate if short.
Append a ledger row; stop when <n_questions> clear the bar, or at <budget>.

Iteration 0 — frame & draft. Restate <topic> and what is interesting about it; draft 3-5 candidate questions spanning different angles. Record nothing as strong yet.

Then, until stop (<n_questions> strong, or <budget>):

Gather novelty evidence. Run the <novelty_check> for each candidate's core: <lit> search/snippet (or WebSearch). If a direct answer exists, note the closest answered work; if only related work exists, note the open part. Each <lit> call prints JSON; on failure it prints {"error","fallback"} and exits non-zero — then fall back to WebSearch/WebFetch.
Score. Spawn a fresh Grader (spawn-or-degrade) and hand it each candidate plus its evidence; it returns the raw per-axis points. Convert raw/25 → total/100.
Diagnose & revise. Find each promising question's lowest axis and make one focused move on it: narrow an over-broad question to a specific population/condition; operationalize an unanswerable one into a measurable comparison; pivot an already-answered one toward the part the check showed is still open; raise significance by tying it to a decision or a contested claim. Drop questions with a fatal axis that revision cannot save; add a fresh candidate if you are short.
Log one ledger row and continue until <n_questions> are strong.

On stop, write <report>: each strong question with its rubric scores, the novelty note (closest answered work / the open part), why it is answerable (the study-shape that would resolve it), and why it matters — plus any runners-up and the axis that held them back.

Ledger

<sandbox_root>/ledger.tsv, tab-separated, never commas in the text. Header:

iter	question	total	weakest_axis	revision

Example:

iter	question	total	weakest_axis	revision
0	how does sleep affect learning	35	specific	drafted; far too broad
1	does sleep timing affect retention	62	answerable	operationalized: spaced-review vs sleep-matched review, 1-week retention
2	does post-learning sleep within 3h beat delayed sleep for procedural retention	86	-	strong (novel per check: tested for declarative not procedural)

Report the best outcome — the strong questions and their scores — not necessarily the last iteration's set.

Constraints

A few strong questions beat many weak ones — do not pad <report> with questions that do not clear the bar; report them as runners-up with the blocking axis instead.
Novelty is checked, not assumed — when <novelty_check> is lit/web, actually search, cite the closest answered work, and never claim novelty the check contradicts. When none, label novelty unverified.
Grade with a fresh Grader scoring raw 0-5 per axis (no weights); the orchestrator converts raw/25 → 100 and never lets the drafter/reviser grade its own questions, so the score stays honest.
One focused revision per question per iteration, targeting its weakest axis, so improvement is attributable and questions converge rather than thrash.
Keep the rubric and threshold fixed so "strong" means the same thing throughout.
The sandbox is self-contained — no ../ escapes. Do not pause the loop to ask whether to continue; run until <n_questions> clear the bar or <budget> is hit.