Lifecycle and Routing
0. 项目基础设施 建立/接管项目结构与状态 → research-project
1. 想 idea 建立领域视野 → 选题 → 设计方案 → research-ideation
2. 迭代方案 简单实验验证 → 诊断改进 → 调 work → research-experiment
3. 写论文 规划 → 梳理 story → 分章节写作 → paper-writing
改写作 / 回应审稿 → paper-revision
投稿前自评审 → paper-self-review
| The user's words look like this | Where to go |
|---|---|
| Start a new project / This folder is a mess / What stage am I at now / Take over a project | research-project |
| What direction to work on / Is this problem worth it / Is there novelty / How to solve this problem / Will A+B work | research-ideation |
| The experiment doesn't work / The numbers dropped / What experiments to do / Which ablations are needed / What demo to make | research-experiment |
| Write the introduction / Organize the story / Section templates / Make slides | paper-writing |
| Is this passage written clearly / Revise it / Received reviews | paper-revision |
| Will it get in / Will it be rejected / Pre-submission checklist | paper-self-review |
At the start of any conversation, run research-project 's project_status.py——
Get the global state and blockers in 30 seconds, avoiding continued investment in a topic that has already been sentenced to death on a methodological level.
When unsure which step the user is at, first ask about the project state (is there a roadmap, has the approach been decided, how far along are the experiments, how long until the deadline), then route.
Five Decision Rules
When they conflict with common-sense defaults, these five take precedence. They are all decidable, not attitudes.
1. Ideas come from the roadmap, not from other people's papers. First set the long-term goal → plan the roadmap (a set of important tasks) → choose a task → discover a failure case → think of a solution. The opposite is seeing a SOTA paper and going to improve it: limited impact, easy to collide with others, and possibly led astray by its wrong direction.
2. Topic selection carries more weight than the solution. Topic selection simultaneously determines the upper bound of novelty and the upper bound of value. Time spent on topic selection has the highest return;on a problem that already has a well-established solution, even the best solution cannot save it。
3. The value of one experiment loop = whether it produced a verified essential technical reason. Improving a method is doing SGD on the idea, and root cause analysis is computing the gradient. A loop without a root cause means the next change is equivalent to rolling dice—this is more fatal than experiments running slowly.
4. To judge whether a paper is worth doing, only ask: what new knowledge does it bring to readers. If it brings none, it is a waste of time, and may even earn negative evaluations. This rule is both a criterion for topic selection and a criterion for self-evaluation.
5. Don't stop at "it works." If a pain point repeatedly raised by industry is only made barely usable and then you move on, it amounts to no contribution in this direction— it becomes "published several papers, but never truly solved any problem." Criterion: if someone now wanted to put this method into a real product, what would be the first thing to get stuck? Has it been solved?
Anti-patterns
| Anti-pattern | Why it is wrong | Correct approach |
|---|---|---|
| Seeing a SOTA paper and wanting to improve it | Small room for innovation, easy to collide with others, possibly led astray by a wrong direction | Start from a roadmap milestone task |
| Boosting numbers on a technology's original setting/data | The room for improvement is often very small | Start froma new failure case |
| Believing a task has been "done completely" | Papers only report the best results; changing the data often makes it not work | Explore the algorithm's upper limit on harder data |
| Start working on any topic you can think of | Skip importance ranking | Rank first, then pick the most important one within your capability |
| If the experiment doesn't work, change the parameters and run it again | Stochastic gradient; no matter how fast you loop, it won't converge | First locate and verify the essential technical cause |
| Try to design a perfect experiment in one go | Slows down the loop | Minimum viable experiment, binary criterion |
| When a new hammer comes out, improve it on the hammer's own setting | Still a follow-up | Use the new hammer to solve a task on your own roadmap |
| Start writing only when the paper deadline is near | Low completeness | Start one month in advance (init_project.py --deadline generate a schedule) |
Execution layer (5 of them, distributed with this project in the same directory)
The six above governjudgment, the five below governexecution, use them in combination. They are at the same level as this skill set,
all are pure skills (no API key required), and the way to load a helper is
exec(open("<skills>/literature-review/kernel.py").read())—replace the middle part with the
skill name to use from the table below,<skills> is the root directory of this skill set (the same level as this skill).
| Scenario | What the methodology layer provides | What the execution layer provides |
|---|---|---|
| Literature review | The structure of the literature tree / challenge-insight tree, the four types of novelty | literature-review：search_openalex / expand_citations / verify_dois |
| Reading papers | What to extract (problem, pipeline, technical insights) | pdf-explore：pdf_outline / pdf_pages / pdf_scan / pdf_grep |
| Single figure | The rhetorical requirements of the pipeline figure (must differ from prior work, highlight the novel module) | figure-style：apply_figure_style() + data fidelity/label economy/post-render verification |
| Multiple subfigures | — | figure-composer：panel_task / compose_figure + adversarial self-review |
| The narrative of the whole figure set | The 11-step writing order and story organization | paper-narrative：narrative_review_task review the arc, which one is missing, which one to cut |
When there is a conflict: field rhetoric is governed by the methodology layer ("the pipeline figure is to highlight novelty rather than to make readers understand"
is the reality of CV/graphics submissions); technical correctness and readability are governed by figure-style (data fidelity and color-vision-deficiency friendliness are non-negotiable).
This is the only adjudication rule for the whole set—when other skills encounter a conflict between the two layers, cite it; do not restate it separately,
because restated rules drift with each one's changes.