Do not immediately stretch the topic or materials into sentences; complete them in the order of 글 설계 → 근거 정리 → 구조 작성 → 초안 → 문체·구조 검사 → 재작성 .
1. Interpret the request
Check the following items or infer them from context.
- Reader
- The change expected after reading the text
- Core message
- Text type
- Target length and tone
- Content that must be included or avoided
- Facts, figures, examples, and sources that can be used
Ask only about information that would significantly change the result. For a general blog request, set a reasonable reader and length and proceed immediately.
When deciding the text type, read only the relevant type in references/article-types.md. If there is a user style sample or a specific tone is required, also read references/voice-and-style.md.
2. Design the text
assets/article-brief-template.mdFill in the items in as internal working notes. Reveal them only if the user also requests a plan.
- Write the core message in one sentence.
- Separate what the reader already knows from what they will newly learn.
- Decide the question each subheading will answer.
- Structure it so the argument continues even when reading only the title and subheadings.
- Do not unnecessarily delay important answers until after the introduction.
Reflect keywords or search exposure only when the user requests it. Do not damage Korean sentences to repeat keywords.
3. Manage evidence
references/evidence-integrity.mdand classify the material into the following.
- Facts provided by the user
- Facts directly verified
- Reasonable inference
- Information that cannot be verified
Do not write things you have not experienced as if they were first-person accounts. Do not invent unverified statistics, quotations, product specifications, or dates. If the text requires up-to-date facts or external evidence, research them and record the sources. If they cannot be verified, reduce the scope or state the uncertainty.
4. Write the draft
references/authoring-workflow.md와 references/voice-and-style.md.
- In the first paragraph, reveal the answer the reader will gain or the text's sense of the problem.
- Each paragraph should have one central function.
- Use scenes, actions, figures, and examples rather than abstract evaluations.
- Do not match every paragraph to the same length, sentence pattern, and ending.
- Use lists only for information that is truly parallel.
- In the conclusion, do not stop at summarizing the body; connect it to a judgment or next action.
If a file output is needed, copy assets/article-template.mdand write it, but remove all remaining placeholders.
5. Check structure and style
SKILL_DIRReplace with the absolute path of the directory containing this file, and run the following in the draft.
uv run "$SKILL_DIR/scripts/article_check.py" path/to/article.md
uv run "$SKILL_DIR/scripts/lint.py" path/to/article.md --genre blog --json
uv run "$SKILL_DIR/scripts/outline.py" path/to/article.md
article_check.py: Check the title, duplicate subheadings, empty sections, and incomplete cover.lint.py: Look for translationese, clichés, mixed sentence endings, excessive abstraction, repetition, and rhythm.outline.py: Create material to check whether the argument holds together using only the title and the first sentence of each paragraph.
If there are many technical terms and English abbreviations, also run the following.
uv run "$SKILL_DIR/scripts/terms.py" path/to/article.md
6. Rewrite and converge
Do not treat inspection results as automatic errors; judge each as 수정 or 유지. Save the JSON before revision and compare it against the baseline after rewriting.
uv run "$SKILL_DIR/scripts/lint.py" path/to/article.md \
--genre blog --json > /tmp/write-natural-korean-before.json
uv run "$SKILL_DIR/scripts/lint.py" path/to/article.md \
--genre blog --baseline /tmp/write-natural-korean-before.json
references/revision-checklist.mdFinally check factual preservation, paragraph function, style, and the introduction and conclusion with . Do not damage precise terminology, intentional repetition, or the author's individuality just to eliminate lint.
7. Deliver the final version
By default, present only the final version for the reader to read first. After that, briefly add important writing and editing decisions. Do not expose or leave internal briefs, lint JSON, or decision notes in the project unless the user requests them.