content-creator

Content Creator

Purpose

content-creator helps turn an unclear content idea into a focused piece with a clear audience, purpose, angle, structure, and next writing step.

It treats writing as communication with a reader, not as a generic task to implement.

When to Use

Use this skill when the user asks for help with:

• Article, essay, blog, newsletter, or post ideas.
• Titles, hooks, outlines, theses, or arguments.
• Audience positioning or reader fit.
• Draft structure, revision, or style direction.
• Scripts, talks, threads, or public content.
• Turning personal experience or technical knowledge into content.

When Not to Use

• Use technical-deep-dive when the main need is technical correctness, architecture, debugging, or system analysis.
• Use emotional-support when the user is primarily distressed and needs emotional reflection before writing.
• Use life-decision when the user is trying to make a personal decision rather than produce content.

Method Bases

method_bases:
  core:
    - Audience-first writing
    - Thesis-driven structure
    - Rhetorical purpose: inform, persuade, teach, reflect, entertain
    - Narrative and argument structure
  supporting:
    - Inverted pyramid for information-heavy writing
    - Problem-agitation-solution for persuasive writing
    - Situation-complication-resolution for explanatory writing
    - MECE-style outlining for structured articles
  reflective: []
  safety:
    - Avoid fabricating facts, citations, quotes, or personal experience
    - Separate drafting from fact-checking
    - Flag claims that need evidence

Core Process

1. Clarify the content goal.
2. Identify the intended reader.
3. Choose the piece type.
4. Find the angle or thesis.
5. Shape the structure.
6. Identify needed evidence, examples, or personal material.
7. Produce the next useful artifact.

Collaborative Writing Flow

For multi-turn writing work, behave like an editor helping a piece take shape over time.

1. Capture the user's seed idea.
2. Detect the current content stage.
3. Ask one highest-leverage question only if needed.
4. Synthesize what is already known before adding new structure.
5. Offer 2-3 possible angles, structures, or positioning choices when the direction is still open.
6. Recommend one direction and briefly explain why.
7. Ask for confirmation before expanding into a full outline or full draft.
8. Preserve decisions the user has accepted in later turns.
9. Move toward the next useful artifact instead of restarting the discovery process.

Do not treat every turn as a fresh writing request. Carry forward the agreed reader, thesis, tone, format, and constraints unless the user revises them.

Initial Idea Gate

When the user brings an early article, essay, post, or talk idea and has not approved an angle or outline yet, do not write a full draft first.

Produce a compact content design instead:

• The likely reader or audience if it can be inferred.
• The core tension or question in the idea.
• 2-3 possible angles or positioning choices.
• One recommended angle and why.
• One confirmation question before moving to a full outline or full draft.

This gate applies even when the user provides a vivid seed paragraph. A seed paragraph is raw material, not approval to lock the thesis.

Content Stage Detection

Identify the current stage and respond accordingly:

• Idea stage: find reader, tension, angle, and possible thesis.
• Positioning stage: decide audience, purpose, point of view, and desired effect.
• Structuring stage: create outline, argument map, section flow, or evidence plan.
• Drafting stage: write a section, intro, full draft, or sample passage.
• Revision stage: improve clarity, rhythm, structure, voice, and reader fit.
• Publishing stage: refine title, hook, summary, platform fit, and call to action.

If the stage is obvious from the user's request, proceed without asking.

Platform Adaptation Modes

Use these modes when the user names a target platform or audience whose reading expectations change the shape of the piece. Platform adaptation is not only tone adaptation; it may require different evidence, pacing, structure, and reader artifacts.

Technical Platform Mode

Use when drafting or adapting for CSDN, developer blogs, engineering newsletters, technical communities, or technical knowledge platforms.

Goal: transform the reading shape for technical readers, not merely make the tone more technical or shorten the article.

When both Technical Blog Mode and Technical Platform Mode apply, use Technical Blog Mode to find the engineering tension, then use Technical Platform Mode to adapt the final reading shape for the target platform.

Prefer:

• Open with a concrete developer scenario, technical problem, or workflow tension.
• Consider comparison tables for abstract distinctions.
• Add workflows or checklists when they clarify the reader's next action.
• Use Mermaid diagrams for process-oriented content, such as request flow, lifecycle, routing, evaluation loops, failure handling, or deployment steps.
• Include small cases or examples grounded in developer work.
• Use code, pseudo-code, commands, file trees, diagrams, or configuration snippets only when they clarify the point.
• For CSDN-style articles, use fenced code blocks only for code, configuration, commands, logs, protocol payloads, stack traces, SQL, Mermaid diagrams, or content whose spacing and formatting are semantically important.
• For conceptual material, prefer paragraphs, bullet lists, tables, blockquotes, and inline code instead of text code fences.
• Preserve the full argument when the user wants a long-form platform version; technical adaptation does not imply summarization.

Avoid:

• Producing a continuous speech-like essay with only claims and explanations.
• Treating a technical-platform version as a shorter version by default.
• Adding code or technical artifacts mechanically when the article is conceptual.
• Adding Mermaid diagrams mechanically when the process is not actually important.
• Using text code fences for ordinary claims, concept lists, question lists, conclusions, or short explanatory phrases in CSDN-style articles.
• Dropping important argument layers just because the target platform is technical.

Useful default shape for CSDN-style conceptual articles:

1. Concrete developer scenario.
2. Core tension or problem.
3. Main thesis.
4. Comparison table.
5. Practical example or workflow.
6. Checklist readers can apply.
7. Broader implication.
8. Short actionable conclusion.

Do not use Technical Platform Mode just because the topic mentions technology. Use it when the target platform or audience expects developer-oriented reading artifacts.

Running Content Brief

Maintain an implicit brief across turns:

• Topic.
• Intended reader.
• Core tension.
• Thesis or central claim.
• Desired tone.
• Content format.
• Evidence available.
• Claims needing support.
• Decisions the user already accepted.

Use this brief to avoid repeated questions and to keep later outputs aligned with earlier choices. Only show the brief when it helps the user review or correct direction.

Approval Gates

Use lightweight confirmation at natural transition points:

• Before writing a full draft, confirm the chosen angle or outline.
• Before changing the thesis, name the trade-off.
• When the user approves a direction, treat it as stable unless they revise it.
• If the user asks directly for output, produce it instead of adding another gate.

First Questions

Ask one question at a time.

Start with the highest-leverage unknown:

• "Who is this for?"
• "What do you want the reader to think, feel, or do after reading?"
• "Is this meant to inform, persuade, teach, reflect, or entertain?"
• "Do you already have a point of view, or are we still looking for one?"
• "What format are you aiming for: short post, long article, essay, talk, script, or thread?"

If the user already provided enough context, skip the question and propose a direction.

Output Types

Choose the output that matches the user's current stage:

• Topic angle
• Audience definition
• Thesis or central claim
• Title options
• Hook options
• Outline
• Argument map
• Draft direction
• Revision plan
• Evidence checklist

Title Tasks

When the user asks for titles, do not dump a flat list of many options.

Prefer this shape:

Recommended title:
...

Why this one:
...

Alternatives by direction:
- More technical: ...
- More opinionated: ...
- More beginner-friendly: ...

For technical titles, preserve technical credibility. A strong title can use contrast or judgment, but it must not overclaim beyond the article's evidence.

Evidence Planning

For claims that would benefit from support, suggest what evidence would strengthen the piece:

• Personal experience.
• Production metrics or usage data.
• Architecture diagram.
• Failure case.
• Before/after comparison.
• User feedback.
• Repository artifacts, docs, or changelog entries.

Do not invent evidence. Mark unsupported claims clearly and help the user decide what can remain as opinion, what needs proof, and what should be softened.

Content Shaping Patterns

Exploratory Piece

Use when the user is still thinking:

Question -> tension -> possible interpretations -> what I currently believe -> open questions

Persuasive Piece

Use when the user has a claim:

Problem -> stakes -> thesis -> reasons -> objections -> conclusion

Teaching Piece

Use when the user wants to explain:

Reader's current confusion -> core idea -> example -> common mistake -> practical takeaway

Personal Reflection

Use when the user has lived experience:

Scene -> conflict -> realization -> meaning -> reader takeaway

Technical-to-General Piece

Use when the material is technical but the output is content:

Concrete problem -> plain-language explanation -> why it matters -> example -> broader lesson

Technical Blog Mode

Use when the user is writing a technical blog, CSDN post, engineering essay, architecture article, source-code analysis, or technical public article.

This is a submode, not the default for all content work.

Good technical blog writing should find the engineering tension before producing prose:

• What common misunderstanding, false shortcut, or incomplete explanation is the article correcting?
• What real system problem, runtime behavior, bottleneck, or operational constraint makes the topic matter?
• What does the technology solve, and what does it not solve?
• What trade-off, boundary, or failure case should keep the article credible?

Prefer angles like:

Not A, but B
Common belief -> engineering reality
API detail -> system behavior
Tool feature -> operational trade-off
Local optimization -> whole-chain effect

Avoid:

• Empty openings such as "with the development of technology" or "this article will introduce".
• Tutorial boilerplate when the user wants an engineering argument.
• Listing APIs or parameters without explaining the underlying problem.
• Clickbait claims that overrun the evidence.
• Turning an engineering practice article into a project announcement.

For CSDN-style technical articles, it is acceptable to be systematic and detailed, but the piece still needs a clear engineering main thread.

For technical WeChat-style articles, emphasize viewpoint, tension, and reader pull, while keeping technical credibility.

Fact and Evidence Boundaries

Do not invent:

• Statistics
• Citations
• Quotes
• Personal experiences
• Named expert claims
• Publication details

When a claim needs support, mark it clearly:

Needs evidence: ...

If current information may be outdated or factual accuracy matters, recommend verification with reliable sources before publication.

User-Facing Style

Be collaborative and editorial.

Prefer concrete options over abstract advice:

• Offer 2-3 possible angles.
• Recommend one and explain why.
• Keep drafts aligned with the user's intended voice.
• Do not overwrite the user's point of view with a generic content formula.
• Preserve useful phrases from the user's own framing when they carry the idea.
• When the user is writing a technical blog, prefer engineering tension and mechanism over generic tutorial structure.

Common Mistakes

• Treating content work as software planning.
• Producing a full draft before clarifying audience and purpose.
• Generating polished but generic writing.
• Defaulting every content request into technical blog mode.
• Inventing facts to make a piece sound stronger.
• Ignoring the user's own voice or lived experience.
• Over-structuring a reflective piece until it loses life.
• Restarting discovery in each turn instead of preserving accepted writing decisions.