A skill for writing work-related Japanese so it is easy to read and understand. From work documents such as meeting minutes, research reports, internal guides, research memos, and slides, to note, blogs, and essays. Removing AI-ness is built in as part of the process.
Design philosophy
There are two axes. First, "detection by machine, judgment by AI." Because AI has difficulty recognizing its own habits, detection of suspicion is performed deterministically by a machine, and whether to fix it is judged by the AI (you) based on context. Second, "constraints at generation time rather than post-hoc correction." Rather than removing AI-ness after writing, it is more effective to prevent it from occurring in the first place through design before writing and constraints during writing. The process proceeds in the order "design → writing → inspection → convergence."
Execution modes — Quick and Full
Run the same process in two modes with different amounts of effort. Measured time estimates: Quick takes around 30 seconds for a short document (about the length of meeting notes), and about 3 minutes even for a longer one (on the order of 10,000 characters). Full takes around 7 minutes for a short document, and 15–20 minutes for one on the order of 10,000 characters. When starting Full, tell the user this estimate in one sentence before beginning.
Quick (default): Use this for everyday documents. Do not use subagents; complete it here. The only additional file to read is the one type file for the relevant doctype (the style constitution is sufficient as the summary in §2. Other references should be opened only when a lint finding appears and you are unsure how to judge it). For design (§1), complete confirmation of the reader, main message, and headings in your head. For inspection, run lint once and read through the skeleton yourself. Do not omit lint even if the document is short (for short texts, statistical detectors go silent, but prohibited words and translationese are detected even in a single sentence. It is a few seconds of insurance, and if you skip it, Quick's quality assurance does not hold). For the convergence loop, if no new findings appear, end it after one round, do a final pass read-through, and finish. The additional time due to the skill should stay within a few tens of seconds, and if you go beyond that and start loading references, you are doing Full mode work.
Full: When the user says "properly," "carefully," or "it's fine to take time," or when the document is external-facing, management-oriented, or otherwise high-cost on failure, or when it is long (roughly 10,000 characters or more). Once Full is decided on (or the user specifies Full), do not omit steps even if the document is small. In addition to lint, also run outline / terms, and always perform the three reviews of inspection (§4)—structure review, readability review, and doctype verification—in parallel subagents (each returns its findings; integration into the decision ledger and the "fix/keep" decisions must always be made by the parent. Do not split the writing itself—consistency of emphasis, metaphors, and inter-chapter connections cannot be maintained without seeing the whole document). Iterate convergence until the state conditions (§5) are met. Even if you feel "this is overkill for this document," do not arbitrarily thin out the steps; instead propose switching to Quick to the user. Note that empirically, runs with a low thinking budget (effort) tend to cut Full's steps through rationalization. If you are running Full in an environment where effort can be selected, high is recommended (low is sufficient for Quick).
If you are unsure which to choose, it is good to first finish with Quick and then add a word to the user that "it can also be polished again with Full."
How to invoke — write / score / mode specification
When the skill is invoked as a command with arguments, interpret the following forms.
/natural-japanese [quick|full] <対象>— Write / fix (default). Determine whether it is new creation or a rewrite from the target/natural-japanese write [quick|full] <お題や素材>— Explicitly specify new creation. From a state with no original text, write from scratch through the entire process: §1 design (reader, main message, skeleton, emphasis, material gathering) → §2 writing → inspection → convergence. If material is scarce, first gather it in §1-4 or ask the user for it/natural-japanese score [quick|full|exp] <ファイル>— Diagnosis only. Without rewriting the document, return a naturalness score (0–100; higher means more natural = less AI-smelling) and the reason. quick=lint only (30 seconds), full=includes structure and readability review, exp=includes semantic.py deep detection (initial download of about 1 GB).At the very beginning, always readreferences/diagnose.mdread. The definitions of the score calculation formula, bands, and output format are there; if you return by transcribing lint findings without reading it, you are not doing the job of diagnosis mode. After diagnosis, you may propose a rewrite, but do not fix it until asked
If no mode is specified, choose by yourself based on the criteria for execution mode. The same applies for natural language ("write about 〇〇" → equivalent to write, "does this text seem AI-like?" / "score the AI-smell" → equivalent to score).
1. Design — decide before writing
1-1. Reader, purpose, document type
Identify who will read it and what should happen after reading it (ask the user if unclear). Once the document type is determined, read the corresponding template:
- Meeting minutes →
references/doctypes/minutes.md - Research report / analysis report →
references/doctypes/report.md - Internal guide / manual →
references/doctypes/guide.md - Research memos, discussion papers, proposals →
references/doctypes/memo.md - Slide structure →
references/doctypes/slide.md
For documents that don't fit the template (note, blog, essay, etc.), you may skip this section.
1-2. Main message and skeleton
Before writing the body, write the main message in one sentence. If you can't, it's a lack of material, not a writing problem (→ 1-4). Next, create a heading skeleton. Each heading should be a message that contains a conclusion, not a label like "Background" or "Summary." Confirm that the argument holds by reading only the headings in order before proceeding to the body.
1-3. Density design
Writing every section with the same heat and the same thickness itself becomes an "unnaturally over-polished" quality. Design intentional unevenness: make important sections thick, and light sections honestly light. For the procedure, see references/revision-guide.md 's "Density design."
1-4. Material gathering — optional, when writing new content
If you start writing with few proper nouns, numbers, or concrete examples at hand, you won't be able to fix it even if you later realize "I'm only saying generalities." For the procedure of gathering material by alternating inference and search, the criteria for judging it sufficient, and requesting material from the user in an environment where web search is unavailable, see references/revision-guide.md 's "Material gathering."
1-5. Style profile — optional
style-profile.mdIf (the project root or a user-specified location) already exists, load it and use the quirks of perspective, vocabulary, and rhythm as a foundation. If not, you may proceed in generic mode. Only if the user asks to "learn my style," extract characteristics from 3–5 past pieces of writing according toassets/style-profile-template.md and write out a profile (don't be too definitive; add the caveat "as a tendency"). If the user explicitly states that they "don't use" or find "unnatural" a specific word or combination, do not generalize it into a general rule; record it in the same profile's "Expressions to avoid" with the source and scope of application. Do not ban the entire word; make the pointed-out combination the smallest unit.
2. Writing — write under the style constitution
references/writing-constitution.md Write the body using the 12 articles of as constraints. To list just the key points — start with the conclusion and don't write a preamble, headings are messages, explanations go in prose and bullet points are only for truly parallel compression, technical terms are explained in the text in the order "function → name," ground things with proper nouns and numbers, bold only one core point in the text, create density variation, don't repeat the same mold three times, use "not X but Y" only for genuine correction of misunderstanding, disclose limitations and estimates with explicit labels, separate fact from opinion, and in the conclusion reintegrate and, for reports, go as far as So What.
At this stage, don't worry too much about forbidden words or rhythm; you may fully express the content within the bounds of the constitution. The next inspection step will catch the details.
3. Inspection (1) — static detection
uv run scripts/lint.py --json <file>
Mechanically detect prohibited words, translationese, repetition of negative-positive contrasts, uniformity of sentence length, rate of noun-ending sentences, rate of conjunctions at paragraph heads, vocabulary diversity, suspected English syntax, etc. Regardless of the number of detections, the exit code is 0 (since this is a lint, we do not stop CI based on the count). Only for input errors is the exit code 1.
If the genre of the target document is clear, --genre essay|tech|business . This switches to a threshold profile calibrated on a corpus, reducing false positives. For the differences in judgment criteria by genre, see references/genre-notes.md .
In the convergence loop (4–5), the immediately preceding --json output is passed to --baseline , and it automatically sorts them into resolved / new / persisting.uv In environments where this cannot be used (Claude.ai, etc.), references/manual-checklist.md is used to manually trace the same viewpoints.
One more thing: there is an EXPERIMENTAL semantic detector calledscripts/semantic.py . It measures the undulation of similarity between adjacent sentences (flatness of topic) using sentence embeddings; because it is heavyweight, depending on torch + sentence-transformers and involving a ~1GB model download on first run, it is not built into lint.py itself but is made an independent opt-in entry. Only when the full process or the environment allows, additionally run uv run scripts/semantic.py --json <file> , and treat the findings by putting them in the judgment ledger just like lint.
4. Inspection (2) — Judgment ledger and two reviews
lint findings are the presentation of suspicions, not an instruction to mechanically fix everything. Reread the section for the category that was hit this time with references/revision-guide.md , and judge whether to "fix" or "not fix" in light of the context. Proceed while writing down for each finding whether it was "fixed" or "left (reason)" (for the ledger format, see "Judgment Ledger" in the same file).
If a terminology catalog is needed: prohibited words → references/forbidden-patterns.md, translationese → references/translationese.md. Use uv run scripts/terms.py <file> as material for checking whether technical terms are explained at first occurrence. It lists katakana compound words, ASCII abbreviations, and words that look like proper nouns, along with the first-occurrence line, occurrence count, and presence/absence of an explanation marker (whether it has been explained is not judged by the machine but by AI/humans).
Structural review — skeleton read-through
lint can only see the sentence-level surface. Especially in bullet-point-heavy minutes and slides, lint mostly passes them by, so structural review becomes the main actor. Extract and read only the headings and the first sentence of each paragraph from the completed body text, and confirm the following (uv run scripts/outline.py <file> can mechanically extract headings, the first sentence of each paragraph, and bullet-placeholders with line numbers):
- Whether the argument holds (can the story be followed from the skeleton alone?)
- Whether each heading constitutes a message
- Whether there is repetition of the same template (definition-sentence pattern, internal structure of sections, sentence pattern of openings)
- Whether there is variation in density (whether all sections have the same thickness)
- Whether the conclusion connects to So What (for report-type documents)
- In business/tech explanations, case studies, and reports, are you not making readers wait until the latter half for the main answer to a fixed question? Also, apart from factual explanation, are you not making them follow foreshadowing, irregularities, reveals, and payoffs over and over again?
If the document type is fixed, also cross-check against the doctype's "required elements" and "failures AI tends to make."
Readability review
For passages with high reading load, uv run skills/natural-japanese/scripts/lint.py --reading-load <ファイル> you can point them out with (sentence length, buried enumerations, consecutive kanji, double negatives, "no" chains).This is a revision lane with a different purpose from detecting AI-ness, and it does not enter the naturalness score or --baseline comparison. The output is "look at this sentence," not "fix it." Treat the indication as a starting point, and decide how to fix it based on the relevant item in the catalog below.
Word order, comma placement, one idea per sentence, distance between subject and predicate, overuse of demonstratives, and redundant expressions are judgment areas proven not to be mechanically thresholdable.references/readability-principles.md(general principles) and references/readability-antipatterns.md(a catalog classifying 27 types of bad writing patterns by reading load from A to J) while making a visual judgment every cycle.Apply the catalog from the front—A (nested negation), B (dependency distance), and C (weight of words and forms) are the high-load layer that forces readers to compute within a sentence, while H, I, and J span document, notation, and reader knowledge. Do not make brevity the objective function; use it as a tiebreaker only among equally ranked candidates after confirming fact preservation and subject-predicate/dependency relations. An increase in character count from sentence splitting or expanding enumerations is a correct result and is not a reason for rejection.
Problems found in structure review and readability review should also be written as one line each in the judgment ledger, just like lint findings.
If a paragraph can only state generalities (no proper nouns, numbers, or concrete examples), it is often a problem of material, not of how it is written.references/revision-guide.md Look at the "branch for insufficient material" and decide whether to return to information gathering.
5. Convergence
After reflecting the "fixed" items in the ledger, rerun lint and check whether new findings appear. Repeat 3–4 until all findings in the ledger are triaged and corrections are not producing new findings. If the same finding recurs two cycles in a row, see references/revision-guide.md 's "divergence guard."
When rewriting an existing document, applying the same kind of correction (turning headings into conclusions, converting bullet lists into prose, etc.) uniformly to every item erases the document's natural variation and can actually increase AI-ness. For the principle of fixing only the places where value can be added, see references/revision-guide.md 's "do not apply revisions uniformly."
6. Final pass — self-check loop and evaluation harness
Even if lint and the ledger converge, that only means known surface patterns have disappeared. Beyond this point, "a sterile-room-like coldness" and "dragging, verbose padding" that lint cannot catch tend to remain.
In full mode (and for important documents),references/eval-rubric.md の 6-axis revision rubric is used to conduct an objective evaluation.
- De-AI-ness / naturalness of style: Are there presentational declarative statements, empathy-baiting, translation-style dashes, or canned conclusions?
- Information density / conciseness (elimination of rambling padding): Have unnecessary preambles, lecturing, and paraphrased filler that steal the reader's time been stripped away?
- Functionality / scannability: Can the desired information be reached by the shortest path without confusion?
- Clarity of logic and persuasiveness: Do causal relationships make sense, and are they grounded in measurements and concrete examples?
- Humanity / sincerity (warmth, motivation): Does it avoid white-room syndrome and contain the writer's genuine feelings and awareness of the problem (Why)?
- Self-proving power: Is the document itself a supreme example that lives up to its own billing?
The passing criteria are 90 points or higher on all axes and an overall average of 92 points or higher. If any axis falls short, identify the bottleneck and revise, looping until it passes (for detailed procedures, see references/eval-rubric.md and references/revision-guide.md ). In quick mode, mentally review these 6 perspectives in one pass and finish. If you notice anything off, fix it and consider it done.
7. Cleanup
Once complete, delete all intermediate files created during the work (ledgers, lint JSON, draft backups, etc.). The only things that may remain in the user's project are the finished document and, only if the user explicitly wants it, the style-profile.md . For details, see references/revision-guide.md "Handling of work files".
Reference examples
For concrete before/after examples, see references/examples.md .