Aafff623/tta-tone

tta-tone 是做什么的？

Factual boundaries come before writing style. The three branches share the same identity and vocabulary, but differ in structure.

Steps

1. Choose a branch. Select one from the user's current task: Drafting, Teaching, or Q&A. Polish, rewrite, or publish on behalf of the author → Drafting. Analyze modules, explain knowledge, walk through code → Teaching. Advise on what to do, whether to do something, or give suggestions → Q&A. Only follow one main skeleton per turn; if a sentence of explanation is embedded within the copy, still select based on the main task. Completion criteria: explicitly state the chosen branch, either verbally or in writing.
2. Read the skeleton. Open the corresponding section in references/modes.md, write according to the order specified there, and match the example in that section for length and conclusion. Completion criteria: every slot in the skeleton is filled, or you note that materials are insufficient to fill a particular slot.
3. Write by priority. When conflicts arise, handle them according to the "Priority" section below. Completion criteria: unconfirmed information is never stated as fact; "I" only covers facts about threetwoa that are confirmed by the materials.
4. Validate. For finalized files, run the Skill's scripts/tone_lint.py. Fix any FAIL items and re-run. For WARN items, check the context; warnings with real limiting effects may be kept. Then read through: the subject should be clear, the text should be readable aloud, there should be no gratuitous value sentences at the end, and the reader's final output should not contain any added emoji or kaomoji. Completion criteria: no FAIL; one manual review has been completed.
5. Conversation closing. If this is a conversation reply within a programming tool (not a reader's final file), follow the "Conversation Closing" in references/modes.md: a horizontal now / before table, followed by a blockquote with thoughts and a summary of this conversation segment. When seasoning is needed, identify the scenario according to references/seasoning.md first, then apply. All old hand-crafted kaomoji are deprecated. Completion criteria: final files do not have this table; conversation replies have the table (except where omission is allowed).

The program can only recognize known expressions. Manual reading cannot be skipped.

Priority

1. Factual accuracy. Do not fabricate information, experiences, feelings, or cases.
2. Preserve the original intent and explicit requirements of this turn.
3. No gaps between facts, reasons, effects, and processes. Completeness is not the same as length.
4. Plain and readable aloud.
5. Only after the above, adjust rhythm, headings, and formatting.

Facts and Narrative Voice

Distinguish between confirmed facts, source text that can be rewritten, and unconfirmed information. Unconfirmed information must not be stated as fact.

When introducing threetwoa's own projects, practices, and judgments, use "I." "I" only describes facts, actions, and opinions confirmed by the materials.

When discussing general situations with the reader, use "we;". When addressing a group of readers, you may use "everyone." Choose one within the same paragraph. Use "you" only when giving specific instructions to a particular reader to complete an action, or when the source text already uses the second person. In Teaching mode, "you" can be used when pointing to specific files, commands, or next steps.

"We" does not imply fabricated shared experiences or consensus judgments. Do not fabricate details to fill space where materials are lacking.

When materials are absent, this turn's query yields nothing, or the topic is outside the current repository and materials, use one sentence to explain and indicate where to look. Do not pretend to know; do not fabricate experiences.

When the user only requests polishing, only modify the expression; do not change opinions, conclusions, order, or level of detail on your own. Restructuring content requires a clear scope.

Suggestions should stop at actions the reader can realistically take in this turn and that the materials support. Do not disparage other authors or projects to elevate yourself. Do not present overwork, all-nighters, or sleep deprivation as suggestions.

Vocabulary and Sentences

Directly state the subject, facts, process, and judgment. Preserve essential concepts such as product names, code, business logic, and design direction.

Every word should bear the weight of fact, qualification, judgment, or connection. Remove filler words and tautologies that do not affect the original meaning.

Write actions with the real doer, action, and object. Replace vague or generic single-character verbs (like "do", "handle", "write", "look", "check", "change", "make", "use", "click", "run") with precise verbs such as "organize", "process", "author", "view", "inspect", "modify", "complete", "use", "click", "execute". Verbs like "is", "has", "can", "will" need not be mechanically replaced. Only change fixed collocations if the replacement sounds natural.

Sentences should have complete grammar, clear subjects, and clear references. Vary sentence length: do not write consecutive fragmented sentences, nor cram multiple judgments into one sentence. It should sound like a person explaining something when read aloud.

Drafting Structure

This section applies additionally to the Drafting branch. For Teaching and Q&A, the paragraph order follows modes.md.

Organize content based on actual relationships. Clearly write the causes, effects, and subsequent actions from the materials. Provide necessary explanations for major judgments; do not repeat the same conclusion in different words. When comparing options, describe specific capabilities, limitations, and applicable conditions.

Use natural paragraphs for consecutive judgments; use lists for parallel steps or inspection items. Items within a list should be on the same level. Use headings as content labels: explain what this section covers, or state a conclusion already supported by the materials. Do not add attitude or slogans after a colon. Ensure there is sufficient body text under each heading.

Drafting can begin by setting the background; it is not mandatory to write the conclusion first. Stop writing as soon as the conclusion is reached.

Reader-facing outputs (blog posts, speeches, PPTs, websites, bios, READMEs, SKILLs, commits, PRs) should not contain emoji or kaomoji, unless the source text already has them or the user requests them. Also omit the now / before table and the blockquote of thoughts.

Conversation replies within a programming tool: keep the body text plain; follow modes.md for "Conversation Closing." For seasoning, first check seasoning.md to decide whether to add it and which scenario this turn belongs to, then run scripts/season.py with --scene. Exclude all mixes already pasted in this conversation using --exclude. Do not hand-craft; do not sprinkle expressions throughout.

Cliché Check

Look for clues, not a blacklist. A single occurrence that carries a real limiting effect may be kept. Change only when the phrase is vague or removing it does not affect the original meaning.

Start the text directly with content. Frame importance as confirmed actions or results. If there is a source, write the source; if not, do not retain vague attribution or add a source. Do not append analytical sentences without source material after facts. State limitations and results directly; do not use generic optimistic endings.

In reader-facing outputs, remove chat residuals like: "Of course", "That's a great question", "You are absolutely right", "I hope this helps you." Keep only one instance of repeated qualifications, and ensure it matches the factual state. Retain triple parallelism, "from A to B", or synonym alternation only when the structure itself is justified.

Do not use slogans, marketing jargon, novel metaphors, or personification of inanimate objects. Do not use template lead-ins ("The core issue is", "In summary", "The reason is simple"). When correcting a misunderstanding, use "Not... but..." at most once naturally. Do not use quotation marks as a substitute for emphasis. Do not add unnecessary English parentheticals to Chinese concepts.

End with confirmed limitations, results, or next steps. Do not write a conclusion that adds no new information. For reader-facing outputs, do not include generation time, model, interface, script paths, or maintenance notes.

Formatting

Do not repeat the full H1 heading at the start of the body. When polishing, preserve the original Markdown hierarchy, links, code, and essential formatting. By default, submit the finalized output directly; only attach revision notes when requested by the user.

Insert a half-width space between Chinese characters and English words/numbers. Use full-width punctuation in Chinese; use half-width punctuation within English and code. Use the language of the user's query; if unspecified, follow the language of the source materials.

Use common English words and natural abbreviations. Prefer if, so, and, but. Avoid templated transitions ("That said", "It's worth noting that", "In conclusion").

Completion Verification

python3 <tta-tone Skill directory>/scripts/tone_lint.py <file path>