NAI OS

/nai-issue-to-agent — bridging nai-analysis into the agent systems

Feeds one nai-analysis issue to /nai-option-study or /nai-review, then posts the write-up back as a comment. A bridge over the pattern, not one more copy of it.

You type /nai-issue-to-agent <issue-id-or-url> <option-study|review-pack>. The orchestrator resolves the UUID, runs scripts/issue-bridge/fetch-issue.mjs to pull that one issue out of nai-analysis’s Supabase project and write it as that agent's normal input file, then dispatches /nai-option-study or /nai-review — unmodified, exactly as if you had typed it by hand. Once the deliverable exists, it stops and shows you what would be posted, then waits for your explicit confirmation before running post-comment.mjs to insert the write-up back onto the issue as one comment, authored as the issue's owner.

What makes this one different from the other systems: it has no subagents of its own. Wave 2 is an entire other system, run exactly as if invoked directly — the bridge contributes only the two narrow steps on either side of it. That is a genuine structural wrinkle in “one pattern, repeated across every system”: this is that pattern, once, with a fetch and a post grafted onto its front and back.

%%{init: {'theme':'neutral', 'flowchart':{'htmlLabels':false,'nodeSpacing':45,'rankSpacing':55}}}%%
flowchart TD
    H["Human types<br/>/nai-issue-to-agent <id> <agent>"] --> C

    subgraph L1 ["1 - Orchestrator (.claude/commands)"]
        C["/nai-issue-to-agent<br/>resolves the UUID,<br/>stops before the irreversible step"]
    end

    C -->|"step 1"| F["fetch-issue.mjs"]
    F -.->|"OK <slug> or MISSING / ERROR"| C
    C -->|"step 2: dispatch,<br/>unmodified"| SYS["/nai-option-study or /nai-review<br/>the whole system, run as-is"]
    SYS -.->|"deliverable + cockpit"| C

    C --> STOP{"STOP — human<br/>confirms explicitly"}
    STOP -->|"confirmed"| P["post-comment.mjs"]
    STOP -.->|"silence / no"| END1["nothing posted"]
    P -.->|"OK"| C
    C ==> OUT["one issue_comments row<br/>you decide what happens next"]

    F --> T1
    P --> T1
    subgraph L3 ["3 - Tools (the only route out)"]
        T1["fetch-issue.mjs / post-comment.mjs<br/>one issue id in, one row out — no scan, no edit"]
    end

    classDef orch fill:#dcefe9,stroke:#0f6f63,stroke-width:2px
    classDef tool fill:#f4f1ea,stroke:#8a7a5a
    classDef human fill:#fdf3e0,stroke:#8a5a00,stroke-width:2px
    class C orch
    class T1 tool
    class H,OUT,STOP,END1 human
A fetch, a full agent system run untouched, a hard STOP, then a post. The STOP exists because issue_comments has no update/delete policy — once posted, the comment cannot be edited or removed through the app, so the human confirms before the one irreversible step, not after.

The boundary here is scope, not capability. fetch-issue.mjs and post-comment.mjs (scripts/issue-bridge/) hold a Supabase service-role key, which normally means broad access — but each script only ever touches the one issue id passed as its argument: no list/scan query, and the only write either script performs is a single insert into issue_comments. Neither script edits an issue's content or status. The orchestrator never edits issue content, changes status, or sends/deletes anything beyond that one comment either — the trade-off decision and all further stakeholder communication stay the human's, same as every other system on this page.

Next/nai-issue-check →