work-items-to-issues

Name: work-items-to-issues
Author: testdouble

122stars12forks

How to install work-items-to-issues?

testdouble/han/work-items-to-issues

$npx -y skills add testdouble/han --skill work-items-to-issues

Installs into the current project.

Summary

Break a work-items.md file (produced by /plan-work-items) into independently-grabbable GitHub issues, one per slice, in each slice's target repo. Use when you want to turn a work-items file into GitHub issues, publish work items as issue tickets, or create implementation tickets

Files · 1

View on GitHub

SKILL.md

1	# Work Items to GitHub Issues
2
3	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.
4
5	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.
6
7	## Rules
8
9	- 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.
10	- Native `blocked_by` relationships are within-repo only. A cross-repo `Depends on` is a format error to surface for repair.
11	- Symbolic-ID prefixes: accept whatever the input uses. Both shapes are valid input — single-prefix across repos (e.g., `W-N` for every slice) and per-repo prefixes (e.g., `V2-N` backend, `W-N` frontend, `EV-N` events). The publish scripts accept any uppercase prefix.
12	- Every slice issue body MUST link the reference artifacts an implementer needs — API/event contracts, design frames, schema docs, runbooks, ADRs, coding standards. Issues that consume an HTTP endpoint or event payload MUST link the contract section that defines it.
13	- UI slices, when the plan folder has a `ui-designs/` subfolder, MUST embed the relevant screenshots inline using same-target-repo raw URLs. See [references/screenshot-embed-rules.md](./references/screenshot-embed-rules.md).
14	- NEVER include process artifacts in issue bodies or the work-items preamble. Excluded categories — iteration histories, decision logs, review findings, team findings, facilitation summaries, gap analyses, and anything under an `artifacts/` subfolder of the plan that is not a contract or design reference. Full include/exclude list in [references/reference-artifact-inventory.md](./references/reference-artifact-inventory.md).
15
16	## Process
17
18	### 1. Locate the work-items file
19
20	If the path is not provided, ask for it. The input is a single `work-items.md` produced by `/plan-work-items`. Read it.
21
22	If the user named a target repo (or repos), a label, or an assignee, note them for Steps 2 and 6. By default, issues are created with no label and no assignee — only apply a label or assignee when the user explicitly asked for one.
23
24	### 2. Build the SYM→repo map
25
26	Determine which repo each slice belongs to. Use both signals and reconcile them:
27
28	- Primary — cross-repo work order prose. Most `work-items.md` files include an intro paragraph naming which SYMs ship to which repo (e.g., "W-1 through W-4 ship to `acme-api`. W-5 through W-9 ship to `acme-web`."). Parse this for the mapping.
29	- Corroborating — file paths inside each slice. Each slice's `Description.` and `References.` blocks reference files in the target repo. Path roots map cleanly: `acme-api/...` → `acme/acme-api`, `acme-web/...` → `acme/acme-web`, `acme-events/...` → `acme/acme-events`. Use this to verify the prose and to assign any slice the prose doesn't cover.
30
31	If the prose and the file-path evidence disagree for a slice, surface the conflict to the user before proceeding.
32
33	### 3. Validate the format with evidence-based repair
34
35	Check the work-items file against the format invariants in [references/issue-template.md](./references/issue-template.md) and [references/work-items-file-format.md](./references/work-items-file-format.md):
36
37	- Heading shape. Every slice heading matches `## <SYM-N> — <title>` with an em-dash separator (already-published headings annotated as `## <SYM-N> (#NNN) — <title>` are valid too).
38	- `Depends on` line. Literal bold marker `Depends on.`, trailing period, `None.` or comma-separated SYMs.
39	- Within-repo blockers. Every SYM named in a `Depends on` line maps to the same target repo as the dependent slice (under the map from Step 2).
40	- Screenshot URLs. When present, match `https://github.com/<org>/<target-repo>/raw/<branch>/.github/issue-assets/<feature-slug>/<SYM-N>/<file>.png` against the target repo's default branch and a real PNG file under `<plan-folder>/ui-designs/`. `<feature-slug>` is the kebab-cased bas

People who liked this also viewed

6 picks

Type

work-items-to-issues

122stars12forks

View on GitHub

How to install work-items-to-issues?

testdouble/han/work-items-to-issues

$npx -y skills add testdouble/han --skill work-items-to-issues

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Work Items to GitHub Issues
2
3	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.
4
5	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.
6
7	## Rules
8
9	- 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.
10	- Native `blocked_by` relationships are within-repo only. A cross-repo `Depends on` is a format error to surface for repair.
11	- Symbolic-ID prefixes: accept whatever the input uses. Both shapes are valid input — single-prefix across repos (e.g., `W-N` for every slice) and per-repo prefixes (e.g., `V2-N` backend, `W-N` frontend, `EV-N` events). The publish scripts accept any uppercase prefix.
12	- Every slice issue body MUST link the reference artifacts an implementer needs — API/event contracts, design frames, schema docs, runbooks, ADRs, coding standards. Issues that consume an HTTP endpoint or event payload MUST link the contract section that defines it.
13	- UI slices, when the plan folder has a `ui-designs/` subfolder, MUST embed the relevant screenshots inline using same-target-repo raw URLs. See [references/screenshot-embed-rules.md](./references/screenshot-embed-rules.md).
14	- NEVER include process artifacts in issue bodies or the work-items preamble. Excluded categories — iteration histories, decision logs, review findings, team findings, facilitation summaries, gap analyses, and anything under an `artifacts/` subfolder of the plan that is not a contract or design reference. Full include/exclude list in [references/reference-artifact-inventory.md](./references/reference-artifact-inventory.md).
15
16	## Process
17
18	### 1. Locate the work-items file
19
20	If the path is not provided, ask for it. The input is a single `work-items.md` produced by `/plan-work-items`. Read it.
21
22	If the user named a target repo (or repos), a label, or an assignee, note them for Steps 2 and 6. By default, issues are created with no label and no assignee — only apply a label or assignee when the user explicitly asked for one.
23
24	### 2. Build the SYM→repo map
25
26	Determine which repo each slice belongs to. Use both signals and reconcile them:
27
28	- Primary — cross-repo work order prose. Most `work-items.md` files include an intro paragraph naming which SYMs ship to which repo (e.g., "W-1 through W-4 ship to `acme-api`. W-5 through W-9 ship to `acme-web`."). Parse this for the mapping.
29	- Corroborating — file paths inside each slice. Each slice's `Description.` and `References.` blocks reference files in the target repo. Path roots map cleanly: `acme-api/...` → `acme/acme-api`, `acme-web/...` → `acme/acme-web`, `acme-events/...` → `acme/acme-events`. Use this to verify the prose and to assign any slice the prose doesn't cover.
30
31	If the prose and the file-path evidence disagree for a slice, surface the conflict to the user before proceeding.
32
33	### 3. Validate the format with evidence-based repair
34
35	Check the work-items file against the format invariants in [references/issue-template.md](./references/issue-template.md) and [references/work-items-file-format.md](./references/work-items-file-format.md):
36
37	- Heading shape. Every slice heading matches `## <SYM-N> — <title>` with an em-dash separator (already-published headings annotated as `## <SYM-N> (#NNN) — <title>` are valid too).
38	- `Depends on` line. Literal bold marker `Depends on.`, trailing period, `None.` or comma-separated SYMs.
39	- Within-repo blockers. Every SYM named in a `Depends on` line maps to the same target repo as the dependent slice (under the map from Step 2).
40	- Screenshot URLs. When present, match `https://github.com/<org>/<target-repo>/raw/<branch>/.github/issue-assets/<feature-slug>/<SYM-N>/<file>.png` against the target repo's default branch and a real PNG file under `<plan-folder>/ui-designs/`. `<feature-slug>` is the kebab-cased bas

People who liked this also viewed

6 picks

Type