skills/linear-nightshift/SKILL.md
Run a night-shift against a collaborator's Linear board. Pulls the team's Grilled tickets (/ro:linear-grill moves a ticket to Grilled once its questions are answered), VERIFIES the questions were actually answered (unanswered → bounce the ticket to the "Question for <name>" state), mirrors verified tickets to ephemeral GitHub issues with ready-for-agent, then runs the standard /ro:night-shift machinery on GitHub. Tail-calls /ro:linear-update for everything that merged + deployed. Triggers on "linear nightshift", "nightshift linear", "drain the linear board", "run the shift off linear", "/ro:linear-nightshift".
npx skillsauth add RonanCodes/ronan-skills linear-nightshiftInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
The hybrid one-way sync in motion (model locked 2026-06-11, ronan-skills#61): Linear is where collaborator stories are born and prioritised; GitHub is the execution layer. This skill is the bridge — it never makes Linear a second execution tracker and never makes the collaborator touch GitHub.
Collaborator files story (Backlog or Ready for agent)
→ /ro:linear-grill asks questions (state: Question for <name>)
→ collaborator answers in comments ← their only job
→ next /ro:linear-grill run promotes to Grilled
→ THIS SKILL: verify answers → mirror to GH → night-shift drains
→ /ro:linear-update marks Done with PR + try-it link
API mechanics (auth via the RoBot key — never the OAuth MCP — mentions, states, complexity cap, agent identity as the RoBot user with no label/footer) and board resolution via the repo's .ro-linear.json: see /ro:linear-grill § "Linear API mechanics" and § "Step 0". Holdoff tickets are parked: never pull them into a run.
/ro:repo-mode: work repos NEVER touch Linear or GH — refuse loudly.state.type = unstarted, name from the repo's .ro-linear.json states.grilled) + their comments; the target repo's existing queue (gh issue list --label ready-for-agent). Print a pre-flight summary: N grilled tickets, M look answered, K look unanswered, existing GH queue depth.For each Grilled ticket, first load its full context per /ro:linear-run § "Load full ticket context" and emit the context-load receipt there (mandatory gate — no mirror, no build without it): the whole issue description, every comment oldest→newest, and every image/attachment on the body and in comments — the receipt's images <M> count and the images themselves must carry into the mirrored GH issue so the build agent isn't missing a pasted screenshot or an earlier clarification. The most recent comments are most authoritative; an edited reply (newer updatedAt) counts as new. Then find the latest grill comment (API-user comment containing numbered questions) and judge:
/ro:linear-grill --issue <ID>) and bounce.Bounce = one comment, mention-first, naming exactly which questions are open ("@name — moving this back to your questions column: questions 2 and 4 still decide the build…"), then issueUpdate state → the questions state from .ro-linear.json (e.g. "Question for Eoin"). Never silently skip — the collaborator must see WHY their ticket didn't run.
For each verified ticket, create an ephemeral execution mirror:
gh issue create --label ready-for-agent --label linear-mirror \
--title "<ticket title> (NUT-<n>)" \
--body "## Linear\n\n<ticket URL> — canonical story + the collaborator's answers.\n\n<description + distilled answers + assumptions>\n\n### Close-the-loop tests\n<standard block>"
Rules: the mirror carries the distilled answers (workers must not need Linear access); create the linear-mirror label once (idempotent, case-insensitive check); move the Linear ticket to In Progress with a one-line comment ("queued for tonight's build run").
Invoke /ro:night-shift (or /ro:planner-worker --queue) against the repo's GH queue — the mirrors are ordinary ready-for-agent issues; ALL existing machinery (worktrees, dev-links, Closes #N, mergers with the stale-squash guard, retro, nightsheet, Pushover/Telegram) applies unchanged. This skill adds nothing to the execution layer.
After the run (and deploy, per the repo's policy): for every mirror whose PR merged, invoke /ro:linear-update --issue <NUT-n> --pr <#> --deployed. This is the only way the night-shift path is allowed to reach the interview / Ready-to-Test state. Never move a ticket there with a bare issueUpdate. /ro:linear-update enforces the hand-off gate (see /ro:linear-update § "The hand-off gate"): no transition without an acceptance-criteria checklist AND at least one screenshot, and for mobile/responsive-tagged tickets (or tickets whose bounce/description names a phone symptom) an explicit real-device or emulation verified on <device/viewport> line. A merged mirror that can't satisfy the gate (no screenshot possible, or a mobile fix with no real-device evidence) stays out of the interview state: /ro:linear-update holds it and says why; carry that into the nightsheet as a held-for-evidence line rather than forcing it through.
That gate moves passing tickets to Interview (assigned to the collaborator, with acceptance criteria), not Done; the collaborator closes the loop by validating. For mirrors that escalated/stuck: comment on the Linear ticket honestly (what blocked it), move back to Grilled.
After all per-ticket hand-offs, if the board has a pinned "📰 Release notes" issue, post the day's changelog once: /ro:linear-update --daily-digest --issue <pinned-ID> --repo <owner/name> (aggregates the run's merged+deployed work in plain language; skips silently on a zero-change day). See /ro:linear-update § "Daily-digest mode".
--plan-only — pre-flight + verification verdicts only, no mirrors, no run. --workers N, caps: passed through to night-shift.
| Condition | Behaviour |
|---|---|
| Zero Grilled tickets | Say so; suggest /ro:linear-grill if Backlog has ungrilled tickets |
| All Grilled tickets bounce | Report each bounce reason; no run |
| Repo-mode = work | Refuse: this flow is for personal repos only |
/ro:linear-run (the front door that calls this) · /ro:linear-grill (upstream) · /ro:linear-update (tail) · /ro:night-shift (the engine) · ronan-skills#61 (design)
testing
--- name: linear-pipeline description: The Fable orchestrator for a single dispatched Linear ticket. Holds almost no context itself; it receives `--issue <ID> --detached`, decides the stage sequence, and fans out a sub-agent per stage, passing forward only each stage's artifact (never re-derived, never inlined into its own context). Step zero, before any planning or stage routing, is a boundary triage against `canon/security-boundary.md` (#199): a match tags Ronan Connolly and stops the run, no
development
--- name: in-your-face description: Capture a chat-only answer into a durable artifact (markdown + HTML, PDF when cheap) and launch it automatically so the user cannot miss it. Use when user says "in your face", "don't let me lose this", "save that answer", "make that durable", or right after answering a substantive side question (a recipe, comparison, how-to, or generated prompt) that would otherwise die with the context. category: workflow argument-hint: [--no-open] [--vault <short>] [hint of
tools
One-shot headless OpenAI Codex CLI calls for background/admin AI tasks — summaries, classification, extraction, admin glue. The default engine for anything that runs AI constantly in the background (daemon-driven, per-event), because it bills the flat ChatGPT subscription instead of Claude usage or per-token API spend, and it keeps working while Claude is rate-limited. NEVER for coding — coding stays Claude. Use when a skill or daemon needs a cheap always-on AI call, when the user says "use codex", "ask codex", "codex as backup", or when building a background summarizer/classifier into a listener or loop. Reads auth from ~/.codex/auth.json (ChatGPT account, no API key).
research
Turn a warranty rejection, repair quote, or RMA email into a cited decision brief — legal read (NL/EU consumer law), is the part user-serviceable, live part and new-unit prices, repair-vs-DIY-vs-new economics, before-you-send-it checklist, deadlines. Use when the user pastes or screenshots a repair quote, warranty rejection, "not covered" email, onderzoekskosten fee, or asks "should I repair or replace this".