| 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:
- Core stance and workflow.
- Target-journal rules.
- Paper-type playbook.
- Task-specific instructions.
- Language rules.
- 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.
