菜单
Use this skill whenever you need to report document review issues. It defines the standard issue format — field names, types, severity levels, line-number conventions, and best practices — used across all agent workflows in this project.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | issues |
| description | Use this skill whenever you need to report document review issues. It defines the standard issue format — field names, types, severity levels, line-number conventions, and best practices — used across all agent workflows in this project. |
Every agent that identifies problems in a document must follow these output conventions precisely. This ensures issues are consistently structured and can be processed downstream.
Each problem must be reported as an issue with the following fields:
title (str)
A short, specific title that names the problem. If the instructions specify a title format for the rule, use it exactly, substituting any bracketed placeholders with the actual value (e.g. "Figure/Table Missing Title: Figure 3", "Author Bio Issue: Jane Smith"). If no title is specified, create a concise one that clearly identifies the problem and the affected element. Good titles are scannable and self-explanatory.
description (str, markdown supported)
A 1–3 sentence explanation of the problem. Reference the specific text, element, or rule that failed. Explain what was expected and what was found. Do not invent content — base every judgment strictly on what is present in the document. Markdown formatting (bold, inline code, etc.) is supported and encouraged when it improves clarity.
severity ("none" | "low" | "medium" | "high")
Choose based on impact on document quality:
"high" — critical problems that significantly undermine document integrity: missing required sections, broken or unresolvable references, absent mandatory elements."medium" — notable problems that reduce clarity or compliance: incomplete sections, unreferenced figures or tables, inconsistent numbering, rule violations that affect readability."low" — minor issues with minimal impact: style suggestions, optional improvements, minor formatting inconsistencies."none" — informational, opt-in only. Use exclusively when the workflow's user prompt explicitly asks you to surface valid / passing checks alongside problems (e.g. confirming a recommendation is well-grounded, attesting that a section meets a rule). Never emit "none" issues unless the workflow instructions request them — by default, do not create entries for rules that pass.When the workflow instructions specify a severity for a particular rule, always use that value.
start_line (int)
The 1-indexed line number in /main.md where the text relevant to this issue begins. Set to 1 when no specific location can be determined (e.g. a missing section that is absent from the entire document).
end_line (int)
The 1-indexed line number in /main.md where the relevant text ends. Must be ≥ start_line. Set to 1 when no specific location can be determined.
suggested_action (str, optional, markdown supported)
A direct, concise recommendation to the author on what to do to resolve this issue. Set this field whenever a concrete author-facing fix applies; omit it when no actionable recommendation can be made (e.g. for purely diagnostic findings).
The suggested_action is downstream-consumed: another agent will read the original document together with the issue and this field, and apply the change. Be specific enough that this is possible without further clarification — point to the exact location, name the element, and state the change in imperative form (e.g. "Replace 'Figure 3' with 'Figure 2' on line 142 to match the figure caption.", "Add a citation supporting the sentence on line 88. Do not invent the citation — flag for the author to provide one.").
Critique, do not generate. Suggest formulaic fixes (rewording, restructuring, pointing to where a citation is needed, fixing a numbering mismatch) but never fabricate content. Do not invent citations, references, data, or new prose paragraphs. For nuanced cases where the right fix requires author judgement, plain guidance text is acceptable (e.g. "Add a citation to support this specific sentence — the author should select an appropriate source.").
Keep it short — one or two sentences, or a tight bulleted list if multiple sub-steps are needed.
long_description (str, optional, markdown supported)
An extended markdown description for issues that require more detail than fits in description. Use this field only when the issue is complex enough that a short paragraph is not sufficient — for example, when you need to list multiple affected locations, quote specific passages, compare expected versus actual content, or provide step-by-step remediation guidance. If description alone communicates the problem clearly, omit this field entirely.
When used, format long_description with markdown to maximize readability:
## or ### headings to separate distinct sections (e.g. What was found, What is expected, Affected locations).Report one issue per problem found. Only create an issue for a failing rule or missing element — do not add entries for rules that pass, unless the workflow's user prompt explicitly asks you to surface passing checks as informational (severity: "none") items.
/main.md is line 1.start_line and end_line to bracket that passage.start_line and end_line to 1. Never report such an issue with a range that spans the entire document; a whole-document range is reserved for problems that genuinely apply to every line.severity: "none") entries for passing checks.Use this skill to check that a document uses neutral, objective language. Flags trigger words (certainty language without evidence), advocacy language (unsupported recommendations or opinion framing), and subjective tone (value judgments or emotional language). Invoke when asked to review a document's tone, neutrality, or objectivity.
Use this skill to check whether an in-text citation is actually supported by the source it cites — deciding, for each cited claim, whether the cited source supports it, only partially supports it, does not support it (is silent on it or contradicts it), or cannot be checked. Invoke when asked to validate that a document's claims are backed by their cited references (claim / citation substantiation), given access to the cited sources.
Use this skill as the entry point when the user gives a generic, unspecified request to use Draft Detective on their document — e.g. "run draft detective", "analyze my document", "review this document", "check my paper", "what can you check?", "what can you do?". It lists everything Draft Detective offers and asks the user what to run. Do NOT use it when the user has already named a specific check or operation (run that skill directly).
Use this skill to find and catalogue every abbreviation and acronym occurrence in a document — recording, for each occurrence, any accompanying inline definition, how many times the abbreviation has appeared so far, where it appears, the definition listed in any Abbreviations section, and whether the occurrence is exempt from compliance checks. Invoke when asked to extract, list, or inventory the abbreviations/acronyms in a document (e.g. as input to an abbreviation compliance check).
Use this skill to check that a document's abbreviations and acronyms follow publication style — each is defined inline at its first use, listed in a dedicated Abbreviations section, used consistently, and not given conflicting meanings. Invoke when asked to review or validate a document's abbreviations/acronyms for compliance (e.g. per a manual of style).
Use this skill to validate the author biography section of a research publication — that each author bio has the right sentence count, states position and affiliation, describes research focus, and names the highest degree. Invoke when asked to check a document's "About the Authors" / author biography section.