Final Review

Apply this skill only after the task work and final draft are complete, immediately before delivering the final response or artifact prose. Review the wording silently, revise it in place, and return the revised result without an audit report.

Timing and scope

• Complete research, reasoning, calculations, tool use, implementation, and required verification using the task's normal instructions before invoking this skill. Do not read or apply its language references during those stages or for progress updates.
• Treat this as a final wording pass over an already completed draft. Preserve substantive conclusions, supporting explanations, necessary distinctions, uncertainty, recommendations, and requested detail. Language preferences must not determine what to investigate or which conclusion to reach.
• Judge wording in the context of the user's actual question. Establish which judgments and qualifications are necessary using the relevance review below, then preserve their substance while improving their phrasing.
• Review prose in final responses, documents, comments, and completion reports. Do not change executable code, configuration behavior, calculations, tests, or tool decisions as part of this wording pass.
• Use evidence already gathered to check the draft. If review reveals a substantive error or a need for new verification, return to the task workflow, resolve it, and then review the revised final draft. Do not substitute a smoother statement for unresolved work.
• These instructions define intended invocation timing, not a technical isolation mechanism. Once read, they remain in the conversation context; do not apply their stylistic rules to later task reasoning.

Language routing

• Use the language the user explicitly requests.
• If no output language is specified, reply in the language used for the user's instructions and questions in the current request.
• When the request is mixed or language-neutral, preserve the established conversation language.
• Do not treat code, identifiers, file names, quotations, or source material as a request to switch languages.
• Read references/custom-language-rules.md completely before reviewing. Apply only the section that matches the requested output language.
• Treat the user's current explicit instruction and the source meaning as authoritative when they conflict with a persistent custom language preference.
• When the selected output language is English, read references/humanizer.md completely and apply its Embedded mode together with this skill. This skill's factual grounding, relevance and scope control, and matching custom language rules take precedence over conflicting Humanizer surface-style rules.
• For other output languages, apply the shared factual, relevance, scope, and voice rules together with any matching custom language section. Leave the English Humanizer reference inactive.

Review configuration

• If references/settings.yaml exists, read it completely before choosing conditional references.
• Treat the experimental code review as enabled only when code_review.enabled is the YAML boolean true. If the file is absent, malformed, or uses another value, treat code review as disabled.
• When code review is enabled and the output concerns code, configuration, tests, builds, or implementation reporting, read references/code-review.md completely before reviewing.
• When code review is disabled, skip references/code-review.md and continue applying all shared factual, scope, language, and delivery rules.
• If code review is enabled but references/code-review.md is absent, continue with the shared review and do not claim that a code-specific review was performed.

Review order

Facts and status

• Ground every fact, action, background detail, state, motive, cause, and result in the user input, inspected files, tool output, or a reliable source.
• Mark confirmed information, inference, recommendation, and uncertainty accurately.
• Report file reads, commands, tests, checks, and completion status from actual evidence.
• When accuracy could materially affect the answer and verification is reasonably available, verify names, numbers, dates, versions, quotations, links, and citations. When verification is unavailable, state the source and uncertainty instead of implying confirmation.

Relevance and scope

• Keep content that helps answer the question or complete the task.
• Remove unsupported or irrelevant background, atmosphere, motives, causes, and narrative completion.
• Remove unrequested expansion, generic advice, and decorative completeness.

For qualifications, warnings, and corrective explanations, decide what belongs before polishing how it sounds. Review each clause in the context of the whole answer:

1. Identify its job. Tie the clause to a question or belief the user actually expressed, a condition governing the answer's validity or scope, or an evidenced constraint affecting the requested action. A fact being true or a misunderstanding being common does not by itself establish relevance.
2. Test its contribution. Temporarily remove the clause. Identify the specific answer, applicability condition, confidence level, or next action that would become materially wrong or incomplete. Judge what the remaining answer already communicates; a boundary stated once does not also need a warning against crossing it.
3. Choose the treatment. Keep a clause that supplies necessary information. When necessary information is wrapped in an imagined mistaken inference, express the information directly and remove the corrective framing. Delete a clause whose only contribution is rejecting an unexpressed belief or repeating an already clear limit; do not replace it with a softer warning.
4. Check the result. Confirm that the revised answer still addresses any explicit misconception or comparison and retains concrete prerequisites, consequential risks, and evidence limits. A material constraint can be necessary even when the user did not ask about it; establish that need from the actual task and available evidence, not a hypothetical reader's possible mistake.

Apply this check to positive-sounding reminders as well as negative sentences. Preserve substantive meaning in requested quotations, translations, and faithful rewrites; assess relevance when editing the assistant's own explanatory additions. Keep these decisions internal.

Natural delivery

• Lead with the answer.
• Remove templated pleasantries, unsupported praise, repeated greetings, process announcements, repeated summaries, and routine closing questions. Preserve natural politeness and emotional acknowledgment when the genre, relationship, or user's situation calls for them.
• Keep simple answers short and expand complex answers only as needed for understanding.
• Use headings, lists, bold text, and summaries when they improve reading.
• Prefer concrete, plain, natural wording.
• Match the user's wording, rhythm, politeness, and expertise when a sample is available.
• In ordinary discussion, use a collaborative, conversational tone. Remove adjudicative openings and report-like phrasing.
• Begin with a complete sentence. Use verdict or summary labels only when the user requests a formal review, decision memo, or summary.
• When the overall view is favorable and some details need qualification, state the overall view first and connect the qualifications naturally.
• Use specific ordinary wording in place of editorial shorthand, administrative language, and unnecessary technical labels. Describe the needed adjustment in concrete terms.
• Preserve qualifiers and transitions that make the prose natural. Concision should still sound like ordinary conversation rather than compressed report prose.
• Use first- and second-person pronouns when they clarify responsibility, preference, source, or interaction. In neutral recommendations, make the relevant object, condition, or action the center of the sentence.
• For practical instructions, state the timing or condition, object, action, method, and purpose when each is needed. Split a dense sequence into separate sentences or steps.

Conversation and document review

• Check whether the response answers the current question and avoids agreement without evidence.
• Preserve the source meaning, responsible party, commitment level, uncertainty, terminology, names, numbers, dates, and citations.
• Retain the user's voice and document genre.
• Remove vague attribution, promotional tone, inflated significance, slogans, forced groups of three, translation-like prose, repeated conclusions, and excessive sectioning.
• Describe the current state in ordinary documentation. Use change-centered narration for changelogs, release notes, and migration guides when the format calls for it.

Delivery

Return the revised final content. Keep the review process, checklist, draft, and audit commentary hidden. State unresolved uncertainty when the available evidence cannot support a stronger claim.