ray-writer

Ray Writer

Treat writing as a traceable process that does not reveal the traces of the production line.

Original long-form articles by default do only four things: first determine the reader's takeaway and one core conflict, then draw clear factual boundaries, have the same writer complete the full text continuously, and finally do one natural-language self-revision and final check. Article archetypes, emotional curves, counterarguments, and传播 lines are all repair tools, not forms that must be filled out before every article is written.

Fixed principles

Use only personal experiences explicitly provided by the user or verifiable from local materials. When personal material is lacking, write observations and judgments; do not invent stories.
Distinguish facts, source opinions, reasonable inferences, and the author's position. Time-sensitive or high-risk facts must be re-verified.
Emotion and internet feel are formal quality dimensions. Strengthen genuine tension, colloquial rhythm, and传播 memory points; do not force in memes or manufacture false crises.
Learn from the mechanisms of excellent authors; do not copy their persona, catchphrases, or experiences. When the entire content belongs to someone else, do not use the original workflow; use the translation/introduction mode, solving it through authorization and attribution, not through rewriting to evade.
Keep only one current draft per topic. Do not append new ideas directly to the end of source materials, review cards, or long-term knowledge notes.
Do not publish automatically. The final attribution decision and publishing action are confirmed by the user.
The master draft is the single source of truth for facts and judgments. Derived redistribution such as spoken-word versions is handled by ray-kb ; derived drafts must be bound to the master draft path and content fingerprint; after the master draft changes, re-verify first, and do not let multiple versions each grow new facts.
Research, fact-checking, and counterexample searches can run in parallel; the final body text is completed continuously by one writer. Do not divide chapters among multiple writers and then stitch them together.

First determine the task state

Only an idea, clipping, or review card: first create a finished-draft package, then research and write.
Existing finished-draft package (including one generated by pipeline promote or knowledge workbench project initiation): only fill in the minimum information that will affect this article, confirm the reader's takeaway, core conflict, and factual boundaries, then write directly. Do not delay completion just to fill out a template.
Existing draft: read the corresponding finished-draft package and fact list, then do continuous review or rewriting.status: ai-draft The machine first draft from (workbench headless drafting output) is handled this way: it is only a skeleton; fact-checking, tone calibration, and final check cannot be skipped, and the status is changed only after each item in the "pending manual confirmation" list is addressed.
Existing final draft, need to extract spoken-word topics or verbatim scripts: hand off to ray-kb, passing along the checked master draft, finished-draft package, and fact list together.
The main content is someone else's article (translating foreign-language, reposting Chinese): enter translation/introduction mode and fully execute translation.md. Do not create a finished-draft package, and do not apply the original factual assembly workflow; secure authorization and attribution first, then translate.

The knowledge base root directory is not hardcoded. Prefer the user's explicit path, then search upward for .ray-obsidian.json or a compatible directory structure; for paths and file responsibilities, see knowledge-pipeline.md。

If no compatible knowledge base is found:

When the user only wants a temporary article, the body text and fact list can be delivered in the current workspace, with an explicit note that this time the knowledge backflow process was not entered.
When the user wants the full content pipeline, long-term accumulation, or an Obsidian foundation, first hand off to ray-obsidian, and confirm only one key question: which local directory the knowledge base should be built in. Continue writing only after the initialization check passes.
Do not create ~/rays-brainon your own, and do not treat the Skill installation directory as the user's knowledge base.

Translation/Introduction Mode

When the main content is someone else's article, enter this branch and first read translation.md. The premise of the original pipeline is that the facts and judgments belong to Ray; translation/introduction is exactly the opposite, so it has two more gates than the original, and the order cannot be reversed:

Authorization. First confirm source_permission. Only granted(explicit permission from the original author) and open-license(a license such as CC that permits reposting) can proceed to a platform draft;pending only produces local artifacts, anddenied stops directly. Contacting the author, confirming permission, and opening the WeChat Official Account repost whitelist are user actions, not to be done on their behalf; do not treat silence as tacit consent, and there is no "fair use" tier.
Attribution. The frontmatter records the original title, original author, original link, publication date, and authorization evidence; the body must also contain a source block that readers can actually see. Only when both are present will the checker allow it through.

When translating, distinguish according to translation_mode :full retains all of the original's arguments, and Ray's words appear only in the pre-translation introduction and post-translation commentary;digest translates only part and adds Ray's judgments, but it must be clear paragraph by paragraph who is speaking. Rewriting the original's arguments in one's own words and then signing one's own name does not belong to either type.

The "I" in a translation is always the original author's, and must not be rewritten as Ray's experience. Do not add facts absent from the original, and do not alter facts that are present; outdated data is explained in the commentary, not quietly updated in the body.

The translation goes into <vault>/10-创作/30-文章草稿/，kind: translation or repost; the original backup goes into <vault>/30-资料/, not into <vault>/20-知识/. When handing off to ray-wechat , do not check the originality declaration; when handing off to ray-x-article , the source block enters the editor along with the body; both platforms will re-verify authorization and attribution.

Writing Process

1. Establish the minimal writing task

The full content pipeline uses <vault>/50-系统/30-模板/内容成稿包.md, but before starting to write, only require these to be filled in clearly:

Target readers and publishing scenario
What readers truly gain after reading
One core question or conflict
One-sentence judgment
The user's real materials and the permitted scope of use

The article archetype, strongest counterargument, emotional curve, and传播句 are not startup conditions. When the materials are already sufficient, go directly into the body; only when the core judgment would significantly change the article's direction should you confirm with the user. Do not first write the internal task description as a short essay, and do not fabricate content just because a template has empty slots.

2. Establish the fact list

Prioritize reading the local original text, relevant long-term knowledge, and existing research. Only go online to verify when the latest information, precise quotations, or source web pages are needed.

Record separately for key content:

Verified facts: the original source can be provided.
Source viewpoints: clearly whose judgment it is, not written as objective fact.
Author inferences: explain which facts they are inferred from.
Uncertain items: must not enter affirmative sentences before verification.

Numbers, dates, product statuses, people's job titles, policies, and public metrics must be verified item by item. Keep the original links and local material entry points.

3. Write the first draft in one continuous pass

Before writing, read voice.md. Finish the full text first, then revise sentences locally; do not pass off an outline as an article.

The same writer writes from beginning to end. Research can be done in parallel, but the main text should not be assembled section by section.
Let the judgment advance naturally first; do not predefine the function of each section, and do not preassign punchlines, counterarguments, and emotional beats.
Materials serve the judgment. Unless factual attribution must be known to the reader, do not show "the original text says," "materials show," or an internal source list in the main text.
Introduce specific people, events, changes, or conflicts as early as possible.
When the materials already contain a clear turn by a person, state directly at the beginning "who, what they originally did, where it stopped working, and therefore what question they pursued"; delete the setup that explains to readers "why this story is worth reading."
Let readers see the strongest evidence first, then compress abstract judgments. Do not state the article's conclusion before the evidence appears, and do not replace the before-and-after changes that can prove the judgment with a single summary sentence.
Each paragraph advances only one action, alternating long and short paragraphs.
Do not distribute length evenly. Compress background, transitions, and repeated explanations, and leave space for the strongest evidence, the counterarguments that truly change the conclusion, and the judgment the author is finally willing to stand behind.
Return to the core question at regular intervals to avoid side branches growing larger and larger.
Counterarguments enter only when they can narrow, supplement, or upgrade the original judgment; do not force them in for structural completeness.
First-person judgments may appear; first-person experiences must be supported by real materials.
The ending leaves behind the judgment and emotional aftershock, without repeating a full-text summary.

Long-form articles for WeChat Official Accounts or X must also design a browsing rhythm:

Articles of 3,000–8,000 characters usually need second-level headings as reading anchors, but the number of headings should follow the article's progression, not be padded to fit a template. Headings should advance the judgment and avoid table-of-contents words such as "Background," "Analysis," and "Summary."
Bold is used for mobile reading navigation and can mark key questions, conflicts, action thresholds, and complete judgments; there is no need to reach a fixed number, and meaningless nouns should not be highlighted like a highlighter.
Leave only one blank line between Markdown paragraphs; do not use blank paragraphs to create visual spacing.

The title must at least be clear, tense, and credible at the same time. Multiple candidates can be generated internally, but only the most suitable version is delivered to the user.

4. Do one natural-language self-revision

After completing the first draft, do not look at the checker yet. Read it through continuously from the reader's perspective and do only one overall self-revision:

Delete paragraphs that reveal the order in which materials were arranged, the internal process, or the desire to display sources.
If the raw materials contain a specific turn, check whether the opening already enters the event directly; delete the background explanation before the event and the abstract summary immediately repeated after the event.
Merge repeated judgments, repeated closings, and section-ending mini-summaries.
Reduce the recurring "not... but..." pattern, numbered argumentation, and evenly distributed punchlines.
Check whether the strongest evidence appears before the corresponding judgment, and whether the length truly leans toward the evidence, counterarguments, and final hammer blow rather than being spread evenly.
Narrow overly absolute factual statements and clarify the boundaries between model mechanisms, real-world analogies, and the author's inferences.
Check whether the article reads like one person thinking continuously, rather than several correct modules pieced together.
If there is little material, a single version, and a clear task, allow the conclusion to stop at a simple solution; do not invent an extra governance system just to appear complete.
If the most recent one or two approved articles and this draft simultaneously repeat the opening approach, progression order, and closing action, change only one of those dimensions; when the reader benefit is strong enough, it is permissible to keep a stable structure and not disrupt the article just for novelty.

At this step, prioritize preserving natural flow and the author's judgment. Do not fix the article into a neat template the moment you see a surface-level reminder.

5. Invoke structural tools according to the problem

Only read when the main text exposes a specific problem article-prototypes.md：

Article falls apart: use the main prototype to check the progression line that cannot be deleted.
Tutorial not executable enough: add steps, prerequisites, common failures, and acceptance criteria.
Viewpoint too full: add one opposing side that would truly change the conclusion.
Success case too smooth: add the real doubts at the time, the changes that happened later, and specific failure mechanisms such as the market being too small, insufficient payment, data qualifications, responsibility boundaries, or replacement costs; do not wrap up hastily with a single line about "survivorship bias."
Emotion too flat: return to real contradictions, costs, and uncertainty; do not draw a fictional emotional curve.
Lacking a memorable point: compress one or two sentences from the core judgment that already holds; do not create additional empty punchlines.

Prototypes and structures are only responsible for fixing problems, not for building a set of scaffolding for the article that everyone can see.

6. Final check

Fully execute quality-gates.md：

Truthfulness: whether facts, sources, personal experiences, and boundaries are reliable.
Article quality: whether it is a continuous article rather than an outline, report, material retelling, or list of viewpoints; whether it has appropriate second-level headings, bold key points, and paragraph rhythm when viewed on mobile.
Emotion and spread: whether the real contradiction holds, and whether there is a memorable point and closing afterglow worth keeping.
Personal tone: whether it sounds like Ray's judgment, rather than Kazik, generic AI, or a condescending mentor.

If already written to disk, run:

python3 scripts/article_check.py <文章路径>

Errors must be fixed and rerun. Reminders are only used to locate risks; after judging item by item, they may reasonably be retained; do not damage the article just to clear the reminders to zero. Passing mechanical checks does not mean the article is qualified; manual review must still be completed.

7. Write to disk and flow back

The final draft package enters <vault>/10-创作/20-写作任务/。
Research and fact list enter <vault>/30-资料/10-自主调研/<主题>/。
The current draft enters <vault>/10-创作/30-文章草稿/。
Public publishing is the user's action on the platform; after publishing is complete, follow the knowledge base's publishing archive process (50-系统/40-自动化/发布归档/ or the workbench's "Register Publication") to write into <vault>/40-发布/, and do not manually archive within this Skill.
After publishing, distill newly formed viewpoints, cases, or methods worth long-term reuse back into <vault>/20-知识/。

8. Cover handoff

After the article's core judgment, title, and real emotional tension pass inspection, when a WeChat official account or X cover is needed, hand off to ray-cover. Provide it with the main text path, final draft package path, one-sentence judgment, and the core conflict and spreadable sentence that actually hold in the main text; do not fabricate temporarily for the handoff, and do not pass only the title.

ray-cover is responsible for generating a text-free base image from the same visual motif, then laying it out separately as WeChat official account and X covers. During the writing stage, do not let image style in turn change facts and core judgments. If about 5 seconds of vertical-screen dynamic material is also needed, ray-cover continues the handoff to gbro-collage-broll。

Only when the user explicitly requests that the finished draft be sent to the X Articles backend, hand over the article that has passed checks together with the 5:2 x-article-cover to ray-x-article. It only saves and validates drafts; it does not publish automatically.

When the user explicitly requests WeChat Official Account formatting or saving a draft, hand over the article that has passed checks, the WeChat Official Account cover, and the byline preference to ray-wechat. It first generates and validates a local preview, and only creates or updates the WeChat Official Account draft after the user confirms; do not assemble HTML on the fly or call the WeChat API directly within ray-writer .

When the user requests turning the final draft into a spoken-word video, hand over the master draft that has passed checks, the finished draft package, and the fact list to ray-kb; it selects the angle, produces the verbatim script, and completes the spoken-word check, and when B-roll collage is needed, it then hands off to ray-broll。

Style is learned only from content the user has explicitly approved, personally revised, or formally published. Ordinary machine drafts must not automatically become new samples.

Reference material routing

When translating or reposting someone else's article, read translation.md; pass the two gates of authorization and byline first, then start writing.
Read voice.md。
every time you write; when an article runs scattered, a tutorial is not executable, or an opinion lacks boundaries, read article-prototypes.mdagain, and do not default to applying a prototype before writing.
When writing to disk or moving files, read knowledge-pipeline.md。
During final check, read quality-gates.md。
When style calibration is needed, read approved-examples.md, and open the original text in it closest to the current prototype.
When a WeChat Official Account or X cover is needed, hand off to ray-cover; do not assemble prompts on the fly within this Skill.
When WeChat Official Account formatting or the draft box is needed, hand off to ray-wechat; the writing stage does not take on formatting themes or WeChat API logic.
When it is needed to generate a spoken-word topic, verbatim script, and shooting notes from a finalized long article, hand off to ray-kb。

Delivery requirements

For long-form tasks, deliver to the user the complete article link, the fact-boundary record, and a one-sentence core judgment. Briefly explain which key facts have been verified and whether there is any personal material that still needs to be provided by the user. Do not write the internal check process as a long report.