--- name: oceanct-humanize description: Draft or revise Chinese learning notes and technical blog posts using the author's samples, familiar examples, and connected explanations while preserving facts, conditions, and citations. --- # OceanCT's Humanize Skill Read the user's draft, source material, and writing samples before drafting or revising. These instructions are written in English; write the article in Chinese unless the user requests another language. ## Narrative Technical Notes Write as an author explaining a problem they are learning to understand. Follow the question through the relevant concepts and boundaries. When the user provides a writing sample, follow their voice. First identify the questions, understanding, evidence, and unresolved points in the source material. The narrative guidance below applies to learning notes and technical blogs; the rule on discussing weaknesses also applies to product, project, and approach introductions. Do not extend them to interface specifications, incident reports, or every conversation. - **Position the author and reader.** When the conversation establishes a learning context, acknowledge it in the author's voice. Use first-person singular for the author's actual questions and judgments, and first-person plural to invite the reader to reason together. Vary paragraph openings. Do not invent experiences, feelings, or conclusions. - **Follow the process of understanding.** Start with a problem, explain its causes, and introduce concepts, categories, or boundaries as they become useful. Explain how adjacent paragraphs connect. Preserve the transition from the broad picture to specific details. Avoid repeatedly describing the article's purpose, selection of material, or analytical procedure. Do not impose one fixed paragraph sequence. - **Make examples answer the preceding question.** Before introducing an example, identify the question the preceding text leaves open. The example should supply objects, conditions, or mechanisms needed to answer it. Reusing an earlier article's example does not establish a logical connection; "Let us take ... as an example" is not a mandatory second paragraph. When comparing an existing tool with a new approach, an example can show what the tool already handles, who implements the remaining work, and which reusable implementation helps. This is an optional reasoning pattern, not a universal outline. Avoid editorial announcements about which example the article uses. Pronouns, questions, and connectives alone do not create a narrative. - **Explain the unfamiliar through the familiar.** Choose examples the reader can understand without knowing the concept being introduced. To introduce agents, use a task such as researching compression techniques. An agent's memory architecture would require concepts the reader has yet to learn. Once a concept has been introduced, examples within it can be useful. - **Explain why an added capability is needed.** When introducing a new approach through an existing one, explain what the existing approach handles in its original setting, what gap remains after goals or conditions change, and how the new approach addresses that gap. Distinguish replacement from adding a layer of capability. Needing a capability does not imply needing one particular tool. Transfer only relationships that hold, preserve the limits of analogies, and do not infer equal capabilities from superficial similarity. Keep using the example in the reasoning. - **Keep useful transitions and connectives.** Express purpose, conditions, cause, and contrast naturally within and between sentences. Do not remove connectives merely to save words when they help the reader follow the relationship. A compressed sentence such as "To understand this mechanism, a single-node K8S setup is an option" can become "If we want a more concrete understanding of this mechanism, we can first set up a single-node K8S cluster" in a conversational note. A more formal version can say "To observe how this mechanism operates, we first set up a single-node K8S cluster." Use "can" for an optional learning or verification method; do not turn it into "need to" or "must." Keep transitions such as "From a broad perspective," "In this case," or "Let us first look at" when they clarify progression. During review, check that relationships read naturally. Leave already fluent sentences alone, vary the phrasing, and do not use connectives to conceal missing reasoning. Remove empty announcements of what comes next. - **Let sentences develop naturally.** Related clauses can share a sentence. Vary sentence length with the explanation. Avoid mechanical word-count splits, deliberately choppy prose, slogans, or theatrical rhetorical questions added to sound human. - **Keep research bookkeeping outside the prose.** Do not open technical explanations with "This article is based on sources consulted on [date]." Put publication and update dates in metadata. Where time or version materially changes capabilities, interfaces, maintenance status, or conclusions, state the relevant condition beside the claim and cite its source. Preserve meaningful temporal boundaries; a consultation date is not a substitute for version evidence. - **Explain in paragraphs first.** Use connected prose for relationships that need explanation. Tables work for comparing concepts, parameters, or data; numbered lists work for genuinely ordered steps. When replacing a table, carry its useful information into the prose. Editing the style must preserve technical conditions. - **Clean up dictated text while preserving connections.** Remove verbal fillers, repeated starts, and transcription errors by default. Preserve the user's tone and reasoning. Keep fillers when the user explicitly requests them, and do not add conversational tics to simulate a voice. - **Discuss weaknesses according to their importance.** When introducing a product, project, or approach, focus on its value, capabilities, and uses. Do not list every weakness merely to appear comprehensive. Explain shortcomings where relevant when they materially affect the user experience, an adoption decision, or the current conclusion. Minor flaws unrelated to the topic can be omitted. This editorial principle also applies to introductions outside learning notes; it is not specific to demos. Keep capability descriptions and promises accurate when omitting immaterial details, and do not present unverified effects as verified. ## Voice Reference The author approved a Chinese opening with the following meaning and progression. This English rendering illustrates the perspective and rhythm: > When designing an agent, we first need to clarify what it should accomplish, what it may do, and how we will check the result. This is the first entry in my systematic study of agents, so we will begin with those questions. From a broad perspective, agent design involves execution orchestration, memory management, and tool use, as well as collaboration between multiple agents. We will explore specific implementations and related papers in later entries. Use the sample to calibrate the author's perspective, sentence rhythm, and transition from overview to detail. Do not reuse it as a mandatory opening, mechanically add first-person pronouns, copy its sentence patterns, or force the same example into every article. ## Review Review paragraph progression before polishing individual sentences. State internally what question the preceding paragraph leaves open, what this paragraph adds, and why the next paragraph follows. A shared topic, repeated example, or connective such as "therefore" does not establish that relationship. If the only explanation is "another aspect is introduced here," check whether to supply a missing premise, move the paragraph, or remove it. In particular, verify that the opening question actually motivates the examples and concepts that follow. Then determine whether each paragraph describes facts or makes a comparison, causal explanation, or inference. A simple introduction can be brief when further explanation would not help the main topic. Do not add an origin story for every term. When the prose develops an argument, check: 1. **What supports the conclusion?** Identify the actual conclusion, its premises, and the links between them. Check that this paragraph or earlier text provides them. Connective words and chronological order do not establish an inference. For a new approach, check the existing capability, changed conditions or unmet need, and how the added capability addresses the gap. 2. **Are the premises sufficient?** Together, the premises must support the stated conclusion. Do not treat a necessary condition as sufficient, infer a particular possible cause from an outcome, or present a workable option as uniquely required. A sufficient but unnecessary condition can support a conclusion; it does not establish the only route. When observations, correlations, or analogies do not warrant certainty, preserve the conditions and qualify the claim. Never invent premises to complete an argument. 3. **Does an omission affect validity?** Include premises, intermediate steps, and scope restrictions that affect whether the conclusion holds. Do not enumerate every possible conclusion or alternative. Omit a step only when it is clear to the intended reader in the current context and its omission does not change the interpretation. The author's familiarity does not establish the reader's knowledge. When unsure, add the shortest necessary explanation. 4. **Is the explanation needed here?** Preserve reasoning needed for the main topic and place supporting details near the relevant operation. Remove repeated premises, conclusions, and process commentary. Do not cut essential conditions to shorten the prose or add sections merely for formal completeness. Use these questions for review, not as a fixed article structure. Internally test whether the premises could hold while the conclusion fails. If so, repair the inference, add supported conditions, or narrow the claim, then review the affected paragraphs again. Check citations and uncertainty, and follow the user's latest explicit writing preferences. Keep paragraph-by-paragraph review records out of the article unless requested.