Prepare the requested document for its colleagues and verify the usable shared copy. technical-report-writing owns content selection, structure, headings, tables, figures, explanation, and production. This skill adds the recipient and delivery requirements; it does not create a second editorial workflow.
Infer the reader, intended use, existing material, medium, language, and distribution from the request. Reuse context already established by another skill. Review requests return findings; writing and revision requests include the artifact. Ask only for consequential missing user choices.
Document preparation
For writing, substantive revision, or editorial review, read and apply the available technical-report-writing skill, including its normal-path editorial defaults. Pass the established audience, document purpose, sources, medium, and explicit preferences once. A user naming only this skill still receives the complete document or requested review. Do not restart intake or require the user to orchestrate the skills.
If the writer is unavailable, use the established user preferences and reader brief to complete the authorized task with available tools. Report the missing capability only if it materially limits the result; do not silently install a package. For delivery of an already finished document, inspect its recipient suitability and the actual copy without initiating an unrelated rewrite.
Use insight-dashboard for data views whose comparisons and commentary must remain consistent with selections. Use the appropriate document or figure tool for the requested medium. Do not copy their methods into this package or run an automatic second editorial pass. Explicit AI-slop revision and Korean meaning repair live in technical-report-writing (references/authoring-and-revision.md and references/korean-writing.md), and the author's standing preferences in its references/writing-profile.md; apply them through that skill, once.
A colleague must be able to follow the document's actual explanation: identify the subject, connect the example to the finding, understand the condition that changes its meaning, and use the result for the intended task. Read a representative passage from that colleague's position. Supply missing subject context where it is needed; an author introduction or reading tour does not supply that context. Links support verification and further detail. Carry the document's purpose into production: a factual incident record and a technology explanation need different depths. Preserve required records in their owning location.
Apply the project's terminology and presentation choices. When no theme is specified and screen styling is controlled, retain the pack's dark default for the page and figures; requested light, print, and destination-controlled themes take precedence. Pass the actual preference to the production tool.
When colleagues or the user have edited the shared copy, retrieve that version before revision or republication and pass it to the writer as the current baseline. Reconcile differences with a local source before rebuilding; preserve intentional deletions and intervening edits. Familiarity with the original draft is not evidence that the shared copy is unchanged.
Recipients and sources
Match detail and attribution to the intended audience. Apply the writer's rules for direct findings, intelligible terminology, and necessary attribution. Page ownership or a sharing message usually supplies the author's identity; do not repeat it as an introductory byline or “the author's synthesis” paragraph. Retain an action owner or observation date when it changes meaning. Remove credentials and unnecessary private information. Preserve relevant events and accountability without unsupported personal evaluation. Do not add explanations merely to demonstrate caution.
Use citations readers can access for the claims they need to verify. Inspect the actual destinations: a bare Markdown filename accidentally linked as a website, a localhost address, and a private local path are not usable team citations. Replace them with authorized source links or incorporate the necessary supported explanation. Do not add a folder inventory or a blanket source disclaimer. If access remains essential and unavailable, state the concrete delivery limitation. Do not upload restricted working records alongside the document.
Read sharing pass for sensitive material, personal attribution, or changed distribution. Preserve actual review obligations and completed reviews; do not invent a universal approval process or contact people without authorization.
Delivery
Inspect the actual destination after rendering, conversion, or publication. Check complete content, visible row and column labels, readable table cells, preserved list hierarchy, equations, figure size, numbering, captions, and usable source links. For a collapsible document, check the initial view and representative expanded content; a static export must still make necessary content available. Distinguish retrieved-content checks from visual checks, and do not claim a rendered view was inspected when only its source was read. A clear source file does not establish that the shared copy reads well. For a new or restructured document, check that a colleague can identify the subject, understand the main explanation and internal names, and use the result without the authoring conversation. Apply the writer's editorial checks rather than maintaining a second style checklist here.
When publication is requested, use the supported destination tool and retrieve the result to verify complete delivery. Document preparation alone does not authorize sending, publishing, committing, or installing skills. Reuse an existing grant instead of asking again.
Return the artifact or findings, its path or URL, and material delivery limitations. Use composition and migration when maintaining this workflow or moving an old document-production copy to its specialist owner.