技能创建器
skill-creator
创建、改进和评估自定义技能,把专业流程转化为可重复使用的 AI 能力。
fse-writing-style【数据与研究】Use when revising an ESEC/FSE paper for a practitioner-grounded software-engineering contribution on the first page, research-question contracts, a threats-to-validity section that argues rather than recites, evidence proportional to the claim, double-anonymous wording, and disciplined use of the ACM-template page budget.
独立 GitHub 快照 · 自动分类 · 以原作者文档为准
Use this when revising the main paper. FSE papers are PACMSE journal articles read by SE empiricists, so they need a software-engineering contribution stated in the first page and evidence a reviewer trusts. The failure this skill prevents is a technically fine paper that reads like a systems demo or an ML result with an SE title glued on.
| Section | Job it must do | Common failure |
|---|---|---|
| Intro | Problem, inadequacy, contribution, evidence preview, SE payoff — first page | Leads with a technology trend, not a problem |
| Background/Motivation | Why a practitioner or the field needs this now | Motivation by assertion, no grounding |
| Approach / Study design | The technique or the RQs + protocol, reproducibly | Method described too thinly to re-run |
| Evaluation | Each RQ answered with proportional evidence | Metrics that proxy for the claim rather than test it |
| Threats to validity | The threats that bite, each bounded | Generic list untethered from this study |
| Related work | Delta-first positioning against SE literature | Catalog of citations with no contrast |
| Draft pattern | FSE-safe rewrite |
|---|---|
| "Our tool significantly improves..." | "detects X% more defects (95% CI ...) than on " |
| "We evaluate on a large dataset." | "We evaluate on projects sampled by , listed in the artifact" |
| "Results show our approach works well." | "RQ2: developers acted on of comments (effect size ...); threats in §5.2" |
| "State-of-the-art performance." | Claim scoped to the subjects, metrics, and regime actually tested |
| "The LLM understands the code." | "the model's output matched in of cases" |
[Construct] does the metric measure the SE outcome you claim? (e.g. proxy for causation)
[Internal] could something other than your technique explain the effect? (confounds, tuning)
[External] to which projects/languages/teams does the finding generalize?
[Conclusion] are the statistics appropriate; multiple comparisons corrected; variance reported?
-> for each that bites: state it, then state the mitigation, next to the affected result
A draft with three RQs, nine figures, and a sprawling background: keep all three RQ answers, the two figures that carry the headline findings, and a threats subsection per RQ; move secondary plots and full protocol tables to the artifact with explicit forward references; cut background to what the argument needs. The test of a good cut: a reviewer should be able to answer "what did each RQ find, and what threatens it?" from the body alone.
[Writing diagnosis] clear / under-motivated / over-claimed / evidence-mismatched / over-scoped
[First-page fix] <new framing leading with the SE contribution>
[RQ audit] <RQ -> metric -> where answered -> proportional? yes/no>
[Threats fix] <threat that bites -> mitigation to add, placed by the result>
[Anonymity edits] <tool names / self-citations / links to rewrite>