UI はローカライズ済みです。スキルの紹介と説明文書は選択した言語へ AI が自動翻訳し、コード・コマンド・パス・専門用語は原文のままです。原作者の文書が優先されます。
スキルを探す
データ・研究 · SKILL.md

fse-writing-style

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.

Independent GitHub snapshot · Automated classification · Original documentation governs

スキルの説明

GitHub

name: fse-writing-style description: 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.

FSE Writing Style

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.

Revision rules

  • Lead with the SE contribution: the problem a practitioner recognizes, why the current state is inadequate, the contribution (technique and/or finding), the evidence, and what changes for software engineering.
  • State research questions as contracts. Each RQ should name what is measured and how it will be judged; every RQ must be answered explicitly in the results, and no result should exist without an RQ it serves.
  • Pair every claim with proportional evidence — real subjects, a fair baseline, a statistic with an effect size, or a qualitative code with agreement — not adjectives.
  • Argue threats to validity; do not recite them. Name the construct, internal, external, and conclusion threats that actually bite this study, and say what you did to bound each. A boilerplate threats paragraph is a tell that the author has not stressed their own claims.
  • Respect the page budget as a design constraint, not a formatting afterthought — the ACM template is generous but finite, and a study that only fits by shrinking threats or method is over-scoped.
  • Maintain heavy double-anonymity in self-citations, tool names, acknowledgements, funding, and the data-availability wording.

Empirical-SE paper skeleton

SectionJob it must doCommon failure
IntroProblem, inadequacy, contribution, evidence preview, SE payoff — first pageLeads with a technology trend, not a problem
Background/MotivationWhy a practitioner or the field needs this nowMotivation by assertion, no grounding
Approach / Study designThe technique or the RQs + protocol, reproduciblyMethod described too thinly to re-run
EvaluationEach RQ answered with proportional evidenceMetrics that proxy for the claim rather than test it
Threats to validityThe threats that bite, each boundedGeneric list untethered from this study
Related workDelta-first positioning against SE literatureCatalog of citations with no contrast

Sentence-level rewrites

Draft patternFSE-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"

Threats-to-validity discipline

[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

Vignette: compressing a three-RQ study

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.

Output format

[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>
保存したスキル