@devshop/crew 0.8.1 → 0.9.1

package/CHANGELOG.md

@@ -1,3 +1,17 @@
+## [0.9.1](https://github.com/devshop-software/crew/compare/v0.9.0...v0.9.1) (2026-05-07)
+
+
+### Bug Fixes
+
+* **prep:** workspace-aware project-root resolution ([51b13c2](https://github.com/devshop-software/crew/commit/51b13c2d053e6435862f474e9cda339e5ff0da54))
+
+# [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)
 
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@devshop/crew",
-  "version": "0.8.1",
+  "version": "0.9.1",
   "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/skills/prep/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: prep
-description: Interactive brief-writer. Produces a two-part `<FEATURE>-BRIEF.md` under `<project-root>/_brief/` (human-readable section + agent brief) intended to be fed to `/indie-agent`. Project root is auto-detected (bare-clone layout via `.bare/`, otherwise git toplevel). Reads project conventions from `CLAUDE.md` at runtime — contains no project-specific knowledge. Use when the user invokes /prep.
+description: Interactive brief-writer. Produces a two-part `<FEATURE>-BRIEF.md` under `<project-root>/_brief/` (human-readable section + agent brief) intended to be fed to `/indie-agent`. Project root is auto-detected: nearest ancestor whose `CLAUDE.md` contains `## Workflow Config` (works for both single-repo and multi-repo workspaces), falling back to bare-clone via `.bare/` or git toplevel if no workflow config is set yet. Reads project conventions from `CLAUDE.md` at runtime — contains no project-specific knowledge. Use when the user invokes /prep.
 ---
 
 # Prep
@@ -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)?
 
@@ -75,15 +74,20 @@ If an answer is vague, follow up once. Two rounds max — don't interrogate.
 
 Briefs live in `<project-root>/_brief/<SLUG>-BRIEF.md`. Resolve the project root generically, in this order:
 
-1. **Bare-clone layout** — walk up from CWD. If any ancestor directory contains a `.bare/` subdirectory (a bare git repo used by a worktree-layout setup), that ancestor is the project root.
-2. **Regular git repo** — otherwise, run `git rev-parse --show-toplevel`. The result is the project root.
-3. **Fallback** — if neither applies, use the CWD and warn the user that no project root was detected.
+1. **Workflow Config anchor (preferred)** — walk up from CWD. The first ancestor whose `CLAUDE.md` contains a `## Workflow Config` heading is the project root. This works for both shapes:
+   - **Single-repo project** — the project-root `CLAUDE.md` has `## Workflow Config` (written by `/adjust`). Found at the project root.
+   - **Multi-repo workspace** — the workspace-root `CLAUDE.md` has `## Workflow Config`; sub-repo `CLAUDE.md` files (if any exist inside `<stack>/main/`) do not, since `/adjust` only writes workflow config at workspace root. Walking up from `backend/main/<wt>/` finds the workspace root, not the stack root.
+2. **Bare-clone layout (fallback)** — if no `## Workflow Config` is found above, walk up looking for a `.bare/` subdirectory. The ancestor containing it is the project root. (Used when `/adjust` hasn't run yet but the bare-clone is set up.)
+3. **Regular git repo (fallback)** — otherwise, run `git rev-parse --show-toplevel`. The result is the project root.
+4. **Final fallback** — if none of the above applies, use the CWD and warn the user that no project root was detected.
+
+In workspace mode, the resolved project root is the **workspace root** — the brief lives there, not inside any sub-repo. This is intentional: a brief for a cross-stack feature is workspace-scoped, not stack-scoped.
 
 Create `<project-root>/_brief/` if it does not exist. Write the file there.
 
 ### Lifecycle — the brief is ephemeral
 
-The brief lives at the **top layer** of the project (e.g. the bare-clone root), outside any tracked working copy. It is not committed and will be deleted once consumed. History of a feature lives in `<workflow-dir>/` under the worktree that shipped it — that is where spec, implementation, QA, and review artifacts persist.
+The brief lives at the **top layer** of the project — the bare-clone root in single-repo projects, or the workspace root in multi-repo workspaces — outside any tracked working copy. It is not committed and will be deleted once consumed. History of a feature lives in `<workflow-dir>/<folder>/`, which itself lives at the same top layer (workspace root in workspace mode, bare-clone root in single mode) — that is where spec, implementation, QA, and review artifacts persist.
 
 Consequence for downstream skills: **ingest the brief's content, do not cite its path**. A `_workflow/.../01-spec.md` that references `../_brief/FOO-BRIEF.md` will break the first time someone cleans up `_brief/`. Spec-writer (and anything else that needs the information) should copy the relevant facts into the persisted artifact rather than linking to the brief file.
 
@@ -91,8 +95,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.
@@ -181,7 +183,7 @@ Briefs are ephemeral handoff artifacts and should not be committed.
 1. Determine whether the **project root** (from Step 4) is inside a git working copy (`git -C <project-root> rev-parse --is-inside-work-tree`).
 2. If yes, read the project root's `.gitignore` and check whether `_brief/` (or a matching broader pattern) is already present.
 3. If not, append `_brief/` with a short comment explaining what it is.
-4. If the project root is **not** inside a working copy (typical for a bare-clone root, which only hosts sibling worktrees), skip this step. The folder is outside any tracked tree, so gitignore is irrelevant. Note this to the user so they understand why no `.gitignore` was touched.
+4. If the project root is **not** inside a working copy (typical for a bare-clone root or a multi-repo workspace root, neither of which is itself a git repo), skip this step. The folder is outside any tracked tree, so gitignore is irrelevant. Note this to the user so they understand why no `.gitignore` was touched.
 
 Never create a `.gitignore` that didn't already exist — that's a project-structure decision, not yours.
 
@@ -201,17 +203,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 +216,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.