hub-launch 1.16.0 → 1.17.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>`
+ *
+ * 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,CA2DpD"}

package/dist/scripts/verify-post.js

@@ -0,0 +1,72 @@
+import { existsSync } from 'node:fs';
+import { readFile, rm, writeFile } from 'node:fs/promises';
+import { tmpdir } from 'node:os';
+import { join } from 'node:path';
+import { runGh } from './lib/exec.js';
+import { emitJson, fail, logStderr, runScript } from './lib/io.js';
+/**
+ * verify-post — Step 8 of the hula.verify workflow.
+ * Invoked as: `hula script verify-post -- <pr-number> <report-file>`
+ *
+ * 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 = '';
+        for (const a of args) {
+            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>');
+        }
+        if (!reportFile) {
+            fail(1, 'Report file path is required as second argument.');
+        }
+        if (!existsSync(reportFile)) {
+            fail(1, `Report file not found: ${reportFile}`);
+        }
+        // ── 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,
+        ]);
+        if (res.code !== 0) {
+            fail(2, `Failed to post comment to PR #${prNumber}. You can copy the report manually.`);
+        }
+        await rm(commentTmp, { 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,QAAQ,EAAE,EAAE,EAAE,SAAS,EAAE,MAAM,kBAAkB,CAAC;AAC3D,OAAO,EAAE,MAAM,EAAE,MAAM,SAAS,CAAC;AACjC,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;AAEnE;;;;;;;;;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,KAAK,MAAM,CAAC,IAAI,IAAI,EAAE,CAAC;YACrB,IAAI,QAAQ,CAAC,IAAI,CAAC,CAAC,CAAC,EAAE,CAAC;gBACrB,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,CAAC,CAAC,EAAE,6DAA6D,CAAC,CAAC;QACzE,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,yEAAyE;QACzE,MAAM,UAAU,GAAG,IAAI,CAAC,MAAM,EAAE,EAAE,uBAAuB,QAAQ,KAAK,CAAC,CAAC;QACxE,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,CAAC;YACtB,IAAI;YACJ,SAAS;YACT,QAAQ;YACR,aAAa;YACb,UAAU;SACX,CAAC,CAAC;QACH,IAAI,GAAG,CAAC,IAAI,KAAK,CAAC,EAAE,CAAC;YACnB,IAAI,CACF,CAAC,EACD,iCAAiC,QAAQ,qCAAqC,CAC/E,CAAC;QACJ,CAAC;QAED,MAAM,EAAE,CAAC,UAAU,EAAE,EAAE,KAAK,EAAE,IAAI,EAAE,CAAC,CAAC;QAEtC,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-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.)

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

@@ -72,7 +72,7 @@ Stop execution here. Do not proceed.
 Run the gather script — it fetches issue details, finds the linked PR, and downloads file changes and diff in one terminal approval:
 
 ```bash
-bash .github/scripts/hula-verify-gather.sh <issue-number>
+hula script verify-gather -- <issue-number>
 ```
 
 The script outputs JSON with `status`, `issueTitle`, `issueState`, `issueUrl`, `prNumber`, `prTitle`, `prUrl`, `prState`, `prBranch`, `prIsDraft`, `diffFile`, `filesChanged`, and `lines`.
@@ -295,7 +295,7 @@ Wait for user response.
 Save the verification report to a temporary file, then run the post script (one terminal approval):
 
 ```bash
-bash .github/scripts/hula-verify-post.sh <pr-number> /tmp/hula-verify-report-<pr-number>.md
+hula script verify-post -- <pr-number> /tmp/hula-verify-report-<pr-number>.md
 ```
 
 The script outputs JSON with `status`, `prNumber`, and `commentUrl`.