Han v5.0.0 alpha 1#130
Draft
mxriverlynn wants to merge 90 commits into
Draft
Conversation
Extract readability-editor, edit-for-readability, and their reference docs into a new foundational han-communication plugin; consuming skills delegate to it rather than reading vendored copies.
Full delegation (user choice) replaces all three inline uses of the standard; D4 rescoped, D5 gains opt-in dependency fallback, D7 expands to the full docs/tooling inventory; 11 findings recorded.
Resolve dead spec anchors, add missing inline D1/D5 links, complete cross-reference fields on all decisions and findings.
…ndency Every plugin that hosts or triggers a delegating skill (han-core, han-coding, han-github, han-reporting, han meta, han-atlassian) declares han-communication directly; no transitive-resolution reliance. Closes OI-1 and cleans up han-planning exclusion wording.
…findings Team (junior-developer, adversarial-validator, evidence-based-investigator, gap-analyzer) confirmed the plan's foundations and surfaced: step-order preservation risk under forced delegation (D4), dependency-graph narration scope (D7 class 5), manifest description updates (D8), the Codex packaging surface (new D10), plus delegation-scope wording and future-wrapper rule.
…me doc scope Resolve 9 findings: split Preconditions for the Codex surface (F23), widen D4's step-preservation commitment to renumber/split/heading cases (F28), qualify D10 Codex parity + opt-in install path + OI-2 (F29), and reframe D7 doc classes as a comprehensive grep so the recurring missed-file class is closed (F25-F27, F30, F31).
Final round (Large cap): junior-developer clean; adversarial-validator reproduced the D5/D10 inventories and confirmed no file-discovery gap. Resolved 4 refinements (F32-F35): rewrite-depth for docs/readability.md, order-significant non-numbered lists in the preservation commitment, OI-2 blast-radius correction, and the mandated Review History section.
…guidance skill) Adopt the readability-guidance skill approach after evidence gathering (Claude Code docs + in-repo): skills invoked via the Skill tool run in the same context, so han-communication exposes a resource-surfacing readability-guidance skill that sources the standard cross-plugin for in-voice drafting. D3 reframed (source cross-plugin), D4 reframed (staged model, editor retained for synthesis only), D11 added (the guidance mechanism), OI-3 added (prototype gate). Preserves docs/readability.md's staged model that full delegation collapsed; rehabilitates the F3 hybrid.
…ated Adversarial R4 found readability-guidance is the repo's documented data-fetch composition anti-pattern (skill-composition.md). Per user direction (option 3): built and ran an inline prototype (resumed 3/3 — weak signal, not reliability), did NOT update skill-composition.md, hardened OI-3 into a rigorous blocking spike with a named fallback, and captured the risk + inline-vs-fork distinction on D11. Fixed revision propagation: stale D7 'abolished staged model' (F36), editor rule-path break (F37), impossible edge-case examples (F40), decision counts (F43), and refreshed the Review History for R4.
…ualified Rigorous subagent-harness spike (46 trials, 4 arms): 34/34 same-context Skill-call invocations completed with zero early exits, including a worst-case adversarial arm. Forked context:fork disqualified because it isolates the guidance so its content never reaches the caller. api_retry could not be induced (infra-level fault), so that path is reduced by inference, not measured. D11 known-risk resolved and prototype gate cleared; skill-composition.md to record the inline variant as a supported exception.
Records the spike outcome in the spec: OI-3 marked resolved, the inline readability-guidance mechanism validated (34/34 same-context runs, zero early exits) and the forked variant disqualified. Bakes the inline (no context:fork) requirement into the Primary Flow, updates the open-item count 2 -> 1, and notes the unmeasured api_retry residual risk plus the documented fallbacks.
…ption The OI-3 spike validated one narrow shape that looks like data-fetch but is supported: an inline (never context:fork) sub-skill that surfaces a whole shared standard into the caller's context and hands control back. Carves it out of the data-fetch section with its three defining properties, adds it to the decision guide, and keeps the honest limit that api_retry was not directly exercised.
Move the spike report, incident fixture, all 46 trial artifacts, and the 8 harness skill definitions from the session scratchpad into artifacts/oi-3-spike/ so the spike is reproducible independent of the session that ran it. Add a pointer from the research note.
…anic graduated to T1 Lightweight self-review round confirming the post-spike edits are internally consistent (open-item count, trial counts, cross-file claims all agree). One finding (F46): the OI-3 edit had leaked the context:fork frontmatter mechanic into a Primary Flow behavioral sentence. Since the spike settled that mechanic, it graduates from the OI-3 open item to a new technical note T1; Primary Flow restated behaviorally. No blocking open items remain (OI-2 non-blocking); spec ready for plan-implementation.
…ation) Medium team (PM + junior-developer + structural-analyst + devops-engineer + test-engineer), 2 rounds. Produces feature-implementation-plan.md plus the implementation decision log (8 full + 1 trivial decision) and iteration history, and a discovery-notes inventory. Key outcomes: 6-phase copy-first/delete-last sequencing with a hard pre-delete grep gate; the exact 6-plugin direct-dependency edge list (confirming D5 from scratch); editor invocation-contract change (rename + drop rule-path arg); the Codex surface is EXTENDED not built (RECON-1), with zero Codex dependency/description edits; version bumps listed but deferred to release (han-core a MAJOR candidate); a grep-driven docs sweep including the 'agents live in han-core' exception; manual verification (static grep/diff + one light smoke, no CI). 3 YAGNI deferrals. Open items OI-2 and the semver call are both non-blocking.
…(Phase 1) Stand up the new han-communication plugin additively — the suite still runs on the existing vendored copies until later phases rewire and delete them. - Both manifests: .claude-plugin/plugin.json (no dependencies) and .codex-plugin/plugin.json mirroring han-core's Codex schema - Co-located canonical references/readability-rule.md + writing-voice.md - readability-editor agent and edit-for-readability skill (byte copies) - New inline readability-guidance skill (no context: fork) that surfaces the standard into the caller's context - han-communication entries added to both marketplaces Refs feature-implementation-plan.md D-4, D-7, T1.
…e 2) Add the han-communication dependency edge to the six declaring Claude manifests before any consumer rewire, so the capability resolves by qualified name once Phase 3 lands. - han-core gains its first-ever dependencies key (["han-communication"]) - han-coding, han-github, han-reporting prepend han-communication - han meta and han-atlassian prepend han-communication - Update dependency-narrating descriptions for han, han-coding, han-atlassian in both plugin.json and the marketplace.json mirror - han-planning, han-linear, han-feedback, han-plugin-builder untouched - Zero Codex edits (schema has no dependencies field) Refs feature-implementation-plan.md D-1, D-4.
…s-plugin (Phase 3) All 13 consumer skills now source the shared readability standard by invoking han-communication:readability-guidance at their drafting point instead of reading a vendored ../../references/readability-rule.md file. - 9 synthesis skills: editor dispatch renamed han-core -> han-communication and the now-unresolvable rule-path argument dropped (the editor reads its own co-located canonical rule); gap-analysis's size-conditional skip preserved - 4 draft-and-self-check skills (runbook, issue-triage, ADR, html-summary): gain the guidance invocation, dispatch no editor - edit-for-readability (han-communication copy): editor rename + rule-path drop - self-check lead-ins repointed to the in-context standard; the six criteria blocks are unchanged - 6 secondary template/reference files repointed off the dead rule path Refs feature-implementation-plan.md D-3.
…s (Phase 4) With every consumer rewired and the pre-delete grep gate clean, remove the duplicated readability capability so han-communication owns the only copy. - 6 vendored references deleted (han-coding, han-github, han-reporting x readability-rule.md + writing-voice.md) - 4 han-core originals deleted (readability-editor agent, edit-for-readability skill, readability-rule.md, writing-voice.md) - find now returns exactly one copy of each reference file - no han-core:readability-editor / han-core:edit-for-readability name survives in plugin source Refs feature-implementation-plan.md D-2.
…ove (Phase 5) Repoint every doc, index, and dependency narration at the new han-communication home and reframe the invariants the move inverts. - Move long-form docs: readability-editor -> docs/agents/han-communication/, edit-for-readability -> docs/skills/han-communication/; fix their sibling links - New readability-guidance long-form doc, with the api_retry residual-risk troubleshooting note - Skills index gains a foundational han-communication section (readability-guidance + edit-for-readability); agents index entry repointed - Reframe "all agents live in han-core" to name the han-communication exception (CLAUDE.md, CONTRIBUTING.md); record han-core's first-ever dependency - Replace the vendoring instruction with cross-plugin sourcing via readability-guidance (CONTRIBUTING.md, docs/readability.md) - Repoint canonical readability-rule.md / writing-voice.md pointers, dependency narration (README, choosing-a-han-plugin, extend-han how-to), and the han-atlassian Codex co-requisite; add han-communication to both install lists - Repoint live .claude/ maintenance skills and the PR template at the new writing-voice.md location - CHANGELOG Unreleased entry records the extraction; history left untouched Refs feature-implementation-plan.md D-6, D-7, D-9.
The lint workflow added in #120 surfaced three pre-existing failures. This commit fixes the two shellcheck findings and the broken symlink. - init-guidance.sh: the first sed expression matches the literal text "${CLAUDE_PLUGIN_ROOT}" as it appears in the vendored SKILL.md, so the single quotes are required and SC2016 is a false positive. Disable the check at that call with a comment explaining why. - upload-screenshots.sh: verify_on's retry loop never reads its counter, so SC2034 fired on it. Use the conventional throwaway `_` instead. - .claude/rules/plugin-entity-taxonomy.md: the symlink still pointed at docs/guidance/, which ad6ee13 moved to han-plugin-builder/skills/guidance/references/. That commit rewrote the adjacent .claude/rules/ text references but could not catch a symlink target. Repoint it at the file's current home.
The lint workflow added in #120 runs Prettier over all files, but the repo had never been formatted with it, so the hook rewrote 279 files and failed the job. This commit lands that formatting so the hook is a no-op. Formatting only: prose is rewrapped to the 120-column width set in .prettierrc.json, emphasis markers are normalized, and table cells are padded. No prose was changed. The one non-whitespace change is in han-coding/skills/coding-standard/SKILL.md, where an ordered list was misnumbered 1, 2, 4, 5; Prettier owns ordered-list numbering per .pre-commit-config.yaml and renumbered it to 1, 2, 3, 4.
# Conflicts: # han-atlassian/.claude-plugin/plugin.json # han-coding/.claude-plugin/plugin.json # han-github/.claude-plugin/plugin.json # han-plugin-builder/skills/guidance/scripts/init-guidance.sh # han-reporting/.claude-plugin/plugin.json # han/.claude-plugin/plugin.json
…d consolidating guidance (#114) 140+ files, and +4K/-1K ... 😭 this may be the cause of a Han v5 release. still a WIP though. needs a lot of testing and fine tuning first. that said ... --- ## Summary **This PR extracts Han's readability standard into a new foundational `han-communication` plugin that every prose-producing plugin depends on, so the writing rule and voice profile live in one canonical place instead of being copy-pasted into each plugin.** ## Behavior changes The readability standard now has a single owner. Before this branch, `readability-rule.md` and `writing-voice.md` were vendored into `han-core`, `han-github`, and `han-reporting`. "Vendored" means the same files were duplicated on disk. Editing the standard meant editing several copies and hoping they stayed in sync. Now the two files live only in `han-communication/references/`, the duplicates are deleted, and there is one source of truth. Consuming skills reach the standard through a new inline skill, `han-communication:readability-guidance`. "Inline" means it runs in the calling skill's own context rather than in a separate agent. It reads the two canonical reference files and hands control straight back, so the standard stays loaded while the caller drafts and self-checks. Rewired skills (`code-review`, `research`, `update-pr-description`, `stakeholder-summary`, and others) now invoke that skill instead of reading a vendored copy. The `readability-editor` agent and the `edit-for-readability` skill also moved into `han-communication`. The adversarial rewrite pass they perform is unchanged. For anyone installing the suite, `han-communication` is a new dependency edge beneath everything. The `han` meta-plugin now bundles it, and `han-core`, `han-coding`, `han-github`, `han-reporting`, and the opt-in `han-atlassian` each declare a direct dependency on it. This is `han-core`'s first-ever dependency. Installing any prose-producing plugin now pulls in `han-communication` automatically. ## What to look at first 1. Start with `han-communication/skills/readability-guidance/SKILL.md`. It holds the new inline skill and the mechanism the whole PR turns on. Confirm that the "runs in the caller's context, does not produce a deliverable" contract reads clearly, since every consumer now depends on that behavior. 2. Check the dependency edges in the `plugin.json` manifests and `.claude-plugin/marketplace.json`. Verify that the new `han-communication` dependency is declared on each prose-producing plugin and that the meta-plugin bundles it, so no consumer sources the standard without depending on its owner. 3. Read one or two rewired consumer `SKILL.md` files, for example `han-core/skills/research/SKILL.md` and `han-github/skills/update-pr-description/SKILL.md`. Check that the cross-plugin invocation replaces the old vendored read cleanly and that nothing still points at a deleted copy. 4. Compare the Phase 4 deletions (`git show 563efec --stat`) against the Phase 3 rewiring. Confirm that every vendored copy that was removed had its consumers repointed first, so no skill is left reading a file that no longer exists.
Tier 6. Rewrite docs/choosing-a-han-plugin.md as the scent-and-link plugin index (D4): each plugin gets a one-line scent and a link to its README, with the per-skill deep-links and restated full purposes removed so the plugin READMEs and skills index stay canonical. Label the doc as the plugin index and cross-link the workflows page; keep the install-decision table and dependency explanation.
Tier 7. Point every active reader-facing description and cross-reference at the new in-plugin locations (D9): the root README, CLAUDE.md project map and conventions, CONTRIBUTING.md contributor flow, all how-to guides, the standalone docs pages (concepts, evidence, quickstart, sizing, yagni, readability, why-solo-and-small-teams), the PR template blob URL and checklist (D-6), and the han-update-documentation maintenance tooling (SKILL.md, audit-checklist, scope-mapping). Add the workflows inbound links from the root README and both indexes (D-8). CHANGELOG.md and the frozen docs/plans and docs/research archives are left unchanged (D-5, D10).
## What this is A feature specification (not an implementation) for the plugin-centric documentation reorganization requested in #115, produced with `/plan-a-feature`. It plans moving the docs to a plugin-first layout without breaking the "one canonical source per concept" convention. Targets `han-v5.0.0-alpha-1`, per the request. ## The plan, in one paragraph Every plugin gets its own light README front door (what/how/why + scent-line links, bundled-vs-opt-in status, and dependencies). Each skill and agent long-form doc moves out of the repository-root `docs/` folder and into the plugin it describes, at `{plugin}/docs/skills/{name}.md` and `{plugin}/docs/agents/{name}.md`. The skills and agents indexes stay but shrink to alphabetized scent-and-link lists. `docs/choosing-a-han-plugin.md` becomes the plugin index (and keeps its install-decision role). A new `docs/workflows.md` carries the composition scenarios plus mermaid flow diagrams that render on GitHub with no build step. A rendered docs site (mkdocs/sphinx/readthedocs) is deferred under YAGNI. ## Key decisions settled with the maintainer - Long-form docs live **inside each plugin** (`{plugin}/docs/...`), not a central folder. - Per-plugin READMEs are **light front doors** (scent + link), so they don't duplicate the long-form docs. - The **plugin index folds into `choosing-a-han-plugin.md`** rather than a new file. - Composition scenarios + **mermaid diagrams go to a new `docs/workflows.md`**; the rendered site is deferred. ## Review Three specialists reviewed the draft (`information-architect`, `junior-developer`, `gap-analyzer`); 16 major + 2 minor findings were resolved by evidence. The most consequential adjustments: - **Scope was widened** from ~9 files to the full active blast radius (~37 files), plus relative-link recomputation inside moved docs and a repository-wide link-integrity acceptance gate. - **The plugin README is declared canonical for plugin purpose**, and the catalog slims to a plugin index, so the dedup goal isn't defeated at the plugin tier. - **The plugin-README standard and template** (which currently mandate the heavy per-skill blocks) and the **stale `han/README.md`** and **zero-skill meta-plugin edge case** were brought into scope. - The shared-agent dispatch note was corrected (the `readability-editor` lives in `han-communication`, not `han-core`). A project-manager synthesis pass reconciled all cross-references, and a readability pass rewrote the spec prose. ## Files - `docs/plans/plugin-centric-docs-reorg/feature-specification.md` — the behavioral spec - `docs/plans/plugin-centric-docs-reorg/artifacts/decision-log.md` — 18 decisions (D1–D18) - `docs/plans/plugin-centric-docs-reorg/artifacts/team-findings.md` — 18 findings and resolutions - `docs/plans/plugin-centric-docs-reorg/artifacts/feature-technical-notes.md` — T1 (GitHub mermaid rendering) ## Open item - **OI-1** (non-blocking): whether `han-core`'s README keeps by-purpose grouping or goes flat. A default is recorded. Closes #115 once the plan is implemented.
…nning in the plugin description
…test-plan.md exists
## What this adds A new `han-coding` skill, `/manual-test-planning`, that produces a plain-language manual test plan from whatever context is supplied to the call: an executive summary, a high-level list of named tests, and a detail section per test with the by-hand steps to follow and the outcomes to expect. ## Behavior - A test verifies a single outcome, or a group of related outcomes only when the exact same steps produce every outcome in the group. - The whole document is plain language with short, concise sentences and no technical detail, written for a person who may not be technical. - Every test detail section includes expected outcomes. - When nothing in the supplied context can be manually tested, the skill says so and asks for additional context; with none, its only output is that statement and no document is written. - The finished document gets the standard readability pass: `han-communication:readability-guidance` before drafting, a `readability-editor` rewrite, and the readability self-check. ## Files - `han-coding/skills/manual-test-planning/SKILL.md` — the skill definition - `han-coding/skills/manual-test-planning/references/template.md` — the document template - `han-coding/docs/skills/manual-test-planning.md` — the long-form operator doc - Two-way disambiguation added to `test-planning`'s description, plus scent-line and index updates in `han-coding/README.md`, `docs/skills/README.md`, `han-coding/.claude-plugin/plugin.json`, and `CLAUDE.md` No version bump; versions are left for the release process.
…tance criteria Work items now open with a plain-language summary, then the acceptance criteria that define done. All remaining detail is written in support of a named criterion, test expectations fold into the criteria (no separate Tests block), and technical detail stays at intention-and-touch-points altitude because prescribed edit lists go stale before the work is picked up.
…ve disclosure The plan template is now the reader's layer: a plain-language opening and Outcome first, an intention-level approach naming touch points instead of edits, work units in outcome terms, then lazily created specialist sections. The team-composition table and statistics summary are gone from the plan (they live in the companion artifacts, linked from a closing Sources and Plan Records section), the four-table RAID log collapses to Risks and Assumptions, and the template carries the why: non-authors must be able to read the plan, and prescribed edit lists go stale before the work is picked up.
…ork items The GitHub, Jira, and Linear ticket formats now mirror the reshaped work-item body: Summary, then Acceptance criteria (carrying test expectations), then Supporting detail at intention altitude. No script depends on the removed Description and Tests blocks.
Criteria-immediately-after-summary is the drafting discipline (so all detail is written in support of the criteria), not the rendered order. The output places acceptance criteria at the end of the work item, immediately before Depends on, across the work-item, GitHub, Jira, and Linear templates.
- Summary is three to five very short plain sentences with no technical detail and no ID references; inline 'See plan: D-N' breadcrumbs are replaced by a Plan decisions block in References, each ID paired with a one-sentence description of what it is. - 'Supporting detail' becomes 'Work to be done': plain-language bullets with technical detail nested beneath the bullet it supports. - Acceptance criteria exclude standard operating procedure (commit pushed, CI green) and unexplained prohibitions; a prohibition must carry its validated reason.
…tems Mirrors the plan-work-items template changes: plain-sentence summary without inline plan references, a Work to be done list with nested technical detail, a Plan decisions References bullet (ID plus a one-sentence description), and acceptance criteria that exclude standard operating procedure and unexplained prohibitions.
…ge work items Same changes as the plan-work-items and issue templates: plain-sentence summary, Work to be done list with nested technical detail, Plan decisions References bullets, and acceptance criteria that exclude standard operating procedure and unexplained prohibitions.
… work items Same changes as the other work-item surfaces: plain-sentence summary, Work to be done list with nested technical detail, Plan decisions References bullets, and acceptance criteria that exclude standard operating procedure and unexplained prohibitions.
…user stories - New operating principle: every plan section leads with plain-language prose, and technical detail is minimal references only, placed below the plain language it illustrates. When in doubt, prefer more plain language over more technical detail. - The plan template gains a User Stories section (US-N IDs, derived only from behavior the spec commits to) and a Story column in the Work Units table so each unit names the story it advances. Stories frame the operator or consuming system when there is no end-user surface, and the section is omitted only when no actor benefits in a describable way.
## Summary **This PR restructures planning and ticket artifacts into a summary-first, acceptance-criteria-driven shape, so work items and implementation plans read top-down and stop prescribing edit lists that go stale as the codebase moves.** ## Behavior changes The central change replaces `Description` and `Tests` in every work item and ticket with `Supporting detail` plus acceptance criteria that carry the test expectations as observable outcomes. Work items are now drafted summary-first and criteria-second, so every block of supporting detail backs a specific criterion and detail that backs none is cut. In the rendered output, a plain-language summary opens the item and the acceptance criteria sit at the bottom, just before `Depends on`. The `plan-work-items` and `plan-implementation` skills also shift to an "intention over prescription" altitude: an item names the goal and its touch points, such as a file path, a contract, or a boundary, but never enumerates line-level edits. Plans and tickets are often executed after the code has moved, and a prescribed edit list would mislead whoever picks up the work. The `feature-implementation-plan` template is reordered for progressive disclosure (plain-language opening, then intention-level sections, then deeper records) and drops its inline team-composition table and statistics summary, which now live one hop away in the companion artifacts. Three sections are renamed to match: `RAID Log` splits into a lazy `Risks and Assumptions` section plus `Open Items`, `Decomposition and Sequencing` becomes `Work Units and Sequencing`, and `Source Specification` becomes a closing `Sources and Plan Records` section. The downstream ticket templates in `han-github` (GitHub issues), `han-atlassian` (Jira), and `han-linear` (Linear) are updated to match the new work-item field shape, keeping published tickets consistent with the source `work-items.md`.
…standard Add the scoped escape clause to readability-rule.md: break a rule when following it would make the prose read worse, yielding to both hard gates (the vocabulary blocklist and fidelity). Add a stale-figures principle to the writing-voice blocklist with the load-bearing-versus- decorative dividing line and the signature-analogy carve-out, plus the foreign, Latinate, and archaic diction category. Carry both into the readability-editor agent as a governing principle and a criterion-5 amendment, keeping the rubric at six criteria. Implements docs/plans/orwell-six-rules/feature-implementation-plan.md (D-1 through D-4); verified per D-5 (manual dry run), D-6 (guidance review), and D-7 (scoped doc-consistency check).
…#140) ## Summary **This PR teaches Han's shared writing standard to catch stale figures of speech and clumsy stock phrasing, and to break its own rules when following them would read worse, so that every skill's prose output stays vivid without turning wooden.** ## Behavior changes Every Han skill that produces prose reads its writing rules live from two shared files in `han-communication`. `readability-rule.md` holds the drafting-and-rewrite standard, and `writing-voice.md` holds the voice profile with its blocklist. This PR edits those two files, so the change reaches every consuming skill at once without touching any skill itself. The one exception is the `readability-editor` agent: it runs a hardcoded rubric instead of reading those files, so this PR weaves the same rules into its rubric directly. Two things change for anyone whose prose runs through the standard. First, the voice profile now flags three kinds of tired language: worn-out figures of speech, foreign or Latinate stock phrases like "in lieu of" and "per se", and archaic formal words like "aforementioned" and "herein". The figures-of-speech rule draws a line between decorative clichés (out) and load-bearing physical-world analogies (kept), so Han's own signature style stays legal. Second, the standard gains an explicit escape clause: when following a drafting rule would produce clumsy prose, break the rule. That clause yields to the two hard gates it cannot override, so it never licenses a blocklisted word or a loss of fidelity to the source meaning. The rest of the branch is the paper trail behind those edits: a research report comparing Orwell's six rules of writing against the existing standard, plus the planning artifacts that turned the report's findings into the four targeted edits. The six-point self-check and the editor agent's six rubric criteria are unchanged, so every count claim across the docs stays accurate.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
This PR bundles the v5.0.0 alpha changes to the Han plugin suite into one branch: install it to try the new communication plugin, the manual test-planning skill, and the reorganized documentation together.
Behavior changes
Install this branch to try the changes below, listed from most to least visible.
han-communication, now owns the suite's single readability standard and writing voice, plus thereadability-guidanceandedit-for-readabilityskills and thereadability-editoragent. Install it alongside the other plugins.han-codingskill,manual-test-planning, creates a plain-language manual test plan that a human can follow by hand. It includes an executive summary, named tests, and steps with expected outcomes.test-planningskill is renamed toautomated-test-planning. Use that name when you want a plan aimed at automated tests.README.md.docs/tree.docs/workflows.mdmap shows which skills chain together.docs/choosing-a-han-plugin.mdis now the plugin index and install guide.hanmeta-plugin now pulls inhan-communicationfor you, so installinghangets the readability layer automatically.han-plugin-buildercovering Sonnet 5, Opus 4.8, and Fable 5.