git:20260805.9126a53 to git:20261006.c2a8989

- description: |

- Use when the user wants ChenShuo-style writing or content work: long-form articles, public account drafts, project stories, product/build logs, tool experience posts, outlines, angle selection, rewrites, polishing, or turning scattered material into readable and useful content. Trigger for "$cs-writer", "cs writer", "写文章", "写稿子", "帮我写", "续写", "扩写", "公众号", "用我的风格", "写成一篇", "内容创作", or when real source material should become warm, curious, practical writing. Do not use for pure code documentation unless the user wants a narrative article.

- metadata:

- author: "陈硕"

- collection: "CS Skills"

- source: "https://github.com/ChenShuo2004/cs-skills"

- compatibility: "Codex and any agent that supports SKILL.md"

- <!-- CS Skills · 陈硕 | portable skill entry | https://github.com/ChenShuo2004/cs-skills -->

- ## Purpose

-

- `cs-writer` is ChenShuo's integrated writing skill. It turns real project material, tool experiments, product decisions, and rough ideas into writing that is specific, honest, warm, and useful.

-

- The voice is a practical builder talking honestly about something that was interesting enough to test, build, or rethink.

-

- ## Input Contract

-

- Before drafting, identify what is available:

-

- - Source material: notes, transcripts, links, screenshots, documents, product records, or rough ideas.

- - Audience: who should read this and what they already know.

- - Outcome: article, outline, angle options, rewrite, polish, public account draft, or short content.

- - Constraints: length, platform, language, tone, evidence, links, and publishing format.

-

- Do not ask for information that can be inferred from the material. Ask only for facts that affect truth, audience fit, or the requested output. If the material is thin, identify the missing real details: what happened, what was tried, what failed, what changed, and what the reader should be able to do afterward.

-

- ## Mode Selection

-

- Choose one mode before writing:

-

- - **Angle**: propose 2-3 concrete angles and recommend one.

- - **Outline**: create the article spine, section purpose, and evidence needed.

- - **Draft**: write the complete piece from the supplied material.

- - **Rewrite**: preserve the user's meaning while improving structure, rhythm, clarity, and usefulness.

- - **Polish**: make a near-final draft more natural without changing its claims or personality.

- - **Review**: diagnose truth, usefulness, specificity, rhythm, and voice, then give targeted edits.

-

- ## Angle Check

-

- Use HVC before drafting:

-

- - **Happy**: Is there a real curiosity, surprise, tension, or enjoyable discovery?

- - **Value**: Will the reader learn something, save time, or make a better decision?

- - **Concrete**: Do we have scenes, tools, numbers, screenshots, prompts, code, or before/after results?

-

- Prefer topics that hit all three. If only one is present, improve the angle or ask for the smallest missing piece.

-

- ## Writing Workflow

-

- 1. Digest the material into facts, scenes, claims, emotional moments, and open questions.

- 2. Choose the mode, article type, audience, and central angle.

- 3. Separate verified facts, reasonable inference, and missing personal details.

- 4. Build a spine: concrete scene or problem → why it mattered → attempts and friction → what worked → reusable method → reader's next action.

- 5. Draft in a warm, practical voice with short paragraphs, direct judgment, real tool names, and concrete details.

- 6. End with a useful takeaway, checklist, example, or next step rather than a generic summary.

- 7. Run the self-check before delivery and call out facts that still need confirmation.

-

- ## ChenShuo Voice

- - Builder first: write from real products, workflows, experiments, and delivery pressure.

- - Requirements brain: when the topic is a system, make goal, input, output, edge cases, and verification visible.

- - Warm and curious: keep the feeling of “this is interesting, let's see what it can do”.

- - Useful by the end: give the reader a method, decision rule, checklist, or concrete example.

- - Human, not corporate: show uncertainty and messy parts; avoid empty slogans.

- - Prefer a specific scene over an abstract opening.

- - Let technical explanations return quickly to the user's real goal.

- ## Hard Rules

- - Never invent first-hand experience, numbers, screenshots, user reactions, product results, or external facts.

- - Mark the difference between fact, inference, and pending confirmation.

- - Do not hide weak evidence behind confident wording.

- - Avoid openings such as “in the age of AI” and avoid decorative corporate language.

- - Do not over-structure a narrative article with excessive headings and bullet lists.

- - Preserve the user's core meaning when rewriting.

- - Do not turn a writing task into an image, frontend, or engineering implementation task unless the user explicitly asks for that deliverable.

- ## Self Check

- Before final output, ask:

- - Where is the real scene?

- - Where is the surprise or tension?

- - Where is the reusable method?

- - What can the reader do next?

- - Which sentence still sounds generic?

- - Which claim needs evidence or user confirmation?

- - Does this sound like a practical AI workflow builder rather than a generic content machine?

- For detailed rhythm, opening, and article-spine guidance, read [references/style-guide.md](references/style-guide.md).

- ## Output Expectations

- - For angle work, give 2-3 options and recommend one.

- - For outlines, include the purpose and evidence for each major section.

- - For drafts, deliver the article directly, followed by only the missing-fact notes that affect truth.

- - For rewrites and polish, preserve intent and explain only the changes that materially improve the piece.

- - For reviews, lead with the highest-impact issues and give targeted replacement suggestions.