PKM closed loop'swriting stage (write): turn the distill produced viewpoints into a publishable article draft.
Customer-readable explanation
What this skill can do
Write the viewpoints distilled by distill into a finished draft. Use the user's viewpoints as the skeleton and vault excerpts as the material to generate an article that can then be handed off to publish. You can specify a WeChat Official Account/Zhihu/essay style
| What the customer wants | What the skill will do | What the customer can see |
|---|---|---|
| Complete the work covered by this skill | Read the user request, necessary context, and this skill's main workflow, and execute the minimum reliable steps | The customer will see Obsidian/vault file changes, terminal logs, generated artifact paths, and the final receipt. |
| Missing dependencies, permissions, configuration, or keys | Stop actions that require external state, and clearly state what is missing | Install commands, application addresses, configuration paths, or questions that require customer confirmation |
| Execution complete | Summarize successes, skips, failures, file changes, and verification results | A completion receipt that can be copied into a ticket/log |
How the customer uses it
- Describe the goal in natural language and provide the necessary inputs: files, URLs, repos, workspaces, proposals, vaults, or platform account status.
- The Agent first determines whether this skill is triggered, then checks dependencies, configuration, permissions, and risky actions.
- For actions that can be dry-run or previewed, provide a preview first; for actions involving deletion, overwriting, sending, publishing, or writing remote state, ask for customer confirmation first.
- After execution, verify the real output; do not substitute "looks successful" for evidence.
- The final reply must give the customer a visible summary: what was done, log summary, file changes, issues, and next steps.
Dependencies and installation
Install this skill (single skill):
npx skills add soia-team/soia-open-skills -g -a '*' -s soia-pkm-compose -y
Configuration conventions:
~/.config/soia-skills/soia-open-skills/soia-pkm/soia-pkm-compose/config.yml
SOIA_PKM_COMPOSE_CONFIG_FILE=<custom-config-path>
- If this skill does not need private configuration, you can skip creating
config.yml。 - If an API key, cookie, session, provider home, or local path is needed, it can only go into private
config.yml, the process environment, or the provider's own login state; it must not be written into the repository, vault body, or logs. - Strong dependencies, optional dependencies, and third-party skill relationships must be based on this
SKILL.mdand the subsequent "dependencies / prerequisites / resources / boundaries" description; if it is not clearly written, add the description first or ask the customer, and do not guess. - Third-party skills may only declare dependencies and installation methods; do not directly modify third-party skill files.
Logs and completion receipt
Every execution must let the customer see the process and results. Minimum receipt format:
完成：<一句话说明本次完成了什么>。
日志摘要：
- started: <检查到的输入/配置/依赖，不打印秘密值>
- processed: <数量或范围>
- created/updated: <数量或路径>
- skipped/failed: <数量和原因>
文件变化：
- <绝对路径或“未改动文件”>
验证：
- <运行过的检查、命令或人工核对点>
问题与下一步：
- <缺 key / 缺依赖 / 需要客户确认 / 建议下一条命令；没有则写“无”>
Core principles
- The viewpoints are yours, the article is yours. compose uses the viewpoints you distilled as the skeleton and the excerpts/articles in the vault as evidence, organizing them into a coherent article.Do not invent viewpoints out of thin air or add judgments you have not expressed。
- If material is missing, ask; do not make it up.
Workflow
- Gather material：
- Single article → a certain article's
## 我的看法+## 原文summary - Topic → output produced by distill mode B's
50_草稿/…观点综述.md, or the "My Take" on multiple articles under a certain MOC
- Single article → a certain article's
- Confirm angle and style: First read
00_Obsidian系统/个人说明书.mdfor the reader and tone positioning of the corresponding platform, and set the tone accordingly; only confirm with the user the differences specific to this piece (specific angle, title direction), and no longer ask from scratch "who am I / who is the reader / what style". Only when the personal manual does not have this file or lacks the definition for that platform, fall back to asking the user. - Build structure: opening (hook/question) → body (your viewpoint + arguments) → ending (elevation/action).First give an outline for the user to confirm, then start writing.
- Write the draft: Write according to the outline, with your viewpoint as the main thread and excerpts/articles as supporting evidence (use
[[]]bidirectional links to note the source). - Save the draft：
<vault-drafts-dir>/YYYY-MM-DD-<标题>.md，frontmattertags:[草稿]、status:草稿、source_notes:[[…]](source notes). - Receipt: Inform the draft path, word count, and structure, and prompt "tell me which section you want changed; if satisfied, say
发布这篇hand it over to publish".
Title process
After finishing the first draft (after step 4 of the process and before saving the draft), select according to the table below at least 3 candidate titlescovering 2 different formulas and give them to the user to choose from; do not decide on the user's behalf:
| Hook formula | Phrasing | Example |
|---|---|---|
| Number roundup | Use numbers to quantify the scope covered | Three steps to build a sustainable reading system |
| Counterintuitive | Challenge the reader's default assumptions | You think the more books you read the better? Actually it's the opposite |
| Question | Directly pose a question the reader cares about | Why do you read many books but remember nothing? |
| Contrast and conflict | Present the tension between two approaches/viewpoints | Others hoard books, I hoard viewpoints |
| Result promise | Directly state what the reader will get after reading | After reading this, you can build your own reading system |
| Scenario immersion | Bring the reader into a specific scenario | Late at night while scrolling your phone, what are you avoiding |
| Authoritative backing | Cite credible sources/data as support | Harvard research found: fragmented reading is stealing your focus |
| Suspense and omission | Leave an information gap to entice clicks | I deleted 90% of my reading notes and kept only this one |
De-AI-ify self-check
Before submitting, self-check against this list of high-frequency issues, and lightly revise anything found: formulaic openings (in this era, with the development of...), empty big words (excellence, disruptive), fake punchlines (sound fierce but add no information), overuse of dashes, bullet stacking (content that could be written as natural paragraphs but is forcibly split into lists), and individually smooth sentences with no information progression between paragraphs (every sentence reads smoothly, but together there is no main thread).
In most cases, dolight revision: only address the specific issues hit by the list, without rewriting the full text. If the original draft clearly does not look like a finished piece (like a material-compilation draft, outline draft, or initial AI draft), escalate toDeep revisionand explain the reason to the user; deep revision output is written to a new file and does not overwrite the first draft.
Boundaries
- Only produce
50_草稿/, do not touch the excerpted original text. - Viewpoints must come from the user (distill output or direct dictation); AI does not fabricate positions.
- When citing vault content, use a double link
[[]]to indicate it.
Closed-loop position
clip(收) → organize(整理) → distill(点) → ★compose(写) → publish(发)
Upstream distill provides viewpoints; downstream publish adapts the finished text for multi-platform publishing.
Completion receipt
After execution,mustoutput to the user (do not finish silently):
- What was done — summarize the completed work in one sentence.
- File changes — list newly created / modified / moved files (full paths); if no files were changed, state "no files changed".
- Next steps — optional follow-up suggestions (such as the next skill to connect to).