nsfc-justification-writer

Research Project Rationale Writer

Process

Input

Provide the necessary input according to the user request and configuration file; missing information should be clearly listed and steps depending on that input should be stopped.

Execution Steps

• When a bug is caused by a design flaw in this skill, record it according to bensz-collect-bugs to ~/.bensz-skills/bugs/; do not modify the skill already installed locally by the user; if a workaround is available, record it first and then continue.
• Only when the user explicitly requests public reporting, use the local gh to upload the newly added bug through that skill to huangwb8/bensz-bugs; do not pull/clone the entire repository.

1. First write the field value/necessity and existing evidence, then turn the bottleneck into the relationship, mechanism, property, or boundary to be explained.
2. Scientific questions use interrogative sentences to probe cognitive gaps; hypotheses use falsifiable declarative sentences to predict results. Research objectives, routes, and validation endpoints must not masquerade as questions/hypotheses.
3. Before the hypothesis, focus on facts, literature, and gaps; interventions, comparisons, endpoints, and routes are placed after the hypothesis. Method descriptions from external literature can serve as evidence, but are not equivalent to placing the project plan first.
4. The entry point/contribution needs no fixed heading or number of paragraphs; theoretical, hybrid, and engineering orientations only change the wording and the focus of evidence, not the threshold for passing.
5. After the logic and citation check, it is mandatory to read references/tier2_semantic_review.md, and the current host AI directly performs the Tier2 semantic check. The host AI autonomously plans terminology, argumentation dimensions, and readability, and outputs "location/obstacle/impact/faithful revision". Check long-sentence hierarchy, reference, abbreviations/new concepts, abstract nouns, cohesion, and ineffective modifiers; do not popularize science or forcibly revise because of necessary qualifications.
6. Readability rewriting must preserve verified facts, objects, qualifications, questions/hypotheses, citations, labels, and LaTeX structures; if faithful preservation is impossible, keep the original sentence and record the risk, and do not add facts/evidence.

Wording boundaries: boastful, absolute, or unsupported exaggeration is semantically reviewed by the host AI according to references/boastful_expression_guidelines.md and classified as logic/expression suggestions; Python only performs deterministic checks such as paths, structural commands, and citation keys, and does not use fixed word lists for judgment.

1. Read the target file and context; when the target is missing, automatically trace main.tex, select candidates according to deterministic priority, and if necessary create a default body file within the whitelist.
2. Check the closed loop of question—hypothesis—evidence—research content and citation keys; then Tier2 must be performed, with results divided into "factual issues, logical issues, expression suggestions".
3. After completing the check, automatically review professional readability;polish first internally locks facts/logic/citations, then performs constrained refinement, without asking the user questions.
4. Automatically generate the complete body text or a unified diff; when changes to structural commands are found, automatically fall back to a body-only proposal and retry.
5. Automatically write after passing whitelist, citation, and quality checks; back up before writing, and after writing display the diff, assumptions, and rollback entry point.
6. Word count and citation checks can run independently; the process is not bound to fixed headings or dimension lists.

• scripts/run.py preview: automatically generate a diff and write according to guardrails.output_mode ; when a read-only check is needed, explicitly add --dry-run。
• refs、wordcount: Independent citation/word-count tool; terminology, argument dimensions, and readability are planned by the Tier2 host AI.
• diagnose: Only executes Tier1 deterministic diagnostics, and prompts the host AI to read references/tier2_semantic_review.md; does not proactively call models, and does not generate Tier2 fallback conclusions.
• coach、review: The main workflow must include Tier2 semantic checks executed directly by the host AI. Boastful/absolutist risks are judged by the AI according to reference guidelines; the script does not perform fixed phrase matching.
• apply-section: legacy title replacement writing; new workflows prioritize automatic writing using full-body proposals, without relying on \\subsubsection。
• diff、rollback: View or roll back auto-written changes; the rollback command still requires an explicit --yes to avoid erroneous operations.

Read in order according to the task references/tier2_semantic_review.md, then read as needed within it references/scientific_question_guidelines.md、references/scientific_hypothesis_guidelines.md、references/professional_readability_guidelines.md and references/boastful_expression_guidelines.md. For user workflows, script usage, and architectural boundaries see README.md; inspection dimensions are autonomously planned by the host AI, without relying on a fixed terminology matrix or four-dimension thresholds.

Output

Default output:

目标文件（自动选择及依据）：...
修改范围：仅白名单正文
主要问题：...
建议正文或 unified diff：...
引用与事实守护：...
未修改：标题、结构命令、配置和样式文件

Readability findings are classified under "expression suggestions" and are not treated as factual errors; Tier2 is a mandatory item for complete diagnosis, completed directly by the current host AI, without going through a Python responder or fallback.

When the body boundary cannot be clearly determined, continue with the minimal safe body range; if materials are insufficient, adopt conservative assumptions and record them in "assumptions and items to be verified", without pausing to wait for user input. Always execute the whitelist, backup, and missing bibkey checks and report actual changes.

Output management

Intermediate files for new tasks of this Skill are uniformly written to ./.bensz-api/task-{yyyymmdd-hhmm}-{简短描述}/{skill名}/input|output|log/. The same task reuses one task root directory; only for multi-Skill collaboration create shared/. Formal deliverables are not written to this directory; historical hidden directories only allow explicit compatible reading, migration, or cleanup.

Validation

After completion, execute the Skill's existing static checks, script validation, or manual review, and record the pass criteria.

Failure and recovery

Preserve error evidence and completed artifacts; retry from the most recent failed step only after the input, environment, or external dependency has recovered.

Constraints

• Automatically understand the target file, paragraph, and objective, directly generate the final draft and write it to the safe target; simultaneously output the unified diff, backup path, and assumption record.
• Only modify body text that is automatically determined and passes the whitelist; preserve titles, section/environment commands, labels, citation commands, and configuration commands.
• Only modify whitelisted body files, do not modify main.tex, configuration files,.cls、.sty. When the target is not unique, automatically select and record the selection basis in the order "configured target → filename contains project justification/justification → lexicographically first item".
• The target may come from the user or configuration; do not assume a fixed filename.
• Citation keys must be verifiable in the project .bib ; do not add unverifiable citations, results, or absolutist conclusions.

Common hard constraints

• When a task requires persistence to disk, use a unique ./.bensz-api/task-{yyyymmdd-hhmm}-{简短描述}/ root directory; place shared materials in shared/, and place Skill-specific materials in that Skill's input/、output/、log/。
• Formal deliverables, source code, and formal plans are stored according to project conventions and are not written to the task workspace; do not overwrite, delete, migrate, or write remotely without authorization.
• Project maintenance changes check BAC availability and record requirements, AI outputs, tool results, file changes, and validation summaries; BAC only performs process auditing and does not replace attribution, responsibility, or compliance judgments.
• Do not log API keys, access tokens, passwords, cookies, environment/credential files, private prompts, identity information, local usernames, hostnames, or unnecessary large volumes of raw data.
• File paths must be normalized and restricted to the authorized project scope; external URLs, subprocesses, and network access follow the principle of least privilege to prevent path traversal, SSRF, and command injection.
• The Skill version is recorded solely in its own config.yaml:skill_info.version; changes to public APIs, protocols, directories, or configuration are synchronized with the documentation and CHANGELOG.md。
• Report only design flaws in the Skill or Bensz infrastructure itself to bensz-collect-bugs; first write a sanitized report to ~/.bensz-skills/bugs/, the current task is not interrupted, public reporting occurs only when the user explicitly requests it, and directly modifying the source code of a Skill already installed by the user is prohibited.

Skill-Specific Constraints

Do not exceed the scope declared in this Skill's description and the above process; do not disguise unverified information as definitive conclusions.