iru-knowledge-to-issue

name	iru-knowledge-to-issue
description	Convert one or more pending/not-completed agreements from the `knowledge/` base (built by `iru-knowledge-process-inbox`) into a GitHub issue. Asks the user which agreement(s) to convert, accepting a pending task id (`<timestamp>-<n>`), a `knowledge/pending/pending-*.md` filename, a `knowledge/agreements/ agreement-*.md` filename/id (with an item number if it has more than one open item), or a plain natural-language description — searching `knowledge/pending` and `knowledge/agreements` by content when given the latter. Once an agreement is resolved, gathers additional context from its meeting's full transcription and attachments (via `knowledge/meetings/meeting-<timestamp>/`) and from the current codebase (via the `iru-explore` skill), then hands the synthesized purpose to the `iru-create-github-issue` skill to draft and file the issue — passing the meeting transcription and attachments along too, either as an actual attachment (small text embedded, large/ binary uploaded as a release asset, per that skill's own logic) or, when the file is already committed and pushed in this repository, as a link to it instead of duplicating its content. Invoke as `/iru-knowledge-to-issue` to be asked which agreement(s) to convert, or `/iru-knowledge-to-issue <id-filename-or-description>` to skip straight to resolving that one. Stops early if `knowledge/` doesn't exist yet (run `iru-knowledge-setup` and `iru-knowledge-process-inbox` first) or if this repository isn't hosted on GitHub. Does not mark the source agreement complete — filing an issue means the work is now tracked, not done; it instead appends the created issue's URL back onto the pending file (and a note on the agreement item) so a re-run doesn't file a duplicate, leaving `iru-knowledge-complete` as the step that later closes it out for real. Use whenever a meeting agreement or action item needs to become actionable GitHub-issue work instead of staying a markdown checkbox nobody triages.
model	sonnet

Knowledge to Issue

Turn a pending or not-yet-completed agreement recorded in knowledge/ into a well-formed GitHub issue — grounded in the meeting that produced it and, where useful, the current codebase — using iru-create-github-issue to actually draft and file it. This skill's own job is resolving which agreement, gathering why it matters, and handing that off; drafting and filing stays iru-create-github-issue's job so the two skills don't drift apart.

Step 1 — Confirm prerequisites

Two things must both hold before doing any real work:

• knowledge/ exists and has content: check for knowledge/pending and knowledge/agreements. If knowledge/ doesn't exist at all, tell the user to run iru-knowledge-setup first, then iru-knowledge-process-inbox to populate it from meeting transcriptions, and stop. If it exists but both knowledge/pending and knowledge/agreements are empty, tell the user there's nothing to convert yet and stop.
• This repository is hosted on GitHub: get the remote URL (git remote get-url origin, falling back to git remote -v or whichever remote the current branch tracks) and check it matches github.com or a GitHub Enterprise Server domain — reuse iru-explore's "Repository host" finding instead of re-detecting if it already ran earlier in this conversation. If the host is something else, or there's no remote at all, tell the user this skill only files GitHub issues (via iru-create-github-issue) and stop — don't guess at another platform's equivalent.

Step 2 — Determine which agreement(s) to convert

If the skill was invoked with an argument, treat it as the identifier (or natural-language description) to resolve in Step 3. Otherwise ask the user, in plain conversational text (this is open-ended, not a fixed choice), which pending or not-completed agreement(s) they want turned into a GitHub issue. Make clear any of these forms works:

• A pending task id (<timestamp>-<n>) or its filename (pending-<timestamp>-<n>.md).
• An agreement file's id/filename (agreement-<timestamp>.md) — plus which item number, if that file has more than one still-open item.
• A plain description of the agreement in their own words (e.g. "the one about adding retry logic to the client").

They may name more than one in the same answer (a list, or "these two: ... and ..."). Process each one through Steps 3-9 below, one at a time, so a problem resolving or filing one doesn't block the others.

Step 3 — Resolve the identifier to a concrete agreement item

For the current identifier:

• Pending task id or filename: look for knowledge/pending/pending-<id>.md directly.
• Agreement id/filename, with an item number: open knowledge/agreements/agreement-<timestamp>.md and locate that numbered item.
• Agreement id/filename, no item number given: open the file; if it has exactly one item that's still unchecked ([ ]), use that one. If it has more than one open item, list them via AskUserQuestion and ask which one they meant.
• Natural-language description: search the content of every file in knowledge/pending and knowledge/agreements for a match (grep-style keyword search, not just filename matching). If exactly one file/item matches clearly, use it. If several plausibly match, present short excerpts of each via AskUserQuestion and ask the user to pick. If none match at all, list the task ids/filenames that do exist (derived from the actual files present, the same fallback iru-knowledge-complete uses) so the user can pick one directly instead of guessing.

Once resolved, read the pending file (if one exists) for its agreement/meeting references, then open the matching numbered item in its knowledge/agreements/agreement-<timestamp>.md file. Record: the task id (if any), the agreement file path and item number, the item's own text verbatim, and the meeting reference (if the pending file states one — see iru-knowledge-process-inbox's Step 9 for the format it writes).

• Item is already checked off ([x]) and no pending file exists for it: this agreement is already marked complete. Tell the user plainly and ask via AskUserQuestion whether they still want an issue filed anyway (e.g. for a regression or follow-up work) or want to skip this one — don't silently file an issue for finished work.
• Pending file already has a - GitHub issue: ... line (see Step 9): an issue was already filed for this agreement in an earlier run. Tell the user and ask via AskUserQuestion whether to open a second issue anyway or skip this one — don't file a silent duplicate.

Step 4 — Gather context: the meeting transcription and attachments

If the resolved item has a meeting reference, read knowledge/meetings/meeting-<timestamp>/meeting.md in full (its Summary and Full transcription sections) and list every other file alongside it in that same meeting directory (attachments carried over by iru-knowledge-process-inbox's Step 6) — Read each one that's readable (text, PDF, image) for context, same as iru-create-github-issue's own file-reading step.

Since one meeting can cover several topics/agreements, pick out specifically the parts of the summary/ transcription that relate to this agreement item — not the whole meeting — as the core "why it matters" and "what was actually decided" material for the issue.

If the resolved item has no meeting reference (e.g. a hand-created pending/agreement file), note that plainly and rely on Step 5 alone for grounding.

Step 5 — Gather context: the codebase

Run Skill({skill: "iru-explore"}) with no ticket argument — there's no GitHub issue yet, so this is a general orientation pass, not one scoped to a ticket. Skip re-running it if general exploration already happened earlier in this same conversation and looks reasonably current.

Using the agreement item's own text (plus whatever Step 4 surfaced) as keywords, search the codebase (grep, or the Explore agent for a broader sweep) for the specific classes/files/modules this agreement would actually touch — the same targeting iru-explore applies when it's given a real ticket, done here by hand since this skill has no ticket to hand it yet. This is what makes the issue's eventual Context/Acceptance-criteria sections concrete instead of vague, and it's reused as-is by iru-create-github-issue's own Step 2 in Step 8 below.

Step 6 — Synthesize and confirm the purpose

Combine the agreement item's own text, Step 4's meeting context, and Step 5's codebase findings into a short purpose statement: what problem this solves or capability it adds, why it matters (grounded in what was actually discussed/decided), and any acceptance criteria the agreement text or meeting discussion implies.

Show this synthesized purpose to the user via AskUserQuestion before handing it off:

• File it as-is (recommended once it reads accurately).
• Let me adjust it first — take their correction and re-synthesize.
• Skip this one — move on to the next identifier from Step 2, if any, without filing anything.

Step 7 — Prepare attachments: link vs. actual attachment

For every file gathered in Step 4 (the meeting's transcription source and its other attachments) plus the resolved pending/agreement markdown files themselves, decide how each should reach the issue:

• Already tracked and pushed (check with git ls-files --error-unmatch <path>, then confirm the commit that added/last-touched it is reachable from the pushed branch, e.g. git log origin/<branch> -- <path> returns a match): prefer a link to the file's stable location in the hosted repository (e.g. https://github.com/<owner>/<repo>/blob/<branch>/<path>) over re-uploading its content — the file already lives durably in the repo and may keep changing there.
• Not tracked, or tracked but only committed locally (not yet pushed): treat it as a local file to actually attach — hand its path to iru-create-github-issue's Step 4 in Step 8 below, which embeds small text files inline and uploads larger/binary ones as a release asset.

Always include the meeting's full transcription file one way or the other — it's normally the single most useful piece of context for whoever picks up the resulting issue.

Step 8 — File the issue via iru-create-github-issue

Run Skill({skill: "iru-create-github-issue", args: "<Step 6's confirmed purpose statement>"}). As its own steps run in this same turn:

• Step 1 (GitHub host): already confirmed in this skill's Step 1 — it should pass through immediately.
• Step 2 (explore): reuses Step 5's exploration from this skill instead of repeating it.
• Step 3 (purpose): answer immediately with Step 6's confirmed purpose statement, already given as the argument; if it still asks a clarifying follow-up, answer from Step 4/5's gathered context rather than bouncing the question back to the user — only actually ask the user if the gathered context genuinely doesn't cover it.
• Step 4 (additional context): supply, as "attached files/documents", every file Step 7 marked for actual attachment (with its local path); supply, as "URLs", every file Step 7 marked as already linkable. Don't fabricate related issues — only mention one if the user names it.
• Steps 5-8 (due date/importance, label, draft, confirm+create): let these proceed on their own terms — due date/importance/label are judgment calls that skill already knows how to make or ask about; don't pre-empt them. If the user declines to create the issue at the draft-confirmation step, treat this identifier as skipped (not an error) and continue to the next one from Step 2, if any.

Capture the created issue's number and URL from that skill's own Step 9 report, if it created one.

Step 9 — Record the issue back into the knowledge base

If Step 8 actually created an issue, append a line noting it — without checking off or otherwise altering anything else:

• To the pending file (if one exists for this item): add - GitHub issue: <url> after its existing Agreement:/ Meeting: lines.
• Near the matching numbered item in its knowledge/agreements/agreement-<timestamp>.md file: add a short trailing note, e.g. 1. [ ] <original text> _(tracked in <url>)_ — leave the checkbox itself unchecked; filing the issue means the work is now tracked elsewhere, not that it's done.

This is what Step 3's duplicate-detection check looks for on a re-run. Do not run iru-knowledge-complete here — that stays a separate, deliberate step for once the work behind the issue is actually finished.

If Step 8 was skipped or declined for this identifier, skip this step for it too — there's nothing to record.

Step 10 — Report

Per identifier processed: which pending/agreement item it resolved to, whether a meeting/attachments and/or codebase context were found and used, the created issue's number and URL (or that filing was skipped/declined, and why), and confirmation that the knowledge base was annotated with the issue link. Remind the user that the agreement itself stays open until they run iru-knowledge-complete once the linked issue's work is actually done.