research-idea

Research Idea

Goal

Establish the research context from user materials and auditable literature evidence, formulate scientific questions and falsifiable hypotheses, separately judge scientific value, credibility, and near-term investment, and form bounded recommendations, a conclusion of no qualified candidate within the current scope, or a conclusion of insufficient evidence. Candidates must come from the preceding investigation and must not be fabricated solely from the materials.

Adjacent Skills:research-topic-extractor extract search topics;research-literature-search generate rls.v1 candidates and provenance;research-literature-radar establish the full landscape;research-literature-interpretation interpret paper by paper;parallel-vibe independent review. For a complete review use research-literature-review, and for an experimental/analysis plan use research-plan。

Process

Input

• Required: at least one of text, files/directories, URL, paper clues, experimental phenomena, repository, or PR background.
• Optional: research goal, time/resource boundaries, output path, number of review rounds and number of reviewers.
• Default report directory:./docs/ideas/; default task area:./.bensz-api/task-{yyyymmdd-hhmm}-{简短描述}/research-idea/。
• By default, 3 review rounds with 3 people per round; at most 3 tasks in parallel for paper interpretation.

Execution Steps

1. Startup and summarization. Read run instructions, lock the task directory, and use only scripts/start_workflow.py to establish the BSK identity; begin the literature phase only when status=initialized and run/visit/attempt are non-empty. Summarize the goal contributions, the questions/decisions served, and the resource status, and save only the necessary de-identified content. Use research-topic-extractor to generate topics, 5–10 English keywords, and 2–5 core questions, and in input/theme.json cite the original artifacts.

1. Literature evidence. Use research-literature-radar to consume the Search manifest and all canonical candidates, and generate an item-by-item covered landscape and hash/count summary; stop when full reconciliation has not been performed or when the hash drifts. For selected papers, call research-literature-interpretation: one task per paper, at most 3 in parallel, no nesting; only call it an "independent agent" when there is a reconcilable host receipt. Prefer full text, and narrow conclusions when only the abstract is available; record stable sources, evidence depth/scope, questions, methods, results, limitations, and supporting/refuting relationships.

2. Research map. According to research synthesis guidelines write output/research-map.md, including research line comparisons, landscape coverage, key relationships, stable O opportunity numbers, R core paper anchors, and Search record IDs. Explain the objects/measurements, premises, strongest counterexamples, and the distinguishing evidence required; separate source relationships from "synthetic judgments pending verification." Temporal order, terminological similarity, or measurement differences do not automatically prove inheritance, causation, or contradiction.

3. Generate and screen candidates. Treat the user summary, topics, evidence, and map as shared facts, and use parallel-vibe n=3 to independently generate candidates; in the first round, do not preset the best direction, and agents do not read each other's drafts. Initially explore 3–7, and finally retain one or zero. According to report template Write the question, hypothesis, key predictions, counterevidence, value/non-triviality, innovation/disruption potential, incremental contribution over recent work, strongest alternative direction, credibility, investment, and contextual basis; use O/R numbers for work evidence, and O with academic citations for formal reports. Definitional assumptions, no knowledge increment, method names substituting for mechanisms, or meaningless scenario transfer should be prioritized for restructuring/elimination. If all fail, re-explore at most once with new evidence or a new explanation; if materials are insufficient, remain insufficient。

4. Candidate-level novelty search. For each candidate intended for retention, generate candidates/Cx/theme.json, propose 5–25 queries around direct near neighbors, equivalent hypotheses, opposing evidence, and applicable boundaries, and call research-literature-search to generate an independent rls.v1 bundle. Consume canonical candidates one by one, following the novelty search guide to save novelty/Cx/novelty-decision.json. Abstracts may exclude clearly non-equivalent work; only near neighbors that determine novelty are escalated to full text. If a decisive near neighbor has not been verified, it may enter review with a gap, but scientific_evidence_sufficient=false、claim_eligible=false. For eliminated items, record the reason novelty search was not performed; do not fabricate results.

5. Independent review and selection. According to review reference , execute the agreed rounds serially, by default sequentially challenging value, explanatory/discriminative ability, reselection, and transfer boundaries. Reviewers must independently read the evidence and have thread/done/RESULT completed receipts, model, input/output hashes, and timestamps; only RESULT, role-played drafts, or paraphrases do not count as required review. The main Agent synthesizes based on arguments and counterexamples, not by majority vote; after substantially rewriting the question/hypothesis, perform novelty search again. Report value, credibility, and investment separately; do not offset low value with feasibility.

6. Conclusion and report. The conclusion can only be recommended、no_qualified or insufficient；bounded_recommendation/degraded can be delivered in stages but cannot be completed. The abstract advances according to the question, existing answers, relationship to research lines, strongest near neighbors, and important unknowns, providing necessary terminology and key judgments with nearby citations; tables, timelines, or fixed length are not mandatory. Formal reports by default use the GB/T 7714—2025 sequential numbering system,reference_map save the one-to-one mapping of R to bibliography numbers, and finally cite according to ## References ; when a journal/degree style is specified, declare it according to the template and manually review. Before completion, check narrative coherence, evidence depth, opposing evidence, importance of gaps, and bibliographic metadata; do not disguise semantic review as a script Gate. According to report template , write the report and run:

python3 research-idea/scripts/validate_report.py --report "{最终报告路径}"
python3 research-idea/scripts/check_completion.py --project-root . --task-root "{本轮任务根}" --report "{最终报告路径}"

When customizing filenames, add for structural validation --allow-custom-name, or let the completion check read the manifest. Save research-idea/output/completion-evidence.json（schema research-idea-completion-v6), binding dependent artifacts, paper interpretation, reviewers, summary, and final synthesis. Only when the required Verifier, BSK Gate,completed status, and completion check all pass can completion be claimed.

Output

Finally deliver one Markdown file, default path:

./docs/ideas/Research-Idea_{github仓库名}_{pr名}_{时间戳}.md

When the repository/PR cannot be identified, use the current directory/branch; if that still fails, use repo/manual. The report includes evidence depth, research map, basis for candidates or zero candidates, value/credibility/investment, recent work, novelty search, counterevidence, risks, and minimum next steps; hidden task areas, test/parallel-vibe paths, manifest, or internal instructions must not be exposed.

Output management

Reuse one .bensz-api/task-* root for the same task; each Skill uses an independent input|output|log, and only cross-Skill materials are placed in shared/. Novelty searches, reviews, drafts, and logs remain in the hidden workspace; formal reports remain in the user directory.--task-root Must be inside the project; legacy --workspace-dir layouts are kept read-only and are not migrated automatically.

Validation

• Verify separately artifact_ready、execution_recorded、evidence_sufficient、claim_eligible; file existence or format passing does not prove a scientific claim. The v2 R anchor report is read-only compatible and cannot obtain v3 completion qualification.
• The search bundle retains rls.v1, query/canonical hash, counts and full-consumption status; paper interpretation, full-text sources and reviewer receipts can return to the source artifact.
• Proposed recommendation candidates must not skip multi-query novelty checking. When key coding manuals, independent ground truth, annotation consistency, audit/ethics prerequisites or baseline evidence are missing, only insufficient/bounded_recommendation。
• Test source code is located in tests/research-idea/; caches and logs are written to the task area. Versions are maintained only in config.yaml:skill_info.version ; interface or directory changes are synchronized with README, CHANGELOG and tests.

Failure and recovery

Retain error evidence and completed artifacts, and recover according to the run snapshot, Kernel projection, active attempt and original parameters. When evidence changes or the Verifier fails, use phase_entry.py --mode retry to supersede the attempt, then re-authorize/review; old handoffs, Gates and authorizations must not be reused. Stop when there is Skill/interpreter drift, legacy identity, snapshot corruption, Kernel unavailability or transition failure, and do not backfill historical identity or falsely claim completion.

Control

config.yaml:runtime declares five States and two required Verifiers; for the index see states and verifiers。stage-readiness judge pipeline/evidence/claim readiness, andhypothesis-merit interrogates novelty, non-triviality and disruptive potential. BSK is responsible for identity, binding, Gates, events and state; this Skill retains only domain adaptation.

At each stage, first use phase_entry.py --mode start to consume the action authorization of the current visit/attempt, then use --mode finish to obtain the handoff and submit the required result bound to the same evidence_hash/evidence_refs . Transition occurs only when all results are completed and pass; other verdicts remain in the current State.

scripts/edge_rules.py is shared by stage entry, completion checks and evidence-consistency: the hypothesis-merit applicability of the four forward edges is, in order, not_applicable、applicable、not_applicable、applicable. BSK validates evidence/Gate/transition binding, and the Skill reconciles paper interpretation and reviewer receipts. Legacy sites of v2–v5 or unbound transitions are kept read-only.

Constraints

Comply with the following common constraints, and enforce the specific boundaries of this Skill.

Common hard constraints

This block is maintained centrally by docs/templates/skill-common-constraints.md ; the SKILL.md of each ## 约束 must synchronize this block verbatim, and common rules must not be rewritten in copies.

• When the task requires writing to disk, use the unique ./.bensz-api/task-{yyyymmdd-hhmm}-{简短描述}/ root directory; place shared materials in shared/, and place Skill-specific materials in that Skill's input/、output/、log/。
• Formal deliverables, source code and formal plans are stored according to project conventions and are not written to the task workspace; without authorization, do not overwrite, delete, migrate or write remotely.
• Project maintenance changes check BAC availability and record requirements, AI outputs, tool results, file changes and verification summaries; BAC performs process auditing only and does not replace attribution, responsibility or compliance judgment.
• Do not record API Keys, access tokens, passwords, Cookies, environment/credential files, private Prompts, identity information, local usernames, hostnames or unnecessary large-volume raw data.
• File paths must be normalized and restricted to the authorized project scope; external URLs, subprocesses and network access follow least privilege to prevent path traversal, SSRF and command injection.
• The Skill version is uniquely recorded in its own config.yaml:skill_info.version; Public API, protocol, directory, or configuration changes must be synchronized with the documentation and CHANGELOG.md。
• bensz-collect-bugs is an Agent Skill; only design flaws in the Bensz Agent Skill or the Bensz infrastructure itself should be reported to it. First anonymize the data and write it into ~/.bensz-skills/bugs/, the current task is not interrupted, public reporting is only allowed when the user explicitly requests it, and directly modifying the source code of a Skill already installed by the user is prohibited.

Skill-specific constraints

Must not exceed the frontmatter description and the scope of the above process; must not disguise unverified information, unexecuted steps, or interim results as definitive conclusions.