zhihu-publisher

Zhihu Publisher

The overall orchestration entry point for the Zhihu publishing process. 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 zhihu-publisher what it is, how to use it, first-time use, authorization, or credential configuration:

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.
Only provide introductions, first-time use instructions, and authorization guidance; do not proceed to generate draft, validate, preview, or publish.

First version check of the session

After this skill is first loaded in each session, or when the user asks whether zhihu-publisher has a new version, requests an update check, version check, update, or upgrade:

Immediately read reference/update.md, access the version API according to its process, and compare the API version of the skill with the same name against the local SKILL.md 's 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 an issue that clearly appears to be caused by an old version.
When an automatic check finds a new version, first notify the user of the current version, the latest API version, the update recommendation, and the restart requirement, and wait for the user to choose whether to update or not update for now; before the user chooses, do not continue to confirm the content form, organize draft, validate, preview, upload media, or publish.
If 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, only return the version assessment, update recommendation, and restart requirement; do not continue to confirm the 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.
If the version API cannot be accessed or the version cannot be parsed, explain the reason why the check cannot be performed; do not guess whether there is a new version.

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.
For installation or enablement guidance, see reference/zhihu-mediacloud-uploader.md。
Upload parameters, credential configuration, MCP configuration, error handling, and descriptions of upload result fields are all subject to zhihu-mediacloud-uploader 's 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 only use it to upload images, and must not use its video or general file upload capabilities.

Pre-launch check

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

If the version check has not yet been completed after this skill is first loaded in this session, first perform the above "First version check of the session". If the automatic check fails, briefly explain the reason and continue with the subsequent launch checks; if the automatic check finds a new version, first wait for the user to choose whether to update or not update for now. When the user explicitly asks about the version or updates, stop after completing the version check, and do not perform credential, dependency, or publishing process checks.
Check the source of Zhihu OpenAPI credentials.
- First check whether the current process environment variable ZHIHU_OPENAPI_APP_KEY / ZHIHU_OPENAPI_APP_SECRET is complete.
- Check again whether the shared credential file ~/.zhihu/openapi-credentials.json exists and contains complete credentials.
- When any source can provide complete credentials and there is no conflict between sources, continue with the subsequent process; credential permissions and read priority are still determined by zhihu-mediacloud-uploader or reference/auth-info.md checked before the actual upload/publish.
- When checking and reporting credential status, only state the source, completeness, and consistency; do not output, repeat, or display in masked form any raw content of ZHIHU_OPENAPI_APP_SECRET .
- When credentials are missing, sources are inconsistent, the user is unclear 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。
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

Runtime 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	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 `draft/latest-draft.md` the original image references in; for local images, the corresponding files also need to be read	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; when publishing, only the validate result is still used
`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 publish OpenAPI HTTP response	Publishing result record returned to the user

Invalidation rules:

draft/latest-draft.md When changes occur,validate/、preview/、publish/ all downstream artifacts are considered expired and must be regenerated.
validate/latest.json When changes occur,preview/latest.html and publish/ downstream artifacts are considered expired and must be previewed again and reconfirmed.
When the path or file content of an uploaded local image changes, all old validate, preview, and publish artifacts are considered expired; they must be re-uploaded, validated, and previewed according to the latest local files. When the original local image does not exist or is unreadable, a new preview must not be generated.
When the user discovers preview/latest.html When the content is incorrect, do not directly modify the preview or validate artifacts; you must first modify draft/latest-draft.md, then regenerate validate and preview.
preview/latest.html After regeneration, you must wait again for user confirmation; 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 path, and network images use the original URL provided by the user; do not regenerate the title, body, or other publishing fields from draft.
The publishing 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, prefer appending that artifact directory to the current worktree's .git/info/exclude, and do not by default modify the user project's .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, warn 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 publishing 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 draft, load upload dependencies, upload, validate, preview, or publish, and do not call zhihu-mediacloud-uploader or other upload capabilities to process the video.

Handle no-material publishing requests
- When the user asks to publish an article, question, or idea, but has neither provided a directly publishable title, body, media, link, or an explicitly referenced existing draft, nor explicitly asked the model to create content, first directly tell the user that no content to publish has been provided.
- By default, only ask the user to provide content, and do not proactively offer the option of "I will generate content for you." Use a clear prompt, for example:你还没有提供要发布的内容。不建议完全由 AI 生成正文——平台侧的 AI 识别可能影响内容分发，建议以你的原创内容为主。请把要发布的标题、正文、图片或链接发给我。 Stop after the prompt 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 creative instructions such as "write an article" or "generate content," still handle it as a request without material. When the user explicitly asks the model to write or generate, treat it as authorized generation, and do not repeatedly discourage or ask for confirmation again; but before generating, you must first prompt once: it is not recommended to have the body text generated entirely by AI, AI detection may affect content distribution, and for article or idea forms it is recommended to declare AI-assisted creation in the creation statement. After the prompt, continue generating directly.
- When the user chooses to provide it themselves, wait for them to submit content; after receiving the content, re-check from this step. When the user chooses to have the model generate it, create only based on the content form, topic, intent, and context already given by the user; when 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 #话题#, otherwise 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 process, or explicitly references existing readable content, do not handle it as a new request without material.
Pre-start check
- First execute the "Pre-start check" above.
- When this skill is loaded for the first time in this session, follow reference/update.md to automatically check the API version once; do not repeat the automatic check in the same session. When a new version is found, first wait for the user to choose update or not update for now; do not continue the publishing process 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, update, or upgrade this time, follow reference/update.md to complete the version check and then stop, and do not continue the publishing process.
- When neither environment variables nor the shared credential file can provide complete credentials, or when 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 process, and do not continue draft, validate, preview, upload media, or publish.
- After the credential check passes, then check zhihu-mediacloud-uploader; when the dependency skill needs to be installed, initialized, or the Agent needs to be restarted, stop subsequent processes according to the check result.
Confirm content form
- Supports article(article),question(question),pin(idea).
- When the user explicitly specifies the form, execute according to the user's specification.
- When the user does not specify the form, first infer and recommend the most suitable form based on the content, explain the recommendation result and ask the user whether to confirm, and at the same time allow the user to choose a different article, question, or idea.
- Do not generate structured results, previews, or upload media before the user confirms.
Organize publishing draft
- Before writing to ./.zhihu-publish-output/ , first execute the "Git anti-mistaken-commit rules" above.
- Organize the raw information provided by the user, the publishing intent, the confirmed content form, the title intent, the body, media references, links, topics, and other publishing requirements into a Markdown draft.
- Faithfully preserve the title, body, facts, opinions, structure, and tone provided by the user. A user's request to publish, convert, or generate a preview does not constitute authorization to polish or rewrite; any deletion, condensation, expansion, rearrangement, merging, splitting, or semantic rewriting must first obtain the user's explicit permission for the specific action and field.
- Idea topics only record topics explicitly provided or confirmed by the user; when the user only authorizes the model to generate idea content, that authorization must not be expanded to generating topics. When the user has not explicitly requested topics, do not ask, infer, create, or 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 retain accurate original references in the draft in order of appearance: 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 an uploaded URL; this order is used for one-to-one mapping between preview and validate images.
Generate a Zhihu-adapted structured result
- Read and execute zhihu-validate/SUBSKILL.md。
- Default input ./.zhihu-publish-output/draft/latest-draft.md。
- Before converting or uploading media, follow zhihu-validate/reference/conversion.md to perform the title and body length pre-check. When a limit for the current content form is exceeded, state the actual length and the 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 forms, 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 it, switch it to an article, or split it, first update the draft according to the user's choice, write a new timestamped draft, and then re-run the length pre-check and validate.
- Each split piece of content must be treated as an independent publishing item, with content form 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 dependency skill is installed.
- After the dependency is installed or confirmed loadable, load and execute zhihu-mediacloud-uploader of SKILL.md, but only allow it to be used to upload images; do not copy or rewrite its upload parameters, credentials, MCP, error handling, or 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 serve as a candidate file first; only after zhihu-validate/scripts/finalize_validate_json.py successfully parses, checks, and commits it can the new latest.json be handed to preview. When 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).
Generate local preview
- Read and execute zhihu-preview/SUBSKILL.md。
- Input ./.zhihu-publish-output/validate/latest.json。
- If this publication contains user-provided content images, additionally read ./.zhihu-publish-output/draft/latest-draft.md the original image references in, 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; the post-upload URL, redirected URL, or other substitute addresses must not be used.
- The original source mapping must not modify validate/latest.json; publication still uses the post-upload Zhihu media URL and media attributes within it.
- Output ./.zhihu-publish-output/preview/latest.html(and the historical file with the same timestamp).
Wait for user confirmation
- Strictly execute zhihu-preview/SUBSKILL.md the "deliver preview to user" rules: first confirm that latest.html has been generated, then preferentially call the platform command to open the local HTML using the system default browser. open_resource or other tools that only open local files in a code editor must not be used instead of a browser preview.
- Unless there is verifiable evidence proving that the specified platform command does not exist, the current environment clearly has no user desktop capability, or the user refuses the required authorization, the corresponding platform's external browser command must actually be executed once. The external open attempt must not be skipped 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 verify 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. On macOS, only openmay be used; on Linux, only xdg-openmay be used; platform commands must not be replaced on one's own. The original exit status of the platform command must be preserved; wrappers such as || echo ... that rewrite a failure status as success must not be used.
- After the system default browser open command succeeds, the host built-in browser, WebView, or browser control tools must not be called again to open the same preview; the opening paths of the external system browser and the host built-in browser must be mutually exclusive.
- When the external open command exit status is 0 and there is no platform command exception, it must be regarded as a successful open; the Agent being unable to observe the external browser window, the command returning asynchronously, or not obtaining a window screenshot do not constitute failure. Before degrading 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 throws an exception, the host explicitly reports that there is no user desktop capability, or the user refuses the required authorization; when none of this evidence is present, the built-in browser must not be called. Only when the built-in browser is unavailable, opening fails, or the user refuses the required authorization, provide a clickable Markdown file link using the 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, you must first send the user a visible notice stating that the system default browser failed to open, briefly explaining the reason for the failure, and clearly informing them that the built-in browser will be used instead; only after the notice has been sent may the built-in browser opening action be executed. When the external open command succeeds, this failure notice must not be sent.
- 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 the preview content incorrect or requests modifications, do not directly edit ./.zhihu-publish-output/preview/latest.html、./.zhihu-publish-output/validate/latest.json or the publish request file.
- Modifications may only be applied to the draft: first, based on the user's modification request, re-read zhihu-validate/SUBSKILL.md and the 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 modifications should express the user's intent and source content that can be reliably extracted by the validate rules; if the user's request cannot be expressed by the current validate rules, first explain the limitation, and do not bypass it by manually editing the validate JSON or preview HTML.
- After the draft is updated, re-run zhihu-validate and zhihu-preview, and again wait for user confirmation.
- Before user confirmation, do not proceed to the publish step.
Enter the publishing process
- After user confirmation, read and execute zhihu-publish/SUBSKILL.md。
- The publish stage reads ./.zhihu-publish-output/validate/latest.json。
- In the publish 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, and the source of truth for subsequent stages.
./.zhihu-publish-output/validate/latest.json: The publishing-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 publishing 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 fully AI-generated body text is not recommended; by default, do not offer the "generated by model" option. Before the user submits content or explicitly requests generation, you must not perform the credential check or any publishing stage.
When content is AI-generated or involves AI assistance, article and idea publishing must proactively recommend the creation declaration ai_creation, and explain that not declaring may affect subsequent AI identification and content distribution; whether to declare is still up to the user, and if the user has not explicitly chosen, do not send this field. Ideas only support ai_creation, and must not send other creation declarations supported by articles; the publish OpenAPI for questions has no creation declaration 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; validate by default only extracts this publishing content from draft/latest-draft.md .
Without the user's explicit permission, user-provided content must not be deleted, condensed, expanded, reordered, merged, split, or rewritten; 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; only when the user explicitly requests generating or adding topics, or explicitly provides or confirms specific topics, may topics be written into the draft and body. The content subject itself is not a Zhihu topic instruction.
When the title or body exceeds the length limit of the current content form, options must first be provided and the user's choice awaited; without the user's choice, content must not be condensed, the form switched, content split, media uploaded, or structured results generated.
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 use local image file URIs according to the zhihu-preview rules.
After being routed through a request without materials, 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. If missing, handle according to reference/auth-info.md and reference/zhihu-mediacloud-uploader.md respectively.
When neither the environment variable 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, media upload, or publishing; do not parse credentials from other skills' MCP configurations.
Each stage is executed according to the corresponding sub-skill; the root skill does not reimplement conversion, preview, or publishing details.
Do not use the preview HTML as publish content.
Content images provided by the user must use their original sources in the 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 applies only to the preview HTML and must not modify the validate output or publish input.
After generating the preview, you must confirm the file exists and preferentially open it with the system default browser; unless there is verifiable evidence proving the platform command does not exist, the host explicitly 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 instead of the preview, nor skip the attempt because the external window cannot be observed.
On Windows, you must first use Test-Path -LiteralPath -PathType Leaf in the same PowerShell process to verify the Windows absolute path, then use Start-Process -ErrorAction Stop to open it; when the current terminal is Bash, you must call 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 openmay be used, and on Linux, only xdg-open. Do not use wrapper commands that obscure the original exit status.
When the system default browser open command's original exit status is 0 and there is no exception, it must be treated as successful; the Agent being unable to observe external windows, 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 specified platform command not existing, the original exit status being non-zero, a command exception, the host explicitly lacking user desktop capability, or the user refusing authorization, is it permitted to attempt 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 link pointing to preview/latest.html a clickable Markdown file link to the absolute path, and note that the host may display source code. By default, a local HTTP service must not be started.
When the external system browser fails to open and you are preparing to fall back to the built-in browser, you must first notify the user that the external browser failed to open, briefly explain the reason for the failure, and inform them that you are about to switch to the built-in browser; you must not open the built-in browser first and then add the explanation afterward.
Before user confirmation, 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 and zhihu-validate 's documentation, 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.
When this skill is first loaded in this session, automatically check the interface version once; 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, a Git accidental-commit prevention check must be performed; do not modify the user's project .gitignoreby default, prefer using .git/info/exclude。