my-note-publish

Original：🇨🇳 Chinese

Translated

3 scripts

Publish notes from a local content file to a blog that supports /api/content/notes, generate untitled Markdown, reuse the publication ID, and verify the upload by reading it back. Use this to publish notes or short posts, or save note drafts; use my-blog-build for long-form posts and site builds.

1installs

Sourcekingstar718/my-skills

Added on2026-10-22

NPX Install

npx skill4agent add kingstar718/my-skills my-note-publish

SKILL.md Content (Chinese)

View Translation Comparison →

Publishing Notes Locally

Requires Python 3.10+ with no third-party dependencies. Content is written to R2 through the blog content API, and saving it triggers a static-site rebuild on the server.

Configuration

Read

BLOG_BASE_URL

and

BLOG_ADMIN_PASSWORD

first, and fill in any missing values from the local configuration. When the first publish attempt returns

missing_config

, guide the user to enter the blog domain and site

ADMIN_PASSWORD

:

Windows: Explain that a local configuration window is about to open, and run
```
scripts/publish_note.py setup --gui
```
. The window allows both the domain and password to be entered, with the password masked. If the tool returns a running session, continue waiting for the user's actions; after the user saves, reuse the original publication record and continue publishing. If the user cancels, retain the content and record, do not publish, and do not repeatedly open the window.
Other systems: Ask the user to run
```
scripts/publish_note.py setup
```
in their own interactive terminal, where the domain is visible and the password is hidden. An Agent's non-interactive tools cannot enter the password on the user's behalf; continue publishing only after configuration is complete.

Never require the user to submit a password in chat, output a password, or place a password in command arguments, content, publication records, or the repository. The local configuration is reused across sessions; Windows uses DPAPI encryption for the current user, while other systems use a local file with permissions of 0600. Do not open the configuration window when the user only wants to write or preview content. See references/usage.md for the configuration location, reconfiguration, and environment-variable overrides.

Publishing Process

Determine whether the user wants to publish, save a draft, or only write the content. Execute immediately when the user has explicitly requested publishing; stop at the preparation stage when the user has only requested writing.
Preserve the original content when the user provides the complete body. When generating or polishing Chinese content, read the
```
cn-writing
```
skill from the same plugin at cn-writing. Notes do not have titles, so do not add the long-form
```
#ai
```
heading tag.
Write the content to a UTF-8 file and run
```
scripts/publish_note.py prepare --file <content-file> --out <publication-record.json>
```
. The script generates a unique filename, a UTC publication timestamp with an offset, and the complete Markdown. Add
```
--draft
```
for drafts. When the user specifies a time, pass an ISO8601 timestamp with
```
--pub-datetime
```
; it must include
```
Z
```
or an explicit offset.

Before publishing, optionally run

scripts/publish_note.py publish --prepared <publication-record.json> --dry-run

to inspect the content.

To publish, run
```
scripts/publish_note.py publish --prepared <publication-record.json>
```
and read the JSON result. Reuse the same publication record for every retry. The script first performs a GET request to check for a file with the same name: if the content is identical, it skips the PUT request; if it differs, it refuses to overwrite it.
Report only statuses substantiated by the script.
```
saved_verified
```
means the content read back from R2 matches;
```
deployTriggered: true
```
only means that the rebuild request succeeded, and the page usually takes another 1–2 minutes to update. Drafts are not publicly visible.

Do not treat the local content file as the source of truth for R2. Keep the publication record in the user's working directory or a temporary directory, not in the plugin source code. Images in the content should use existing

/media/...

URLs. Use

my-blog-build

to upload images and modify published content.

Failure Handling

```
already_saved
```
: A file with the same name and identical content already exists, and no duplicate write or rebuild was triggered; this run cannot determine whether the previous rebuild succeeded.
```
missing_config
```
: Follow the configuration process to request the missing values, then continue using the original record after configuration is complete.
```
conflict
```
: A file with the same name has different content. Inspect the publication record and remote content; do not overwrite automatically or retry with a new ID.
```
save_uncertain
```
: The PUT outcome is uncertain. Rerun the operation with the original publication record, read the remote content first, and then decide whether to write it.
```
saved_unverified
```
: The save API succeeded, but the read-back failed or did not match. Retain the record and investigate; do not publish again with a new ID.
```
deployTriggered: false
```
: The content was saved, but the rebuild was not successfully triggered. Explain that the server-side Deploy Hook needs to be checked; do not repeatedly issue PUT requests.
Authentication failures, HTTP errors, or timeouts: Describe the failed stage based on the result, do not echo credentials, and do not retry indefinitely.

See references/usage.md for the API scope, command examples, and status descriptions.