@devshop/crew 0.11.0 → 0.11.2

package/CHANGELOG.md

@@ -1,3 +1,17 @@
+## [0.11.2](https://github.com/devshop-software/crew/compare/v0.11.1...v0.11.2) (2026-05-12)
+
+
+### Bug Fixes
+
+* **prep:** reshape boundary question as positive in-scope enumeration ([1c3db27](https://github.com/devshop-software/crew/commit/1c3db271a61d8a13cd14f6c24e68201ca980ca7c)), closes [#18](https://github.com/devshop-software/crew/issues/18)
+
+## [0.11.1](https://github.com/devshop-software/crew/compare/v0.11.0...v0.11.1) (2026-05-09)
+
+
+### Bug Fixes
+
+* **indie-agent:** timestamp workflow folders, commit progress log on run-done ([c9c8c35](https://github.com/devshop-software/crew/commit/c9c8c35c00c080f363c33c62595d6440b446547e))
+
 # [0.11.0](https://github.com/devshop-software/crew/compare/v0.10.1...v0.11.0) (2026-05-09)
 
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@devshop/crew",
-  "version": "0.11.0",
+  "version": "0.11.2",
   "description": "Project-agnostic Claude Code skills for spec → implement → qa → review → ship",
   "bin": {
     "crew": "scripts/cli.js"

package/skills/indie-agent/SKILL.md

@@ -58,9 +58,9 @@ The input may include a natural-language breakpoint instruction like "stop after
 
 ## Step 1W — Worktree Setup (new features only)
 
-1. **Derive the folder name:** Short, scannable kebab-case name (2–5 words) derived from the input. No timestamp prefix in the directory name. Example: `dark-mode`, `auth-refactor`, `db-seed-script`
-2. **Derive the branch name:** `<branch-prefix>YYYYMMDD-HHMM-<folder-name>` using the current timestamp. Example: `feature/20260413-1423-dark-mode`. The timestamp lives in the branch name, not the directory.
-3. **Determine the worktree path:** `../../wt/<folder-name>` — inside the `wt/` subdirectory at the project root. Example: if you're running from `~/projects/rival.sale/main`, the worktree goes to `~/projects/rival.sale/wt/dark-mode`.
+1. **Derive the folder name:** `YYYYMMDD-HHMM-<kebab>` using the current local timestamp + a short kebab-case description (2–5 words) derived from the input. Example: `20260509-1932-competitor-monitoring-toggle`. The timestamped form is the single name used for the workflow folder, the worktree directory, and the branch suffix — folders sort chronologically when listed.
+2. **Derive the branch name:** `<branch-prefix><folder-name>`. Example: `feature/20260509-1932-competitor-monitoring-toggle`.
+3. **Determine the worktree path:** `../../wt/<folder-name>` — inside the `wt/` subdirectory at the project root. Example: if you're running from `~/projects/rival.sale/main`, the worktree goes to `~/projects/rival.sale/wt/20260509-1932-competitor-monitoring-toggle`.
 4. **Create the worktree:** `mkdir -p ../../wt && git worktree add <worktree-path> -b <branch-name> <base-branch>`
 5. **Copy local environment files:** Copy `.env` (and `.env.local` if it exists) from the current worktree into the new worktree. These are gitignored and won't exist in the fresh checkout.
 6. **Switch context:** all subsequent steps run inside the worktree directory
@@ -445,9 +445,12 @@ Write `05-indie-summary.md` in the workflow folder:
 
 After writing the summary:
 
-1. Stage `05-indie-summary.md`: `git add <workflow-dir>/<folder-name>/05-indie-summary.md`
-2. Commit: `docs: add indie agent run summary for <feature-name>`
-3. Push to the same branch
+1. Append a final `[orchestrator] <ISO-8601 UTC> — run done` line to `<workflow-dir>/<folder-name>/_progress.log`.
+2. Stage both the summary and the progress log: `git add <workflow-dir>/<folder-name>/05-indie-summary.md <workflow-dir>/<folder-name>/_progress.log`
+3. Commit: `docs: add indie agent run summary for <feature-name>`
+4. Push to the same branch
+
+Why both files: ship's own log lines (commit, push, PR creation) are written *after* ship's commit and never make it into the PR otherwise. This step is the catch-all that ensures the full run is recorded in git.
 
 Present the final report to the user: PR URL, check status, iteration counts, and worktree path. Remind: "After merge, clean up with: `git worktree remove <path> && rm -rf <path>`"
 
@@ -462,7 +465,7 @@ Present the final report to the user: PR URL, check status, iteration counts, an
 - Dispatch implementation, QA, and fix-loop phases with `run_in_background: true` so the orchestrator stays responsive
 - Verify the output artifact after every agent returns before proceeding
 - Create a dedicated worktree for each new feature
-- Use short, scannable folder names in `wt/` (timestamp goes in the branch name, not the directory)
+- Timestamp the workflow folder, worktree directory, and branch with the same `YYYYMMDD-HHMM-<kebab>` form so workflows sort chronologically
 - Check artifact state before each phase — never re-run completed phases
 - On "status" queries from the user while a subagent is running, read `_progress.log` — never peek into the subagent's thinking (you can't)
 - Reinforce the progress-log mandate in every phase's task instructions — the log is the only signal the orchestrator has

package/skills/prep/SKILL.md

@@ -60,7 +60,7 @@ Ask targeted questions in **one batch** (not drip-fed). Choose 3–6 from:
 1. **What's broken / needed** — one sentence in the user's own words, if the rough description was vague.
 2. **Concrete motivating source** — a PR, bug report, dated incident, workflow folder, ticket. "Why now?" This often becomes the brief's strongest paragraph.
 3. **Decisions already made** — what has the user already ruled in or out? These are the non-obvious constraints no code-reading will reveal (e.g. *"we're nuking both DBs before this lands"*).
-4. **Boundary** — where's the edge of this feature? What's adjacent that we want to deliberately leave alone — something a developer might be tempted to also fix here? Ask even if the user didn't mention it; this is where briefs silently fail.
+4. **Boundary** — what's in scope at the edges? Name 2–5 adjacent things (files, capabilities, models, flows) and for each, mark whether this feature touches it or not. Ground every candidate in something concrete you saw in Step 2 — a file path, a table, a flow — not abstract categories. Frame the question to the user as a positive enumeration (*"which of these are in scope?"*), never as negation (*"what's excluded?"*). The Out-of-scope section is derived at draft time from the candidates the user did not mark as in-scope; do not ask the user to enumerate exclusions directly.
 5. **Acceptance shape** — what must be observably true when this is done? 1–3 items, not exhaustive. You'll flesh them out when drafting.
 6. **Post-merge manual steps** — anything a human has to do after the PR merges (DB operations, flag flips, smoke checks)?
 
@@ -232,4 +232,5 @@ If you catch yourself thinking any of these, stop:
 - *"The human section needs more detail to be complete"* — STOP. If a reader can't stop after that section, you've overloaded it. Move the detail to the agent section.
 - *"The acceptance criteria are general on purpose, to leave flexibility"* — STOP. Vague criteria are the #1 reason `/indie-agent` drifts. Be specific.
 - *"This brief is ready — I didn't ask about out-of-scope because the user didn't mention it"* — STOP. Ask. Out-of-scope is where briefs silently fail.
+- *"I'll ask the user to list what's NOT in scope"* or *"I'll show a multi-select of things to exclude"* — STOP. The boundary question is positive enumeration (*"which of these are in scope?"*). Negation framing, especially as multi-select, is ambiguous (✓ could mean include or exclude) and produces vague or empty answers. Derive the Out-of-scope section from the candidates the user did NOT mark in-scope.
 - *"The user stated an outcome and I'm writing a mechanism"* — STOP. If the user said "swap X for Y when Z," that's what the brief says. `useSidebar()`, CSS strategies, component extraction, which file to modify — those are `/spec`'s calls, made after codebase exploration. Pre-deciding them here looks helpful but strips spec-writer's ability to weigh alternatives.