create-battle-plan 1.1.0 → 1.1.1

package/bin/cli.js

@@ -590,18 +590,18 @@ ${peopleSections}
 
   console.log(`${DIM}   ─────────────────────────────${RESET}`);
   console.log('');
-  console.log(`${CYAN}${BOLD}   Next steps:${RESET}`);
+  console.log(`${CYAN}${BOLD}   To start your first session,${RESET}`);
+  console.log(`${CYAN}${BOLD}   copy and paste this into your terminal:${RESET}`);
   console.log('');
-  console.log(`   ${BOLD}cd ${path.relative(process.cwd(), targetDir) || '.'}${RESET}`);
-  console.log(`   ${BOLD}claude${RESET}`);
+  const relPath = path.relative(process.cwd(), targetDir) || '.';
+  console.log(`${DIM}   ┌─────────────────────────────────────────┐${RESET}`);
+  console.log(`${DIM}   │${RESET}  ${BOLD}cd ${relPath} && claude${RESET}${DIM}${' '.repeat(Math.max(0, 37 - relPath.length - 12))}│${RESET}`);
+  console.log(`${DIM}   └─────────────────────────────────────────┘${RESET}`);
   console.log('');
-  console.log(`   Then type ${GREEN}${BOLD}/good-morning${RESET} to start`);
-  console.log(`   your first session.`);
-  console.log('');
-  console.log(`${DIM}   Claude already knows your project, metrics,`);
-  console.log(`   and team. Just dump context into the chat —`);
-  console.log(`   call transcripts, research, meeting notes,`);
-  console.log(`   replies — it'll cascade into the right docs.${RESET}`);
+  console.log(`   Once Claude is running, type ${GREEN}${BOLD}/good-morning${RESET}`);
+  console.log(`   to start your first session. Claude will`);
+  console.log(`   introduce itself, explain how everything`);
+  console.log(`   works, and help you set your first targets.`);
   console.log('');
 }
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "create-battle-plan",
-  "version": "1.1.0",
+  "version": "1.1.1",
   "description": "Scaffold a Battle Plan project — a markdown-based context system for LLM-powered project management",
   "bin": {
     "create-battle-plan": "./bin/cli.js"

package/template/.claude/commands/good-morning.md

@@ -4,32 +4,65 @@ description: Morning standup — status briefing, metrics snapshot, and today's
 
 # Morning Standup
 
-Run these steps in order. Be concise — the user wants a briefing, not an essay.
+Run these steps in order.
 
 ## Step 0: First-Run Welcome (one time only)
 
-Check if `.battle-plan-onboarding.json` exists. If it does, this is the user's FIRST session after running `npx create-battle-plan`. Do the following:
+Check if `.battle-plan-onboarding.json` exists in the repo root. If it does, this is the user's **FIRST session** after running `npx create-battle-plan`. This is a special moment — the user just installed this and wants to understand what they've got. Make them feel like their project is in good hands.
 
-1. Read `.battle-plan-onboarding.json` to get their project context
-2. **Welcome them by reflecting what they told the installer** — project name, horizon, metrics, domains, people. Show them you already have full context. Make them feel like they're picking up mid-conversation, not starting from scratch.
-3. **Explain what Battle Plan is and how it works**, briefly:
-   - "Battle Plan keeps your project context in markdown files that stay in sync. When you tell me something new — a call, a reply, a metric change — I update a chain of docs in a fixed order so nothing gets dropped."
-   - Mention the cascade: metrics.yml → battle plan → source docs → verification
-   - Mention: "Just dump context into the chat. Call transcripts, research, meeting notes, replies — I'll cascade it into the right docs."
-4. **Explain the commands:**
-   - `/good-morning` — start each session with a status briefing (what you're running now)
-   - `/wrap-up` — end each session cleanly: status review, cascade, metrics report, commit
-   - `/distill` — compress docs when they get too long for me to read efficiently
-5. **Explain metrics:** "Your metrics live in `metrics.yml`. Every number in every doc traces back to that file. Scripts verify they stay in sync. You never have to worry about stale numbers."
-6. **Explain what to do next:** "Set targets for your metrics in the battle plan, then start working. Tell me about any calls, research, or updates and I'll keep everything current."
-7. Rename `.battle-plan-onboarding.json` to `.battle-plan-onboarding-done.json` so this welcome doesn't repeat.
+**Read `.battle-plan-onboarding.json`** to get their project context. Then write a warm, personal welcome that covers ALL of the following. This should feel like a knowledgeable co-pilot introducing itself, not a product manual.
 
-Then proceed to the normal standup flow below (Steps 1-4).
+### Part 1: Personal welcome (reflect their project back to them)
+
+Greet them warmly. Show them you already know their project by name, their time horizon, their metrics, their domains, and their people. Reference these specifics naturally — don't just list them. The user should feel like they're continuing a conversation, not configuring a tool.
+
+Example tone: "Welcome to your battle plan for [project]. You've got [horizon] and you're tracking [metrics] — I've got all of that loaded and ready to go."
+
+### Part 2: What this is (the big picture)
+
+Explain what they now have, in plain language:
+
+- **This is your project's memory.** Every conversation, decision, metric, and insight lives here in markdown files. When you close this chat and come back tomorrow — or next week — I read these files and pick up exactly where we left off. Nothing gets lost between sessions.
+- **You don't organize anything.** When you tell me something new — a call you had, research you found, a number that changed, a reply you got — I update the right files in the right order automatically. That's called the cascade.
+- **The cascade works like this:** new info flows into `metrics.yml` first (if a number changed), then into your battle plan (the operating doc that tracks where you are), then into the source docs for each domain. At the end, a verification script checks that everything is consistent.
+- **Think of it as dumping context.** You can paste a full call transcript, a messy list of notes, a forwarded email, a research summary — anything. You don't need to format it or tell me where it goes. Just dump it in and I'll cascade it to the right places.
+
+### Part 3: How to use it day to day
+
+Explain the rhythm:
+
+- **Start each session** with `/good-morning` (what you just ran). I'll brief you on where you stand — metrics, priorities, what's stuck, what's next. Think of it as a daily standup with your AI co-pilot.
+- **During the day**, just talk to me. Tell me what happened, paste in notes, ask me to update things. Every piece of new info triggers the cascade automatically.
+- **End each session** with `/wrap-up`. I'll review the day, show you what changed, sync everything, and offer to commit. This is how you close out clean without forgetting to log something.
+- **When docs get long**, run `/distill`. Over time, your daily logs and conversation journals will grow. `/distill` compresses older content into a thorough summary and archives the raw text — nothing is ever deleted, but I can read the docs faster.
+
+### Part 4: How metrics work
+
+- Your key metrics live in `metrics.yml` — it's the single numeric source of truth for the whole project.
+- Every number that appears in any doc traces back to that file via source annotations. When a metric changes, the cascade propagates the new value everywhere it's referenced.
+- Shell scripts verify the numbers stay in sync. You'll never have a stale "42" in one doc when the real number is "47" in another.
+- Right now all your metrics are at zero. One of the first things we'll do is set targets.
+
+### Part 5: What to do right now
+
+Transition into action:
+
+- "Let's start by getting some real data into the system. Here's what I'd suggest..."
+- Prompt them to set targets for their metrics
+- Ask if there's any existing context they already have — calls they've had, research they've done, decisions they've already made. Anything they can tell you now will make the battle plan immediately useful.
+
+### After the welcome
+
+Rename `.battle-plan-onboarding.json` to `.battle-plan-onboarding-done.json` so this welcome doesn't repeat.
+
+Then show a **compact metrics table** (all zeros, no targets yet) and transition into the onboarding questions naturally. Don't run the full standup format (Steps 1-4 below) on the first run — there's nothing to report yet. Instead, go straight to helping them populate the battle plan.
 
 ---
 
 ## Step 1: Gather State (parallel reads)
 
+*Skip this on first run (Step 0 handles it). On all subsequent runs, start here.*
+
 Read all of these in parallel:
 - `metrics.yml` — current numbers
 - `docs/battle-plan.md` — TL;DR + latest day log (find today or the most recent day entry)
@@ -71,4 +104,6 @@ After the user answers:
 
 ## Tone
 
-Direct, no fluff. Think military briefing, not newsletter.
+On first run: warm, confident, thorough. The user should feel like they just hired a great project manager who already read the brief.
+
+On subsequent runs: direct, no fluff. Think military briefing, not newsletter.