The PKM loop'swriting stage (write): turn the viewpoints produced by distill into a publishable article draft.
Client-readable description
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 be handed off to publish. You can specify a WeChat Official Account/Zhihu/essay style
| What the client wants | What the skill will do | What the client can see |
|---|---|---|
| Complete the work covered by this skill | Read the user request, necessary context, and this skill's main workflow, and execute the minimal reliable steps | The client 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 client confirmation |
| Execution completed | Summarize successes, skips, failures, file changes, and verification results | A completion receipt that can be copied into a ticket/log |
How the client 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 client confirmation first.
- After execution, verify the real output; do not substitute "looks successful" for evidence.
- The final reply must give the client 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-article-draft -y
Configuration conventions:
~/.config/soia-skills/soia-open-skills/soia-pkm/soia-pkm-compose-article-draft/config.yml
SOIA_PKM_COMPOSE_ARTICLE_DRAFT_CONFIG_FILE=<custom-config-path>
- If this skill does not need private configuration, you may skip creating
config.yml。 - If an API key, cookie, session, provider home, or local path is needed, it can only be placed in a 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 the "dependencies / prerequisites / resources / boundaries" description following this
SKILL.md; if it is not clearly written, add the description first or ask the client, 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 client 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 arguments, organizing them into a coherent article.Do not invent viewpoints out of thin air, and do not add judgments you have not expressed。
- If material is missing, ask; do not make it up.
Workflow
- Collect materials：
- Single piece → an article's
## 我的看法+## 原文summary - Topic → the output of distill mode B's
50_草稿/…观点综述.md, or the "My take" on multiple pieces under a MOC
- Single piece → an article's
- Confirm angle and style: first read the reader and tone positioning for the corresponding platform in
00_Obsidian系统/个人说明书.md, and set the tone accordingly; only confirm this piece's differences (specific angle, title direction) with the user, no longer asking from scratch "who am I / who is the reader / what style". Only fall back to asking the user when the personal manual lacks this file or the platform definition. - 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
[[]]double 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 paragraph to change; once satisfied, choose the
publish-*family according to the target platform".
Title process
After finishing the first draft (after step 4 of the process, before saving the draft), pick at least 3 candidate titlescovering 2 different formulas from the table below and give them to the user to choose; do not decide for the user:
| Hook formula | Wording | Example |
|---|---|---|
| Number rundown | Quantify the scope with numbers | Build a sustainable reading system in three steps |
| Counterintuitive | Challenge the reader's default assumptions | You think the more you read the better? Actually the opposite |
| Question | Directly pose a question the reader cares about | Why do you read many books but can't remember them? |
| Contrast/conflict | Set up 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 | When you scroll your phone late at night, what are you avoiding |
| Authority backing | Cite credible sources/data as support | Harvard research finds: fragmented reading is stealing your focus |
| Suspense/gap | Leave an information gap to lure clicks | I deleted 90% of my reading notes, keeping only this one |
De-AI 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 buzzwords (excellence, disruptive), fake aphorisms (sound punchy but add no information), overuse of dashes, bullet stacking (things that could be natural paragraphs but are forcibly split into lists), and sentences that are smooth individually but have no information progression between paragraphs (every sentence reads well, but together there is no main thread).
Do in most casesLight revision: only address the specific issues hit by the list, do not rewrite the whole text. If the original draft clearly does not look like a finished piece (like a material-organizing draft, outline draft, or first AI draft), escalate toDeep revisionand explain the reason to the user; the deep revision output is written to a new file and does not overwrite the first draft.
Boundaries
- Only place in
50_草稿/, do not touch the original excerpted text. - Viewpoints must come from the user (distill output or direct dictation); the 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.
Receipt after completion
After executionmustoutput to the user (do not quietly finish and say nothing):
- 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).