Editorial Chief Workflow

SKILL.md

---
name: editorial-chief-workflow
description: Coordinate multi-agent editorial and publishing work as a chief editor using a dynamic strategy-loading workflow. Use when planning topics, decomposing content-production tasks, assigning writing/design/review/layout work, enforcing business-goal alignment, and delivering final review-ready files into the real Obsidian publication directory. This skill requires two execution parameters: target audience and publication channel. If either is missing, ask before proceeding. Then load the matching audience profile and channel strategy from references before assigning agents or accepting results.
---

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