Poetize Blog Automation

POETIZE Blog Automation

Use this skill to operate a POETIZE blog as a personal publishing and maintenance system. It is built on the existing POETIZE API feature, not browser automation. It is free-first, growth-first, and maintenance-first. It is not monetization-first.

中文简介

• 这是一个面向 POETIZE 博客的 OpenClaw skill，用来通过 POETIZE 的 /api/api/* 接口进行文章发布、更新、隐藏、分类标签维护、主题切换、数据分析和 SEO 运维。
• 目前仅支持 awesome-poetize-open 开源分支，不适用于原版 POETIZE。
• 专为开源版 awesome-poetize-open 设计。
• 它更适合“个人博客运营”而不是“泛内容生成”，默认坚持免费优先、维护优先、质量优先。

Public Distribution Position

• Treat this as an OpenClaw integration for the open-source awesome-poetize-open release.
• It is designed for the open-source branch of POETIZE.
• Before publishing to ClawHub, remove secrets, local machine paths, and private content from any bundled files.
• When publishing publicly, link back to the source repository and keep the applicable license and attribution notices intact.
• Prefer a project-prefixed public slug such as awesome-poetize-open-blog-automation so the registry entry stays tied to the open-source project.

Compatibility

• Required project version: awesome-poetize-open.
• Expected API surface: the POETIZE admin API routes documented in references/poetize-api.md.
• Do not use this skill with the original POETIZE project.
• For other forks, verify endpoint names and payload shapes before the first write action.

OpenClaw-First Execution Rules

• Use {baseDir} for any file path that points inside this skill folder.
• Prefer single-line shell commands in examples so they remain portable across shells.
• Use python in examples and switch to python3 when that is the installed binary.
• Invoke this skill only for explicit POETIZE tasks. Do not route generic writing or generic SEO requests here.
• Prefer scripts/render_openclaw_config.py to generate OpenClaw config instead of hand-writing JSON.
• Run scripts/openclaw_smoke_test.py before the first real write action on a new OpenClaw environment.
• Point POETIZE_BASE_URL at the public nginx/domain origin.
• Actual request path = ${POETIZE_BASE_URL}/api/api/...; do not append /api inside the variable value itself.

Read references/poetize-api.md before publishing, updating, querying, or operating articles. Read references/openclaw-setup.md when connecting the skill to OpenClaw. Read references/strategy-playbook.md before deciding whether to create, refresh, or hide content. Read references/decision-matrix.md before setting publish posture, search posture, or paywall posture. Read references/creativity-workflow.md before drafting article copy. Read references/evaluation-scenarios.md when validating the strategy layer. Run scripts/run_strategy_evals.py to verify the local strategy layer before shipping skill changes.

Breaking change:

• All mutating commands now require --brief-file.
• OpenClaw should treat assets/article-brief.template.json and assets/ops-brief.template.json as the starting point for strategy briefs.

Operating Position

• Act like a blog editor, content operator, and maintenance assistant.
• Optimize for long-term content quality, search visibility, and low-effort maintenance.
• Default to free, public, searchable content unless the user clearly asks for a draft or private post.
• Treat paid posts as an uncommon edge case for established blogs with clear conversion intent.
• Prefer improving old content, reorganizing taxonomy, and maintaining content quality over pushing paywalls.

Workflow

1. Gather the publishing intent. Decide whether the user wants a draft or a public article. Decide whether the task is new content, old-content maintenance, taxonomy cleanup, SEO follow-up, or article takedown by hiding. Default to free content unless the user explicitly asks for a draft or a paywalled post. Create a strategy brief before any mutating action.

2. Create the strategy brief. Use {baseDir}/assets/article-brief.template.json for article creation or article refresh work. Use {baseDir}/assets/ops-brief.template.json for update or hide operations. Fill primaryGoal, reasoning, and the required brief fields before calling any mutating script. If required brief information is missing, stop and ask for it.

3. Diverge, then converge. Produce 2 or 3 candidate angles first. Choose one final direction and record it as selectedAngle. Record the rejected candidates in alternativesConsidered.

4. Write the article in Markdown. Prefer a single H1 at the top. Keep the body as clean Markdown. Use short lead paragraphs, clear section headings, lists only when they improve readability, and avoid HTML unless required. If the article includes images, save them as local files first and reference them from the Markdown file with relative paths such as ![示意图](./assets/diagram.png). publish_post.py will upload those local article images through /api/resource/upload before publishing and replace them with returned URLs. When the task is maintenance, prefer revising existing articles over creating duplicates.

5. Add front matter for routing and publishing metadata. Use the front matter keys documented in references/poetize-api.md. At minimum provide title, sort or sortId, and label or labelId. Prefer existing sort and label names when IDs are unknown. The script will query /api/categories and /api/tags first and reuse exact matches. If exact matches fail, the script may return close category or tag candidates for confirmation. Close matches are suggestions only and must not be auto-selected. It will not create a new category or tag unless you explicitly allow it. Be explicit about article switches when the user mentions them: commentStatus for comments recommendStatus for recommendation viewStatus for visibility submitToSearchEngine for search-engine push Only set paid fields when the user explicitly wants a paywall and the content clearly deserves it. For most personal blogs, keep payType: 0. When the user does not want to upload a cover, set coverBlank: true or cover: " ".

6. Publish through the bundled publish script. Use {baseDir}/scripts/publish_post.py for create or content update flows driven by Markdown. OpenClaw runtime only needs: POETIZE_BASE_URL POETIZE_API_KEY --brief-file is mandatory. If the markdown body references local images or local <img src="..."> files, the script uploads them automatically before sending the article payload. For paid posts, the script will check /api/payment/plugin/status first, but paid publishing is not the default path for this skill. If the payment plugin is installed but not configured, provide paymentPluginKey in front matter and optionally pass --payment-config-file payment.json.

7. Operate existing articles, themes, analytics, and SEO through the management script. Use {baseDir}/scripts/manage_blog.py. It supports: article listing exact-title lookup article detail article update article hide global article theme switching article analytics site visit trends controlled SEO config sitemap update It does not support article deletion. If the user wants a post effectively removed from public view, hide it by setting viewStatus: false. update-article and hide-article now require --brief-file.

8. Return the final result. Prefer --wait so the script polls until the async task finishes. Report the returned articleId, articleUrl, task status, visibility state, and any follow-up analytics when requested.