cmm-content-factory

name	cmm-content-factory
description	Use this skill as an independent content factory orchestrator when the user wants to run or design an end-to-end content production workflow across active search, subscription collection, topic planning, platform writing, image/card production, video packaging, and publishing to platform drafts. It can consume a CMM business-blueprint brief, but it is not owned by the CMM business OS. It coordinates content-stage skills (planning, writing, web-search, image, visual, typesetting, video, publishing) plus the bundled remotion render engine. Live auto-publish is an optional plugin.
version	0.1.3

Content Factory

cmm-content-factory is the orchestration layer for automated content production. It does not collect sources, write every format, generate every asset, or publish by itself. It chooses the right content-stage skills, keeps the workflow state coherent, and enforces handoff contracts between stages.

Boundary

Use this skill for:

• Building an end-to-end content workflow.
• Turning searched or subscribed information into selected topics.
• Choosing platform-specific content formats.
• Coordinating article, image, video, and publishing skills.
• Keeping draft packages auditable before publication.
• Creating a content task record so source, planning, writing, visual, and publish artifacts can be reviewed and traced (agent-written convention, not a replay engine).

Do not use this skill as:

• A web-search backend. Use cmm-web-search.
• A subscription/news collector. Daily source-pool collection is a separate, optional channel.
• A final publishing approval bypass. Publishing still needs an explicit user gate.
• A replacement for the specialized cmm-* stage skills it coordinates.

Composition

The factory is self-contained as a content-production system. It coordinates the installed content-stage skills (planning, writing, web-search, image-creator, visual-production, typesetting, video-production, publishing) and the bundled cmm-remotion-video render engine. The stage skills currently keep their cmm-* names for compatibility, but they are operational dependencies of this factory, not proof that the factory belongs inside the CMM business OS.

CMM business OS (cmm-business-os / cmm-diagnosis / cmm-blueprint) is only one possible upstream. When CMM routes an acquisition module here, it passes a content_brief through blueprint.yaml route[].brief; direct user requests, source pools, articles, transcripts, and drafts can also enter this skill without CMM.

Live auto-publish (browser automation against platforms) and specialized source scrapers are optional plugins, not part of the core package; they are never required for planning, writing, image, typesetting, video, or draft-package work.

Pipeline

information_input
  -> topic_selection
  -> content_diagnosis
  -> platform_writing
  -> visual_packaging
  -> video_packaging
  -> publish_draft
  -> review_learning

Stage Routing

Stage	Purpose	Skill
active_search	User-initiated keyword, article, case, competitor, or fact search	cmm-web-search
subscription_collection	Daily source pool from feeds, RSS, news push	cmm-web-search (generic collection); specialized scrapers are an optional plugin
topic_selection	Rank and select creator-ready topic cards	cmm-content-planning
content_diagnosis	Decide angle, format, platform fit, risks, and first action	cmm-content-planning
platform_writing	Produce platform-specific article/post/script drafts	cmm-content-writing
visual_packaging	Produce cover, article images, social cards, Xiaohongshu image sets	cmm-visual-production
image_generation	Generate raw image assets (covers, illustrations, backgrounds) from visual_plan specs after approval	cmm-image-creator (native runtime image generation preferred, configured third-party APIs optional)
typesetting	Typeset finished long-form drafts into WeChat-compatible publish HTML (13 themes + 15 components + deterministic renderer + layout checks)	cmm-typesetting
video_packaging	Produce short-video scripts, storyboards, render packages, video checks	cmm-video-production + bundled cmm-remotion-video render engine
publish_draft	Assemble publish package, create drafts	cmm-publishing (live auto-publish via optional plugin)

Read references/skill-routing.md before changing route decisions. Read references/knowledge-routing.md before saving any learned method, rule, or pitfall: reusable domain knowledge belongs in the skill files (so it ships and is copyable), not in private per-user memory.

Workflow Rules

1. Start by identifying the input lane:

   • active_search: the user asks to search, compare, verify, or find cases.
   • subscription_collection: the user asks for daily sources, feeds, news push, AI hot, or a source pool.
   • user_material: the user provides documents, notes, drafts, links, transcripts, or raw material.
   • business_blueprint_brief: an upstream CMM blueprinted acquisition module provides route[].brief.

2. Normalize every input into a source or material card before topic selection.

3. Create a task directory for non-trivial content production. Save intermediate artifacts as source-cards.*, topic-card.*, content-plan.*, content-package.*, visual-package.*, video-package.*, and publish-package.* when those stages are used. For any task spanning two or more stages, also write a content-task-record.yaml in that directory (schema in references/content-task-record-contract.md) and keep it updated with artifact paths, key decisions, and backend checks — it is the one file that ties the task's per-platform outputs together. For multi-stage tasks, content-task-record.yaml must also carry a gate_checklist that records each required stage gate as passed, pending_user_confirmation, blocked, or waived with a concrete reason. A downstream stage may not start unless the upstream gate is passed or explicitly waived; user-facing confirmation gates may only be passed after the user confirms in chat. Also keep stage_status_panel current. Whenever the workflow enters or exits planning, writing, visual generation, typesetting, or publishing, update and summarize: current stage, completed confirmations, waiting confirmations, blocker, and next action.

4. Select topics before writing. If the user already has a chosen topic, still build a minimal topic card.

5. Run CMM content diagnosis before generating final drafts unless the user explicitly asks for direct drafting.

6. No styleless writing. Any article draft produced through CMM Content Factory must use an explicit style_selection from the CMM style system. Never draft from the base model's generic voice, and never leave writing style implicit. If the user specifies a style in the current turn, use that. Otherwise choose a default from the style system before writing. User profiles are runtime configuration, not part of the shared skill package: resolve the active user profile from the current environment, current user request, or ~/.cmm/profile/. In this local machine, ~/.cmm/profile/neo.yaml is a local default when it exists and the user did not request another profile; do not hardcode Neo-specific traits into shared skill rules. If multiple profiles are available and no default is clear, ask the user to choose; if no user profile exists, use the shipped persona-neutral default profile and state that the article is using the generic default.

7. Style selection must be recorded before drafting. content_plan must include style_selection.user_profile, writing, visual, layout, and selection_reason before cmm-content-writing runs. content_task_record must also record style_checks.user_profile_loaded, user_profile_path, writing_style, and layout_style. Missing style selection is a blocker, not a warning.

8. Personal style is a pre-draft writing constraint, not a post-check. When an active user profile exists, generate and record a personal_style_brief before drafting. This brief translates the profile and account template into concrete writing constraints that are loaded before the model writes:

   • opening_strategy: how this article enters through the user's lived pain, observation, or first-hand use, not a generic concept definition.
   • core_judgment: the author's strongest useful take for this exact topic.
   • practitioner_perspective: for AI tools, product updates, workflow articles, tutorials, and practical tech explainers, the author's stance type, realistic use scene, how the author would or would not use the thing, likely misuse, and evidence boundary. Do not fake hands-on experience.
   • structure_strategy: how the article should be shaped by the author's judgment before generic article-type templates are applied.
   • selection_logic: how examples, tools, cases, or sections are selected and what is intentionally not selected.
   • paragraph_rhythm: how the profile's cadence maps to the target platform.
   • must_sound_like: concrete first-person/product-practitioner signals this article must carry.
   • forbidden_shape: structures that would make the piece feel generic, such as tool manuals, equal-weight listicles, average explanations, or framework blocks that the account template did not ask for.

   personal_style_brief has priority over generic article-type scaffolds, but it never has priority over the selected title's promise. If the generic type (for example tool_list_comparison) would turn the piece into a tool manual, reframe the subtype so the author's core judgment shapes the angle while keeping the title's promised subject visible as the article's main deliverable. General CMM writing rules are downstream constraints and sanity checks; they do not replace the pre-draft instruction package. Missing personal_style_brief is a blocker for drafting. The brief must then be converted into drafting_instruction.pre_draft_style_constraints before cmm-content-writing writes正文. This object is the executable version of the user's profile for the current article: opening move, first-300-character judgment, article backbone, practitioner perspective, section-level intent, paragraph rhythm, first-person stance, required judgment signals, allowed lexicon, banned shapes, and rewrite triggers. If it is missing, generic, or only repeats profile labels, drafting is blocked. A post-draft voice_match_evidence cannot pass unless it proves the draft followed these constraints, not merely that the profile was loaded.

9. Voice match must be evidence-based. Any CMM article draft must include a voice_contract plus voice_match_evidence from cmm-content-writing. Loading a profile or using a few preferred words is not enough. The evidence must prove that the draft matches the selected style's structure, viewpoint, sentence rhythm, opening/closing pattern, and forbidden tones. Downstream visual planning, typesetting, draft creation, and publishing may continue only when voice_match_evidence.passed: true and failures are empty. If it fails or is missing, stop and rewrite.

10. Rewrites inherit style. Any rewrite, compression, polishing, title revision, opening revision, final pass, or platform adaptation of an existing CMM article must inherit the current style_selection. Do not revert to a generic writing voice just because the user asks for "shorter", "cleaner", "more concise", "final version", or similar edits. Change style only when the user explicitly asks to change style.

11. Stage changes rerun the matching gate. When a conversation moves from discussion/writing into visual planning, image generation, typesetting, or publishing, do not continue from conversational assumptions. Re-enter that stage's CMM gate, read the required stage references, and record the decision before acting. If the user changes an already-recorded decision during or after a later stage, append a change_log entry to content-task-record.yaml with the old value, new value, reason, confirmation status, timestamp, and affected artifacts. Examples: final title replacement, confirmed-body rewrite, image text change, body image repositioning, layout theme switch, publishing backend fallback, or draft target change. Do not rely on the latest artifact alone to explain why it differs from the original plan.

12. Writing decision gate before drafting. Before generating any WeChat article正文, the agent must internally decide the demand fit, not immediately "write a full article" from a topic. Record this in content_plan, content_package, and content_task_record:

• user_real_need: what the user is actually trying to express or solve, not just the literal topic.
• reader_takeaway: what the reader can understand, decide, avoid, or do after reading.
• article_type: quick news judgment, short opinion, practical guide, tutorial, deep analysis, list/recommendation, etc.
• target_length: a justified length range for that type and topic payload (for example, a one-point news judgment should not be padded into 2000+ words).
• one_sentence_spine: the article's central promise in one sentence.
• must_include: facts or arguments required to fulfill the title/user ask.
• must_exclude: adjacent facts, advice, or "useful-looking" expansions that would waste reader time or move the article off topic.
• scope_boundary: what this article is not trying to cover. Do not confuse this with asking the user for approval. It is a mandatory internal editorial decision gate. Ask the user only when materially different article types, audiences, or boundaries are plausible and cannot be inferred. If the spine cannot be stated in one sentence, the reader takeaway is vague, or the target length is unsupported by the content payload, do not draft; refine the plan first.

13. WeChat title-outline direction confirmation. For WeChat long-form articles, present a concise direction brief after content_plan and before drafting_instruction; wait for user confirmation before drafting正文. This is the forward-looking confirmation for "what article are we going to write", distinct from the final title/body confirmation after the draft exists. Before producing this direction brief, load the WeChat title rules from cmm-content-writing/references/platform-copy-specs.md and cmm-content-writing/references/title-spec.md, then record a title_direction_gate in content_plan. Direction-stage titles are not final publish titles, but they still must be platform-feasible and must shape the article promise. Do not generate one lone title and ask the user to accept it. Provide 3-5 direction title candidates, each with computed length, title pattern, angle, and reason. For WeChat, candidates must fit the CMM title production budget before they are shown. If the article is about a product, tool, brand, or named person, the subject must remain in the title unless the user explicitly approves a subjectless headline. If the article is about an update, the title direction must show what changed from the previous state; do not write only "来了/上线了" when the feature existed before. Include:

• 推荐标题方向 / 备选标题方向: 3-5 working direction candidates, not the final title; include length, pattern, angle, and why each can work.
• 文章主旨: one sentence stating the core claim the reader should remember.
• 读者对象: who the article is for, and who it is not for when relevant.
• 内容口径: selection standards, boundary conditions, merge/dedupe rules, exclusion rules, and evidence requirements.
• 文章大纲: proposed H1/H2 structure and what each section solves.
• 标题承诺如何兑现: how the outline visibly pays off the title promise.
• 待确认问题: 1-3 questions that would materially change the article if answered differently.

If the user explicitly asks for a direct draft in the current turn, the confirmation may be waived only by recording the exact instruction and the reason in content_task_record.gate_checklist.title_outline_direction_confirmation. Otherwise, WeChat long-form drafts should not proceed to drafting_instruction until this direction is confirmed. For non-WeChat, short social posts, or single-stage rewrites, use judgment and avoid unnecessary interruption.

For WeChat publishing tasks, final title and final正文 confirmation is not optional: after writing, run the final title gate from cmm-content-writing/references/title-spec.md, present 3-5 final title candidates grounded in the finished body, recommend one, and present the final body for user confirmation before visual generation, final typesetting, or any draft-box action. The user's initial request to "write and publish to draft box" records target intent only; it does not count as approving the unseen title/body. 14. Pre-draft instruction package. After a working title, outline, writing decision, and personal style brief exist, assemble drafting_instruction in content_plan and pass it to cmm-content-writing as the primary generation input. This is not another after-the-fact quality gate; it is the instruction package the model must follow while writing. It must answer:

• title_promise: what the title explicitly promises the reader.
• body_must_center_on: the visible subject that must carry the article (for example 10 tools, 5 methods, 3 mistakes, one verdict, one tutorial task).
• article_shape: where that subject appears in the outline and whether it is visible at H2/H3/list-item level.
• personal_style_role: a runtime-derived object from the active user profile, including source profile, voice, rhythm, stance, phrase/lexicon preferences, and avoid-list; it shapes angle, judgment, selection, and rhythm without replacing the promised subject.
• pre_draft_style_constraints: the executable profile constraints that must shape the draft before generation, including opening move, first-300- character judgment, article backbone, section intent, paragraph rhythm, first-person stance, required judgment signals, allowed lexicon, banned shapes, and rewrite triggers.
• must_include: what has to appear to satisfy the title and user ask.
• forbidden_drift: what the draft must not turn into.
• length_strategy: how long the draft should be and why.
• source_boundaries: what can be claimed from sources and what must stay cautious or omitted.

Priority order is: drafting_instruction.title_promise > article_shape > personal_style_role > article_type_template > length/layout/visual constraints.

If the title promises a counted list (10 tools, 5 methods, 3 mistakes), the counted objects must be explicit article subjects, not hidden inside a workflow, paragraph, or supporting example. If the instruction package cannot make this visible, revise the title, outline, or personal style brief before drafting. Post-draft checks should be minimal sanity checks against this package, not a separate creative engine. 15. Generate platform drafts from the selected topic card plus source cards, not from a title alone. 16. Generate visual or video packages only after the target platform and content format are known. WeChat body illustration count gate. Before planning WeChat body illustrations, read and apply cmm-visual-production/references/article-illustration-method.md and cmm-visual-production/templates/wechat-body-illustration-template.md. When moving from final title/body confirmation into the visual stage, re-enter the visual gate instead of carrying over writing-stage intuition. Do not recommend, imply, or ask the user to approve a body-image count until body_image_count_gate has been computed and shown. Any recommendation about "how many body images" must state the actual body character count, the table bracket, minimum_required, recommended_count, the planned count, and whether a waiver is required. Never estimate body-image count from taste or memory. Compute the minimum body-image count from the article length table in article-illustration-method.md before planning individual images. The visual plan must include:

body_image_count_gate:
  article_chars:
  article_type:
  minimum_required:
  recommended_count:
  planned_count:
  count_status: pass | waiver_required | failed
  rationale:
  replacement_breakpoints:
    - section:
      replaces_image_job:
      replacement_type:
      reason:

If planned_count is lower than minimum_required, the task must include a body_image_count_waiver in visual-package.yaml or visual-waiver.yaml:

body_image_count_waiver:
  required_count:
  planned_count:
  missing_count:
  waiver_reason:
  replacement_breakpoints:
    - section:
      replaces_image_job:
      replacement_type:
      reason:
  reader_impact_assessment:
  user_confirmation_required: true
  user_confirmed: false

This waiver cannot be self-approved by the agent. Without user_confirmed: true, do not generate images, run final typesetting, or create a WeChat draft-box item. Generic reasons such as "avoid over-illustration", "H2 is enough", or "I think one image is enough" are not valid. Each planned body image must declare a real visual job (explain, compare, summarize, or break up dense text). No visual job, no image. 17. Visual style source gate. Before writing cover or body-image prompts, resolve the selected visual style through the CMM registry and read the exact cover / illustration YAML source. One-line summaries, memory, previous tasks, profile comments, or style names are not sufficient. Record the resolved style id and source file paths in visual_package or content_task_record. 18. Image text lock gate. Before generating any image with model-rendered text, present a per-image text lock table and wait for user confirmation. For WeChat tasks, include:

image_text_lock:
  article_title:
  body_final_status:
  cover_text:
    title:
    subtitle:
  body_images:
    - id:
      title:
      module_labels:
      summary_line:
      text_policy:

The text lock is stricter than a general "looks good" approval: if any text that will be baked into an image changes, regenerate that image instead of patching the bitmap. For WeChat covers, readable baked-in title text is mandatory. Do not use no baked text, title handled by metadata, 无字底图, 无文图, or any equivalent no-text cover policy. Image content and text must be generated by the approved image-generation backend. Do not create or repair content/text with local drawing, deterministic renderers, overlays, screenshot edits, or manual bitmap painting. If the image model cannot reliably render the locked Chinese title, regenerate through the image model with a corrected prompt/provider; do not patch the title locally. Platform-size normalization is allowed as a separate technical step: local resize/crop/pad may be used only to meet the target platform ratio/size, must not add or alter text, objects, visual meaning, or composition beyond the declared safe crop/pad, and must be recorded in visual_package.post_render_report. 生图硬门：生成任何带文字的图（封面/卡片/信息图）前，必须先与用户确认并锁定 「文案三件套」(标题/正文/图上要印的逐字文案)，确认通过才生图，禁止「写文案+生图」同步先斩后奏。 正本见 cmm-image-creator/SKILL.md →「生图前置确认门」。 19. Typesetting preflight. Before WeChat typesetting, verify that the visual assets expected by the article are ready and ordered. Record:

typesetting_preflight:
  layout_style:
  cover_present:
  body_images_expected:
  body_images_ready:
  image_order_checked:
  captions_policy:

Do not start final publish-ready rendering when required cover/body images are missing, unordered, or not aligned with the approved visual plan. 20. Publishing goes to draft by default. If the user explicitly asks for "draft", "草稿", "草稿箱", or equivalent in the current turn, treat that as target intent, not execution approval for an unseen artifact. For WeChat long-form tasks, first produce the local preview (publish.html + cover), ask the user to confirm title/body/cover/image layout, then ask separately whether to create the WeChat draft-box item. Still require separate same-turn confirmation for final public publish. 21. Keep all claims traceable to source cards. If a source is only a search-result URL, inspect the real page before citing it. 22. Platform line isolation. Each platform is its own production line; do not borrow another platform's content, format, or view rules. In particular, a WeChat (公众号) article must not reference Xiaohongshu rules, card templates (xhs-quick-knowledge / xhs-checklist / xhs-quote-poster), 3:4 card canvases, or carousel logic — WeChat = long-form HTML + 2.35:1 cover + 16:9 body images. See references/styles/selection-rules.md rule 8. 23. Image model + WeChat image ratio defaults. Image gen is tiered: host- native image tool first (e.g. Codex's built-in) when available. The bundled third-party script rotation (nano-banana → gpt-image2 → others) is a fallback only after host-native is unavailable, explicitly overridden, or fails a required quality gate. Record the provider and any fallback reason in visual_package. See cmm-image-creator/references/provider-policy.md. All WeChat in-article images are 16:9; only the cover (头图) uses 2.35:1.

Handoff Contracts

Use these artifacts between stages:

• source_card: one searched, subscribed, or user-provided source.
• content_brief: one upstream business/content direction brief, such as CMM route[].brief, with topic seed, audience, claim, evidence, target platforms, and avoid-list.
• style_selection: cross-cutting style choice for a task — one writing, visual, and layout template id from the style system plus the user profile reference; selected during planning and consumed by writing, visual, video, and publishing stages.
• topic_card: one selected creator-ready topic.
• content_plan: platform, format, angle, outline, evidence, risks, recorded style_selection, and the writing decision gate (user_real_need, reader_takeaway, article_type, target_length, one_sentence_spine, include/exclude boundaries).
• content_package: drafted text/script/thread/post variants.
• visual_package: cover, illustration, card set, image prompts, layout notes, body_image_count_gate, optional body_image_count_waiver, resolved style source paths, and image_text_lock when generated images contain text.
• video_package: short-video script, storyboard, caption plan, assets, and render notes.
• publish_package: platform target, draft content, assets, metadata, status, approval gate, and typesetting_preflight for WeChat long-form outputs.
• content_task_record: task id, artifact paths, decisions, backend checks, errors, and recovery notes.

Read references/pipeline-contracts.md when a task needs exact fields. Read references/content-task-record-contract.md when a task spans more than one content stage. Read references/styles/style-system.md before any writing, visual, or video stage. The style system has three layers: framework and template library ship with the skill; the user profile lives outside it at ~/.cmm/profile/ and never enters a release package. Record the chosen style_selection in the content_plan and the content_task_record.

Default Operating Mode

For an ordinary "make content from a topic" request:

1. Build or accept a topic_card.
2. Research step — mandatory gate, see references/research-policy.md. Any user input or user-provided material that enters content production must run through research before diagnosis. Do not decide this by topic type, material format, user wording length, subjective/objective framing, or whether the material appears complete; those only change what to research, never whether the research gate exists. Research must cover factual checks, semantic boundaries, and source/material normalization as applicable: facts, data, dates, sources, public usage, definitions, adjacent concepts, Chinese/English expressions, potential confusion, disputes, boundary wording, and unsupported claims in user materials. Tool tiering: ① host-native web search/fetch if this session has one (zero-config, preferred) → ② else cmm-web-search (bundled, needs keys) → ③ else: normalize user-provided material and explicitly mark unresolved verification/boundary gaps; if no material exists, tell the user search is unavailable and encourage them to share material (better result) while making clear they can continue without it — proceed on their choice, writing conservatively. Either way normalize findings to source_card[]; never fabricate specifics, never silently skip.
3. Run cmm-content-planning diagnosis to choose format and platform.
4. Resolve style before drafting. Resolve the active user profile from the current request or local ~/.cmm/profile/ configuration. On this machine, ~/.cmm/profile/neo.yaml is the local default when present unless the user asks for another style; in shared use, each user should provide their own profile or fall back to the persona-neutral default. Record the resolved style_selection in content_plan and style_checks in content_task_record. Do not draft if no writing style has been selected.
5. WeChat account-template gate. When the target platform is WeChat, resolve the account template before drafting. If the selected user profile declares account_templates.wechat, expand and read that private template. If it does not, use the bundled persona-neutral fallback references/templates/wechat-default-template.md. The account template is the primary visible article shape, not a loose reference and not another optional style hint. Add wechat_context_gate to content_plan, content_package, and content_task_record.style_checks with platform_rules_loaded, user_profile_loaded, account_template_path, account_template_loaded, article_type_template_loaded, calibration_style_checked, and passed. If the resolved template is not loaded, stop before writing. The later voice_contract must cite the account template as one source file and must reflect its opening, structure, paragraph, practicality, personal-judgment, and closing rules. Other quality gates may validate the draft silently, but they must not add extra visible modules, tables, prompt blocks, checklist blocks, or "framework-looking" sections unless the account template or the user explicitly asks for them.
6. Generate personal_style_brief before drafting and record it in content_plan, content_package, and content_task_record.style_checks. It must make the selected user's profile operational for this exact article: the opening strategy, core judgment, practitioner perspective, article backbone, selection logic, paragraph rhythm, must-sound-like signals, and forbidden shapes. For AI tools, product updates, workflow articles, tutorials, and practical tech explainers, practitioner_perspective must state a realistic use scene, what the author would or would not do, likely misuse, and evidence boundary. Do not fake hands-on use. For any active user profile, extract these constraints from that profile instead of hardcoding a creator's voice in the shared skill. On this machine Neo is only the local default profile, not the package default. A list title does not automatically mean equal-weight listicle structure, but the listed objects must remain explicit article subjects. If the brief cannot state the author's core judgment or it changes the title's promise into another article, stop and refine the plan before writing.
7. Run the writing decision gate before drafting. Decide and record user_real_need, reader_takeaway, article_type, density_level, target_length, one_sentence_spine, must_include, must_exclude, and scope_boundary. For clear short-opinion/news-judgment topics, proceed on recorded assumptions. For ambiguous lists, tutorials, evidence standards, audiences, or category boundaries, present the concise WeChat planning brief and ask only the questions that materially change the article.
8. Load and pass the WeChat title direction gate, then present the pre-draft title-outline direction confirmation before drafting_instruction for WeChat long-form articles. Record the result in content_task_record.gate_checklist.title_direction_gate and content_task_record.gate_checklist.title_outline_direction_confirmation; if the user changes the title direction, angle, or outline, update content_plan before drafting.
9. Assemble drafting_instruction before writing and pass it to cmm-content-writing. It must combine the selected title's promise, the article shape, the runtime-derived personal style role, pre_draft_style_constraints, must-include items, forbidden drift, length strategy, and source boundaries. For counted-list titles, the counted objects must be visible in the planned article shape. If the instruction package cannot make the article's subject explicit, revise the title, outline, or personal style brief before routing to writing.
10. Route writing to cmm-content-writing.
11. Verify the returned content_package.personal_style_brief stayed aligned with the plan and actually shaped the article. If the draft's structure is driven by a generic template while the personal brief is only decorative, stop and rewrite.
12. Verify the returned content_package.writing_decision stayed aligned with the plan: the draft density level and length match the chosen type, the one-sentence spine is fulfilled, and excluded adjacent topics were not expanded.
13. Run a light post-draft sanity check against drafting_instruction. If the title promised visible objects or steps and the draft hides them inside a different framework, treat it as title/body mismatch and rewrite before any downstream stage. Do not add new creative constraints at this stage; repair by returning to the pre-draft instruction package.
14. Verify the returned content_package.wechat_context_gate, voice_contract, and voice_match_evidence. Record voice_match_passed in content_task_record.style_checks. If wechat_context_gate.passed is false, evidence is missing, or voice_match_evidence.passed is false, stop and rewrite before any visual, typesetting, draft, or publish step.
15. Run the final WeChat title gate against the finished正文, present 3-5 final title candidates plus the final body for confirmation when the target is a WeChat article. Record the result in content_task_record.gate_checklist.final_title_gate and content_task_record.gate_checklist.title_body_confirmation.
16. Route images/cards to cmm-visual-production; if the output form is already fixed (single image, known-size cover, reusing a finished card), call cmm-image-creator directly (see references/skill-routing.md → Minimal-Path). Even on Minimal-Path, a factory task must still produce a reviewable visual_package or visual_waiver. For WeChat covers, enforce the mandatory cover-text rule and image text lock before generation.
17. Route video work to cmm-video-production when format/engine is still to be decided; for a fixed-format vertical video, call cmm-remotion-video directly (see Minimal-Path).
18. Run typesetting and stop at the preview gate. Show the local publish.html and cover path, then wait for user confirmation of title/body/cover/body-image layout before any platform backend call.
19. Create a publish_package through cmm-publishing. Default to draft / fill-only and let the user click the final publish button themselves. Before invoking any WeChat draft-box backend, run scripts/validate_task_gates.py <task_dir> --mode before-draft; if it fails, repair the task instead of replacing the flow manually.

For a CMM-routed acquisition module:

1. Accept blueprint.yaml route[].brief as a content_brief; do not re-run business diagnosis or ask for facts already present in the brief.
2. Translate the brief into a minimal topic_card and content_plan.
3. Continue with the normal content factory stages from planning onward.

For a daily content factory task:

1. Accept or collect subscribed source cards through a Content Factory adapter.
2. Run cmm-content-planning for topic selection across target platforms.
3. Present a short topic board to the user.
4. After topic approval, continue with diagnosis, writing, visual packaging, and draft publishing.

For an active-research content task:

1. Run cmm-web-search with focused queries.
2. Convert useful results into source_card records.
3. Build a minimal topic_card.
4. Continue with diagnosis and production.

Multi-Platform Fan-out (一文多发)

When one source goes to several platforms (e.g. WeChat + Xiaohongshu + X + Douyin), handle it as one fan-out task, not N independent tasks, so assets are made once and reused — not rebuilt per platform.

1. One task root, shared asset pool. Keep a single task directory for the source with a shared assets/base/ pool. Per-platform outputs live in sibling subfolders (wechat/, xhs/, x/, douyin/) but draw from the same base pool.
2. Generate once, normalize only for platform fit. Produce a shared visual direction and locked text once. If an approved generated image needs a platform ratio/size adapter, local resize/crop/pad is allowed as a technical compliance step, but it must not add text, remove meaning, paint new content, or change the semantic composition. Record the adapter input/output, crop/pad mode, target size, and review status. Any content change requires a new image-generation job through cmm-image-creator.
3. Re-voice / re-cut per platform, reuse the rest. Copy/threads/voiceover are platform-specific (route through cmm-content-writing); the visual base and the core claim are shared.
4. Track it in one content-task-record.yaml fanout block (see references/content-task-record-contract.md): list each platform, its adaptation, the reused base assets, and per-platform status (planned / written / visual / draft / published). This is what makes "一文多发" auditable instead of N disconnected folders.

Publishing each platform still follows the fill-only gate — the user clicks the final publish on each.

Stop Conditions

Stop and ask for user confirmation before:

• Publishing or sending to an external platform.
• Creating a platform draft. A current-turn request for "草稿箱" sets the target action, but the user must still confirm after seeing the final preview.
• Using paid APIs when keys or cost limits are unclear.
• Running long backfills or broad collection jobs.
• Deleting, replacing, or merging existing skills.