hub-launch 1.16.0 → 1.18.0

package/dist/scripts/verify-post.d.ts

@@ -0,0 +1,12 @@
+/**
+ * verify-post — Step 8 of the hula.verify workflow.
+ * Invoked as: `hula script verify-post -- <pr-number> <report-file> [--repo-root <path>]`
+ *
+ * Posts a verification report as a PR comment mentioning @copilot.
+ * Emits structured JSON to stdout; all other output goes to stderr.
+ * Exit codes: 0=success, 1=user error, 2=tool error.
+ *
+ * Node port of `hula-verify-post.sh` (cross-platform: no bash, no jq).
+ */
+export declare function main(args: string[]): Promise<number>;
+//# sourceMappingURL=verify-post.d.ts.map

package/dist/scripts/verify-post.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"verify-post.d.ts","sourceRoot":"","sources":["../../src/scripts/verify-post.ts"],"names":[],"mappings":"AAOA;;;;;;;;;GASG;AACH,wBAAgB,IAAI,CAAC,IAAI,EAAE,MAAM,EAAE,GAAG,OAAO,CAAC,MAAM,CAAC,CAmFpD"}

package/dist/scripts/verify-post.js

@@ -0,0 +1,91 @@
+import { existsSync } from 'node:fs';
+import { mkdir, readFile, rm, writeFile } from 'node:fs/promises';
+import { join } from 'node:path';
+import { runGh } from './lib/exec.js';
+import { emitJson, fail, logStderr, runScript } from './lib/io.js';
+import { resolveRepoRoot } from './lib/read-config.js';
+/**
+ * verify-post — Step 8 of the hula.verify workflow.
+ * Invoked as: `hula script verify-post -- <pr-number> <report-file> [--repo-root <path>]`
+ *
+ * Posts a verification report as a PR comment mentioning @copilot.
+ * Emits structured JSON to stdout; all other output goes to stderr.
+ * Exit codes: 0=success, 1=user error, 2=tool error.
+ *
+ * Node port of `hula-verify-post.sh` (cross-platform: no bash, no jq).
+ */
+export function main(args) {
+    return runScript(async () => {
+        // ── argument parsing ──────────────────────────────────────────────────
+        let prNumber = '';
+        let reportFile = '';
+        let repoRootArg = '';
+        for (let i = 0; i < args.length; i++) {
+            const a = args[i];
+            if (a === '--repo-root') {
+                repoRootArg = args[++i] ?? '';
+            }
+            else if (a.startsWith('--repo-root=')) {
+                repoRootArg = a.slice('--repo-root='.length);
+            }
+            else if (/^[0-9]/.test(a)) {
+                if (!prNumber)
+                    prNumber = a;
+                else
+                    fail(1, `Unexpected positional argument: ${a}`);
+            }
+            else if (!reportFile) {
+                reportFile = a;
+            }
+            else {
+                fail(1, `Unknown argument: ${a}`);
+            }
+        }
+        if (!prNumber) {
+            fail(1, 'Usage: hula script verify-post -- <pr-number> <report-file> [--repo-root <path>]');
+        }
+        if (!reportFile) {
+            fail(1, 'Report file path is required as second argument.');
+        }
+        if (!existsSync(reportFile)) {
+            fail(1, `Report file not found: ${reportFile}`);
+        }
+        // Resolve the repo root and ensure the repo-local tmp directory exists.
+        // Done defensively here too (not just in verify-gather) in case verify-post
+        // is invoked in isolation without verify-gather having run first.
+        const cwd = repoRootArg || undefined;
+        const repoRoot = await resolveRepoRoot(cwd);
+        const tmpDir = join(repoRoot, '.hublaunch', 'tmp');
+        await mkdir(tmpDir, { recursive: true });
+        // ── Build comment body with @copilot mention ──────────────────────────
+        const commentTmp = join(tmpDir, `hula-verify-comment-${prNumber}.md`);
+        const report = await readFile(reportFile, 'utf-8');
+        const body = '@copilot Please review this verification report and address any gaps.\n\n' +
+            report;
+        await writeFile(commentTmp, body, 'utf-8');
+        // ── Post comment ──────────────────────────────────────────────────────
+        logStderr(`📝 Posting verification report to PR #${prNumber}...`);
+        const res = await runGh(['pr', 'comment', prNumber, '--body-file', commentTmp], { cwd });
+        if (res.code !== 0) {
+            fail(2, `Failed to post comment to PR #${prNumber}. You can copy the report manually.`);
+        }
+        // Best-effort cleanup of all three repo-local scratch files for this PR:
+        // the comment body, the report Claude wrote, and the diff verify-gather
+        // wrote. `{ force: true }` so a missing file (e.g. the diff was never
+        // fetched, or gather ran under a different --repo-root) is a silent no-op
+        // and never turns a successful post into a reported failure.
+        const diffFile = join(tmpDir, `hula-verify-diff-${prNumber}.patch`);
+        await Promise.all([
+            rm(commentTmp, { force: true }),
+            rm(reportFile, { force: true }),
+            rm(diffFile, { force: true }),
+        ]);
+        // ── Output result ─────────────────────────────────────────────────────
+        emitJson({
+            status: 'success',
+            prNumber: Number(prNumber),
+            commentUrl: res.stdout.trim(),
+        });
+    }, args);
+}
+//# sourceMappingURL=verify-post.js.map

package/dist/scripts/verify-post.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"verify-post.js","sourceRoot":"","sources":["../../src/scripts/verify-post.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,UAAU,EAAE,MAAM,SAAS,CAAC;AACrC,OAAO,EAAE,KAAK,EAAE,QAAQ,EAAE,EAAE,EAAE,SAAS,EAAE,MAAM,kBAAkB,CAAC;AAClE,OAAO,EAAE,IAAI,EAAE,MAAM,WAAW,CAAC;AACjC,OAAO,EAAE,KAAK,EAAE,MAAM,eAAe,CAAC;AACtC,OAAO,EAAE,QAAQ,EAAE,IAAI,EAAE,SAAS,EAAE,SAAS,EAAE,MAAM,aAAa,CAAC;AACnE,OAAO,EAAE,eAAe,EAAE,MAAM,sBAAsB,CAAC;AAEvD;;;;;;;;;GASG;AACH,MAAM,UAAU,IAAI,CAAC,IAAc;IACjC,OAAO,SAAS,CAAC,KAAK,IAAI,EAAE;QAC1B,yEAAyE;QACzE,IAAI,QAAQ,GAAG,EAAE,CAAC;QAClB,IAAI,UAAU,GAAG,EAAE,CAAC;QACpB,IAAI,WAAW,GAAG,EAAE,CAAC;QACrB,KAAK,IAAI,CAAC,GAAG,CAAC,EAAE,CAAC,GAAG,IAAI,CAAC,MAAM,EAAE,CAAC,EAAE,EAAE,CAAC;YACrC,MAAM,CAAC,GAAG,IAAI,CAAC,CAAC,CAAE,CAAC;YACnB,IAAI,CAAC,KAAK,aAAa,EAAE,CAAC;gBACxB,WAAW,GAAG,IAAI,CAAC,EAAE,CAAC,CAAC,IAAI,EAAE,CAAC;YAChC,CAAC;iBAAM,IAAI,CAAC,CAAC,UAAU,CAAC,cAAc,CAAC,EAAE,CAAC;gBACxC,WAAW,GAAG,CAAC,CAAC,KAAK,CAAC,cAAc,CAAC,MAAM,CAAC,CAAC;YAC/C,CAAC;iBAAM,IAAI,QAAQ,CAAC,IAAI,CAAC,CAAC,CAAC,EAAE,CAAC;gBAC5B,IAAI,CAAC,QAAQ;oBAAE,QAAQ,GAAG,CAAC,CAAC;;oBACvB,IAAI,CAAC,CAAC,EAAE,mCAAmC,CAAC,EAAE,CAAC,CAAC;YACvD,CAAC;iBAAM,IAAI,CAAC,UAAU,EAAE,CAAC;gBACvB,UAAU,GAAG,CAAC,CAAC;YACjB,CAAC;iBAAM,CAAC;gBACN,IAAI,CAAC,CAAC,EAAE,qBAAqB,CAAC,EAAE,CAAC,CAAC;YACpC,CAAC;QACH,CAAC;QAED,IAAI,CAAC,QAAQ,EAAE,CAAC;YACd,IAAI,CACF,CAAC,EACD,kFAAkF,CACnF,CAAC;QACJ,CAAC;QACD,IAAI,CAAC,UAAU,EAAE,CAAC;YAChB,IAAI,CAAC,CAAC,EAAE,kDAAkD,CAAC,CAAC;QAC9D,CAAC;QACD,IAAI,CAAC,UAAU,CAAC,UAAU,CAAC,EAAE,CAAC;YAC5B,IAAI,CAAC,CAAC,EAAE,0BAA0B,UAAU,EAAE,CAAC,CAAC;QAClD,CAAC;QAED,wEAAwE;QACxE,4EAA4E;QAC5E,kEAAkE;QAClE,MAAM,GAAG,GAAG,WAAW,IAAI,SAAS,CAAC;QACrC,MAAM,QAAQ,GAAG,MAAM,eAAe,CAAC,GAAG,CAAC,CAAC;QAC5C,MAAM,MAAM,GAAG,IAAI,CAAC,QAAQ,EAAE,YAAY,EAAE,KAAK,CAAC,CAAC;QACnD,MAAM,KAAK,CAAC,MAAM,EAAE,EAAE,SAAS,EAAE,IAAI,EAAE,CAAC,CAAC;QAEzC,yEAAyE;QACzE,MAAM,UAAU,GAAG,IAAI,CAAC,MAAM,EAAE,uBAAuB,QAAQ,KAAK,CAAC,CAAC;QACtE,MAAM,MAAM,GAAG,MAAM,QAAQ,CAAC,UAAU,EAAE,OAAO,CAAC,CAAC;QACnD,MAAM,IAAI,GACR,2EAA2E;YAC3E,MAAM,CAAC;QACT,MAAM,SAAS,CAAC,UAAU,EAAE,IAAI,EAAE,OAAO,CAAC,CAAC;QAE3C,yEAAyE;QACzE,SAAS,CAAC,yCAAyC,QAAQ,KAAK,CAAC,CAAC;QAClE,MAAM,GAAG,GAAG,MAAM,KAAK,CACrB,CAAC,IAAI,EAAE,SAAS,EAAE,QAAQ,EAAE,aAAa,EAAE,UAAU,CAAC,EACtD,EAAE,GAAG,EAAE,CACR,CAAC;QACF,IAAI,GAAG,CAAC,IAAI,KAAK,CAAC,EAAE,CAAC;YACnB,IAAI,CACF,CAAC,EACD,iCAAiC,QAAQ,qCAAqC,CAC/E,CAAC;QACJ,CAAC;QAED,yEAAyE;QACzE,wEAAwE;QACxE,sEAAsE;QACtE,0EAA0E;QAC1E,6DAA6D;QAC7D,MAAM,QAAQ,GAAG,IAAI,CAAC,MAAM,EAAE,oBAAoB,QAAQ,QAAQ,CAAC,CAAC;QACpE,MAAM,OAAO,CAAC,GAAG,CAAC;YAChB,EAAE,CAAC,UAAU,EAAE,EAAE,KAAK,EAAE,IAAI,EAAE,CAAC;YAC/B,EAAE,CAAC,UAAU,EAAE,EAAE,KAAK,EAAE,IAAI,EAAE,CAAC;YAC/B,EAAE,CAAC,QAAQ,EAAE,EAAE,KAAK,EAAE,IAAI,EAAE,CAAC;SAC9B,CAAC,CAAC;QAEH,yEAAyE;QACzE,QAAQ,CAAC;YACP,MAAM,EAAE,SAAS;YACjB,QAAQ,EAAE,MAAM,CAAC,QAAQ,CAAC;YAC1B,UAAU,EAAE,GAAG,CAAC,MAAM,CAAC,IAAI,EAAE;SAC9B,CAAC,CAAC;IACL,CAAC,EAAE,IAAI,CAAC,CAAC;AACX,CAAC"}

package/dist/templates/planning-instructions.md

@@ -54,13 +54,13 @@ This means:
 - Inform the user that the plan has been created
 - **Immediately proceed** to the confirmation/validation workflow
 - Do NOT wait for the user to type `/hula-confirm` — continue in the same session
-- Read `.hublaunch/proceed-instructions.md` and execute validation against the saved plan
+- Read `hula instructions proceed` and execute validation against the saved plan
 - Skip the file-location confirmation step (the path is already known from this session)
 
 **PHASE 6: INLINE VALIDATION (replaces separate /hula-confirm)**
 
 - Validation runs automatically after the plan file is saved
-- Execute the full `proceed-instructions.md` validation workflow inline
+- Execute the full `hula instructions proceed` validation workflow inline
 - The MCQ validation questions (if any) are asked in this same session
 - Plan is updated with improvements before handing off to the user
 - `/hula-confirm` remains available as a standalone command for re-validation at any time
@@ -237,10 +237,10 @@ After generating and saving the draft plan file (following Phase 6 below), infor
 
 1. **Inform the user** that the plan has been created
 2. **Announce auto-continue**: State that validation is starting now (no user action needed)
-3. **Execute validation inline**: Read `.hublaunch/proceed-instructions.md` and run the full validation workflow against the plan file you just saved
+3. **Execute validation inline**: Read `hula instructions proceed` and run the full validation workflow against the plan file you just saved
 4. **Skip the file-location guard**: The plan path is already known from this session — do not ask "Is this correct?"
 5. **Carry forward context**: Use everything learned during planning to resolve validation questions where possible
-6. **Offer the launch**: After validation completes, follow the "Launch Offer" section of `.hublaunch/proceed-instructions.md` — determine the issue name, ask the launch question, and on an affirmative reply execute the `/hula-launch` workflow. Never launch without an affirmative reply.
+6. **Offer the launch**: After validation completes, follow the "Launch Offer" section of `hula instructions proceed` — determine the issue name, ask the launch question, and on an affirmative reply execute the `/hula-launch` workflow. Never launch without an affirmative reply.
 
 **Output format after saving the plan file:**
 
@@ -252,7 +252,7 @@ After generating and saving the draft plan file (following Phase 6 below), infor
 📋 **Proceeding to validation now…**
 ```
 
-Then continue immediately by reading `.hublaunch/proceed-instructions.md` and executing the validation workflow against the saved plan path. Begin at Step 2 (Comprehensive Validation Analysis) — skip Step 1 (file location) because the path is already known.
+Then continue immediately by reading `hula instructions proceed` and executing the validation workflow against the saved plan path. Begin at Step 2 (Comprehensive Validation Analysis) — skip Step 1 (file location) because the path is already known.
 
 **Recovery fallback:** If inline validation cannot complete (context window limit, tool error, interrupted session), print:
 
@@ -292,7 +292,7 @@ After successfully saving the plan, output the handoff message from Phase 5 abov
 📋 **Proceeding to validation now…**
 ```
 
-Then immediately continue with the inline validation workflow described in Phase 5 (read `.hublaunch/proceed-instructions.md` and execute it against the saved plan path, starting from Step 2 and skipping the file-location confirmation).
+Then immediately continue with the inline validation workflow described in Phase 5 (read `hula instructions proceed` and execute it against the saved plan path, starting from Step 2 and skipping the file-location confirmation).
 
 The HTML comment allows the system to reference the plan file for further operations.
 
@@ -701,7 +701,7 @@ src/
    - Phase 3: Create DRAFT plan
    - Phase 4: Save the plan file immediately
    - Phase 5: Auto-continue to validation in the same session
-   - Phase 6: Inline validation (replaces separate `/hula-confirm`; the standalone command remains available) — ends with the Launch Offer (see `.hublaunch/proceed-instructions.md`)
+   - Phase 6: Inline validation (replaces separate `/hula-confirm`; the standalone command remains available) — ends with the Launch Offer (see `hula instructions proceed`)
 
 4. **PLAN FOR AI IMPLEMENTATION**: The plan must be self-contained
 

package/dist/templates/skill-creation-instructions.md

@@ -88,7 +88,7 @@ branch at run time (and re-reads it on every scheduled fire). The file MUST be o
 the branch before the run, so publish it first:
 
 ```bash
-bash .github/scripts/hula-schedule-manage.sh --publish-skill .hublaunch/skills/<filename>
+hula script schedule-manage -- --publish-skill .hublaunch/skills/<filename>
 ```
 
 Parse the single JSON object it prints:
@@ -103,7 +103,7 @@ Only after a successful publish, invoke the run wrapper with `--action-path`
 pointing at the committed file:
 
 ```bash
-bash .github/scripts/hula-schedule-run.sh --action-path .hublaunch/skills/<filename> [--entry-point <path>] [--outcome-type <type>] [--schedule "<cron>"]
+hula script schedule-run -- --action-path .hublaunch/skills/<filename> [--entry-point <path>] [--outcome-type <type>] [--schedule "<cron>"]
 ```
 
 Pass only the flags you resolved. Quote the cron expression.

package/dist/templates/skills/hula-confirm/SKILL.md

@@ -10,9 +10,9 @@ You are an expert plan validator for the HubLaunch project, specializing in ensu
 
 ## Instructions
 
-Read the detailed confirmation guidelines from the workspace file:
+Read the detailed confirmation guidelines by running:
 
-`.hublaunch/proceed-instructions.md`
+`hula instructions proceed`
 
 Follow those instructions carefully to validate and enhance implementation plans.
 
@@ -296,7 +296,7 @@ After updating the plan:
    🚀 Are you ready to launch? (Unless you tell me otherwise, I'll use the issue name `<issueName>`.)
    ```
 
-   Then follow the **Launch Offer** section of `.hublaunch/proceed-instructions.md`: resolve `<issueName>`, ask the launch question, and on an affirmative reply execute the `/hula-launch` workflow with `<issueName> <planPath>` (plus any `--handoff`/`--test` flags). Never launch without an affirmative reply; on a negative or deferring reply, print the fallback message and stop.
+   Then follow the **Launch Offer** section of `hula instructions proceed`: resolve `<issueName>`, ask the launch question, and on an affirmative reply execute the `/hula-launch` workflow with `<issueName> <planPath>` (plus any `--handoff`/`--test` flags). Never launch without an affirmative reply; on a negative or deferring reply, print the fallback message and stop.
 
 ## Important Guidelines
 

package/dist/templates/skills/hula-fix/SKILL.md

@@ -68,7 +68,7 @@ Stop execution here. Do not proceed.
 Run the setup script — it handles issue lookup, validation, worktree creation, and session file writing in one terminal approval:
 
 ```bash
-bash .github/scripts/hula-fix-setup.sh <issue-number>
+hula script fix-setup -- <issue-number>
 ```
 
 The script outputs JSON with `status`, `issueTitle`, `prBranch`, `worktreePath`, and `sessionFile`.
@@ -111,7 +111,7 @@ Switch your working context:
 cd <worktreePath>
 ```
 
-Where `<worktreePath>` is the path returned by `hula-fix-setup.sh` in Step 2.
+Where `<worktreePath>` is the path returned by `hula script fix-setup` in Step 2.
 
 Apply fixes using the edit tool, making sure file paths are relative to (or inside) the worktree directory.
 
@@ -133,7 +133,7 @@ Progress display:
 Generate a commit message based on the issue number, files changed, and nature of changes, then run the commit script (one terminal approval):
 
 ```bash
-bash .github/scripts/hula-fix-commit.sh <issue-number> "fix(#42): <generated-message>"
+hula script fix-commit -- <issue-number> "fix(#42): <generated-message>"
 ```
 
 The script outputs JSON with `status`, `commitMessage`, and `filesChanged`.

package/dist/templates/skills/hula-help/SKILL.md

@@ -0,0 +1,117 @@
+---
+name: hula-help
+description: Interactive onboarding and reference guide for hub-launch. Walks new users through prerequisites, hula login, hula init, and the plan → launch → verify → fix → merge workflow, and looks up any hula command or /hula-* skill. Use when the user is new to hub-launch, unsure what to run next, or asks how a command/skill works.
+disable-model-invocation: true
+argument-hint: "[getting-started|workflow|commands|config|<question>]"
+allowed-tools: Bash Read
+---
+
+You are an onboarding guide for hub-launch (the `hula` CLI and its `/hula-*` Agent Skills). Your job is to help a user — often a beginner — understand what hub-launch is, what's already set up in their project, and what to do next, through a short, interactive conversation. Never overwhelm: one focused answer or menu at a time, then wait for the user's next pick.
+
+## Golden rules
+
+1. **Read live, never guess or embed stale copy.** Always pull current facts from `README.md`, `docs/commands.md`, and (where relevant) `hula <command> --help` in this repo — never rely on memorized text, since it can drift out of date.
+2. **Informational by default.** Explain what to run and why. Only *run* a command yourself under "What you're allowed to run" below.
+3. **One step at a time.** Don't dump the whole README. Answer what was asked, then offer the next logical option.
+4. **Beginner-safe tone.** No unexplained jargon. Define terms the first time you use them (e.g. "a *plan* is a markdown file describing what to build").
+5. **No troubleshooting.** This skill is for getting started and looking things up, not for diagnosing errors or stuck states. If asked to debug something broken, say that's outside what this skill covers and point at the relevant command's own error output instead.
+
+## Input
+
+$ARGUMENTS
+
+- No argument → run the **State Check**, then show the **Topic Menu**.
+- One of `getting-started`, `workflow`, `commands`, `config` → run the **State Check** silently, then skip the menu and go straight to that topic's section below.
+- Anything else (free text) → run the **State Check** silently, then treat it as a free-form question — answer it by reading the relevant doc section(s), same read-live rule applies.
+
+## Step 1: State Check (silent, read-only, no confirmation needed)
+
+Before responding, gather context. None of these require confirmation — they don't mutate anything:
+
+```bash
+test -f .hublaunch/hublaunch.config.js && echo "initialized" || echo "not-initialized"
+git rev-parse --abbrev-ref HEAD 2>/dev/null || echo "no-git"
+hula --version 2>/dev/null
+```
+
+If initialized, `Read .hublaunch/hublaunch.config.js` and note (never print the values themselves, only presence/absence):
+- Is `hulaApiKey` (or `anthropicApiKey`/`daytonaApiKey`) present with a non-empty value? → user has likely completed `hula login`.
+- If `.hublaunch/trackedPlans.json` exists, `Read` it — does it have any entries? → user has launched at least one plan before.
+
+If any check fails (not a git repo, config unreadable), treat that signal as unknown and continue — don't block on it.
+
+Classify into one state:
+- **Fresh** — no `.hublaunch/hublaunch.config.js` → hasn't run `hula init` yet.
+- **Initialized, not logged in** — config exists, no API key set.
+- **Ready, no history** — config + key set, `trackedPlans.json` empty/missing.
+- **Mid-workflow** — tracked plans exist and/or current git branch isn't the default branch.
+
+## Step 2: Opening line (tailored, one line, then always show the menu)
+
+Pick ONE line matching the state:
+
+- Fresh: `👋 Looks like hub-launch isn't initialized in this project yet.`
+- Initialized, not logged in: `👋 hub-launch is initialized, but I don't see login credentials yet.`
+- Ready, no history: `👋 You're set up — haven't launched a plan yet?`
+- Mid-workflow: `👋 Looks like you're mid-workflow on branch \`<branch>\`.`
+
+(Skip this step entirely when the user passed an explicit topic argument — go straight to that topic instead.)
+
+## Step 3: Topic Menu
+
+```
+What do you need help with?
+
+1. Getting Started — install, login, init, your first plan → launch → merge cycle
+2. The Core Workflow — what /hula-plan, /hula-launch, /hula-verify, /hula-fix, /hula-merge each do
+3. Commands Reference — look up any hula CLI command or /hula-* skill
+4. Configuration — .hublaunch/hublaunch.config.js basics
+5. Something else — just ask your question
+```
+
+Wait for a reply (number, keyword, or free text). Do not proceed until the user responds.
+
+## Topic: Getting Started
+
+Read `README.md`'s "Quick Start" and "Requirements" sections (and the "Core Workflow" intro) live, then walk the user through, in order, only up to where the **State Check** says they already are — skip and say "✅ already done" for steps already satisfied:
+
+1. Requirements — Node ≥18, `gh` CLI ≥2.4.0 authenticated (`gh auth login`), Playwright Chromium (`npx playwright install chromium`).
+2. Install — `npm install -g hub-launch` (or `pnpm add -g hub-launch`).
+3. `hula init` — initializes `.hublaunch/hublaunch.config.js`. If State Check showed **Fresh**, offer to run it now (see "What you're allowed to run").
+4. `hula login` — authenticates GitHub + hula-project. If **Initialized, not logged in**, offer to run it now.
+5. First cycle — `/hula-plan <description>` → `/hula-launch <name>` → `/hula-verify` → `/hula-merge`. Point to Topic: The Core Workflow for details on each.
+
+## Topic: The Core Workflow
+
+Read the "Core Workflow" section of `README.md` live. Explain each step in plain language — one at a time if the user wants depth, or as a compact list if they want the overview:
+
+- `/hula-plan <description>` — writes a plan file to `.hublaunch/plans/`, validates it automatically.
+- `/hula-upload` — syncs the plan to `origin/main` (usually automatic as part of `/hula-launch`, rarely needed standalone).
+- `/hula-launch <name>` — creates the GitHub issue, runs the AI coding session in an isolated cloud container, opens a PR.
+- `/hula-verify` — checks the PR against the plan's acceptance criteria.
+- `/hula-fix <instructions>` — addresses gaps found by verify, or anything else you want changed on the PR branch.
+- `/hula-merge` — merges the PR, cleans up, fast-forwards local `main`.
+- Mention `/hula-info`, `/hula-schedule`, `/hula-confirm` as supporting skills, one line each, only if the user wants more than the core cycle.
+
+## Topic: Commands Reference
+
+Ask (if not already clear from `$ARGUMENTS`) which command or skill they want to know about. Then:
+- For a `hula <x>` CLI command → run `hula <x> --help` and relay the output; also `Read docs/commands.md` for the matching `## \`hula <x>\`` section if more narrative detail would help.
+- For a `/hula-<x>` skill → `Read docs/commands.md` and `README.md` for any matching section. Skills generally aren't documented in `docs/commands.md` (it covers CLI subcommands, not skills) — if there's no match, say so rather than inventing detail, and summarize from the skill's own stated purpose instead.
+
+## Topic: Configuration
+
+If `.hublaunch/hublaunch.config.js` exists, `Read` it (never print secret values — describe presence/absence only) alongside the relevant `README.md` sections (e.g. "Forwarding environment variables to the container", "Configuring per-step model & iteration overrides"). Explain only the fields the user asks about — don't dump the whole schema unprompted.
+
+## What you're allowed to run
+
+- **Always allowed, no confirmation needed**: read-only checks — `hula --version`, `git status`, `git rev-parse --abbrev-ref HEAD`, `hula <cmd> --help`, `Read` on any repo file.
+- **Offer, then wait for an explicit yes**: setup commands that change local/remote state — `hula init`, `hula login`. Never run these without an affirmative reply to your offer first.
+- **Never run**: anything from the plan→launch→merge pipeline itself (`/hula-plan`, `/hula-launch`, etc.) — those are the user's own next command to type, not something this skill triggers.
+
+## Notes
+
+- Never print API key / token values, even partially — only whether a field is set.
+- If `README.md` or `docs/commands.md` can't be read (missing/renamed), say so plainly and fall back to `hula --help` / `hula <cmd> --help` output instead of guessing.
+- Keep every answer short enough to read in a few seconds; offer "want more detail?" rather than front-loading it.
+- This skill does not diagnose errors or stuck workflows — if asked to, say that's outside what it covers.

package/dist/templates/skills/hula-launch/SKILL.md

@@ -2,7 +2,7 @@
 name: hula-launch
 description: Launch a GitHub issue from the current plan. Use when the user asks to launch or assign the plan to a remote agent.
 disable-model-invocation: true
-argument-hint: <branch-name> [<plan-path>] [--handoff <username>] [--test] [--kill] [--kill-and-relaunch]
+argument-hint: <branch-name> [<plan-path>] [--handoff <username>] [--test] [--skip-regression] [--kill] [--kill-and-relaunch]
 allowed-tools: Bash Read
 ---
 
@@ -15,6 +15,7 @@ From `$ARGUMENTS`:
 - **Plan path** (optional): the second word, if present (e.g., `.hublaunch/plans/2026-06-10-14:00-feature-auth.md`).
 - **--handoff** (optional): a `--handoff <username>` flag anywhere in `$ARGUMENTS`.
 - **--test** (optional): the bare flag `--test`, anywhere in `$ARGUMENTS`. Sets test mode (server uses a mock Claude — fast E2E run; a real PR is still created).
+- **--skip-regression** (optional): the bare flag `--skip-regression`, anywhere in `$ARGUMENTS`. Force-skips the regression-tests pipeline step for this one launch (overrides any `steps.regression.skip` config default).
 - **--kill** (optional): the bare flag `--kill`, anywhere in `$ARGUMENTS`. Stops the in-flight task for this branch name **without** relaunching. A plan path is **not** required with `--kill` — the branch name alone is enough.
 - **--kill-and-relaunch** (optional): the bare flag `--kill-and-relaunch`, anywhere in `$ARGUMENTS`. Cancels the in-flight task, resets stale state, and launches a fresh task (needs a plan path, like a normal launch).
 
@@ -47,34 +48,39 @@ With the values known, run exactly one Bash command.
 
 Without handoff:
 ```bash
-bash .github/scripts/hula-launch-run.sh <plan-path> <branch-name>
+hula script launch-run -- <plan-path> <branch-name>
 ```
 
 With handoff:
 ```bash
-bash .github/scripts/hula-launch-run.sh <plan-path> <branch-name> --handoff <username>
+hula script launch-run -- <plan-path> <branch-name> --handoff <username>
 ```
 
 With test mode:
 ```bash
-bash .github/scripts/hula-launch-run.sh <plan-path> <branch-name> --test
+hula script launch-run -- <plan-path> <branch-name> --test
 ```
 
 With handoff + test mode:
 ```bash
-bash .github/scripts/hula-launch-run.sh <plan-path> <branch-name> --handoff <username> --test
+hula script launch-run -- <plan-path> <branch-name> --handoff <username> --test
 ```
 
-Append `--test` whenever the user passed it; it composes with `--handoff`.
+With skip-regression:
+```bash
+hula script launch-run -- <plan-path> <branch-name> --skip-regression
+```
+
+Append `--test` whenever the user passed it; it composes with `--handoff`. Append `--skip-regression` whenever the user passed it; it composes with `--handoff` and `--test` too.
 
 **Stop the in-flight task without relaunching (`--kill`)** — pass only the branch name (no plan path):
 ```bash
-bash .github/scripts/hula-launch-run.sh <branch-name> --kill
+hula script launch-run -- <branch-name> --kill
 ```
 
 **Kill the in-flight task and relaunch fresh (`--kill-and-relaunch`)** — needs a plan path, like a normal launch, and composes with `--handoff`/`--test`:
 ```bash
-bash .github/scripts/hula-launch-run.sh <plan-path> <branch-name> --kill-and-relaunch
+hula script launch-run -- <plan-path> <branch-name> --kill-and-relaunch
 ```
 
 ## Step 3: Show the result

package/dist/templates/skills/hula-merge/SKILL.md

@@ -130,7 +130,7 @@ Suggested test command: npm test
 Generate a commit message based on the issue number, files changed, and nature of changes, then run the local-merge script — it handles commit, push, merge, worktree removal, and session cleanup in one terminal approval:
 
 ```bash
-bash .github/scripts/hula-merge-local.sh <issue-number> "<worktreePath>" "fix(#42): <generated-message>"
+hula script merge-local -- <issue-number> "<worktreePath>" "fix(#42): <generated-message>"
 ```
 
 The script outputs JSON with `status`, `committed`, `filesChanged`, `worktreeRemoved`, and `sessionCleaned`.
@@ -209,7 +209,7 @@ Follow this path when no local fix session/worktree exists. This is the common p
 Run the remote-merge script — it merges the PR directly on GitHub and cleans up any stale session file in one terminal approval:
 
 ```bash
-bash .github/scripts/hula-merge-remote.sh <issue-number>
+hula script merge-remote -- <issue-number>
 ```
 
 The script outputs JSON with `status`, `issueNumber`, `sessionCleaned`, and `localUpdated`.

package/dist/templates/skills/hula-plan/SKILL.md

@@ -10,9 +10,9 @@ You are an expert technical planner for the HubLaunch project.
 
 ## Instructions
 
-Read the detailed planning guidelines from the workspace file:
+Read the detailed planning guidelines by running:
 
-`.hublaunch/planning-instructions.md`
+`hula instructions planning`
 
 Follow those instructions carefully to generate a comprehensive implementation plan.
 
@@ -23,7 +23,7 @@ The user will describe a feature or issue. Your job is to:
 1. **ASK CLARIFYING QUESTIONS FIRST** - Do not immediately generate a plan
 2. Understand the requirements through questions and answers
 3. Analyze the existing codebase context
-4. Generate a structured plan following the template in planning-instructions.md
+4. Generate a structured plan following the template from `hula instructions planning`
 5. Include specific file paths, code suggestions, and actionable steps
 6. Consider testing, documentation, and edge cases
 
@@ -133,7 +133,7 @@ The plan should be immediately actionable by a developer familiar with the codeb
 
 Now proceed directly to plan validation **without waiting for the user**. The plan file was just created in this session — the path is already known.
 
-Read `.hublaunch/proceed-instructions.md` and execute the full validation workflow against the plan at `<path>` (substitute `<path>` with the actual plan file path you just created, e.g. `.hublaunch/plans/2025-12-29-14:30-feature-name.md`).
+Read `hula instructions proceed` and execute the full validation workflow against the plan at `<path>` (substitute `<path>` with the actual plan file path you just created, e.g. `.hublaunch/plans/2025-12-29-14:30-feature-name.md`).
 
 **Important adjustments for inline execution:**
 
@@ -144,6 +144,6 @@ Read `.hublaunch/proceed-instructions.md` and execute the full validation workfl
   > ⚠️ Auto-validation could not complete. Run `/hula-confirm <path>` to resume.
 
   where `<path>` is the plan file path.
-- **Finish with the Launch Offer** — after validation completes, execute the "Launch Offer" section of `.hublaunch/proceed-instructions.md` (issue-name resolution, the launch question, and launching on an affirmative reply). Never launch without an affirmative reply.
+- **Finish with the Launch Offer** — after validation completes, execute the "Launch Offer" section of `hula instructions proceed` (issue-name resolution, the launch question, and launching on an affirmative reply). Never launch without an affirmative reply.
 
 **Note:** The plan is saved locally. When you run `/hula-launch`, the plan is automatically synced to `origin/main` before the GitHub issue is created and the implementation begins — no separate upload step needed. Because validation ends with the Launch Offer, an affirmative reply runs the `/hula-launch` workflow for the user automatically; they can also decline and run `/hula-launch` themselves later. `/hula-confirm` remains available as a standalone command for re-validation at any time.

package/dist/templates/skills/hula-schedule/SKILL.md

@@ -76,13 +76,13 @@ guess between "run an existing action" and "create a new one". Likewise, if an
 Run exactly one Bash command. Use `--built-in` OR `--action-path`, never both:
 
 ```bash
-bash .github/scripts/hula-schedule-run.sh --built-in <name> [--entry-point <path>] [--outcome-type <type>] [--schedule "<cron>"] [--pr-policy <always|skip-if-open|close-previous>]
+hula script schedule-run -- --built-in <name> [--entry-point <path>] [--outcome-type <type>] [--schedule "<cron>"] [--pr-policy <always|skip-if-open|close-previous>]
 ```
 
 or, for a custom action file:
 
 ```bash
-bash .github/scripts/hula-schedule-run.sh --action-path <path> [--entry-point <path>] [--outcome-type <type>] [--schedule "<cron>"] [--pr-policy <always|skip-if-open|close-previous>]
+hula script schedule-run -- --action-path <path> [--entry-point <path>] [--outcome-type <type>] [--schedule "<cron>"] [--pr-policy <always|skip-if-open|close-previous>]
 ```
 
 Pass only the flags you resolved. Quote the cron expression. Only include
@@ -95,14 +95,14 @@ report the result (see **Reporting run/schedule results**).
 
 The user described what they want done but did not supply an existing action.
 
-**Read `.hublaunch/skill-creation-instructions.md` and follow it exactly.** In
+**Read `hula instructions skill-creation` and follow it exactly.** In
 summary it has you: ask clarifying questions first (then STOP), confirm the
 action name, resolve+confirm any cron, write a free-form instruction markdown
 file to `.hublaunch/skills/<YYYY-MM-DD-HH:MM-slug>.md`, **publish it to
 origin/main BEFORE running** via
-`bash .github/scripts/hula-schedule-manage.sh --publish-skill <path>` (abort if
+`hula script schedule-manage -- --publish-skill <path>` (abort if
 that returns `status:"error"`), then run/schedule it with
-`bash .github/scripts/hula-schedule-run.sh --action-path <path> …`, and report the
+`hula script schedule-run -- --action-path <path> …`, and report the
 created file path plus the run/schedule result.
 
 ---
@@ -113,8 +113,8 @@ Run via the management wrapper:
 
 - `list` (no qualifier) → show **both** recent runs and active schedules:
   ```bash
-  bash .github/scripts/hula-schedule-manage.sh --list
-  bash .github/scripts/hula-schedule-manage.sh --list-schedules
+  hula script schedule-manage -- --list
+  hula script schedule-manage -- --list-schedules
   ```
 - "list runs" → only `--list`. "list schedules" → only `--list-schedules`.
 
@@ -123,7 +123,7 @@ Display the `cliOutput` from each result.
 ## Mode: show
 
 ```bash
-bash .github/scripts/hula-schedule-manage.sh --show <runId>
+hula script schedule-manage -- --show <runId>
 ```
 
 Display the `cliOutput`.
@@ -131,7 +131,7 @@ Display the `cliOutput`.
 ## Mode: run-now
 
 ```bash
-bash .github/scripts/hula-schedule-manage.sh --run-now <scheduleId>
+hula script schedule-manage -- --run-now <scheduleId>
 ```
 
 Report the new run id (`runId`) from the JSON, falling back to `cliOutput`.
@@ -140,19 +140,19 @@ Report the new run id (`runId`) from the JSON, falling back to `cliOutput`.
 
 1. Cancel the schedule:
    ```bash
-   bash .github/scripts/hula-schedule-manage.sh --cancel-schedule <scheduleId>
+   hula script schedule-manage -- --cancel-schedule <scheduleId>
    ```
 2. If the cancelled schedule referenced an `actionPath` under
    `.hublaunch/skills/`, **ask the user whether to also delete that file.**
 3. If they opt in, FIRST verify no other active schedule still uses it:
    ```bash
-   bash .github/scripts/hula-schedule-manage.sh --list-schedules
+   hula script schedule-manage -- --list-schedules
    ```
    - If another active schedule references the same `actionPath`, **refuse** and
      report which schedule id(s) still use it. Leave the file on the branch.
    - Otherwise delete it:
      ```bash
-     bash .github/scripts/hula-schedule-manage.sh --delete-skill <actionPath>
+     hula script schedule-manage -- --delete-skill <actionPath>
      ```
 
 ## Mode: update-skill-file
@@ -167,7 +167,7 @@ schedule.
    it with `Write` for a large change), keeping the free-form template format.
 3. Re-publish it:
    ```bash
-   bash .github/scripts/hula-schedule-manage.sh --publish-skill <actionPath>
+   hula script schedule-manage -- --publish-skill <actionPath>
    ```
 4. No schedule change is needed. Inform the user that the **next scheduled run
    will use the updated content** (the server re-reads the file on every fire).
@@ -180,14 +180,14 @@ update-schedule endpoint, so cancel + recreate on the same action:
 1. Read the existing schedule's `actionPath` (or `builtIn`), `entryPoint`, and
    `outcomeType` via:
    ```bash
-   bash .github/scripts/hula-schedule-manage.sh --list-schedules
+   hula script schedule-manage -- --list-schedules
    ```
 2. Resolve the new cron and **confirm the readback** (see Cron table).
 3. Cancel the old schedule, then recreate with the new cron on the **same**
    action:
    ```bash
-   bash .github/scripts/hula-schedule-manage.sh --cancel-schedule <old-id>
-   bash .github/scripts/hula-schedule-run.sh --action-path <same-path> [--entry-point <path>] [--outcome-type <type>] --schedule "<new-cron>"
+   hula script schedule-manage -- --cancel-schedule <old-id>
+   hula script schedule-run -- --action-path <same-path> [--entry-point <path>] [--outcome-type <type>] --schedule "<new-cron>"
    ```
    (Use `--built-in <name>` instead of `--action-path` if the schedule used a
    built-in.)