Write a technical article grounded in facts

Develop a new technical article or project retrospective from a fact ledger, genuine decisions and a reader-facing narrative. A compact direction to help the next screen feel deliberate, specific, and easy to remix.

Draft a new technical article or project retrospective from real material. Help an unfamiliar reader understand the problem, decisions, evidence and limits.

INPUT
Mode/topic: [technical deep dive / project retrospective; specific question]
Reader: [prior knowledge, reading goal, publication context]
Facts: [background, dates, versions, actions, results, records and sources; distinguish confirmed, unverified and conflicting]
Author judgments: [real tradeoffs, reasons, feelings, failures and limits; leave blank if absent]
Expression/length: [Chinese/English, length, fixed title, protected content, banned wording]
Optional style sample: [the author's own short text; borrow expression habits, not facts]

METHOD
1. Define the reader problem. Ask up to three blocking questions and wait for missing core facts or contradictions. Without a style sample, use clear restrained explanation rather than claiming to have learned a personal voice.
2. Build a ledger of names, dates, versions, quantities, actions, results, provenance and confidence. Separate judgments from facts. Use first person only for supplied genuine experience. Preserve numerical conflicts for confirmation instead of choosing a convenient value.
3. Plan an appropriate structure. A deep dive moves through problem, necessary context, method/mechanism, evidence and applicability. A retrospective follows original goal, actual choices/reasons, execution, observed outcomes and known limits. Do not invent failures, tradeoffs or lessons to fill a framework. Open with a specific supplied question, scene or result.
4. Write complete prose with definitions and reasoning that a new reader can follow. Support major judgments with actual material, attribute outside views and label inference. For technical comparisons, state versions, inputs, conditions and evaluation criteria; if absent, treat results as limited observations rather than reproducible benchmarks or general conclusions.
5. Check values, versions, first person, citations and scope. Remove unsupported slogans and conversation artifacts such as as you requested or the previous draft. Preserve a fixed title and avoid compulsory summaries or calls to action. Draft supported material and expose remaining gaps separately instead of smoothing them away.

DELIVER IN ORDER
A. Fact ledger: item / content / source or original record / status; separate contradictions and confirmations needed.
B. Full publishable article: title, natural sections and actual paragraphs, not a placeholder outline. Keep unsupported conclusions explicitly pending or refrain from concluding.
C. Editorial checks: unknowns, conclusion limits, citation locations and genuine basis for first person. State which missing data prevents comparison or causal inference.

BOUNDARIES
Use for new technical writing and project retrospectives; use separate templates for targeted rewriting or platform adaptation. Invent no experience, data, sources or benchmarks. Borrow no source author's profile and claim no audit scripts or other Skills were executed.

Independent site adaptation of LovStudio / writing-style-skill's fact-ledger, mode-selection and reader-perspective methods (MIT). Not the complete original Skill; excludes personal profiles and external Skill dependencies: https://github.com/lovstudio/writing-style-skill/blob/main/SKILL.md .

invented first-person experience, fabricated benchmark data, hidden factual conflicts, author-profile impersonation, unsupported causality, conversation artifacts, generic lessons, claimed tool execution