[taminomara]

Summary

This PR moves every skill's .han/config.md loading into one shared han-core:load-han-config skill, so that a chained run loads the config once and a change to config lookup edits one script instead of forty-odd skills.

Behavior changes

Each skill now reads its configuration by invoking han-core:load-han-config once per run. Before this PR, each skill had its own ~10-line config block. When one skill called another, such as plan-a-feature calling readability-guidance, a single context ended up with several copies of the config and several copies of the "go read it" instruction. A skill that has already loaded the config in this run skips the call.

The new skill is a single context-injection probe, meaning a shell command whose output is pasted into the prompt when the skill loads. The probe runs han-core/scripts/load-han-config.sh. That script prints the project and personal config files between BEGIN/END markers and then prints the config rule (the doc that says how to apply them). If the script fails, a guard swaps in a one-line "no configuration applies" message and the run continues.

To make this work, every plugin now depends on han-core. That adds five new dependency edges: han-communication, han-feedback, han-linear, han-plugin-builder, and han-reporting. han-communication used to depend on nothing. Codex resolves no plugin dependencies, so a Codex install now needs han-core installed beside each plugin. The twelve vendored copies of config-rule.md and the per-plugin han-config-dir.sh resolver are deleted, and the one remaining copy of the rule now starts at its schema. No plugin versions are bumped; the release does that.

What to look at first

• The han-core dependency on every plugin. This is the one choice the maintainer may decline. It ends han-communication's "depends on nothing" status and changes Codex installs. Check the five plugin.json edges, then the updated install wording in the repo map and the plugin index page.
• The guidance correction in han-plugin-builder (skill-composition.md, troubleshooting.md). The old guidance said a data-fetch sub-skill (a skill called only to fetch a value) was unreliable whether forked or inline. It now limits that warning to the forked form (context: fork). The evidence is two trials: 99 runs, then 48 against the shipped loader, with zero early exits. See docs/plans/gh-203-consolidate-config-loading/artifacts/trial2/trial-report.md.
• The loader script and its tests. han-core/scripts/load-han-config.sh and its Bats tests cover neither file present, each file alone, both files in project-first order, and the personal lookup naming the project file. The same test file guards every shipped skill: each carries the loader line once, pre-approves the Skill tool, and keeps no old config block.
• One rewired consumer, such as han-coding/skills/code-review/SKILL.md. The same pattern repeats across 44 skills. Each one adds Skill to its allowed tools, drops the old probe, and points later config references at the rule the loader prints.

Closes #203.

[mxriverlynn]

@taminomara this is great! been meaning to do this for a while now.

i've updated this PR to target the v6.0.0-beta branch as the merge target, and that opened a lot of merge conflicts. can you update the PR to clear these up with the new target branch? thank you

[taminomara]

Done!