jss-software-engineering-submission

name

jss-software-engineering-submission

description

Plan, write, polish, audit, format, cite, and package manuscripts for the Journal of Systems and Software (JSS) and adjacent top software engineering journals such as IEEE TSE, ACM TOSEM, Empirical Software Engineering, and Information and Software Technology. Use for software engineering journal submissions, empirical SE papers, systematic literature reviews or mapping studies, software tool/system papers, architecture/method papers, industrial practice reports, replication or negative-result papers, LaTeX/Elsevier formatting, publication figures and tables, artifacts, data/code availability, cover letters, reviewer responses, and Chinese-to-English academic writing for SE venues.

JSS and Software Engineering Journal Submission - Router

This skill is a router for JSS-centered and top software engineering journal submission work. It mirrors the Nature skill pattern: a short dynamic layer here, a manifest.yaml that maps request axes, static fragments under static/, and deeper references under references/ that are loaded only when needed.

Do not try to apply all JSS or SE-journal logic from memory. Load the matching fragments from disk and use current official sources when submission-critical details may have changed.

Scope

Default interpretation of JSS is the Journal of Systems and Software (Elsevier, ISSN 0164-1212). If the user clearly means Journal of Statistical Software, say the scope mismatch and do not use this skill as the main authority.

Use this skill for:

• Manuscript strategy, section drafting, restructuring, title/abstract/highlights, and Chinese-to-English SE academic prose.
• JSS-specific submission readiness, including evidence strength, article track, open science materials, data statements, LaTeX/Word source, figures, tables, references, software citations, and supplementary material.
• Adjacent SE journal targeting or transfer decisions across JSS, TSE, TOSEM, EMSE, IST, and generic archival SE journals.
• Review response letters, revision maps, and rejection-risk audits for SE papers.

Routing Protocol

Follow these steps every time the skill is invoked.

1. Load the manifest and always-on core

Read manifest.yaml. Then read every file listed under always_load; these define the default stance, workflow, and output format.

2. Detect request axes

Detect these values from the user's request and local files:

• target_journal: jss, tse, tosem, emse, ist, or generic-se. Default to jss when the user says JSS or software engineering journal without a competing target.
• task: manuscript-writing, polishing, latex-format, figure-table, citation-literature, artifact-open-science, reviewer-response, or submission-audit.
• paper_type: empirical, tool-system, slr-mapping, architecture-method, industrial-practice, replication-negative, trend-idea, or review. Default to empirical if unclear.
• language: en or zh-to-en.
• stage: idea, draft, revision, or final.

State the detected axes in one short line before doing substantial drafting or editing so the user can correct the route cheaply.

3. Load matching fragments

For each axis value, read the mapped file in manifest.yaml. If multiple tasks are requested, load the minimum set needed for the requested deliverable. Do not bulk-read every file.

4. Execute with journal-first priority

Apply loaded material in this priority order:

1. Core stance and workflow.
2. Target-journal rules.
3. Paper-type playbook.
4. Task-specific instructions.
5. Language rules.
6. On-demand references.

If a target journal instruction conflicts with a generic SE best practice, follow the target journal. If a policy detail is likely to have changed, verify the current official journal page before giving final submission advice.

5. Use references only when needed

Open these references on demand:

File	Open when
references/source-basis.md	Need official-source provenance, URLs, or to refresh volatile journal rules
references/jss-recent-patterns.md	Need recent JSS topic/genre patterns or article-positioning heuristics
references/se-methodology-checklists.md	Need detailed empirical, survey, MSR, SLR, controlled experiment, or design-science checks
references/latex-and-submission-packaging.md	Need concrete LaTeX, source-file, figure, BibTeX, or submission package checks
references/rejection-risk-audit.md	Need desk-reject, reviewer-risk, novelty/evidence, or scope-risk diagnosis
references/reviewer-response-playbook.md	Need detailed point-by-point response or revision tracker guidance
references/citation-and-literature-search.md	Need literature search, related-work, citation verification, or BibTeX/RIS handling

Non-Negotiables

• Do not invent results, datasets, statistics, artifact URLs, DOIs, author contributions, ethics approval, reviewer comments, line numbers, or acceptance probabilities.
• Do not present a software tool paper as JSS-ready unless the evaluation clearly supports the paper's claims beyond a toy demo.
• Do not treat "we built a system" as a contribution by itself. Convert it into evidence-backed knowledge: design principle, empirical finding, generalizable method, validated architecture, or practitioner lesson.
• For JSS, every central claim needs evidence: empirical study, simulation, formal proof, benchmark, controlled experiment, case study, survey, replication, or other explicit validation.
• For open-science material, prefer DOI-bearing archives and runnable, documented packages. If sharing is impossible, explain the restriction and provide metadata or proxy material where feasible.
• For Chinese input, preserve the author's technical intent, then produce submission-ready English unless the user asks for Chinese-only output.

Completion Check

Before finalizing a substantial deliverable, run the applicable checklist from the loaded task fragment and, when files were created, run:

python scripts/check_skill.py .

when working from the skill root. Report unresolved submission risks instead of polishing over them.