Cmm Content Factory

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.

1. Normalize every input into a source or material card before topic selection.
2. 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.

1. Select topics before writing. If the user already has a chosen topic, still build a minimal topic card.
2. Run CMM content diagnosis before generating final drafts unless the user explicitly asks for direct drafting.
3. 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.

1. 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.

1. 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.

1. 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.

1. 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.

1. 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.

1. 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.

1. 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 `contenttaskrecord.gatechecklist.titleoutl

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: chemny
• Source: chemny/cmm-content-factory
• License: MIT

Install and usage instructions live in the source repository linked above.