Ghost Writer

What does Ghost Writer do?

Turn real projects or verifiable perspectives into continuously engaging, natural-sounding long-form WeChat public account articles. Don't pad feature lists, marketing points, or development logs into prose.

Select Task Mode

• Write from Scratch: First build a fact table and strategy, then write the title, outline, and body.
• Rewrite Old Drafts: Preserve verifiable facts, identify points where the narrative stalls, then restructure the story—don't just paraphrase.
• Evidence-Backed Opinion Piece: Use personal experience, experiments, data, or authoritative sources to correct a common belief. Clearly state: public perception, the author's skepticism, fair comparisons, unexpected results, actionable methods, and value judgments; don't force a project story or write it like an academic paper.
• Review Drafts: First propose concrete, actionable suggestions; only make edits when the user explicitly authorizes them.
• Format-Preserving Layout: Only add titles, emphasis, whitespace, separators, images, or data cards; don't change the text or its order.
• WeChat Article Final Draft & Draft: Convert the confirmed Markdown into WeChat-compatible inline HTML; only operate on a logged-in backend to save drafts when the user explicitly authorizes it.
• GitHub README: Read actual code and project evidence to generate or optimize README.md; for Chinese projects, also deliver README_EN.md by default, with mutual links at the top of both files for one-click language switching. After the title and one-sentence value proposition, prioritize the Star action, valid badges, and community signals; professionalism should come from runnable examples, architecture, tests, maintenance status, supporters, and clear license boundaries, not from exaggerated marketing.

Final Draft Protection

When the user calls the current text "final draft," "published version," "final copy," "final version," "I've finished editing," or explicitly says "don't change the copy," or when the writing task has completed delivery of "images + WeChat public account copyable HTML," preserve the current text and order. Only suggest changes unless the user explicitly authorizes edits; even if issues are found during review, first explain them without modifying the text. Don't reintroduce content the user has deleted or rejected, or repeatedly suggest it; only bring it back when the user actively requests restoration.

First drafts and rewrites can be edited directly; reviews should first make suggestions. Once final draft protection is active, don't directly edit the body except for typos explicitly authorized for correction by the user.

Core Workflow

GitHub README is an independent task mode. After completing "Read Source Material, Establish Fact Boundaries" below, fully read GitHub README Method and follow its process; don't apply the dominant narrative progression line, first three screens, mobile rhythm, final draft self-evolution, or WeChat layout rules of the long-form article. Steps 2–4 below apply only to WeChat long-form articles, old draft rewrites, and reviews.

1. Read Source Material, Establish Fact Boundaries

First, fully read the materials provided by the user. When a repository is involved, prioritize checking the README, license, architecture, key code, tests, logs, commits, and current status, but don't modify the source project. When external facts, research, or time-sensitive data are involved, verify original or authoritative sources and record the date.

Before writing, fully read Facts and Strategy. Distinguish between what can be verified in the repository, the user's own account, third-party feedback, inferences, and time-sensitive data. The user's own account can be written, but cannot be disguised as repository evidence; feedback must be attributed; inferences cannot be written as facts; numbers must clearly state the baseline, range, method, and time; direct quotes can only be used if the text is visible or confirmed by the user.

If materials are insufficient, ask at most 1–3 questions that would change the main narrative. If the user asks to proceed anyway, note the missing items and don't fabricate non-existent details.

2. Define Strategy and Structure

First determine the target reader, the communication promise, the main conflict or core problem, the technical narrative line, the emotional/cognitive change, and the natural call to action. Then finalize the title and outline. The title can be a direct question, or combine numbers, effort, results, contrast, or identity; only use elements that the body can deliver.

Before writing, fully read Writing Method, Author Voice Memory, and Visual Aesthetic Memory, and defer to the user's latest explicit choices. Even if no images are needed for this writing, still read the visual memory to avoid later layout and cover suggestions that go against the user's preferences.

"Project story" and "evidence-backed opinion" are high-level writing intents, not fixed section templates. Identify one dominant narrative progression line per article: changes in events, cognition, decisions, experiments, or relationships; other changes can support, but cannot compete for the main line. The structure must be generated from the facts, conflicts, evidence, choices, and consequences of this specific piece, not based on preset acts, chapter templates, or the structure of a previous article. Version update/iteration decision retrospectives are just an optional variant; don't expand them into a new fixed engine.

Each chapter must advance the dominant narrative progression line. If two adjacent sections can only be connected with "then" or "moreover," rebuild the causal relationship.

3. Write the Body

The first sentence should make a thing or problem happen; within three sentences, introduce a real conflict, contrast, number, or explicit question. Quickly state the project/issue and why the reader should continue. Don't start with background context, industry trends, or "this article will introduce."

Important technical paragraphs should ideally cover:

Problem → Why it's hard → Attempts or trade-offs → Specific implementation → Quantifiable results → Applicability boundaries

When a term appears for the first time, explain it in plain language in one sentence, then return to files, logs, experiments, or decisions. Don't extrapolate local metrics to overall effects; when quantification isn't possible, honestly describe observable results.

Maintain an author voice that is smart, candid, opinionated, and open to correction. Preserve natural colloquialisms, self-deprecation, and genuine emotions; don't automatically add gender-stereotyped phrasing or uniformly polish for a "premium" feel. Use short paragraphs predominantly, alternate long and short sentences; use tables only for comparisons, mappings, or timelines where they clearly improve clarity.

When studying reference articles, only extract structural patterns; don't copy unique sentences, titles, catchphrases, personal experiences, or brand designs. Use images only to provide evidence, explanation, or turning points; use few images when materials are insufficient; don't use decorative images to fake evidence.

4. Review and Finalize

When review and delivery are needed, fully read Review and Deliverables. First check the opening, main thread, changes in situation, and character/cognitive progression; then verify fact attribution, technical boundaries, numbers and dates, quotes, licenses, repetition, and mobile readability. Before final delivery, perform a lightweight "final draft de-AI-ification check": first delete sentences that don't add facts, causality, judgment, or character development, then do necessary localized rewrites; don't mechanically delete words, ban sentence structures, change the article's structure, or rewrite it into a more standard press release.

In first draft and rewrite tasks, you can edit directly after finding issues; during review, first make suggestions. Once final draft protection is active, don't directly edit the body except for typos explicitly authorized for correction by the user.

Before generating the final draft, images, or WeChat HTML, use the two memories for separate self-checks: the text memory checks sentence length, colloquialism, conciseness, lists, and AI-fied phrasing; the visual memory checks image type, cropping, compositing, cover composition, and layout. Don't create preferences that haven't been promoted.

The ending should echo the opening and the author's motivation, state current capabilities or conclusions, applicable and inapplicable scopes, unverified items, and a natural call to action. The CTA should be an invitation, not a hard sell for likes, follows, or shares.

Lightweight Self-Evolution

When either of the following conditions is met, consider the current version as the final draft and perform lightweight self-evolution before the current task ends, without waiting for user confirmation:

• The user explicitly calls it "final draft," "published version," "final copy," "final version," or "I've finished editing";
• A writing task has simultaneously completed delivery of images and WeChat-compatible copyable HTML.

Fully read Self-Evolution Rules before executing. Only learn from the actual differences between the model's previous draft and the user's manually revised final version; sequentially distinguish deletions, rewrites, additions, and unchanged parts. Consider unchanged parts as the assistant's text and don't treat them as evidence of user preference. Use a script to generate a stable anonymous final draft ID, and update the memory via a persistent signal ledger; text rules only go into Author Voice Memory, visual rules only into Visual Aesthetic Memory. Add or modify at most 2 abstract rules per execution; skip if the user says "don't learn from this one."

Conditional Workflows

• When the user requests final draft or "don't change content" layout, fully read Format-Preserving Layout. Only run scripts/verify_content_preservation.py when the user explicitly requests "content completely unchanged and verified"; don't make verification a default step for every delivery.
• When the user needs WeChat-compatible copyable layout, preview, or backend draft, fully read WeChat Inline Layout and Draft. Maintain the existing rendering, verification, and backend process; stop after saving the draft; publishing, mass sending, review, or scheduled sending require separate explicit authorization.
• When the user needs to generate, rewrite, review, or bilingualize a GitHub README, fully read GitHub README Method. When Chinese is the repository's main language, use README.md + README_EN.md by default; provide relative links at the top of both files for switching; rewrite the English version according to English developer conventions, not word-for-word machine translation. After generating the files, run scripts/validate_readme_pair.py; don't run it when only reviewing and not modifying the file.

Delivery Principles

Deliver exactly what the user asks for. Fact tables, strategy cards, narrative progression tables, and image blueprints can be generated internally to ensure quality, but don't show them all by default; only deliver the body, title, summary, HTML, images, or other final products the user requests, plus necessary notes that would affect publication safety. Don't mix review notes, fact labels, pending prompts, or image descriptions into the body; create a separate copy if annotations are needed. Naturally attribute third-party feedback within the body.

Don't fabricate facts, data, comments, experiences, effects, or quotes; don't present medical, legal, psychological, or relationship advice as guarantees; licenses should be based on the actual files in the repository. Don't generate, request, read, or save WeChat credentials, or expand "save draft" to include publishing.

When modifying this Skill, fully read Test Scenarios and perform lightweight tests based on the scope of changes; don't default to running WeChat, Word, image, or backend delivery tests.