@devshop/crew 0.8.0 → 0.9.0

package/CHANGELOG.md

@@ -1,3 +1,17 @@
+# [0.9.0](https://github.com/devshop-software/crew/compare/v0.8.1...v0.9.0) (2026-05-07)
+
+
+### Features
+
+* **prep:** simplify input handling and rephrase boundary question ([2679e32](https://github.com/devshop-software/crew/commit/2679e3208a36aaca816e3997914707874ff5709f))
+
+## [0.8.1](https://github.com/devshop-software/crew/compare/v0.8.0...v0.8.1) (2026-04-30)
+
+
+### Bug Fixes
+
+* don't rewrite users' version range on self-update ([a85a3c3](https://github.com/devshop-software/crew/commit/a85a3c38485f9613bb5a3f679dff08d472601568))
+
 # [0.8.0](https://github.com/devshop-software/crew/compare/v0.7.0...v0.8.0) (2026-04-30)
 
 

package/README.md

@@ -19,7 +19,7 @@ pnpm exec crew init
 
 To pull newer skill content later, run `pnpm exec crew update`. The flow:
 
-1. Auto-detects the package manager (pnpm / npm / yarn / bun) from your lockfile and runs `<pm> update @devshop/crew --latest` to bump the package.
+1. Auto-detects the package manager (pnpm / npm / yarn / bun) from your lockfile and runs `<pm> update @devshop/crew` to bump the package within the range you've pinned in `package.json`. To always pull the absolute newest (including across major versions), set the range to `"latest"`; for "any 0.x" use `"0.x"`.
 2. Re-execs the freshly-installed CLI.
 3. Computes the diff and prints a plan: which skills will be added, updated, replaced (had local edits), or removed (no longer in the package).
 4. Prompts `Apply these changes? [Y/n]`. Default Y. Press `n` to abort with no writes.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@devshop/crew",
-  "version": "0.8.0",
+  "version": "0.9.0",
   "description": "Project-agnostic Claude Code skills for spec → implement → qa → review → ship",
   "bin": {
     "crew": "scripts/cli.js"
@@ -38,7 +38,7 @@
   },
   "license": "MIT",
   "devDependencies": {
-    "@devshop/crew": "0.x",
+    "@devshop/crew": "~0.8.0",
     "@semantic-release/changelog": "^6.0.3",
     "@semantic-release/exec": "^7.1.0",
     "@semantic-release/git": "^10.0.1",

package/scripts/lib/self-update.js

@@ -38,11 +38,16 @@ function isLocalDep(projectRoot) {
   } catch { return false; }
 }
 
+// Range-respecting update so we don't rewrite the user's package.json
+// version specifier. To always pull the absolute latest across majors,
+// users can pin "@devshop/crew": "latest" in their package.json (a dist-tag,
+// not a semver range — never gets rewritten); for "all 0.x but never 1.x"
+// use "0.x". Any caret/tilde range will be honored as written.
 const UPDATE_ARGS = {
-  pnpm: ['update', PACKAGE_NAME, '--latest'],
-  npm: ['install', `${PACKAGE_NAME}@latest`],
-  yarn: ['upgrade', PACKAGE_NAME, '--latest'],
-  bun: ['update', PACKAGE_NAME, '--latest']
+  pnpm: ['update', PACKAGE_NAME],
+  npm: ['update', PACKAGE_NAME],
+  yarn: ['upgrade', PACKAGE_NAME],
+  bun: ['update', PACKAGE_NAME]
 };
 
 // Returns one of:

package/skills/prep/SKILL.md

@@ -25,8 +25,7 @@ Activate when called from the `/prep` command. Otherwise ignore.
 
 - **Empty** — ask: *"What's the feature? A one-sentence description works."*
 - **Free text** — a rough description. Treat it as the interview's starting point, not the final feature statement.
-- **Path to an existing `*-BRIEF.md`** — enter **edit mode**: read it, ask what should change, update in place.
-- Contains `--quick` — skip the interview and produce the brief in one pass from whatever context the user gave. Use this only when the user has already stated the feature clearly enough to write the brief without follow-up.
+- **Path to an existing `*-BRIEF.md`** — read it, identify which sections are empty or thin, run the interview only for those gaps.
 
 ---
 
@@ -54,14 +53,14 @@ Before asking questions, spend a few minutes verifying the feature maps to real
 
 ---
 
-## Step 3 — Interview (skip if `--quick`)
+## Step 3 — Interview
 
 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. **Out of scope** — what's tempting but explicitly excluded? Ask even if the user didn't mention it; out-of-scope is where briefs silently fail.
+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.
 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)?
 
@@ -91,8 +90,6 @@ Consequence for downstream skills: **ingest the brief's content, do not cite its
 
 `<SLUG>-BRIEF.md` — uppercase kebab-case slug derived from the feature title (e.g. `MIGRATION-CONSOLIDATION-BRIEF.md`, `DARK-MODE-BRIEF.md`). The `-BRIEF.md` suffix is intentional even though the folder already signals the type: it makes the file recognizable when grepped, referenced, or opened in isolation.
 
-An optional second argument to `/prep` may override the full output path. Default follows the rule above.
-
 ### Structure
 
 The brief has two clearly-delimited sections. The human section comes first so a reader can stop there.
@@ -201,17 +198,6 @@ If the user requests changes, update in place. Re-present only the changed secti
 
 ---
 
-## Edit mode
-
-When invoked with a path to an existing brief:
-
-1. Read it.
-2. Ask what should change (or act on the user's input if they already said).
-3. Update in place; preserve the two-section structure.
-4. Re-present the changed section only.
-
----
-
 ## Constraints
 
 **DO:**
@@ -225,7 +211,7 @@ When invoked with a path to an existing brief:
 - Embed project-specific tool names, framework names, or conventions into the skill file itself. This skill must work in any codebase that has a `CLAUDE.md`.
 - Duplicate content across the two sections — state each thing once, in the section where it belongs.
 - Pad the human section with mechanical detail. If it's longer than one screen, it's failing.
-- Skip the interview in default mode. The point of `/prep` is to extract what only the user knows.
+- Skip the interview. The point of `/prep` is to extract what only the user knows.
 - Explore the codebase to spec-writer depth. This is *pre-spec* work.
 - Prescribe mechanisms (hooks, CSS utilities, component layout, file-level changes) unless the user explicitly committed to one during the interview. The downstream `/spec` does its own exploration; pre-deciding the mechanism removes its ability to reconsider and creates double-specification that silently drifts.
 - Pre-stamp the spec's depth. `/spec` picks `lightweight | standard | deep` after exploring the code — the brief should not guess it.