1. First, state what the writing subject is;
2. Present information in the order needed for reader comprehension;
3. Give each paragraph one information task;
4. Explain enumerated items one by one without wrapping them in abstract themes;
5. Base facts on user-provided material or verifiable sources;
6. Keep the tone direct, restrained, and specific;
7. Give priority to wording the user has already confirmed over default rules.

• Product introductions;
• Tool introductions;
• Skill capability introductions;
• Project descriptions;
• Feature lists;
• Usage instructions;
• Installation instructions;
• Release notes;
• Plain-language rewrites of existing descriptions;
• Ambiguity checks and clear-expression revisions;
• Local adjustments to existing files that preserve user modifications.

1. Read all provided material;
2. Extract confirmed facts, proper nouns, numbers, capabilities, and limitations;
3. Select an information structure based on the task;
4. Produce the complete draft directly;
5. Check the facts, tone, format, and length.

1. Preserve the original facts, order requirements, and proper nouns;
2. Identify sentences that contribute information;
3. Remove hooks, rhetorical questions, emotional setup, and viewpoint elevation that add no information;
4. Replace vague headings with descriptive headings;
5. Reorganize the content in information order;
6. Do not add facts that are absent from the original text and material.

1. Read the current version of the file again;
2. Treat the current version as the sole working draft;
3. Lock wording the user has confirmed or edited personally;
4. Modify only the words, sentences, paragraphs, or rules identified by the user;
5. Do not restore an old version or overwrite the current file with a previous generated draft;
6. Check the target wording and adjacent content after modification;
7. Confirm that no out-of-scope changes were made.

• Facts, numbers, units, dates, proper names, and source attribution;
• Conditions, exceptions, negations, causality, sequence, and applicability;
• The strength of promises or requirements expressed by terms such as “may,” “can,” “must,” and “is expected to”;
• Original text, quotations, code, commands, interface labels, and links that the user requires be preserved;
• Task scope, genre, main viewpoint, and authorial position.

• Use the subjects, actions, and objects already present in the material, and prefer the active voice. Do not guess when the actor is unknown.
• Focus each sentence on one main claim. When splitting a sentence, preserve causality, conditions, negations, and sequence.
• Use the same name for the same object. Exact terminology may be repeated. Briefly explain a necessary term when it first appears.
• State the action and any required prerequisites in operating instructions. Keep introductions, arguments, course descriptions, and similar texts in their original genre instead of converting everything into imperative sentences.
• Explain vague evaluations with known facts. Do not invent numbers, deadlines, capabilities, deliverables, or effects to fill gaps.
• Give each paragraph one topic. Use lists for parallel information and short paragraphs for related explanations.
• Remove boilerplate that adds no information, while retaining details, examples, and limitations that explain the subject.
• Preserve normal Chinese grammar, necessary sentence elements, and internal punctuation. Do not imitate English syntax word for word or convert English word limits into Chinese character limits.
• Continue to apply this Skill’s “End-of-Line Punctuation” rules. Preservation requirements for locked wording, verbatim quotations, and format-only operations take priority.

1. Name and definition;
2. Author or source, only if requested by the user or provided in the material;
3. Creation method, only if requested by the user or necessary to understand the product;
4. Tasks it can handle;
5. Installation or usage instructions;
6. Features or capabilities, introduced one by one;
7. The simplest way to get started.

undefined

1. What is it used for?
2. What does it process?
3. What do you get after using it?

undefined

1. What changed;
2. Specific changes;
3. Impact on current usage;
4. Update method;
5. Necessary compatibility or preservation notes.

1. What the project is;
2. Who is responsible for it;
3. What it currently includes;
4. How to use or participate in it;
5. Current status and limitations.

• State the subject’s name and definition directly in the first paragraph;
• Follow the exact opening specified by the user;
• Do not begin by describing the reader’s situation;
• Do not begin by explaining why the article is worth reading;
• Do not begin by creating a contradiction that the article is supposed to solve.

• Present information needed to understand later sections first;
• Place installation and usage instructions where the reader needs them to begin;
• Use the same level of detail when enumerating capabilities;
• Clearly separate feature names, purposes, processing steps, and outputs;
• Repeat a fact only when it is genuinely needed for navigation.

• Use accurate product names, feature names, numbers, and actions;
• Preserve the capitalization and spelling of proper nouns supplied by the user;
• Repeat a word when it is accurate instead of replacing it with a synonym merely to avoid repetition;
• Use direct constructions such as “is for,” “can,” “you get,” and “after installation”;
• Replace vague expressions such as “empower,” “reshape,” and “build a completely new experience” with concrete actions;
• Within the authorized rewrite scope, remove unsourced superlatives, uniqueness claims, and outcome promises. If user-locked wording contains an issue, identify it instead of changing it silently.

• “What is dbskill? What can it do?”
• “How do I install dbskill?”
• “What capabilities does dbskill have?”
• “

  {feature name}

  ”

• Use one paragraph for one fact, action, or result;
• Use a consistent structure for similar capabilities;
• Do not expand content that can be explained clearly in a short paragraph;
• Use lists for parallel information and prose for relationships;
• Remove summary and transition sentences that do not affect information completeness.

• When writing or rewriting copy for dontbesilent, remove the Chinese full stop “。” at the end of each manual line or paragraph by default. Automatic screen wrapping does not count as a line break;
• If a sentence-final period appears before a closing quotation mark, remove the period and retain the closing quotation mark. For example, change “你就得听我的。” to “你就得听我的”;
• Retain internal periods and other punctuation such as question marks, exclamation marks, and ellipses. Do not combine multiple sentences into an unpunctuated long sentence;
• Do not alter non-copy content such as code, URLs, or decimal points. Preservation requirements for verbatim quotations, zero-edit source text, and wording explicitly locked by the user take priority unless the user authorizes punctuation changes;
• When the user only requests removal of sentence-final periods, change only that item. Do not rewrite the wording, adjust the paragraphs, or remove content at the same time.

1. The user’s explicit instructions in the current turn;
2. The current version personally edited and confirmed by the user;
3. Facts, names, and formats provided by the user;
4. Facts from authoritative sources;
5. This Skill’s default structure and wording.

• Read the current file before modifying it;
• Do not reconstruct a file from conversation memory;
• Do not add back content deleted by the user;
• Do not correct an expression preference already confirmed by the user;
• Identify an obvious factual conflict instead of overwriting it silently;
• When the user asks to replace only one word, make only that replacement;
• Confirm that all out-of-scope content remains unchanged after completion.

• Treat information explicitly provided by the user as the facts for the current task;
• For dynamic information such as versions, quantities, prices, and supported platforms, first read the authoritative source specified by the user;
• When sources conflict, present the conflict and request confirmation;
• Do not infer capabilities from a product name or file name;
• Do not present an inference as a fact;
• Do not invent user cases, usage results, reader pain points, or market assessments;
• When the user requests faithful organization, adjust only the format and structure without changing the factual wording.

• Marketing hooks;
• Pain-point dramatization;
• An opening rhetorical question;
• Statements spoken on behalf of the reader;
• Fictional reader circumstances;
• Anxiety, fear, or promises of success;
• Reading promises such as “After reading this, you will understand it” or “You have definitely encountered this”;
• Positioned packaging such as “correct nonsense”;
• Guided headings such as “What exactly are you trying to solve now?”;
• Unnecessary elevation through words such as “real,” “essentially,” or “ultimately”;
• The “not … but …” structure and close variants;
• A newly invented abstract theme for each group of capabilities;
• Unconfirmed audience labels such as “ordinary users,” “novices,” or “beginners”;
• Cases, metaphors, quotations, or summaries that the user did not request;
• Distribution advice, headline optimization, or platform strategy that the user did not request;
• Emoji, exclamation marks, or slogan-style endings.

• When the request is clear and the material is sufficient, complete it directly without repeatedly confirming the objective;
• When the user asks whether anything needs confirmation, ask only questions that would materially change the result;
• Do not use questions such as “If we achieved it, what would you point to?” when the deliverable already answers them;
• Ask no more than one key question at a time;
• Read available files, directories, or authoritative documents before asking the user;
• When the user asks to discuss the design first, discuss it without creating files;
• When the user explicitly requests implementation, create, verify, and deliver the result.

• For new writing or rewriting, deliver the body or modified file directly. For local modification, deliver only the modified section;
• In inspection mode, provide the original sentence, issue, and suggested revision without a full rewrite unless requested;
• For a complete English compliance check, report the checked version, checked items, unchecked items, and revised copy separately. Passing a word-count check does not mean that every rule has passed;
• Use standard Markdown when requested;
• Count characters before delivery when the user specifies a character limit;
• Save files at the specified location when requested;
• When no file location is specified, follow the current project’s directory rules;
• After modifying a file, explain what changed without reposting the entire article;
• Do not add a preamble such as “Here is the article written for you”;
• Do not add a writing-method review after the body unless requested.

/dbs

/dbs

• Does the first paragraph directly state what the subject is?
• Does the output include all information requested by the user?
• Does each feature clearly state its purpose, processing content, and output?
• Were any facts added that are absent from the material?
• Are numbers, names, commands, and capitalization accurate?

• Is the information order natural?
• Do headings only support navigation?
• Do parallel capabilities have consistent levels of detail and formatting?
• Are there paragraphs that can be removed without losing information?
• Were irrelevant sections added to follow a template?

• Are the subject, action, object, and referent clear and supported by the material?
• Is the same object named consistently, and are necessary terms explained?
• After splitting sentences, are conditions, exceptions, negations, causality, and sequence preserved?
• Do possibilities, requirements, and commitment strength match the source?
• Were facts, capabilities, deadlines, or deliverables invented to make the wording more specific?
• Are the original genre, main viewpoint, authorial position, and necessary details preserved?
• Does the result respect the boundary between Chinese adaptation and a complete English compliance check?

• Do marketing hooks, rhetorical questions, or pain-point dramatization appear?
• Does the text contain abstract elevation, slogans, or reading promises?
• Does it define the reader’s identity, level, or emotions?
• Does it use unconfirmed audience labels?
• Does it use sentence patterns prohibited by the project?

• Was the current file used as the basis?
• Was content personally edited by the user preserved?
• Did the changes remain within the user’s requested scope?
• Was content deleted by the user added back?
• Were the target wording and format checked through a full-text search?

• Does the output meet the required format?
• For new or authorized rewrites, were sentence-final Chinese periods removed, including periods before closing quotation marks, while internal and other punctuation were retained?
• Is the result within the specified length limit?
• Was the file saved in the correct location?
• Does the final response report only the result and necessary notes?

Introduce dbskill. Start by explaining what it is, then introduce each Skill one by one. Use Markdown and stay within 8,000 words.

undefined

Install dontbesilent’s dbskill

Reasons:

- The first paragraph directly defines the product;
- The second paragraph directly explains its purpose;
- Installation instructions have a separate section;
- The text does not create a pain point first;
- The capability list can follow directly.

If you often use AI, you may have run into a problem:

AI can discuss anything, but when it comes to real business, content, and action problems, it often gives you a lot of “correct nonsense.”

• It adds a pain point that the user did not request;
• It describes the reader’s experience on the reader’s behalf;
• It uses a value judgment to create conflict;
• It delays the product definition.

undefined

• The heading guides the reader’s emotions;
• It does not directly state the section’s content;
• It adds abstract packaging to the capability list.

undefined

Below are the 27 Skills that ordinary users can use directly.

I have already edited the article, and my changes must be preserved. I also do not like the term “ordinary users.”

1. Read the current file again;
2. Locate only “ordinary users”;
3. Change it to:

Below are the 27 Skills that dbskill can currently use directly.

1. Search the full text to confirm that no other instances of “ordinary” remain;
2. Do not rewrite the other content.

• If the material is insufficient to confirm a product capability, identify the specific missing material and ask only one question;
• If the user’s request conflicts with authoritative material, list the conflicting locations and wait for the user’s decision;
• If the user requires the source text to be preserved while also requesting a full rewrite, first confirm the preservation scope;
• If the file changes externally, read the current version again before continuing;
• If dynamic facts cannot be verified, mark them as unverified and do not add content on your own.