Make ticket pages open in T3 Code's file viewer, and show plans, mocks and progress inline in the thread

user/agents/skills/ticket/SKILL.md

@@ -25,6 +25,11 @@ Jira has it, the plan with its mocks, live progress, proof beside the mocks, and
 Every epic gets an **epic index** listing its stories in build order. Both render from data
 files that only `ticket-page` writes, and both update themselves as it writes.
 
+Gib works in T3 Code. The page opens in T3's file viewer beside the thread when you link its
+absolute path, so never start a server for it. At two moments, plan approval and hand-off,
+the skill also shows a snapshot inline in the thread with `ticket-page view`, so he can read
+it without leaving the conversation. SITE.md has the commands, under **In T3 Code**.
+
 **Read [SITE.md](SITE.md) before the first write of every run.** It holds the command for each
 moment the phases below name, the plan's JSON shape, how to draw mocks, and how the epic order
 is seeded. Record each moment when it happens, not in a batch at the end, because Gib is
@@ -34,9 +39,8 @@ watching the page change.
 
 ```
 .claude/docs/epics/
-  _site/                         # the shared renderer, refreshed by ticket-page
   <EPIC-KEY>/
-    index.html, epic.data.js     # the epic index
+    index.html, epic.data.js     # the epic index (each index.html carries its own renderer)
     <TICKET-KEY>/
       index.html, ticket.data.js # the ticket page
       resources/
@@ -468,8 +472,8 @@ place from the start.
    epic (or `tickets/` without one), imports every rich-text field verbatim as sanitized
    HTML, writes the page, and prints the ticket folder. Copy the fetched JSON to
    `<target-dir>/resources/issue.raw.json`, which later re-imports and the attachment
-   script read. Record the branch from **Branch setup** with `ticket-page meta`, then open
-   the page with `ticket-page open <KEY>` so Gib can follow from here on.
+   script read. Record the branch from **Branch setup** with `ticket-page meta`, then run
+   `ticket-page open <KEY>` and link the path it prints, so Gib can follow from here on.
 4. `init` ends by listing populated Jira fields the page does not show. Read each one and
    add any that bear on implementing or verifying the ticket as a note. This sweep exists
    because real content sometimes hides in per-project custom fields with unpredictable
@@ -580,7 +584,9 @@ place from the start.
     otherwise.
 12. When a step changes what a user sees, draw its mock artboards with `ticket-page mock`,
     as [SITE.md](SITE.md) describes under **Mocks**.
-13. Stop here. Tell the user the plan is on the ticket page, give its path from
+13. Stop here. Show the plan in the thread: `ticket-page view <KEY> plan`, then each mock
+    artboard with `ticket-page view <KEY> mocks --mock <id>`, each through `html_preview`
+    and then `html_render` (SITE.md, **In T3 Code**). Then link the page path from
     `ticket-page path <KEY>`, summarize the approach in a couple of sentences, and mention
     any open questions that need their input before you'd implement it. Do not start
     implementing in this same run — wait for them to review the plan and invoke
@@ -700,9 +706,10 @@ Entered only when the user has confirmed (per Phase 0) that the plan is approved
 7. **Do NOT invoke the `pre-mr-review` skill yourself.** The org asks that this
    review run from the developer's separate work Claude account, so the audit on
    record must come from there, not from this session. Instead:
-   1. Tell the user the branch is ready for its pre-mr-review and ask them to run
-      `/pre-mr-review` from their work account, then let you know when it has
-      finished. Stop and wait, this is a hard gate.
+   1. Show where the build stands with `ticket-page view <KEY> progress`, through
+      `html_preview` and then `html_render`. Then tell the user the branch is ready for
+      its pre-mr-review and ask them to run `/pre-mr-review` from their work account,
+      then let you know when it has finished. Stop and wait, this is a hard gate.
    2. When they say it ran, read the audit and handoff files it wrote under
       `.claude/audits/pre-mr/` (the context script from the repo's `pre-mr-review`
       skill prints the exact paths). Check the `last_reviewed_head` in the audit
@@ -944,6 +951,7 @@ Entered only when the user has confirmed (per Phase 0) that the plan is approved
 
 If Phase 0 routes here because some steps are already done on the page: check
 `git log` on the current branch against the page's step commits to sanity-check they actually
-match reality (a checked-off step should have a corresponding commit), then continue
-from the first open step. If the plan and the git history disagree, stop and ask
-the user rather than guessing which one is right.
+match reality (a checked-off step should have a corresponding commit), then show
+`ticket-page view <KEY> progress` in the thread and continue from the first open step.
+If the plan and the git history disagree, stop and ask the user rather than guessing
+which one is right.