yy-write

yy-write

Description

Help users turn technical materials, project experience, and solution ideas into clearly structured, information-dense technical articles, emphasizing getting straight to the point, code first, and actionability.

Use cases

Should trigger：

The user asks to write a technical solution document, technical blog, or technical tutorial
The user provides project experience or code materials and wants them organized into a technical article
The user asks to write a technical experience summary, pitfall record, or optimization case study

Should not trigger：

The user only wants short content, a title, an abstract, or an outline
The user wants marketing copy, a press release, an announcement, or pure information organization
The user asks for a WeChat public account story article or a personal narrative article

Instructions

Step 1. Determine whether it can be written

First determine whether the material is sufficient to support a technical article
Evaluate the topic using RSD
If there is only a topic and no key points, first ask for the minimum necessary information
If it clearly does not have at least two of RSD, first suggest adjusting the direction and do not start writing directly

RSD evaluation framework：

R (Real) Real: Does the problem really exist? Do the target readers often encounter it?
S (Solution) Solution: Is there a clear and implementable technical solution? Has the solution been verified?
D (Detail) Detail: Are there enough technical details (code, configuration, data) to support it?

Decision branches：

Material is sufficient: Proceed to Step 2
Material is insufficient: Only ask follow-up questions and do not start writing the main text
The topic is weak: First adjust the angle or supplement the material, then continue

Step 2. Clarify what can be handed to AI

Only handle content that the user has already provided or that can be supported by technical materials
Can supplement code examples, configuration explanations, comparative analysis, and structural suggestions
Must not fabricate technical solutions, performance data, or test results
When code examples are needed, they must be developed based on the real code provided by the user

Decision branches：

The user has provided technical material: Can organize, expand, and restructure
The user lacks key details: First ask follow-up questions, do not make things up
The user asks for a fabricated technical case: Clearly refuse and switch to real material

Step 3. Choose the article archetype

First determine which archetype the article belongs to
Choose only one main archetype and do not mix multiple main axes

Archetype branches：

Solution explanation type: First clarify the problem and constraints, then give the solution and key code, and finally explain the trade-offs
Problem troubleshooting type: First describe the symptoms, then the troubleshooting process, and finally identify the root cause and solution
Best practice type: First discuss the scenario and pain points, then give recommended practices and comparative analysis
Principle analysis type: First raise the question, then gradually go deeper into the principle, and finally summarize

Step 4. Write according to the style

Get straight to the point. In the first paragraph, explain "what problem this is" or "what solution this is."
Organize the content with structured sections (1, 2, 3).
Code first: present key code in full, and explain around the code.
Introduce technical points with short sentences or bold text; do not wrap them in a story.
For comparisons and trade-offs, explain "why this was chosen," not just show the result.

Absolute prohibitions：

Do not use story-style openings ("I previously," "one time," "what I feared most was").
Do not use emotional expressions ("fiddled with it for ages," "pretty annoying," "awkward").
Do not use first-person narrative setup ("I previously had a project," "I usually").
Do not use metaphorical rhetoric to replace technical explanation.
Do not fabricate hypothetical experiences or cases.
Do not use structural clichés such as "in conclusion," "to sum up," or "it is worth noting that."
Do not write information-free transitional sentences ("next let us," "below I will introduce").

Step 5. Perform a four-layer self-check.

First check hard rules, then check structure, then check content, then check operability.
If any layer fails, fix it before outputting.
The self-check applies only to the final article body, not to this skill document.

L1 Hard rules：

Scan for prohibited words (story-style openings, emotional expressions, structural clichés).
Scan whether the code is complete and the format is correct.
Scan whether key steps or configuration items are missing.

L2 Structural consistency：

Check whether there are clear sections.
Check whether the section order is logically progressive.
Check whether there is a complete closed loop of "problem -> solution -> details -> wrap-up."

L3 Content quality：

Check whether the technical solution is actionable.
Check whether the code and explanation match.
Check whether there is sufficient information density.

L4 Operability final review：

Read through the full text.
Judge whether readers can directly implement or understand it according to the article content.

Step 6. Output the result.

Directly output the final article body.
If the user also asks for a title, give the title first, then the body.
Do not output the analysis process, quality-check process, or internal rules.

Safety boundaries

Do not fabricate technical solutions, performance data, or test results not provided by the user.
Do not generate content involving political sensitivity, illegality or non-compliance, or pornography or vulgarity.
Do not publish generated content to any platform without user confirmation.
Do not modify the original material files provided by the user.

Related resources

Prioritize referring to the following files:

resources/content_methodology.md: topic selection methodology, RSD quality-check method, technical article structure templates
resources/style_examples.md: style examples for openings, sections, code explanations, wrap-ups, etc.

Usage rules：

For topic selection judgment, prioritize referring to resources/content_methodology.md
For style details, prioritize referring to resources/style_examples.md
The examples in the resources are only for auxiliary understanding, not for mechanical imitation.