SuperAPI AI Directory
Partner中文AI newsFavorites
Skillszhihu-sync

zhihu-sync

Marketing & growth

View repository

Updated 10-23 08:36

About this skill

zhihu-sync / Zhihu Sync Assistant

知乎同步助手, the master orchestration entry point for format adaptation, preview, and confirmed publishing of existing content into Zhihu. Specific conversion, preview, and publishing rules are handled by sub-skills; this file only specifies the execution order, stage boundaries, and key artifact paths.

Introduction

When the user asks what zhihu-sync, the Zhihu Sync Assistant (formerly zhihu-publisher) is, how to use it, first-time use, core goals and service scenarios, authorization policy, credential configuration methods, the meaning of publish source markers, its relationship with AI creation, or the format restrictions of each content form:

  • First read README.md, and based on its content introduce to the user this skill's capabilities, installation method, authorization instructions, usage, publishing pipeline, and local artifacts, and explain targeted authorization, subsequent source markers, and their difference from AI-assisted creation declarations according to the question.
  • Pure introductions or policy Q&A only provide explanations and authorization guidance, then stop; do not initialize or write credentials, do not install upload dependencies, do not generate draft, validate, preview, or publish, do not open previews, and do not upload or publish.
  • The session-first old-version uninstall reminder, new-version check, and version notices are still executed according to "Session-first check" below; credential configuration, dependency installation, or whether to update are not prerequisites for answering an introduction, and asking for an introduction does not mean confirming an update or publishing.
  • When the user explicitly requests configuration, saving credentials, or directly provides credentials, still read reference/auth-info.md and handle it according to its initialization process, and do not treat an actual configuration request as a pure policy Q&A.

Session-first check

When this skill is first loaded in each session, execute the following two read-only checks in order: the old-version uninstall check targets the old name zhihu-publisher, and the new-version update check targets the current version number of zhihu-sync . Record the status of each check separately; each is automatically checked once per session; pure introductions, version queries, and requests without material are also executed. Video requests that require upload or publishing along with content still stop according to the workflow rules and do not access the version interface.

Old-version uninstall

Check whether the old-name skill can still be loaded by the current Agent, and remind the user to uninstall if coexistence is found. Do not repeat the reminder within the same session, except when the user explicitly requests a re-check.

  • First check the list of available skills provided by the current Agent, and look up name exactly by the skill's zhihu-publisher。
  • When the list is not provided or cannot be confirmed as complete, only check global and current-project installations (including shared directories and symbolic links) in the skill loading directories actually used by the current Agent, read the frontmatter of the candidate SKILL.md , and confirm whether name is zhihu-publisher. Prefer installation paths or configurations provided by the host; do not scan the entire disk, and do not judge solely by folder name.
  • The appearance of zhihu-publisherin repository addresses, authorization URLs, log prefixes, or development repository directories does not mean the old skill is installed; files ofname: zhihu-sync are not considered the old skill even if placed in a directory with the old name.
  • When the old skill is found, remind:zhihu-publisher 已更名为 zhihu-sync。检测到旧 skill 仍可被当前 Agent 加载，建议删除 zhihu-publisher，仅保留 zhihu-sync，避免重复触发或使用旧流程。删除后请完全退出并重启 Agent。 If the known old skill installation paths are available, list them as well; if there is only list evidence, state the name and do not guess the path.
  • Only remind the user to delete the old skill; do not automatically uninstall or delete files, do not delete shared credentials or publishing artifacts, and do not make the user's completion of cleanup a precondition for the current request. If the user has not cleaned up yet, the current task still runs according to the loaded zhihu-sync .
  • When the ability or permission to check is insufficient, briefly explain that it cannot be confirmed whether an old skill exists, and suggest the user check in the current Agent's skill management interface or installation directory; do not treat failure to check as non-existence.

New version check for updates

After this skill is loaded for the first time in each session, or when the user asks whether zhihu-sync / Zhihu Sync Assistant (legacy name compatible) has a new version, requests an update check, version check, update, or upgrade:

  • Immediately read reference/update.md, follow the process therein to access the version API, and compare the API version of the skill with the same name against the SKILL.md in the local metadata.version .
  • Automatically check only once per session; within the same session, repeat the check only when the user again explicitly asks about updates, versions, or upgrades, or when encountering problems that clearly appear to be caused by an old version.
  • When the automatic check finds a new version, first present the current version, the latest API version, the update recommendation, and the restart requirement, and wait for the user to choose to update or not update for now; before the user chooses, do not continue to confirm content form, organize draft, validate, preview, upload media, or publish.
  • When the user chooses not to update for now or to continue the current task, the subsequent process may continue, but it must be stated that the current session still uses the locally loaded version.
  • When the user explicitly asks about the version or updates, return only the version judgment, update recommendation, and restart requirement; do not continue to confirm content form, organize draft, validate, preview, upload media, or publish.
  • When a new version is found, only prompt the user to confirm before updating; do not silently auto-update the skill.
  • When the version API cannot be accessed or the version cannot be parsed, explain the reason the check cannot be performed; do not guess whether a new version exists.

Dependency Skill

  • zhihu/zhihu-mediacloud-uploader: used only to transfer local images or public image URLs supported by this publishing process to Zhihu media cloud, returning the media_key and image information required for publishing.
  • See installation or enablement guidance at reference/zhihu-mediacloud-uploader.md。
  • Upload parameters, credential configuration, MCP configuration, error handling, and upload result field descriptions are all subject to the zhihu-mediacloud-uploader of SKILL.md and its references/ documentation; this skill does not duplicate these details.
  • Even if the dependency skill supports videos or other files, this skill may use it only to upload images and must not use its video or general file upload capabilities.

Pre-startup check

After completing the no-material request routing in step 0 of the workflow below, before confirming content form, organizing draft, uploading media, or publishing, complete the following checks first:

  1. If the first check for this session has not yet been performed, first complete the old version uninstall check and the new version check-for-update as described above in "Session First Check", without repeating checks that have already been performed. The old version uninstall is only a reminder and does not block the current request. If the automatic check fails, briefly explain the reason and continue with the subsequent startup checks; if the automatic check finds a new version, first wait for the user to choose to update or to temporarily not update. When the user explicitly asks about the version or an update, stop after completing the version check, and do not perform credential, dependency, or release process checks.
  2. Check the source of the Zhihu OpenAPI credentials.
    • First check whether the current process environment variables ZHIHU_OPENAPI_APP_KEY / ZHIHU_OPENAPI_APP_SECRET are complete.
    • Then check whether the shared credential file ~/.zhihu/openapi-credentials.json exists and contains complete credentials.
    • When either source can provide complete credentials and there is no conflict between the sources, continue with the subsequent process; credential permissions and read priority are still checked by zhihu-mediacloud-uploader or reference/auth-info.md before the actual upload/publish.
    • When checking and reporting the credential status, only state the source, completeness, and consistency; do not output, repeat, or display with masking any raw content of ZHIHU_OPENAPI_APP_SECRET .
    • When credentials are missing, the sources are inconsistent, the user does not know how to obtain them, the user directly provides credentials, or the shared file needs to be written, immediately read reference/auth-info.mdand handle it according to the initialization process therein.
    • When the user temporarily does not configure credentials, stop the current process; do not continue to confirm the content form, organize the draft, validate, preview, upload media, or publish.
    • Do not parse the MCP configuration files of other skills to obtain credentials; multiple Zhihu OpenAPI skills reuse ZHIHU_OPENAPI_APP_KEY / ZHIHU_OPENAPI_APP_SECRET and ~/.zhihu/openapi-credentials.json。
  3. Check whether the current Agent can already load zhihu-mediacloud-uploader skill。
    • When it can already be loaded, continue with the subsequent process; when media needs to be uploaded, immediately load that skill's SKILL.md and execute according to its documentation.
    • When it cannot be loaded, immediately read reference/zhihu-mediacloud-uploader.mdand install according to the installation process therein, or guide the user to install.
    • When the installation or dependency skill initialization process requires restarting the Agent, stop the current publishing process and prompt the user to re-initiate the publish or upload request after restarting; do not continue to draft, validate, preview, or publish.

Local artifact directory

Run artifacts are written by default to the current working directory when the Skill is executed,not to the user's home directory：

Artifact dependency chain:

用户输入
  -> draft/latest-draft.md
  -> validate/latest.json
  -> preview/latest.html
  -> 用户确认
  -> publish/latest-request.json
  -> publish/latest-response.json

Dependencies:

Artifact Generation stage Dependency input Downstream use
draft/latest-draft.md draft The user's original information, publishing intent, content form, media references, and publishing requirements The sole default source of truth for validate
validate/latest.json validate draft/latest-draft.md, and when necessary, the upload result of zhihu-mediacloud-uploader upload result Structured input for preview and publish
preview/latest.html preview validate/latest.json; when there are content images provided by the user, additionally read the original image references in draft/latest-draft.md , and for local images also read the corresponding files For user verification only; images are displayed using the original sources provided by the user: local images use the local file address, and network images use the original network URL; publishing still uses only the validate result
publish/latest-request.json publish validate/latest.json, user confirmation, publishing credentials, and publish OpenAPI rules curl request body
publish/latest-response.json publish publish/latest-request.json and the publish OpenAPI HTTP response Publish result record returned to the user

Invalidation rules:

  • draft/latest-draft.md changes,validate/、preview/、publish/ all downstream artifacts are considered stale and must be regenerated.
  • validate/latest.json changes,preview/latest.html and publish/ downstream artifacts are considered stale and must be previewed and reconfirmed again.
  • When the path or file content of an uploaded local image changes, all old validate, preview, and publish artifacts are considered stale; you must re-upload, validate, and preview based on the latest local file. If the original local image does not exist or is unreadable, a new preview must not be generated.
  • When the user finds that the content of preview/latest.html is incorrect, do not directly modify the preview or validate artifacts; you must first modify draft/latest-draft.md, and then regenerate validate and preview.
  • preview/latest.html After regeneration, you must wait for user confirmation again; do not publish before confirmation.
  • publish/latest-response.json only corresponds to the request generated in the same run in the same directory; do not use an old response to represent a new request.
./.zhihu-publish-output/
├── draft/
│   ├── latest-draft.md
│   └── YYYY-MM-DD-HHmm-draft.md
├── validate/
│   ├── latest.json
│   └── YYYY-MM-DD-HHmm-result.json
├── preview/
│   ├── latest.html
│   └── YYYY-MM-DD-HHmm-preview.html
└── publish/
    ├── latest-request.json
    ├── latest-response.json
    ├── YYYY-MM-DD-HHmm-request.json
    └── YYYY-MM-DD-HHmm-response.json
  • Each generation simultaneously writes a timestamped history file and overwrites the corresponding latest-* fixed entry point.
  • Timestamped files are used for historical tracking;latest-* files are used for passing between stages.
  • Subsequent stages by default only read their own direct upstream artifacts and do not read earlier artifacts across stages. The only exception is that preview may read draft/latest-draft.md, but only to map user-provided content images back to their original sources: local images use the original local file address, and network images use the original URL provided by the user; do not regenerate the title, body, or other publish fields from the draft.
  • The publish stage by default writes to ./.zhihu-publish-output/publish/latest-request.json / ./.zhihu-publish-output/publish/latest-response.json, and writes a timestamped history file for the same run.
  • When the user explicitly specifies an output path, the user-specified path takes precedence.

Git accidental commit prevention rules:

  • Before writing to the artifact directory for the first time, check whether the current working directory is inside a Git worktree; if it is not inside a Git worktree, continue directly.
  • If it is inside a Git worktree, check whether the artifact directory is already ignored by Git. The default artifact directory is ./.zhihu-publish-output/under the current working directory; when the user explicitly specifies an output path, check the user-specified output directory.
  • If it is not yet ignored, preferentially append the artifact directory to the current worktree's .git/info/exclude, and do not modify the user's project by default .gitignore。.git/info/exclude is a local private ignore rule and will not enter commits.
  • When writing to .git/info/exclude , use a path relative to the repository root, and use /as the path separator. For example, when the current working directory is the repository root, write /.zhihu-publish-output/; when the current working directory is docs/ inside the repository, write /docs/.zhihu-publish-output/。
  • If .git/info/excludecannot be written, before continuing the process, prompt the user that the artifact directory may be included in commits by git add . , and clearly state that the directory should not be committed.
  • Do not add ./.zhihu-publish-output/ to the publish request; this directory is only used for local draft, validation, preview, request, and response artifacts.

Workflow

Execute in the following order, do not skip steps:

Before entering step 0, first check whether the user has provided a video that needs to be uploaded or published with the content. When a video is found, only reply:当前知乎发布流程暂不支持视频，请移除视频后重新提交。 Then stop immediately; do not perform version or credential checks, create or modify a draft, load upload dependencies, upload, validate, preview, or publish, and do not call zhihu-mediacloud-uploader or other upload capabilities to process the video.

  1. Handle publish requests without material

    • When the user asks to publish an article, question, or idea but provides neither a title, body, media, link, or an explicitly cited existing draft that can be published directly, nor an explicit request for the model to create content, first directly tell the user that no content to publish has been provided at present.
    • By default, only ask the user to provide content, and do not proactively offer the option "I will generate content for you." Use a clear prompt, for example:你还没有提供要发布的内容。不建议完全由 AI 生成正文——平台侧的 AI 识别可能影响内容分发，建议以你的原创内容为主。请把要发布的标题、正文、图片或链接发给我。 After prompting, stop and wait for the user to submit content; before that, do not check credentials or dependencies, infer the content form, create a draft, upload media, validate, preview, or publish.
    • When the user only gives a topic, audience, or a one-sentence creative direction, but does not give content that can be published directly, and does not use explicit creation instructions such as "write an article" or "generate content," still treat it as a request without material. When the user explicitly asks the model to write or generate, consider generation authorized; do not repeatedly discourage or ask for confirmation again; however, before generating, you must prompt once: it is not recommended to have the body text entirely generated by AI, as AI detection may affect content distribution; for article or idea forms, it is recommended to declare AI-assisted creation in the creation statement. After prompting, continue generating directly.
    • When the user chooses to provide content themselves, wait for them to submit content; after receiving the content, re-check from this step. When the user chooses model generation, create only based on the content form, topic, intent, and context already given by the user; if information is insufficient, ask only for the information necessary to complete the content.
    • When generating content for an idea, model generation authorization does not include topic generation authorization. Unless the user explicitly requests generating or adding Zhihu topics, tags, or #话题#, do not ask about topics, infer topics, create topics, or insert topics into the body text; merely specifying a content topic does not equal requesting generation of Zhihu topics.
    • When the user is continuing an existing draft, validate, preview, or publish flow, or explicitly cites existing content that can be read, do not treat it as a new request without material.

  2. Pre-start checks

    • First perform the "Pre-start checks" above.
    • When this skill is first loaded in this session, follow reference/update.md to automatically check the API version once; do not repeat the automatic check in the same session. If a new version is found, first wait for the user to choose whether to update or not update for now; do not continue the publish flow before the user chooses. If the automatic check fails and this is not a user-initiated request to check for updates, explain the reason and continue with subsequent checks.
    • If the user is only asking about the version, updates, or upgrades this time, follow reference/update.md to complete the version check and then stop, without continuing the publish flow.
    • If neither environment variables nor the shared credential file can provide complete credentials, or both are complete but inconsistent, first follow reference/auth-info.md to prompt the user to initialize or choose a source; if the user does not configure credentials for now, stop the current flow and do not continue draft, validate, preview, upload media, or publish.
    • After the credential check passes, then check zhihu-mediacloud-uploader; if the dependency skill needs installation, initialization, or an Agent restart, stop subsequent flow according to the check result.

  3. Confirm content form

    • Supports article(article),question(question),pin(idea).
    • When the user explicitly specifies the format, follow the user's specification.
    • When the user does not specify a format, first infer from the content and recommend the most suitable format, explain the recommendation and ask the user whether to confirm, while allowing the user to choose an article, question, or idea instead.
    • Do not generate structured results, previews, or upload media before the user confirms.

  4. Organize the publishing draft

    • Before writing to ./.zhihu-publish-output/ , first execute the "Git anti-accidental-commit rules" above.
    • Organize the raw information provided by the user, the publishing intent, the confirmed content format, the title intent, the body, media references, links, topics, and other publishing requirements into a Markdown draft.
    • Faithfully preserve the titles, body, facts, opinions, structure, and tone provided by the user. The user's request to publish, convert, or generate a preview does not constitute authorization to polish or rewrite; any deletion, condensing, expansion, reordering, merging, splitting, or semantic rewriting must first obtain the user's explicit permission for the specific action and field.
    • For idea topics, record only the topics explicitly provided or confirmed by the user; when the user only authorizes the model to generate the idea content, that authorization must not be expanded to generating topics. When the user does not explicitly request topics, do not ask, do not infer, do not create, and do not insert topics into the body.
    • By default, the draft is written to ./.zhihu-publish-output/draft/YYYY-MM-DD-HHmm-draft.md, and overwrites ./.zhihu-publish-output/draft/latest-draft.md。
    • The draft only carries the user's intent and raw materials; it does not generate Zhihu HTML and does not initiate publishing requests.
    • Local image paths, public image URLs, image captions, and configuration requirements given by the user should all be retained in the draft for extraction during the validate stage.
    • Content images provided by the user must be retained in the draft in order of appearance with accurate original references: local images retain the absolute file_pathpassed to the uploader, and network images retain the original http:// or https:// URL provided by the user. No original reference may be replaced with the uploaded URL; this order is used for one-to-one mapping between preview and validate images.

  5. Generate Zhihu-adapted structured results

    • Read and execute zhihu-validate/SUBSKILL.md。
    • Default input ./.zhihu-publish-output/draft/latest-draft.md。
    • Before converting or uploading media, perform the title and body length pre-check according to zhihu-validate/reference/conversion.md . When an excess over the upper limit for the current content format is found, explain the actual length and the upper limit, provide the user with the options specified in that document, then stop and wait for a choice; do not silently truncate, condense, switch content formats, or split content.
    • When the user chooses to modify it themselves, wait for the user to submit the modified content; when the user chooses to have the model condense, switch to an article, or split, first update the draft according to the user's choice, write a new timestamped draft, then re-run the length pre-check and validate.
    • Each split piece of content must be treated as an independent publishing item, with content format confirmation, draft, validate, preview, and user confirmation performed separately; confirmation of one preview must not represent the other split items.
    • When the input contains local images, or public image URLs need to be transferred to Zhihu, read reference/zhihu-mediacloud-uploader.md to ensure the dependent skill is installed.
    • After the dependency is installed or confirmed loadable, load and execute zhihu-mediacloud-uploader 's SKILL.md, but only allow it to be used for uploading images; do not copy or rewrite its upload parameters, credentials, MCP, error handling, and response field rules in this skill.
    • When the dependency skill requires restarting the Agent, stop subsequent conversion, preview, and publishing, and prompt the user to re-initiate the request after restarting.
    • When upload fails, stop subsequent conversion, preview, and publishing; do not write local paths into the published content, and do not fabricate media upload results.
    • The model output of validate can only first serve as a candidate file; only after it is successfully parsed, checked, and committed by zhihu-validate/scripts/finalize_validate_json.py can the new latest.json be handed to preview. If the script fails, do not overwrite old artifacts or continue to subsequent stages.
    • Output ./.zhihu-publish-output/validate/latest.json(and the historical file with the same timestamp).

  6. Generate a local preview

    • Read and execute zhihu-preview/SUBSKILL.md。
    • Input ./.zhihu-publish-output/validate/latest.json。
    • If this publishing includes content images provided by the user, additionally read the original image references in ./.zhihu-publish-output/draft/latest-draft.md and map them one-to-one in order with the validate images. Only in the preview HTML, replace local images with the original local file URIs, and replace network images with the user-provided original http:// or https:// URL; do not use their post-upload URLs, redirected URLs, or other substitute addresses.
    • The original source mapping must not modify validate/latest.json; publishing still uses the post-upload Zhihu media URLs and media attributes therein.
    • Output ./.zhihu-publish-output/preview/latest.html(and the historical file with the same timestamp).

  7. Wait for user confirmation

    • Strictly follow the "Deliver preview to user" rules of zhihu-preview/SUBSKILL.md : first confirm that latest.html has been generated, then preferentially call the platform command to open the local HTML using the system default browser. Do not use open_resource or other tools that only open local files in a code editor as a substitute for browser preview.
    • Unless there is verifiable evidence proving that the specified platform command does not exist, the current environment explicitly has no user desktop capability, or the user refuses the required authorization, the corresponding platform's external browser command must actually be executed once. Do not skip the external open attempt because the Agent cannot observe external windows, the host provides a built-in browser, or it is speculated that the command may fail.
    • On Windows, within the same PowerShell process, first use Test-Path -LiteralPath and -PathType Leaf to validate the Windows absolute path, then use Start-Process -ErrorAction Stop to open the preview; when the current terminal is Bash, powershell.exe must also be invoked from Bash to execute the same PowerShell logic, and cmd /c start、cmd //c start、explorer.exe or other substitute commands must not be used instead. On macOS, only openmay be used; on Linux, only xdg-openmay be used; do not substitute platform commands on your own. The original exit status of the platform command must be preserved; do not use wrappers such as || echo ... that rewrite a failure status as success.
    • After the system default browser open command succeeds, do not call the host's built-in browser, WebView, or browser control tools to open the same preview; the opening paths of the external system browser and the host's built-in browser must be mutually exclusive.
    • When the external open command exits with status 0 and there is no platform command exception, it must be treated as a successful open; the Agent's inability to observe the external browser window, the command returning asynchronously, or the lack of a window screenshot does not constitute failure. Before falling back to the built-in browser, at least one piece of verifiable evidence must be recorded: the specified platform command is confirmed not to exist, the original exit status is non-zero, the command threw an exception, the host explicitly reports no user desktop capability, or the user refuses the required authorization; without such evidence, the built-in browser must not be invoked. Only when the built-in browser is unavailable, fails to open, or the user refuses the required authorization, provide a clickable Markdown file link using an absolute path, and clearly warn that some hosts may display HTML source code. By default, a local HTTP service must not be started.
    • Before invoking the built-in browser, a visible notice must first be sent to the user, explaining that the system default browser failed to open, briefly stating the reason for failure, and clearly informing that the built-in browser will be used instead; only after the notice has been sent may the built-in browser open action be executed. This failure notice must not be sent when the external open command succeeds.
    • After the browser opens successfully or the fallback delivery is completed, stop immediately at the confirmation stage and wait for explicit user confirmation; do not treat "preview generated" or "preview opened" as the user having confirmed.
    • When the user finds that the preview content is incorrect or requests changes, do not directly edit ./.zhihu-publish-output/preview/latest.html、./.zhihu-publish-output/validate/latest.json or the publish request file.
    • Changes may only be made to the draft: first, incorporating the user's change requirements, re-read zhihu-validate/SUBSKILL.md and, if necessary, zhihu-validate/reference/conversion.md、zhihu-validate/reference/config.md、zhihu-validate/reference/code-languages.md, then update ./.zhihu-publish-output/draft/latest-draft.md and write a new timestamped draft.
    • Draft changes should express the user's intent and source content that can be reliably extracted by the validate rules; if the user's requirements cannot be expressed by the current validate rules, explain the limitation first, and do not work around it by manually editing the validate JSON or preview HTML.
    • After the draft is updated, re-run zhihu-validate and zhihu-preview, and wait for user confirmation again.
    • Do not proceed to the publishing step before the user confirms.

  8. Enter the publishing process

    • After user confirmation, read and execute zhihu-publish/SUBSKILL.md。
    • The publishing stage reads ./.zhihu-publish-output/validate/latest.json。
    • In the publishing stage, first follow reference/auth-info.md to complete the credential check, then follow zhihu-publish/reference/publish-openapi.md and the corresponding type specification to assemble the publish OpenAPI HTTP request, use curl to send the request, and write the request and response to ./.zhihu-publish-output/publish/。

Sub-skill responsibilities

  • zhihu-validate/SUBSKILL.md: Generate the Zhihu-adapted structured result.
  • zhihu-preview/SUBSKILL.md: Generate the local browser preview HTML.
  • zhihu-publish/SUBSKILL.md: The publishing process after user confirmation.

Key artifacts:

  • ./.zhihu-publish-output/draft/latest-draft.md: The draft after organizing the user's original publishing intent and materials; it is the source of truth for subsequent stages.
  • ./.zhihu-publish-output/validate/latest.json: The publish-adapted structured result.
  • ./.zhihu-publish-output/preview/latest.html: The local preview page, used only for verification.
  • ./.zhihu-publish-output/publish/latest-request.json: The request body sent to the publish OpenAPI.
  • ./.zhihu-publish-output/publish/latest-response.json: The publish OpenAPI publishing response.

Key constraints

  • When a new publish request has no directly publishable content and the user has not explicitly authorized model generation, you must first explain that content is missing and ask the user to provide it, and also explain that having the main text fully generated by AI is not recommended; by default, do not offer the "generated by model" option. Before the user submits content or explicitly requests generation, do not perform the credential check or any publishing stage.
  • When content is generated by AI or created with AI assistance, publishing articles and ideas must proactively recommend a creation statement, ai_creationand explain that not declaring it may affect subsequent AI identification and content distribution; whether to declare is still decided by the user, and this field must not be sent when the user has not made an explicit choice. Ideas only support ai_creation, and must not send other creation statements supported by articles; the publish OpenAPI for questions has no creation statement field, so it can only be verbally prompted before publishing, and must not be forged, appended, or replaced with other fields.
  • Do not skip form confirmation.
  • Do not skip the draft stage; by default, validate only extracts the content to be published this time from draft/latest-draft.md .
  • Without the user's explicit permission, you must not delete, condense, expand, reorder, merge, split, or rewrite the content provided by the user; requests such as "publish", "convert", or "generate preview" do not themselves constitute authorization to modify content.
  • When generating ideas for the user, content generation authorization must not be treated as topic generation authorization; topics may be written into the draft and bodyonly when the user explicitly requests generating or adding topics, or explicitly provides or confirms specific topics. The content subject itself is not a Zhihu topic instruction.
  • When the title or body exceeds the length limit of the current content form, you must first provide options and wait for the user to choose; without the user's choice, you must not condense, switch forms, split, upload media, or generate structured results.
  • When images need to be uploaded, do not bypass zhihu-mediacloud-uploader or directly use local paths to generate validate / publish content; only preview HTML may, according to the zhihu-preview rules, use local image file URIs.
  • After being routed through the no-material request, you must first check whether the current process environment variable ZHIHU_OPENAPI_APP_KEY / ZHIHU_OPENAPI_APP_SECRET or the shared credential file ~/.zhihu/openapi-credentials.json can provide complete credentials; after the credential check passes, then check whether zhihu-mediacloud-uploader can be loaded. When missing, handle according to reference/auth-info.md and reference/zhihu-mediacloud-uploader.md respectively.
  • When neither environment variables nor the shared credential file can provide complete credentials and the user does not configure them for the time being, stop the current process and do not continue draft, validate, preview, upload media, or publish; do not parse credentials from other skills' MCP configurations.
  • Each stage is executed according to its corresponding sub-skill; the root skill does not reimplement conversion, preview, or publishing details.
  • Do not use preview HTML as publish content.
  • Content images provided by the user must use their original sources in preview HTML: local images use the original local file URI, and network images use the original http:// or https:// URL provided by the user. Uploaded URLs, redirected URLs, or other substitute addresses must not be used; this replacement only applies to preview HTML and must not modify validate artifacts or publish input.
  • After generating the preview, you must confirm the file exists and preferably open it with the system default browser; unless there is verifiable evidence that the platform command does not exist, the host clearly has no user desktop capability, or the user refuses authorization, you must actually execute the specified external browser command once, and must not use open_resource to open the source code in place of the preview, nor skip the attempt because the external window cannot be observed.
  • On Windows, you must, within the same PowerShell process, first use Test-Path -LiteralPath -PathType Leaf to verify the Windows absolute path, then use Start-Process -ErrorAction Stop to open it; when the current terminal is Bash, you must invoke powershell.exe to execute the same logic, and must not substitute cmd /c start、cmd //c start、explorer.exe or other commands. On macOS, only open, Linux can only use xdg-open. Do not use wrapper commands that would mask the original exit status.
  • When the system default browser open command's original exit status is 0 and there are no exceptions, it must be treated as successful; the Agent's inability to observe an external window, the command returning asynchronously, or the absence of a screenshot cannot be used as grounds for failure. After success, it is forbidden to use the host's built-in browser, WebView, or browser control tools to open the same preview again. Only when at least one piece of verifiable evidence is recorded among the following—the specified platform command does not exist, the original exit status is non-zero, the command throws an exception, the host explicitly lacks user desktop capability, or the user refuses authorization—is it permitted to try the host's built-in browser; only when the built-in browser is also unavailable, fails to open, or the user refuses authorization, provide a clickable Markdown file link pointing to the absolute path of preview/latest.html , and note that the host may display the source code. By default, do not start a local HTTP service.
  • When the external system browser fails to open and you are about to fall back to the built-in browser, you must first inform the user that the external browser could not be opened, briefly explain the reason for the failure, and state that the built-in browser will be used instead; do not open the built-in browser first and then add the explanation afterward.
  • Before the user confirms, do not proceed to the publishing step.
  • When the user finds the preview incorrect or requests content changes, you may only update the draft first; when updating the draft, you must combine the user's requirements with the documentation of zhihu-validate , then regenerate latest.json and preview again.
  • Do not directly edit validate/latest.json、preview/latest.html or publish/latest-request.json。
  • for unsupported content forms or configuration items, state directly that they are currently unsupported.
  • Automatically check the interface version once when this skill is first loaded in this session; when the user asks about the version, updates, or upgrades, also check and notify according to reference/update.md . Do not silently auto-update; after updating, you must prompt the user to restart the Agent.
  • Unless the user explicitly specifies another path, artifacts should be written to the following under the current working directory: ./.zhihu-publish-output/。
  • Before writing to the artifact directory for the first time, you must perform a Git accidental-commit check; do not modify the user's project .gitignoreby default; prefer using .git/info/exclude。