agentsclimarketplace
Sign in

Technical writing

Skill hoon-ch/skills/plugins/hoon-ch-skills/skills/technical-writing

Create or revise technical documentation for developers and end users, including README files, tutorials, how-to guides, troubleshooting docs, reference docs, architecture explanations, and doc reviews. Use when the assistant needs to write docs, restructure existing content, review documentation quality, or turn rough notes into clear Korean-first technical writing.From its SKILL.md

Install
npx -y skills add hoon-ch/skills --skill technical-writing

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

  • no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
  • 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

3.6 KB, as published. Nobody here has run it

Technical Writing

Write for the reader's goal, not for the author's mental model. Default to Korean unless the user, repository, or existing document language clearly indicates otherwise.

Quick Start

Use this skill when the user asks for developer or end-user documentation.

Start by identifying the reader, their goal, and the source of truth. Then choose the document type, draft or revise the document, and run the review loop before delivering the final format.

Workflow

  1. Identify the reader, their goal, and the source of truth.
    • Inspect code, configs, docs, screenshots, tickets, or the running product before documenting behavior.
    • Do not invent commands, flags, screenshots, flows, API fields, or env vars.
    • If something cannot be verified, say so plainly.
  2. Choose the document type before drafting.
    • Read references/doc-types.md.
    • Use the reader's goal to choose between learning, problem-solving, reference, and explanation.
    • If the request mixes goals, split the content into separate sections or separate pages instead of forcing one page to do everything.
  3. Shape the information architecture.
    • Read references/structure.md.
    • Keep one page focused on one primary goal.
    • Put value before background, add a short overview near the top, and keep section patterns predictable.
    • Add cross-links when a concept belongs in another page.
  4. Draft or revise the prose.
    • Read references/style-ko.md for Korean writing.
    • Prefer explicit actors, active voice, short sentences, concrete verbs, natural Korean, and consistent terminology.
    • Keep headings scannable and keyword-rich.
  5. Run a three-pass review before finishing.
    • Read references/review-loop.md.
    • Pass 1: Is this the right doc type for the reader's goal?
    • Pass 2: Is the structure easy to scan, predict, and navigate?
    • Pass 3: Are the sentences clear, concrete, and natural?
  6. Deliver in the requested format.
    • For a new document, produce the final markdown directly unless the user asked for an outline first.
    • For a review, lead with findings and concrete fixes.
    • For a rewrite, preserve verified technical meaning while improving structure and prose.

Use this default output shape when the user does not specify one:

  1. Short overview: who this is for and what they can do after reading.
  2. Main body: sections chosen from the selected document type template.
  3. Verification notes: commands tested, assumptions, and any unverified items.

Failure Fallback

  • If source-of-truth evidence is missing, say what could not be verified and keep the draft scoped to confirmed behavior.
  • If the request mixes documentation goals, split the content by reader goal or document type instead of forcing one structure.
  • If Korean terminology is ambiguous, preserve verified commands, paths, resource names, API terms, and product names exactly.
  • If a review finds structural problems, lead with concrete findings and suggested fixes before rewriting.

Examples

Use this skill to rewrite a README for a Korean developer audience.

Use this skill to review troubleshooting docs against the current CLI behavior.

Keep looking

Skills are one crate of 626,045. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.