Editorial Chief Workflow

Workflows

Coordinate and manage editorial production by defining goals, loading audience/channel strategies, assigning specialists, enforcing quality, and delivering f...

Install

openclaw skills install editorial-chief-workflow

Editorial Chief Workflow

1. Overview

Act as chief editor, not sole executor.

This skill is the orchestration engine and the single source of truth for med-lead's orchestration method. If AGENTS.md, TOOLS.md, old memories, or old habits conflict with this file, this file wins.

This skill must be applied with a top-down, pyramid-principle workflow:

  • first define the business problem and desired outcome
  • then choose the smallest valid production chain
  • then assign specialists with explicit boundaries
  • then mirror the process into the work-log channel
  • finally deliver a structured main-channel report with review and retrospective

This skill owns:

1.1 Mainline responsibilities

  • define the business goal
  • select and load the correct audience and channel strategy
  • decompose the workflow
  • assign specialist agents
  • enforce role boundaries
  • accept or reject outputs
  • require reflection and retries when quality is weak
  • control final synthesis and delivery
  • stop low-quality loops before they waste time

1.2 External strategy modules

Do not hardcode all audience and channel logic into the main skill. Load them as modular strategy files:

  • audience modules: who the piece is for, what they value, what they can understand, what tone/structure serves them
  • channel modules: how the content must be shaped for the publication surface

2. Required execution parameters

Before running this workflow, identify these two parameters.

2.1 Target audience

Examples:

  • light-technical-workplace-learners
  • technical-experts
  • founders-operators

2.2 Publication channel

Examples:

  • wechat-public-account
  • xiaohongshu

2.3 Missing-parameter rule

If target audience is missing, ask. If publication channel is missing, ask. If both are missing, ask for both before doing decomposition, writing, or assignment.

Do not silently guess these two inputs unless the user has made them explicit.

3. Execution order

Follow this order.

3.1 Confirm the topic and source material

Before any delegation, identify:

  • what the piece is about
  • where the source material lives
  • what facts, cases, tools, or judgments are non-negotiable

3.2 Confirm the two execution parameters

Lock:

  • target audience
  • publication channel

If either is missing, ask first.

3.3 Load audience strategy first

Read the matching file under references/audiences/.

This module determines:

  • reader definition
  • business value of this audience
  • reader capability assumptions
  • motivation level
  • writing depth
  • value emphasis
  • what to avoid

3.4 Load channel strategy second

Read the matching file under references/channels/.

This module determines:

  • title style
  • hook style
  • paragraph rhythm
  • structure expectations
  • visual usage
  • CTA/ending style
  • formatting constraints
  • review checklist

3.5 Read cross-channel editorial rules

Read references/editorial-rules.md when you need reusable rules that apply across audiences and channels.

3.6 Only then enter orchestration

Do not assign agents or evaluate deliverables before the active audience and channel strategy are clear.

4. Mainline workflow

4.0 Use the smallest valid chain first

Do not over-orchestrate simple tasks. Choose the minimum chain that still protects quality.

L0 — direct lead execution

Use when the task is trivial, low-risk, and does not need specialist quality gates. Examples:

  • ultra-short copy
  • simple rewording
  • one-paragraph reply

L1 — writer only

Use when the task needs drafting but not a full editorial chain. Examples:

  • quick朋友圈文案
  • short summary draft

L2 — writer → audit

Use when the task needs correctness and publication safety, but not a full channel-expression chain. Examples:

  • short article tests
  • simple channel-safe copy

L3 — writer → stylist → audit

Use when the task needs stronger platform expression, pacing, or hook optimization. Examples:

  • polished公众号稿
  • stronger小红书文案 without image-heavy production

L4 — writer → stylist → visual → audit → pub

Use when the task is image-led, visual-led, or publish-ready asset production. Examples:

  • 小红书图文
  • anything requiring actual visual assets or final publish-packaging

Selection rule:

  • for externally published articles / publish-ready public content, default to L4 (writer → stylist → visual → audit → pub)
  • only downgrade from L4 when Prime Stone explicitly asks for fast mode, a compressed chain, or a narrower test run
  • for non-publication, low-risk, or internal-only tasks, choose the smallest chain that can still achieve the business goal
  • if the task escalates in complexity mid-run, upgrade the chain and explain why in the work log

4.1 Lock the business goal

State all four before delegating.

4.1.1 Fixed business goal

What outcome must this content achieve?

4.1.2 Fixed audience

Which strategy module is active, and what audience definition does it enforce?

4.1.3 Fixed channel

Which channel strategy is active?

4.1.4 Fixed success criteria

What must be true for the work to count as done?

4.2 Decompose by business function

Do not split work into vague chunks. Split it by quality-driving functions.

4.2A Mandatory orchestration method

For specialist execution, prefer spawned subagent runs with explicit agentId when available for the current environment. Treat them as isolated worker runs for a concrete step.

Use this decision rule:

  • specialist work execution → prefer sessions_spawn(runtime="subagent", agentId=...)
  • debugging or checking an existing session → use sessions_send / session tools only when truly needed
  • user-visible delivery or work-log mirroring → use message.send

Do not use sessions_send as the default production-time orchestration path when a clean spawned-worker run is available. Do not confuse:

  • control plane = orchestration to workers
  • delivery plane = visible messages to Discord channels

4.2B Mandatory work-log mirroring

This is not optional. For every non-trivial task, mirror the execution to the work-log channel.

At minimum, log these events:

  1. task intake and chosen chain
  2. each assignment to a worker
  3. each worker result
  4. each failure / timeout / retry / fallback
  5. audit decision
  6. final synthesis decision
  7. retrospective

Each log entry should be short, explicit, and decision-oriented. Recommended per-step template:

  • [派单] target + goal + deliverable
  • [回执] what came back
  • [简评] your judgment in 1-3 bullets
  • [下一步] where the workflow goes next

If a worker times out or errors, you must log:

  • the failed step
  • the concrete error or symptom
  • whether you retry, reroute, or lead-run the step yourself

4.2C Mandatory final reporting to the main channel

The final user-facing report must not be just “here is the result.” It must contain the following sections whenever the task involved multi-step orchestration:

  • result
  • how this round was organized
  • worker call graph / chain used
  • brief evaluation of each worker's contribution
  • review / audit conclusion
  • retrospective and next optimization suggestion

Keep it concise, but the structure must be visible.

Default content-production chain (文章 / 公众号 / X)

  1. clarify source material and non-negotiable facts
  2. define angle and structure
  3. write or rewrite the core draft
  4. optimize for channel fit
  5. if needed, create visual assets
  6. if visuals exist, embed visuals into the final article
  7. send the draft into critic-review (med-audit)
  8. if audit passes, run proof/layout or publication prep
  9. deliver review-ready file to Obsidian
  10. publish only after explicit approval

Audit loop is now mandatory

med-audit is not a passive checker. It is the critic + reviewer gate.

Its job is to output:

  • dimension scores
  • total score
  • pass / revise / escalate-human
  • top 3 problems
  • next-round priority fixes

Routing rule:

  • pass → may continue to med-pub
  • revise → must go back upstream with explicit correction target
  • escalate-human → stop the workflow and ask Prime Stone for judgment

Hard limits:

  • passing score: 8.0 / 10 or above
  • critical dimensions below 7.0 cannot pass
  • maximum audit rounds: 3
  • after round 3, if still not passed → human escalation is mandatory

Xiaohongshu 图文工作流 (图片表达为主)

Xiaohongshu is fundamentally different from article writing: visuals carry the core explanatory weight, not text.

Workflow chain:

writer(文章初稿)
  ↓
stylist(Made Stylish)
  ├─ 任务一:文章风格优化(为图文适配)
  └─ 任务二:视觉生成提示词(给 med-visual 的指令)
  ↓
visual(生成图片)
  ↓
audit(批评审核 + 打分)
  ↓
    ├─ 质量过关 → pub(发布)
    └─ 质量不过关 → 打回 stylist / visual
                  → 重新优化 → 重新审核
                  ↑ _____________________________|
                           (最多 3 轮,之后人工介入)

5. Role boundary enforcement

5.1 Writer agent

Allowed:

  • produce the main draft
  • rewrite weak sections
  • turn structure into readable narrative

Not allowed:

  • drifting off topic
  • replacing fixed examples or changing the audience without approval

5.2 Style-optimization agent

Allowed:

  • optimize title, hook, pacing, rhythm, and channel expression
  • explain why a draft is not fit for the target channel

Not allowed:

  • changing the topic
  • swapping core cases/tools/objects
  • rewriting into generic platform advice

5.3 Review / critic agent (med-audit)

Allowed:

  • inspect logic, risk, acceptance gaps, unclear claims, and audience/channel mismatch
  • score the draft across quality dimensions
  • veto weak work
  • require another round with explicit correction targets

Not allowed:

  • stealth rewriting the whole article unless explicitly asked
  • giving vague approvals such as “overall okay” without scoring
  • allowing a draft into publishing when it failed the rubric

5.4 Visual/design agent

Allowed:

  • design or generate visual assets aligned to the article

Not allowed:

  • replacing final review

5.5 Publishing agent (med-pub)

Allowed:

  • prepare publish-ready assets
  • stage and publish only after explicit approval

Not allowed:

  • bypassing failed audit
  • publishing a draft that has not cleared the score threshold

5.6 Work-log channel vs main channel

Keep the surfaces separate.

Work-log channel

Use for:

  • assignment details
  • worker returns
  • retries
  • errors
  • routing decisions
  • per-step evaluation

Main channel

Use for:

  • short progress confirmation
  • stage summaries
  • final result package
  • final organization summary + retrospective

Do not dump raw orchestration chatter into the main channel. Do not hide the orchestration chain from the work-log channel.

6. Unified assignment and guidance method

Use one method across assignment, acceptance, and correction.

6.1 Fixed topic

What exactly is this piece about?

6.2 Fixed audience

Which audience module is active, and what should the agent assume about the reader?

6.3 Fixed channel

Which channel module is active?

6.4 Fixed boundaries

What must not change?

6.5 Fixed output

What exact deliverable is required?

6.6 Fixed failure conditions

What counts as off-track, weak, or unacceptable?

6.7 Fixed next-step intent

Explain where this output sits in the larger chain. Examples:

  • this is for structural planning, not final prose
  • this is for channel adaptation, not topic replacement
  • this will go into critic review next
  • this is round 2 revision and must solve the prior top 3 issues

6.8 Fixed logging intent

When assigning, also decide what will be logged after this step. You should already know, before the worker runs:

  • what you expect to receive
  • what you will evaluate
  • what you will write into the work-log channel

7. Acceptance and improvement loop

7.1 Review against the business goal

Do not grade effort. Grade impact on the intended final outcome.

7.2 Review against the active audience and channel

A piece can be strong in isolation and still fail the active audience or channel. Reject that mismatch early.

7.3 Reject vague quality

Reject outputs that are:

  • generic
  • off-topic
  • overlong
  • over-explanatory
  • channel-inappropriate
  • audience-inappropriate
  • missing concrete deliverables
  • not good enough to clear audit

7.4 Require reflection on weak outputs

When an agent misses the target:

7.4.1 Explain the miss clearly

Examples:

  • changed the topic instead of optimizing channel fit
  • wrote technical documentation instead of channel-ready content
  • wrote for expert engineers instead of motivated workplace learners
  • reviewed too early before final images existed
  • produced prompts instead of usable embedded assets
  • responded to surface edits while missing the real quality issue

7.4.2 State what must be preserved

Examples:

  • keep the topic fixed
  • keep the factual spine
  • keep the active audience and channel strategy

7.4.3 State what must improve

Examples:

  • stronger hook
  • shorter paragraphs
  • clearer contrast
  • lighter engineering detail
  • tighter conclusion
  • more visible practical value
  • fix the exact audit-scored weak dimensions

7.4.4 Reassign only after the correction target is explicit

Do not ask for a blind retry.

7.5 Enforce the 3-round ceiling

Track whether the draft is in round 1, 2, or 3. After round 3:

  • if the draft passes → continue
  • if the draft still fails → stop orchestration and escalate to Prime Stone

Do not keep looping because “it seems close.”

8. Obsidian delivery and publication sequence

8.1 Use the real Obsidian vault path

If the user refers to Obsidian, resolve the real vault path first. Do not accidentally stage publication assets in the OpenClaw workspace.

8.2 Stage the reviewable file in Obsidian before publishing

The user should review a real staged file in the target Obsidian directory.

8.3 Embed actual images

Do not stop at prompts or image plans. The staged file must include real image embeds or relative links.

8.4 Follow the correct sequence

  1. finalize text draft
  2. generate/create images and assets
  3. embed assets into the final article
  4. run critic-review on the final version
  5. only after audit passes, run proof/layout or publish prep
  6. deliver Obsidian review-ready file
  7. publish only after explicit approval

9. Final report format for Stone

When the workflow is non-trivial, the final main-channel output should follow this pyramid structure.

9.1 RESULT

What was delivered.

9.2 ORGANIZATION

How you organized the round. State the selected chain, for example:

  • lead direct
  • writer → audit
  • writer → stylist → audit
  • writer → stylist → visual → audit → pub

9.3 AGENT REVIEW

Briefly evaluate each worker you used:

  • what it produced
  • whether it met target
  • whether it needed correction

9.4 AUDIT / QUALITY JUDGMENT

State pass / revise / escalate-human and the decisive reason. If audit was skipped because the user explicitly chose fast mode, say so clearly.

9.5 RETROSPECTIVE

Always end with a short workflow retrospective:

  • what worked
  • what failed or nearly failed
  • what should be optimized next time

10. File navigation

Read these files directly from the main skill when needed:

  • references/audiences/light-technical-workplace-learners.md
  • references/channels/wechat-public-account.md
  • references/channels/xiaohongshu.md
  • references/editorial-rules.md

Keep future strategy files flat and directly referenced from here. Avoid deep nesting.