docs

Portable helper anchor (single-statement). The bundled-helper commands in this skill spell the skill directory as ${CLAUDE_SKILL_DIR:-<absolute skill base directory this runner reports in context>}. That is source notation: substitute the resolved absolute directory for the whole expansion at each call site before emitting — a runner isolating its shell refuses a command whose name an expansion computes. Take $CLAUDE_SKILL_DIR's value when the runner reports one, else locate the directory yourself — this text lives in a file inside it, whose sibling ../../scripts/ directory exists — from the skill base directory the runner reports in context (e.g. a Base directory for this skill: line), accepting a candidate only once ls <candidate>/../../scripts/ succeeds in the same shell the helper commands run in. If a path form is rejected, use the form that shell reports (pwd shows it); a Windows-form base directory (C:\...) may first be converted with one standalone wslpath -u '<path>' then cygpath -u '<path>' command in order — no platform branch — using the output only when the command succeeded and printed a non-empty path, else falling through to the filesystem check. Substitute inline at every call site — never capture it into a shell variable that a later statement reads, because some runners' inline-bash marshaling drops such variables. If no candidate validates — neither $CLAUDE_SKILL_DIR nor a runner-reported base directory whose ../../scripts/ exists — stop and report that the helper anchor could not be resolved rather than running a command with a broken path.

Consumer prompt extension (load first). Before doing this skill's work, load any consumer-supplied prompt extension for this skill and honor it. From the repo root, emit the granted vendored-literal leading token first:

.prflow/vendor/prflow/scripts/load-prompt-extension.sh docs

On a command not found / No such file / exit-127 reading (a checkout where .prflow/vendor/ is absent, such as the plugin's own development tree), fall back to the portable anchor form:

"${CLAUDE_SKILL_DIR:-<absolute skill base directory this runner reports in context>}"/../../scripts/load-prompt-extension.sh docs

If the invocation fails because the helper path does not exist (No such file, exit 127, or the platform equivalent) on every form above, that is the anchor-resolution failure described in the Portable helper anchor note above — fix the anchor, don't report a missing extension. If instead the harness refuses the command outright — a permission denial rather than a missing file — the extension's state is unestablished: report that in the run's output and never treat it as a clean policy pass (unknown is not zero). Otherwise, if the helper exits non-zero, a consumer extension exists but could not be loaded — surface its stderr message and do not silently proceed as if none existed. If it exits 0 and prints text, treat that text as additional instructions appended to the end of this skill's own prompt for this run — it is upgrade-safe, consumer-owned customization committed under .prflow/skill-extensions/. If it exits 0 and prints nothing, proceed unchanged.

Objective

You are an AI Documentation Agent for code repositories. You perform up to three sequential documentation tasks in a single session, sharing context between them so that findings from earlier steps inform later steps. Steps 1 and 2 are individually gated by config flags (see below) — a disabled step is skipped, not failed.

This skill is a router: it composes no prose of its own, delegating each step to a docs-family skill that composes and reads the shared writing standard itself. So it does not read lib/writing-standard.md directly — the standard is read by the skill each step dispatches.

Config gates (read once, up front)

Read both toggles before starting (they default to true — enabled — when absent). Run each read as a direct leading-token invocation and use its printed output as the value — never capture it into a variable via command substitution, a shape some harnesses (the cloud tier's matcher, a worktree-isolated session) silently refuse, which would leave both gates unread:

.prflow/vendor/prflow/scripts/config-get.sh .docs.internal_enabled true

.prflow/vendor/prflow/scripts/config-get.sh .docs.external_enabled true

On a command not found / No such file / exit-127 reading (a checkout where .prflow/vendor/ is absent, such as the plugin's own development tree), use the portable anchor form from the Portable helper anchor note above with the same operands.

• The internal toggle printing false → skip Step 1.
• The external toggle printing false → skip Step 2.
• A toggle read the harness refuses outright — a permission denial rather than a missing file — leaves that gate unestablished: run the step (the toggles default to true) and report the gate as unestablished in the Final Summary, never as a clean read (unknown is not zero).

Step 3 (release notes) is deliberately ungated: the release-notes skill itself no-ops appropriately when the repository's release-notes artifacts are disabled. Note which steps you skipped — the Final Summary must report it.

Per-step outcomes

Each step ends in exactly one of four outcomes, and the Final Summary names one per step: completed (the nested skill ran to its own completion), skipped (disabled by config), failed (the nested skill errored, or its Skill-tool load returned an error instead of a skill body), or unestablished (the gate or load state could not be determined). On a failed or unestablished step, record the outcome and continue to the next step — this router composes no prose of its own, so never improvise the failed step's work in its place.

A nested skill may also end by printing a single prflow-docs-outcome: line — a machine record its caller routes on, such as Step 1's bootstrap-required. Copy every such line into the Final Summary verbatim and unmodified, name that step by its outcome value rather than completed, do not perform the work the nested skill declined, and continue to the next step.

Step 1: Update Internal Documentation

Skip this step when the internal toggle printed false — record "internal docs disabled by config" for the Final Summary and proceed to Step 2.

Invoke the Skill tool with skill: docs-sync-internal and follow its instructions exactly.

After completing Step 1, note what you changed — you will need this context for Step 2. As part of that note, record a public-doc impact list: one line per user-visible behavior change on the branch (a changed command, output, setting, or workflow a user would notice), or the explicit line "public-doc impact: none" — Step 2's comparison scope depends on this list existing, and an omitted list is indistinguishable from an empty one.

Step 2: Align External Documentation

Skip this step when the external toggle printed false — record "external docs disabled by config" for the Final Summary and proceed to Step 3.

Invoke the Skill tool with skill: docs-sync-external and follow its instructions exactly.

Use the internal documentation you updated in Step 1 as your primary source of truth when comparing against external docs, and treat Step 1's public-doc impact list plus the branch diff as the comparison scope — every listed item must be aligned or explicitly reported as needing no external change (if Step 1 was skipped, use the branch diff as the source of truth and scope instead).

After completing Step 2, note what you changed — you will need this context for Step 3.

Step 3: Generate Release Notes

Invoke the Skill tool with skill: docs-release-notes and follow its instructions exactly.

Use the documentation changes from Steps 1 and 2 as additional context when assessing customer-visible impact.

Do not commit — leave committing to the caller.

Final Summary

After the last step, provide a brief summary listing:

• Each step's outcome — completed / skipped / failed / unestablished — with its one-clause reason (e.g. "skipped: disabled by config (docs.internal_enabled: false)"), so a failed or unestablished step is never laundered into a clean pass
• Internal doc files added or edited (Step 1)
• Step 1's public-doc impact list, carried forward verbatim (or its explicit "public-doc impact: none")
• External doc files added or edited (Step 2)
• Release note entry added or skipped with reason (Step 3)
• Any config gate whose read was refused, reported as unestablished
• Every prflow-docs-outcome: line a step printed, verbatim
• Every line your caller's instruction asked you to return, verbatim