soia-pkm-publish-x-thread

soia-pkm-publish-x-thread

Turn the finished draft produced by compose into a thread suitable for X. By default, deliver Markdown text in the reply for the client to manually copy and publish; this skill does not call the X API, does not send automatically, and does not modify the original draft.

Client-readable explanation

What this skill can do

Read the finished draft provided by the client, preserve the core points and necessary evidence, and reorganize it into an X thread with a continuous reading rhythm: the first tweet is responsible for making people keep reading, the middle tweets each complete one logical action, and the last tweet gives a natural CTA.

What the client wants	What the skill will do	What the client can see
Post an article as an X thread	Extract the main line, split the argument, number the tweets, and control the length of each	A set of copyable Markdown tweet entries
The draft contains code, commands, or links	Keep code and URLs as-is, adjusting surrounding text if necessary	Untruncated code/links, plus clear notices where safe splitting is not possible
Need to publish to X	Generate publishing text only	"Produce text, publish manually"; will not call the X API or send any content

How the client uses it

1. State "post as an X thread", "split into a tweet series", or "thread this", and provide the finished draft, file content, or path.
2. If requested, also specify the target audience, tone, whether to keep the title, the CTA direction, and the code/links that need to be preserved.
3. The Agent first confirms the input scope and main line, then outputs the thread; by default it does not overwrite the original draft, and only saves separately when the client specifies a path.
4. The client manually copies each tweet and publishes it to X; publishing order follows the numbering.

Dependencies and installation

Install this skill (single skill):

npx skills add soia-team/soia-open-skills -g -a '*' -s soia-pkm-publish-x-thread -y

• This skill is a pure LLM rewriting process, with no scripts, no private configuration, no API key, and no external service dependencies.
• soia-pkm-compose-article-draft is a common upstream artifact, but it is not a hard installation-level dependency; any finished draft can also be provided directly.
• Currently does not connect to the X API. Any "publishing" only means generating text; manual publishing is done by the client.

Logs and completion receipt

Every execution must report the actual processing scope, the number of entries, and the manual publishing boundary, and must not describe "generated" as "published". Minimum format:

完成：已将 <输入范围> 改写为 <N> 条 X thread 文本，未调用 X API。

日志摘要：
- started: <输入来源、目标口吻与约束>
- processed: <条目数量；长度检查结果>
- created/updated: <回复文本或客户指定的输出位置>
- skipped/failed: <未处理内容及原因；没有则写“无”>

验证：
- <每条 ≤280 字符、编号连续、代码/链接完整性核对结果>

问题与下一步：
- 请人工按 (1/N) 顺序复制发布；<其它问题，没有则写“无”>

Splitting rules

1. First determine the main line

• Write in one sentence the core judgment this article should make readers remember; every tweet in the thread must serve this main line.
• Keep evidence, examples, qualifications, and sources that would change the conclusion; delete repetitive setup, irrelevant side lines, and unverifiable exaggerated statements.
• If the original draft has multiple equally important themes, first ask the client to choose the main line; when low-risk, you may choose the main line that best represents the original draft and explain it in the receipt.

2. Organize continuous reading

• The first tweet should clearly state the topic and the conflict/benefit, using concrete facts, counterintuitive judgments, or questions to create a reason to keep reading; do not merely restate the title.
• Each middle item handles only one action: raising a question, giving a judgment, explaining a reason, showing an example, adding a caveat, or landing on a method.
• Each item should be basically understandable even out of context; use natural transitional words to maintain the sense of a thread advancing, and avoid mechanically chopping the article's paragraphs into pieces.
• The final item wraps up the core judgment and gives a CTA that matches the article's content (e.g., replying with experiences, saving the method, continuing the discussion); do not manufacture false urgency.

3. Length and completeness

• Each item contains (1/N)、(2/N) and other numbering,N use the final total number of items; numbering is continuous with no missing items.
• Each item's body must not exceed 280 characters, verified according to X's actual character-counting method; numbering, spaces, and punctuation also count toward the length budget.
• Do not break items in the middle of a code block, and do not rewrite commands, variable names, JSON, regex, file paths, or URLs; when code or links are too long, split the surrounding explanation or clearly note that the client must handle it manually.
• Do not delete negations, units, qualifiers, sources, or key punctuation just to fit within the length limit; when length and completeness cannot both be satisfied, first report the conflict and request a trade-off.
• Preserve the facts of the original draft; do not add numbers, cases, citations, or conclusions not supported by the input.

Output format

The default output is a Markdown list, with each item as one paragraph:

- (1/N) <首条抓钩子与主题>
- (2/N) <一个完整的论证动作>
- …
- (N/N) <核心收束 + CTA>

Outside the list, you may add a line "Length check: passed / needs manual review" and any necessary trade-off notes. Do not disguise items as published links, and do not output API call results. When the client has not specified a save location, produce only the reply text; when a location is specified, then write to a separate draft file, and never overwrite the source file.