work-items-to-issues

## 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](../../references/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. # Work Items to GitHub Issues Take an already-broken-down `work-items.md` file (produced by `/plan-work-items`) and publish each slice as a GitHub issue in its target repo. The breakdown work — drafting slices, assigning symbolic IDs, specifying dependencies, inventorying references — has already been done upstream. This skill's job is to map each slice to its target repo, validate the format, write a per-repo work-items file alongside the source, and run the publish pipeline. ## Rules - Each slice lives in exactly one repo. Cross-repo coordination is documented in prose at the top of `work-items.md` — never as a native blocker link. - Native `blocked_by` relationships are **within-repo only**. A cross-repo `Depends on` is a format error to surface for repair. - Symbolic-ID prefixes: accept whatever the input ...