readability-guidance

Project Context

• personal config directory: !bash "${CLAUDE_PLUGIN_ROOT}/scripts/han-config-dir.sh" 2>/dev/null || echo "$HOME/.claude"
• project .han/config.md: !cat .han/config.md 2>/dev/null || echo ""

As your first action, use the Read tool on .han/config.md inside the personal config directory path above. A read that returns no file is no personal configuration: continue silently. When that file or the project .han/config.md probe supplies content, apply it per config-rule.md, which governs precedence between the two files, relative-path resolution, and what to do with a file that reads but cannot be used.

Readability Guidance

You have invoked readability-guidance to source the shared readability standard before you draft prose. This skill surfaces the standard into your own context and hands control back. It is a means to writing your deliverable, not the deliverable itself: apply what it surfaces while you draft and self-check, then RETURN to the workflow that called you and finish it.

This skill is inline — it runs in your context, not an isolated one, so the standard it surfaces stays available to you after it returns. Do not treat anything here as a stopping point or a final answer.

Which outputs this standard covers

A structured specification, plan, phased build, work-item list, coding standard, or test plan is reader-facing whenever a human reads it end to end — to approve it, follow it, or build from it — even when downstream skills also consume it. Only an artifact consumed purely as a pipeline input, with no human reading it end to end, falls outside the standard. If a human reads your deliverable end to end, apply the standard to it.

Step 1: Resolve the writing-voice source, then read the standard

First resolve which writing-voice profile this run uses:

• When either .han/config.md probe supplied a writing-voice value, resolve it and check that the file exists. A relative value resolves against the folder holding the file that declared it: the working directory for the project file, and the personal config directory the probe reported for the personal file. A full path is used as it stands, and a leading ~ expands to the home directory. When both files supply a value, the project file's wins.
  • When the file exists, it is the writing-voice profile for this run, used in place of the built-in profile.
  • When the file does not exist, warn the user that the configured writing-voice file was not found, naming which of the two configuration files declared it, and ask whether to use the built-in Han voice or skip the writing voice entirely for this run. Honor the answer: fall back to the built-in profile, or proceed with no voice profile at all.
• When neither probe supplied a writing-voice value, the built-in profile at ${CLAUDE_PLUGIN_ROOT}/references/writing-voice.md applies.