" --label "<type>,<AFK|HITL>,size:<X>,area:<..>" --assignee @me --body "$(cat <<'EOF' <body per GITHUB_ISSUE_TEMPLATE> EOF )" ``` ## Step 7: Write back to the board For each created issue, `Edit` `.mpx/BOARD.md` to **move** its item from `# To Process` to `# Ready to implement` and append ` → #<N>` (the issue number) to the item text. **Leave the checkbox marker as `- [ ]` — never write `- [x]` or `- [/]`; the checkbox is the user's alone.** The `→ #<N>` annotation is what `mp-batch-execute` uses to close the loop. (`.mpx/BOARD.md` is a symlink — if Edit/Write refuses it, resolve to the real vault path and edit that; see BOARD_CONVENTION.) Verify that every created issue's item appears exactly once in `# Ready to implement`, has its matching annotation, and no longer appears in intake. ## Step 8: Offer to resolve HITL If any HITL issues were created, offer to resolve them now by running `/mp-hitl` (grill the open questions → flip `HITL`→`AFK`), which makes them batch-executable. ## Report List: created issues (number, title, labels, size), merged bullets, skipped duplicates (with the existing issue number), and any HITL issues awaiting resolution.

# Mp Board To Issues > Converts Obsidian board notes from the To Process lane into labelled GitHub issues, deduping against existing ones. - Skill: `martinopolo/mp-board-to-issues` (Agent Skill) - Install (CLI): `npx skillmds@latest add martinopolo/mp-board-to-issues` - Raw SKILL.md: https://api.skillmd.com/api/skills/martinopolo/mp-board-to-issues/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: MartinoPolo (https://skillmd.com/u/martinopolo) - Updated: 2026-09-10 - Page: https://skillmd.com/skills/martinopolo/mp-board-to-issues --- # mp-board-to-issues Turn board notes into well-formed GitHub issues. $ARGUMENTS First: 1. Resolve `MPX_SKILLS_DIR` and read `/mp/skills/shared/BOARD_CONVENTION.md` now — board format, content→type classification, and the four-lane pipeline (state lives in the lane, not the checkbox). 2. Read `/gh/skills/shared/GITHUB_ISSUE_TEMPLATE.md` now — issue bodies and labels follow it. ## Rules - Conversion is **not** blindly 1:1 — merge related bullets into one issue, and skip notes that duplicate an existing open issue. - Classify HITL only for genuine **unanswered requirement questions**. Visual inspection, manual testing, and QA are not HITL reasons. ## Step 1: Read the board Read `.mpx/BOARD.md`. Fresh notes live under the single `# To Process` intake lane — there is no section argument. Any `$ARGUMENTS` is optional free-text guidance (e.g. "only the login bug"), not a section selector. ## Step 2: Collect items Collect each `- [ ]` bullet under `# To Process`; skip any that already carry a `→ #` annotation (already has an issue), and ignore everything under the downstream lanes (`# Ready to implement`, `# Manual testing`, `# Archive`). Do **not** interpret the checkbox as state — it is the user's manual-verification flag, not a processing marker. For each item, capture its text (including continuation lines) and every `![[...]]` image wikilink, and **read each image** at `.mpx/board-files/` so the visual context informs the issue. ## Step 3: Merge + dedup Group bullets that describe the same fix into a single proposed issue. Check for duplicates against existing issues with `gh issue list --state open --search ""` (and `gh search issues` when useful); mark likely duplicates to skip, noting the existing issue number. ## Step 4: Draft each issue For each proposed issue: - **Body** — follow the GITHUB_ISSUE_TEMPLATE structure (`## Description`, `## Requirements` as REQ-1..N, `## Acceptance Criteria`, `## Notes`). Reference the screenshots in `## Notes`. - **Size** — estimate `size:S` (single file / few lines), `size:M` (multi-file, contained), or `size:L` (cross-cutting) from complexity. - **AFK vs HITL** — AFK when scope is clear; HITL when a requirement question is unanswered (add the `> **Unanswered questions:**` blockquote). - **Type** — infer from the note's content (per BOARD_CONVENTION): a defect → `bug`, a chore/audit/refactor → `task`, a new capability or improvement → `enhancement`. The note's position on the board carries no type information. - **Labels** — the inferred type + exactly one of `AFK`/`HITL` + `size:` + inferred `area:*`. ## Step 5: Confirm before creating Present the full plan with `AskUserQuestion`: each board bullet → proposed issue(s), labels, size, AFK/HITL, and any duplicates being skipped. Only create issues after the user confirms the plan (they may edit it). **Gate:** Continue only when the user has confirmed or amended the full mapping, including every skip. ## Step 6: Create issues Create each confirmed issue: ```bash gh issue create --title "" --label "<type>,<AFK|HITL>,size:<X>,area:<..>" --assignee @me --body "$(cat <<'EOF' <body per GITHUB_ISSUE_TEMPLATE> EOF )" ``` ## Step 7: Write back to the board For each created issue, `Edit` `.mpx/BOARD.md` to **move** its item from `# To Process` to `# Ready to implement` and append ` → #<N>` (the issue number) to the item text. **Leave the checkbox marker as `- [ ]` — never write `- [x]` or `- [/]`; the checkbox is the user's alone.** The `→ #<N>` annotation is what `mp-batch-execute` uses to close the loop. (`.mpx/BOARD.md` is a symlink — if Edit/Write refuses it, resolve to the real vault path and edit that; see BOARD_CONVENTION.) Verify that every created issue's item appears exactly once in `# Ready to implement`, has its matching annotation, and no longer appears in intake. ## Step 8: Offer to resolve HITL If any HITL issues were created, offer to resolve them now by running `/mp-hitl` (grill the open questions → flip `HITL`→`AFK`), which makes them batch-executable. ## Report List: created issues (number, title, labels, size), merged bullets, skipped duplicates (with the existing issue number), and any HITL issues awaiting resolution.