hub-launch 1.11.0 → 1.11.1

package/CHANGELOG.md

@@ -7,6 +7,12 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
+## [1.11.1] - 2026-07-09
+
+### Added
+
+- Offer to launch automatically after plan validation completes, so you can go straight from a validated plan into a run without a separate step.
+
 ## [1.11.0] - 2026-07-08
 
 ### Added

package/README.md

@@ -100,6 +100,9 @@ The primary use case is AI-assisted issue development via the hula-project serve
 ```bash
 # 1. Plan the feature
 #    Validation runs automatically in the same session after the plan is saved.
+#    When validation finishes, the assistant offers to launch right away with a
+#    default issue name derived from the plan (reply "yes" to launch, or decline
+#    and run /hula-launch <name> yourself later).
 /hula-plan Add password reset support
 
 # 2. Upload the plan to origin/main

package/dist/templates/planning-instructions.md

@@ -240,6 +240,7 @@ After generating and saving the draft plan file (following Phase 6 below), infor
 3. **Execute validation inline**: Read `.hublaunch/proceed-instructions.md` 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.
 
 **Output format after saving the plan file:**
 
@@ -700,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)
+   - Phase 6: Inline validation (replaces separate `/hula-confirm`; the standalone command remains available) — ends with the Launch Offer (see `.hublaunch/proceed-instructions.md`)
 
 4. **PLAN FOR AI IMPLEMENTATION**: The plan must be self-contained
 

package/dist/templates/proceed-instructions.md

@@ -305,9 +305,66 @@ R2. Do another validation pass? (A: Yes / B: No, complete)
 - ✅ Testing strategy
 - ✅ User approved
 
-**Next step:** Run `/hula-launch <branch-name>` to create a GitHub issue and start AI-assisted implementation.
+🚀 Are you ready to launch? (Unless you tell me otherwise, I'll use the issue name `<issueName>`.)
 ```
 
+The `🚀 Are you ready to launch?` line is not a static message — it begins the **Launch Offer** procedure below. Resolve `<issueName>`, ask the question, and act on the reply as specified next.
+
+## Launch Offer
+
+After the Completion Format block is printed, offer to launch the plan for the user instead of leaving them to run `/hula-launch` by hand. This turns the usual next step (plan → launch) into a single confirmation.
+
+**⚠️ Launching is an outward-facing action** — it creates a GitHub issue and starts a cloud implementation run. **Never launch without a clear affirmative reply from the user.** Silence, an ambiguous reply, or the end of the session must never trigger a launch.
+
+### 1. Resolve the issue name
+
+Determine `<issueName>` before asking the question:
+
+1. **Look for a name the user specified** anywhere in this conversation — e.g. "use the branch name `foo`", "call the issue `bar`", or a name passed in the original `/hula-plan` arguments. If more than one was mentioned, **the most recent wins**. Use that name verbatim (kebab-case it if needed).
+2. **Otherwise derive the default from the plan file's basename** (the subfolder is never part of the name):
+   - Strip the leading timestamp prefix matching `YYYY-MM-DD-HH:MM-` and the trailing `.md`.
+   - The remaining text is the title slug (e.g. `auto-launch-offer-after-plan`).
+   - If the slug is **longer than 3 words**, shorten it to the 2–3 most distinctive words (e.g. `auto-launch-offer-after-plan` → `auto-launch`). Otherwise keep it as-is.
+   - Always **kebab-case** (lowercase words joined by hyphens), never camelCase — these become git branch names.
+   - Example: `.hublaunch/plans/skills/2026-07-09-14:28-auto-launch-offer-after-plan.md` → slug `auto-launch-offer-after-plan` → `<issueName>` = `auto-launch`.
+
+### 2. Ask the launch question
+
+Ask exactly this (as a literal line), substituting the resolved name for `<issueName>`:
+
+```
+🚀 Are you ready to launch? (Unless you tell me otherwise, I'll use the issue name `<issueName>`.)
+```
+
+Then **STOP and wait** for the user's reply. Do not launch until they answer.
+
+### 3. Interpret the reply
+
+| Reply | Action |
+|---|---|
+| Affirmative ("yes", "go", "launch", 👍, etc.) with no other content | Launch with `<issueName>`. |
+| Affirmative **with a different name** (e.g. "yes, but call it `payment-fix`") | Launch with the new name instead. |
+| Just a bare name (e.g. "`payment-fix`") | Treat as affirmative supplying the name — launch with that name. |
+| Reply contains `--handoff <username>` and/or `--test` | Pass those flags through to the launch. |
+| Negative or deferring ("no", "not yet", "later") | Print the fallback message below and **stop** — do not launch. |
+| Ambiguous (neither clearly yes nor no) | Ask once more for a clear yes/no; still never launch without a clear affirmative. |
+
+**Fallback message** (print verbatim, substituting `<issueName>`) when the user declines or defers:
+
+```
+👍 No problem. When you're ready, run `/hula-launch <issueName>` (or any name you prefer).
+```
+
+### 4. Execute the launch
+
+On a clear affirmative, read `.agents/skills/hula-launch/SKILL.md` and execute its workflow with the arguments `<issueName> <planPath>` (plus any `--handoff`/`--test` flags from the reply). Pass the plan path explicitly — it is known in this session — rather than relying on chat-history extraction.
+
+All error handling, JSON output parsing, and result display come from the `hula-launch` skill's own Steps 2–3. Do **not** duplicate or re-implement them. Launch failures (branch already exists, plan missing on origin, etc.) are reported by the launch script's JSON output and displayed per that skill; do **not** auto-retry.
+
+### Note
+
+The user may always run `/hula-launch <branch-name>` explicitly instead — that path is unchanged. The launch offer is a convenience, not a replacement.
+
 ## Common Validation Patterns
 
 ### Pattern: Missing API Details
@@ -449,5 +506,6 @@ Plan says: "Add deployment preview feature using the API we discussed"
 - **Preserve content** - enhance, don't replace
 - **Iterate if needed** - refinement is a process
 - **Ensure readiness** - plan must stand alone for AI implementation
+- **Offer the launch** - after completion, resolve the issue name and ask the launch question; never launch without an affirmative reply
 
 The goal is to ensure every plan can be successfully implemented by an AI agent without any clarification questions.

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

@@ -293,9 +293,11 @@ After updating the plan:
    - ✅ Edge case coverage
    - ✅ Testing strategy
    
-   **Next step:** Run `/hula-launch <branch-name>` to create the GitHub issue and start the AI-assisted implementation pipeline.
+   🚀 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.
+
 ## Important Guidelines
 
 ### Auto-Fix Capability

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

@@ -144,5 +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.
 
-**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. `/hula-confirm` remains available as a standalone command for re-validation at any time.
+**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/package.json

@@ -1,6 +1,6 @@
 {
   "name": "hub-launch",
-  "version": "1.11.0",
+  "version": "1.11.1",
   "description": "GitHub Issue and PR automation CLI tool with plugin/hook system for project-specific customizations",
   "type": "module",
   "main": "./dist/index.js",