duoshe

어떤 스킬인가요?

Analyze scholarly inputs — including Google Scholar queries, paper titles, abstracts, arXiv/DOI links, BibTeX entries, PDFs, citation lists, author profiles, or broad research directions — then produce a folder of Markdown artifacts containing per-paper summaries, a README overview, and a concrete research idea list. Use when asked to inspect academic literature, organize papers, identify research gaps, brainstorm follow-up research, design experiments, extend a paper idea, or generate project directions from scholarly sources.

설치 방법

프로젝트 폴더에서 아래 명령어를 실행하고, 설치할 에이전트를 선택하세요.

설치 명령을 직접 실행해야 적용됩니다. 지원 에이전트와 필요한 권한·라이선스는 제작자의 안내를 확인하세요.

스킬 원문 파일

interface:
  display_name: "夺舍 (Duoshe)"
  short_description: "Analyze papers and expand research ideas"
  default_prompt: "Use $duoshe to analyze these papers and propose grounded research idea extensions."

# Idea Patterns

Use these patterns to expand literature analysis into testable research ideas. Select only the patterns that fit the user's topic and evidence.

## Method Extensions

- Replace a brittle hand-designed component with a learned, adaptive, or uncertainty-aware component.
- Make an offline method work online, streaming, interactive, or under memory limits.
- Reduce supervision requirements through weak supervision, self-supervision, synthetic data, active learning, or transfer.
- Add calibration, uncertainty estimation, abstention, or failure prediction.
- Improve robustness under distribution shift, occlusion, noise, adversarial examples, rare cases, or long-tail categories.
- Simplify a complex pipeline while preserving performance, interpretability, or controllability.
- Combine two method families only when their failure modes are complementary and measurable.

## Data Extensions

- Build or relabel a dataset for an ignored setting, population, language, sensor, domain, or interaction mode.
- Add richer annotations that expose causality, temporality, uncertainty, explanations, or human preferences.
- Reuse existing datasets with a more realistic split, harder negatives, cross-domain tests, or stress tests.
- Study data efficiency by varying label quantity, quality, noise, or domain coverage.

## Evaluation Extensions

- Test on newer, harder, or more realistic benchmarks.
- Add deployment constraints such as latency, memory, cost, privacy, energy, or human correction effort.
- Compare against stronger recent baselines and include ablations that isolate the proposed mechanism.
- Evaluate robustness, fairness, calibration, generalization, reproducibility, and failure cases.
- Replace proxy metrics with task-level or user-centered metrics when the proxy is weak.

## Analysis Extensions

- Characterize when a method fails and which assumptions break.
- Derive a simpler formulation, bound, diagnostic, or taxonomy that explains existing results.
- Run controlled ablations to separate architecture, data, objective, and training effects.
- Identify hidden confounders in commonly reported improvements.

## System Extensions

- Turn a standalone model into a tool-using, human-in-the-loop, or multi-stage system.
- Add retrieval, memory, planning, verification, or feedback loops when these address a specific limitation.
- Study error propagation across modules and design recovery mechanisms.
- Make the system controllable, inspectable, debuggable, or easier to adapt.

## Proposal Filter

Prefer ideas that satisfy most of:

- The hypothesis can be falsified with one small first experiment.
- The target limitation appears in more than one source or is strongly implied by the method.
- The required data and baselines are obtainable.
- The expected contribution is specific enough to name in one sentence.
- A negative result would still teach something useful.

Avoid ideas that:

- Depend on unverified novelty claims.
- Require large-scale resources before any signal can be tested.
- Only rename existing work without a measurable mechanism change.
- Add complexity without a clear failure mode to fix.

---
name: duoshe
description: Analyze scholarly inputs — including Google Scholar queries, paper titles, abstracts, arXiv/DOI links, BibTeX entries, PDFs, citation lists, author profiles, or broad research directions — then produce a folder of Markdown artifacts containing per-paper summaries, a README overview, and a concrete research idea list. Use when asked to inspect academic literature, organize papers, identify research gaps, brainstorm follow-up research, design experiments, extend a paper idea, or generate project directions from scholarly sources.
---

# Scholar Idea Expander

Use this skill to turn scholarly inputs into a durable Markdown research pack: one overview file, one idea list, and one concise analysis file per paper. Keep output tied to evidence from papers and separate known claims from speculation.

## Accepted Inputs

Accept any of:

- Google Scholar query text
- Pasted Google Scholar results, citation entries, or BibTeX
- Paper title, DOI, arXiv URL, conference URL, project page, or PDF path
- Abstracts, related-work sections, citation lists, notes, or paper summaries
- A broad research direction that needs literature framing and idea expansion

If the user provides only a broad topic, first turn it into 3-6 focused search queries and subtopics, then proceed with the analysis.

## Source Handling

Prefer primary and durable sources:

1. Paper PDF, arXiv page, publisher page, or official conference proceedings
2. Author project page or official code repository
3. Semantic Scholar, OpenAlex, Crossref, DBLP, or Google Scholar metadata
4. Secondary summaries only as weak background context

Do not invent citations, venues, years, benchmark numbers, datasets, or paper claims. If source access is incomplete, say exactly what is missing and mark the claim as needing verification.

Do not rely on scraping Google Scholar pages when access is blocked, rate-limited, or captcha-protected. Ask the user to paste Scholar results, BibTeX entries, paper links, or PDFs, or use alternative scholarly metadata sources.

### Fallback Strategy When Sources Are Inaccessible

If the primary source (PDF, arXiv page, publisher page) cannot be fetched:

1. Try Semantic Scholar (`api.semanticscholar.org`) or OpenAlex for metadata and abstract.
2. If only the abstract is available, analyze what can be inferred and clearly label all claims as `[abstract only — not verified from full text]`.
3. If no source is reachable, tell the user exactly what is missing and ask them to paste the abstract, PDF, or BibTeX directly.
4. Never silently fill gaps with model knowledge. Always surface the limitation before proceeding.

## Workflow

1. Parse the input into papers, topics, methods, datasets, metrics, and user goals.
2. Gather reliable source context when available. Use primary sources over snippets.
3. Build a compact literature map:
   - Seminal or highly relevant papers
   - Recent representative papers
   - Competing method families
   - Common datasets and evaluation settings
   - Repeated assumptions and known limitations
4. Extract research gaps:
   - Assumption gaps
   - Data or annotation gaps
   - Evaluation gaps
   - Method limitations
   - Robustness, scalability, deployment, or reproducibility issues
   - Underexplored combinations of ideas
5. Generate concrete extensions with falsifiable hypotheses and minimal experiments.
6. Rank ideas by novelty signal, feasibility, risk, required resources, and experiment cost.
7. Write the output as a folder of Markdown files unless the user explicitly asks for an inline response.

For additional idea-generation patterns, read `references/idea_patterns.md` when the task asks for many ideas, a proposal, a project plan, or deeper novelty analysis.

## Default Artifact Output

When filesystem access is available, create a single output directory in the current working directory unless the user gives a path. Use a descriptive snake_case folder name such as:

```text
scholar_<author_or_topic>_papers/
```

Create these files:

```text
scholar_<author_or_topic>_papers/
├── README.md
├── idea_list.md
├── 01_short_paper_slug.md
├── 02_short_paper_slug.md
└── ...
```

Use two-digit numeric prefixes so paper files sort in the intended order. Keep slugs lowercase, ASCII, and hyphen/underscore separated. Order papers by the user's priority when given; otherwise use relevance, citation signal, or chronology, and state the basis in `README.md`.

If filesystem writes are not available, return the same files as separate Markdown sections with clear filenames.

## README.md Format

Write `README.md` as the entry point:

```markdown
# <Author/Topic> 论文逐篇整理

来源入口：

- <source name>: <URL or user-provided source>
- 整理时间：<date>

## 作者概况 / 主题概况

- 姓名/主题：
- 机构/领域：
- Scholar 研究标签：
- Scholar 指标或其他指标：<if verified>

## 论文目录

| 序号 | 文件 | 主题 | 状态 |
| ---: | --- | --- | --- |
| 1 | [01_slug.md](01_slug.md) | ... | ... |

## 总体判断

Summarize the main research clusters, trajectory, strengths, and verification caveats.
```

Omit author-specific fields when the input is a topic rather than a scholar profile. Use Chinese headings if the user writes in Chinese; otherwise use English.

## Per-Paper File Format

Each paper file should be concise and source-grounded:

```markdown
# 01. <Paper Title>

## 基本信息

- 标题：
- 作者：
- 目标作者位置：<if relevant>
- arXiv/DOI/venue：
- Scholar 引用：<if verified>
- 公开页面：
- 代码/项目：<if available>

## 研究问题

Explain the problem the paper addresses.

## 核心内容 / 核心方法

Summarize the method, framework, taxonomy, or system.

## 实验结果

Include only reported results that were verified from sources. Omit this section for surveys or papers where results are unavailable.

## 贡献与价值

- ...

## 需要注意

Mention version differences, uncertain metadata, limitations, or citation caveats.
```

Adjust section names to the paper type. For surveys, use `核心内容`; for method papers, use `核心方法`; for benchmarks, include dataset/evaluation details.

## idea_list.md Format

Write `idea_list.md` as a separate research-idea inventory based on all analyzed papers:

```markdown
# Research Idea List

Briefly state the evidence base and the main research lines found in the folder.

## 快速总览

| 编号 | Idea | 方向 | 预期难度 | 潜在产出 |
| ---: | --- | --- | --- | --- |
| 1 | ... | ... | ... | ... |

## 1. <Idea Title>

**动机：** Tie the idea to specific papers or repeated gaps.

**核心 idea：** State the proposal in one paragraph.

**可能方法：**

- ...

**实验设计：**

- ...

**风险：** Explain what could fail or make the idea weak.
```

Produce enough ideas to cover the major clusters in the analyzed papers. For a small paper set, 5–8 ideas is enough; for an author profile or broad area with 10+ papers, 10–15 ideas is appropriate.

## Inline Summary

After creating files, give the user a short final response with:

- The output folder path
- The number of papers analyzed
- The key files created
- Any source-access limitations or metadata that needs verification

## Quality Rules

- Separate verified facts from inference and speculation.
- Prefer precise, falsifiable hypotheses over vague brainstorming.
- Avoid generic ideas such as "combine with LLMs" unless the mechanism, baseline, and evaluation are concrete.
- Explain why each idea is plausible and how it could fail.
- Keep claims about novelty conservative unless the literature check supports them.
- Include negative or risky findings when they affect whether an idea is worth pursuing.
- Use citations or source names whenever possible so the user can trace the reasoning.