chengpeiquan/bassist-skills/bassist-writing-style

Writing Style

Use this skill for language, voice, clarity, and local editing decisions. A more specific skill owns the structure when one is named or clearly applies.

Scope and precedence

• Classify the deliverable before editing. Reference documentation, tutorials,

explainers, engineering notes, refactor summaries, and personal essays need different amounts of context.

• When another named or domain-specific skill applies, follow its structure,

audience, and length. For example, bassist-refactor-summary owns the why -> before -> after -> benefits -> follow-up structure for refactor and engineering transformation summaries. This skill only adjusts wording, rhythm, density, and unsupported claims.

• Do not turn an engineering note into a general article. Do not add a summary,

audience map, option section, or technical appendix unless the source or the requested deliverable needs it.

• Identify one primary reader to choose terminology and detail. Do not write a

separate paragraph for every stakeholder. Add a distinct section for another reader only when the document has an explicit cross-functional purpose.

Core rules

• Preserve the source's purpose, register, familiar wording, and useful sentence

rhythm. Retain passages the user has endorsed. Start with local edits; rewrite the structure only when the reader cannot follow the existing one.

• Use natural written language. In Chinese engineering writing, sound like a

colleague explaining what happened. Keep technical terms precise and let the surrounding sentences stay ordinary.

• Keep the original level of detail unless the task asks for expansion or

compression. Remove repetition, filler, and unsupported framing. Do not remove a sentence merely because it contains context or a transition.

• For code-backed technical writing, treat the current branch implementation as

the authority for behavior. Inspect the repository, branch, relevant source, tests, feature flags, and current diff before describing what is implemented. Product documents and proposed solutions establish requirements or intent; they do not prove that the branch contains the behavior.

• Do not add implementation paths, browser capabilities, fallback rules,

cleanup behavior, metrics, user impact, or test results from general knowledge. Every new factual sentence needs a source in the branch, an observed result, or an explicitly supplied document. If the branch cannot be inspected, keep the wording at the supplied level and mark implementation details as unverified.

• Separate product requirements, technical decisions, observed behavior, and

later consequences. Attribute each claim to evidence. A requirement to support subtitle styling does not establish why a rendering implementation was chosen.

• Establish product intent only from a requirement, design, acceptance

criterion, user statement, or recorded project decision. Establish technical intent only from an implementation record. Otherwise describe the behavior, mark the explanation as inference, or leave the cause open.

• Preserve concrete behavior when simplifying. Keep details such as subtitle

size, position, platform limits, fallback behavior, and test conditions when they affect use or verification. Do not replace them with broad promises such as “a consistent experience.”

• Ban rhetorical contrast templates such as 不是 X，而是 Y, `并非 X，而是

Y, 不只是 X，更是 Y, not X but Y, and not only X but also Y`. State the facts directly. A real comparison can remain when the source requires it; name the facts or options plainly.

• Match the requested language and format. Preserve technical names, commands,

API names, and code in their conventional form.

• Avoid personal pronouns by default. Use them for attribution, quoted speech,

ownership, or personal narration when the material requires them.

Workflow

1. Identify the deliverable, primary reader, purpose, and requested length.
2. Read the reference for that deliverable mode. If a more specific skill is

active, use its workflow and read only this skill's language rules.

1. For technical claims, identify the current repository and branch, locate the

named symbols or behavior, and check the implementation and relevant tests. Record which claims are implemented, planned, observed, or unverified.

1. Mark remaining claims as requirement, decision, observation, consequence, or

inference before explaining why something exists.

1. Preserve the source outline when it already works. Make only the changes that

improve understanding, factual accuracy, or the requested tone.

1. Read the edited text as the primary reader. Check that every paragraph earns

its space and that technical detail appears where that reader needs it.

1. Search for contrast templates, invented intent, unsupported additions, claims

that the branch does not contain, repeated meaning, and unnecessarily formal wording. Review the sentence before and after each edit before delivery.

Deliverable modes

• Reference documentation: purpose, setup, smallest working example, task

usage, API details, and actionable limitations.

• Tutorial: expected result, prerequisites, executable steps, and verification.
• Explainer or decision note: the question or finding, necessary evidence,

consequence, and judgement.

• Engineering note: preserve the problem-to-decision sequence and concrete

constraints. Use a specific engineering skill when one is available.

• Personal essay: let supplied events and observations carry the reflection.

For short responses, keep the same voice and scope without expanding the answer into an article structure.