devflow-kit 1.6.1 → 1.8.0

package/plugins/devflow-implement/skills/self-review/references/stub-detection.md

@@ -0,0 +1,135 @@
+# Stub Detection Patterns
+
+Placeholder implementations that compile but don't deliver real functionality. Flag as **P0-Functionality** issues.
+
+Cross-reference: `core-patterns/references/code-smell-violations.md` covers hardcoded data and fake functionality labeling. This file focuses on structural stub patterns.
+
+---
+
+## 1. Component Stubs
+
+Render nothing meaningful or return placeholder markup.
+
+```tsx
+// STUB — returns static text, no real rendering
+function UserProfile({ userId }: Props) {
+  return <div>Name</div>;
+}
+
+// REAL — fetches and renders actual data
+function UserProfile({ userId }: Props) {
+  const user = useUser(userId);
+  if (!user) return <Skeleton />;
+  return <div><h2>{user.name}</h2><p>{user.email}</p></div>;
+}
+```
+
+**Patterns to flag:**
+- `return null` / `return <></>` in components that should render content
+- Empty function bodies (`{}`) for handlers or lifecycle methods
+- Components returning only hardcoded strings with no data binding
+
+---
+
+## 2. API / Service Stubs
+
+Functions that exist in signature but throw, return hardcoded values, or do nothing.
+
+```typescript
+// STUB — throws instead of implementing
+async function createOrder(items: CartItem[]): Promise<Order> {
+  throw new Error("TODO: implement");
+}
+
+// STUB — hardcoded return, no real logic
+async function getUser(id: string): Promise<User> {
+  return { id, name: "Test User", email: "test@test.com" };
+}
+
+// REAL — actual implementation
+async function createOrder(items: CartItem[]): Promise<Result<Order, OrderError>> {
+  const validated = validateItems(items);
+  if (!validated.ok) return validated;
+  const order = await db.orders.create({ items: validated.value });
+  await queue.publish("order.created", order);
+  return { ok: true, value: order };
+}
+```
+
+**Patterns to flag:**
+- `throw new Error("TODO")` / `throw new Error("Not implemented")`
+- Functions returning hardcoded objects (no DB/API/computation)
+- `"Not implemented"` strings in response bodies
+- Empty async functions (`async function foo() {}`)
+
+---
+
+## 3. Hook / Effect Stubs
+
+State and effects declared but not wired to behavior.
+
+```typescript
+// STUB — effect does nothing
+useEffect(() => {}, [userId]);
+
+// STUB — state declared, setter never called
+const [items, setItems] = useState<Item[]>([]);
+// ... setItems never appears in the component
+
+// STUB — custom hook returns static value
+function usePermissions(): Permissions {
+  return { canEdit: true, canDelete: false };
+}
+
+// REAL — custom hook with actual logic
+function usePermissions(): Permissions {
+  const { user } = useAuth();
+  const { data } = useQuery(["permissions", user.role], fetchPermissions);
+  return data ?? DEFAULT_PERMISSIONS;
+}
+```
+
+**Patterns to flag:**
+- `useEffect(() => {}, [...])` — empty effect body
+- `useState` where the setter is never called in the component
+- Custom hooks returning static/hardcoded values
+- `useMemo`/`useCallback` wrapping static values
+
+---
+
+## 4. Wiring Gaps
+
+Individual pieces exist but aren't connected to the running application. **Highest-value detection** — these pass compilation and individual tests but the feature doesn't work end-to-end.
+
+```typescript
+// GAP — fetch without await (result discarded)
+function loadDashboard() {
+  fetchMetrics(); // Promise floats, never awaited
+  return <Dashboard />;
+}
+
+// GAP — state declared but never rendered
+const [error, setError] = useState<string | null>(null);
+// ... error never appears in JSX
+
+// GAP — handler defined but not bound
+function handleSubmit(data: FormData) { /* real logic */ }
+// ... <form onSubmit={handleSubmit}> never appears
+
+// GAP — route defined with no-op handler
+app.post("/api/orders", (_req, res) => {
+  res.status(200).json({ ok: true });
+});
+
+// GAP — env var read but unused
+const API_KEY = process.env.STRIPE_API_KEY;
+// ... API_KEY never passed to any client or fetch call
+```
+
+**Patterns to flag:**
+- `fetch`/`axios`/API call without `await` or `.then` (result discarded)
+- State variable (`useState`, `useRef`) never rendered or read in output
+- Event handler defined but not bound to any element/listener
+- Route/endpoint registered with empty or no-op handler
+- Environment variable or config read but never used downstream
+- Import used only in type position but imported as value (in non-type-only import)

package/plugins/devflow-java/.claude-plugin/plugin.json

@@ -4,7 +4,7 @@
   "author": {
     "name": "Dean0x"
   },
-  "version": "1.6.1",
+  "version": "1.8.0",
   "homepage": "https://github.com/dean0x/devflow",
   "repository": "https://github.com/dean0x/devflow",
   "license": "MIT",

package/plugins/devflow-python/.claude-plugin/plugin.json

@@ -4,7 +4,7 @@
   "author": {
     "name": "Dean0x"
   },
-  "version": "1.6.1",
+  "version": "1.8.0",
   "homepage": "https://github.com/dean0x/devflow",
   "repository": "https://github.com/dean0x/devflow",
   "license": "MIT",

package/plugins/devflow-react/.claude-plugin/plugin.json

@@ -4,7 +4,7 @@
   "author": {
     "name": "Dean0x"
   },
-  "version": "1.6.1",
+  "version": "1.8.0",
   "homepage": "https://github.com/dean0x/devflow",
   "repository": "https://github.com/dean0x/devflow",
   "license": "MIT",

package/plugins/devflow-resolve/.claude-plugin/plugin.json

@@ -4,7 +4,7 @@
   "author": {
     "name": "Dean0x"
   },
-  "version": "1.6.1",
+  "version": "1.8.0",
   "homepage": "https://github.com/dean0x/devflow",
   "repository": "https://github.com/dean0x/devflow",
   "license": "MIT",

package/plugins/devflow-resolve/agents/simplifier.md

@@ -30,31 +30,39 @@ Analyze recently modified code and apply refinements that:
    - Use proper error handling patterns (avoid try/catch when possible)
    - Maintain consistent naming conventions
 
-3. **Enhance Clarity**: Simplify code structure by:
-
-   - Reducing unnecessary complexity and nesting
-   - Eliminating redundant code and abstractions
-   - Improving readability through clear variable and function names
+3. **Remove Slop**: Detect and remove these categories:
+
+   | Category | Pattern |
+   |----------|---------|
+   | Language-behavior tests | Tests verifying built-in language features work as documented |
+   | Redundant type checks | Runtime checks for types TypeScript already enforces |
+   | Over-defensive handling | try/catch around code that cannot throw |
+   | Debug remnants | console.log, debugger, alert() left behind |
+   | Commented-out code | Dead code preserved in comments |
+   | Unused imports | Imports not referenced anywhere in file |
+   | Verbose names | Unnecessarily long names (`currentUserDataObject` → `user`) |
+   | Unnecessary intermediates | Variables used once, immediately after assignment |
+
+4. **Enhance Clarity**: Simplify code structure by:
+
+   - Reducing unnecessary nesting (early returns, guard clauses)
    - Consolidating related logic
-   - Removing unnecessary comments that describe obvious code
-   - IMPORTANT: Avoid nested ternary operators - prefer switch statements or if/else chains for multiple conditions
-   - Choose clarity over brevity - explicit code is often better than overly compact code
+   - Avoiding nested ternary operators — prefer switch or if/else
+   - Choosing clarity over brevity — explicit code beats compact code
 
-4. **Maintain Balance**: Avoid over-simplification that could:
+5. **Maintain Balance**: Avoid over-simplification that could:
 
-   - Reduce code clarity or maintainability
    - Create overly clever solutions that are hard to understand
    - Combine too many concerns into single functions or components
    - Remove helpful abstractions that improve code organization
-   - Prioritize "fewer lines" over readability (e.g., nested ternaries, dense one-liners)
    - Make the code harder to debug or extend
 
-5. **Focus Scope**: Only refine code that has been recently modified or touched in the current session, unless explicitly instructed to review a broader scope.
+6. **Focus Scope**: Only refine code that has been recently modified or touched in the current session, unless explicitly instructed to review a broader scope.
 
 Your refinement process:
 
 1. Identify the recently modified code sections
-2. Analyze for opportunities to improve elegance and consistency
+2. Analyze for slop categories and clarity improvements
 3. Apply project-specific best practices and coding standards
 4. Ensure all functionality remains unchanged
 5. Verify the refined code is simpler and more maintainable
@@ -87,7 +95,8 @@ Return structured completion status:
 - Files outside the recently modified scope (unless instructed)
 
 **Handle autonomously:**
-- Naming improvements, dead code removal, nesting reduction
+- Slop removal (all 8 categories)
+- Naming improvements, nesting reduction
 - Import sorting and organization
 - Redundant abstraction elimination
-- Comment cleanup (remove obvious, keep non-obvious)
+- Comment cleanup (remove obvious, keep non-obvious)

package/plugins/devflow-rust/.claude-plugin/plugin.json

@@ -4,7 +4,7 @@
   "author": {
     "name": "Dean0x"
   },
-  "version": "1.6.1",
+  "version": "1.8.0",
   "homepage": "https://github.com/dean0x/devflow",
   "repository": "https://github.com/dean0x/devflow",
   "license": "MIT",

package/plugins/devflow-self-review/.claude-plugin/plugin.json

@@ -4,7 +4,7 @@
   "author": {
     "name": "Dean0x"
   },
-  "version": "1.6.1",
+  "version": "1.8.0",
   "homepage": "https://github.com/dean0x/devflow",
   "repository": "https://github.com/dean0x/devflow",
   "license": "MIT",

package/plugins/devflow-self-review/agents/scrutinizer.md

@@ -21,13 +21,15 @@ You receive from orchestrator:
 
 2. **Evaluate P0 pillars** (Design, Functionality, Security): These MUST pass. Fix all issues found.
 
-3. **Evaluate P1 pillars** (Complexity, Error Handling, Tests): These SHOULD pass. Fix all issues found.
+3. **Detect stubs and wiring gaps**: Check for placeholder implementations that compile but don't deliver real functionality. See `references/stub-detection.md` for patterns. Flag as P0-Functionality issues.
 
-4. **Evaluate P2 pillars** (Naming, Consistency, Documentation): Report as suggestions. Fix if straightforward.
+4. **Evaluate P1 pillars** (Complexity, Error Handling, Tests): These SHOULD pass. Fix all issues found.
 
-5. **Commit fixes**: If any changes were made, create a commit with message "fix: address self-review issues".
+5. **Evaluate P2 pillars** (Naming, Consistency, Documentation): Report as suggestions. Fix if straightforward.
 
-6. **Report status**: Return structured report with pillar evaluations and changes made.
+6. **Commit fixes**: If any changes were made, create a commit with message "fix: address self-review issues".
+
+7. **Report status**: Return structured report with pillar evaluations and changes made.
 
 ## Principles
 

package/plugins/devflow-self-review/agents/simplifier.md

@@ -30,31 +30,39 @@ Analyze recently modified code and apply refinements that:
    - Use proper error handling patterns (avoid try/catch when possible)
    - Maintain consistent naming conventions
 
-3. **Enhance Clarity**: Simplify code structure by:
-
-   - Reducing unnecessary complexity and nesting
-   - Eliminating redundant code and abstractions
-   - Improving readability through clear variable and function names
+3. **Remove Slop**: Detect and remove these categories:
+
+   | Category | Pattern |
+   |----------|---------|
+   | Language-behavior tests | Tests verifying built-in language features work as documented |
+   | Redundant type checks | Runtime checks for types TypeScript already enforces |
+   | Over-defensive handling | try/catch around code that cannot throw |
+   | Debug remnants | console.log, debugger, alert() left behind |
+   | Commented-out code | Dead code preserved in comments |
+   | Unused imports | Imports not referenced anywhere in file |
+   | Verbose names | Unnecessarily long names (`currentUserDataObject` → `user`) |
+   | Unnecessary intermediates | Variables used once, immediately after assignment |
+
+4. **Enhance Clarity**: Simplify code structure by:
+
+   - Reducing unnecessary nesting (early returns, guard clauses)
    - Consolidating related logic
-   - Removing unnecessary comments that describe obvious code
-   - IMPORTANT: Avoid nested ternary operators - prefer switch statements or if/else chains for multiple conditions
-   - Choose clarity over brevity - explicit code is often better than overly compact code
+   - Avoiding nested ternary operators — prefer switch or if/else
+   - Choosing clarity over brevity — explicit code beats compact code
 
-4. **Maintain Balance**: Avoid over-simplification that could:
+5. **Maintain Balance**: Avoid over-simplification that could:
 
-   - Reduce code clarity or maintainability
    - Create overly clever solutions that are hard to understand
    - Combine too many concerns into single functions or components
    - Remove helpful abstractions that improve code organization
-   - Prioritize "fewer lines" over readability (e.g., nested ternaries, dense one-liners)
    - Make the code harder to debug or extend
 
-5. **Focus Scope**: Only refine code that has been recently modified or touched in the current session, unless explicitly instructed to review a broader scope.
+6. **Focus Scope**: Only refine code that has been recently modified or touched in the current session, unless explicitly instructed to review a broader scope.
 
 Your refinement process:
 
 1. Identify the recently modified code sections
-2. Analyze for opportunities to improve elegance and consistency
+2. Analyze for slop categories and clarity improvements
 3. Apply project-specific best practices and coding standards
 4. Ensure all functionality remains unchanged
 5. Verify the refined code is simpler and more maintainable
@@ -87,7 +95,8 @@ Return structured completion status:
 - Files outside the recently modified scope (unless instructed)
 
 **Handle autonomously:**
-- Naming improvements, dead code removal, nesting reduction
+- Slop removal (all 8 categories)
+- Naming improvements, nesting reduction
 - Import sorting and organization
 - Redundant abstraction elimination
-- Comment cleanup (remove obvious, keep non-obvious)
+- Comment cleanup (remove obvious, keep non-obvious)

package/plugins/devflow-self-review/skills/self-review/references/stub-detection.md

@@ -0,0 +1,135 @@
+# Stub Detection Patterns
+
+Placeholder implementations that compile but don't deliver real functionality. Flag as **P0-Functionality** issues.
+
+Cross-reference: `core-patterns/references/code-smell-violations.md` covers hardcoded data and fake functionality labeling. This file focuses on structural stub patterns.
+
+---
+
+## 1. Component Stubs
+
+Render nothing meaningful or return placeholder markup.
+
+```tsx
+// STUB — returns static text, no real rendering
+function UserProfile({ userId }: Props) {
+  return <div>Name</div>;
+}
+
+// REAL — fetches and renders actual data
+function UserProfile({ userId }: Props) {
+  const user = useUser(userId);
+  if (!user) return <Skeleton />;
+  return <div><h2>{user.name}</h2><p>{user.email}</p></div>;
+}
+```
+
+**Patterns to flag:**
+- `return null` / `return <></>` in components that should render content
+- Empty function bodies (`{}`) for handlers or lifecycle methods
+- Components returning only hardcoded strings with no data binding
+
+---
+
+## 2. API / Service Stubs
+
+Functions that exist in signature but throw, return hardcoded values, or do nothing.
+
+```typescript
+// STUB — throws instead of implementing
+async function createOrder(items: CartItem[]): Promise<Order> {
+  throw new Error("TODO: implement");
+}
+
+// STUB — hardcoded return, no real logic
+async function getUser(id: string): Promise<User> {
+  return { id, name: "Test User", email: "test@test.com" };
+}
+
+// REAL — actual implementation
+async function createOrder(items: CartItem[]): Promise<Result<Order, OrderError>> {
+  const validated = validateItems(items);
+  if (!validated.ok) return validated;
+  const order = await db.orders.create({ items: validated.value });
+  await queue.publish("order.created", order);
+  return { ok: true, value: order };
+}
+```
+
+**Patterns to flag:**
+- `throw new Error("TODO")` / `throw new Error("Not implemented")`
+- Functions returning hardcoded objects (no DB/API/computation)
+- `"Not implemented"` strings in response bodies
+- Empty async functions (`async function foo() {}`)
+
+---
+
+## 3. Hook / Effect Stubs
+
+State and effects declared but not wired to behavior.
+
+```typescript
+// STUB — effect does nothing
+useEffect(() => {}, [userId]);
+
+// STUB — state declared, setter never called
+const [items, setItems] = useState<Item[]>([]);
+// ... setItems never appears in the component
+
+// STUB — custom hook returns static value
+function usePermissions(): Permissions {
+  return { canEdit: true, canDelete: false };
+}
+
+// REAL — custom hook with actual logic
+function usePermissions(): Permissions {
+  const { user } = useAuth();
+  const { data } = useQuery(["permissions", user.role], fetchPermissions);
+  return data ?? DEFAULT_PERMISSIONS;
+}
+```
+
+**Patterns to flag:**
+- `useEffect(() => {}, [...])` — empty effect body
+- `useState` where the setter is never called in the component
+- Custom hooks returning static/hardcoded values
+- `useMemo`/`useCallback` wrapping static values
+
+---
+
+## 4. Wiring Gaps
+
+Individual pieces exist but aren't connected to the running application. **Highest-value detection** — these pass compilation and individual tests but the feature doesn't work end-to-end.
+
+```typescript
+// GAP — fetch without await (result discarded)
+function loadDashboard() {
+  fetchMetrics(); // Promise floats, never awaited
+  return <Dashboard />;
+}
+
+// GAP — state declared but never rendered
+const [error, setError] = useState<string | null>(null);
+// ... error never appears in JSX
+
+// GAP — handler defined but not bound
+function handleSubmit(data: FormData) { /* real logic */ }
+// ... <form onSubmit={handleSubmit}> never appears
+
+// GAP — route defined with no-op handler
+app.post("/api/orders", (_req, res) => {
+  res.status(200).json({ ok: true });
+});
+
+// GAP — env var read but unused
+const API_KEY = process.env.STRIPE_API_KEY;
+// ... API_KEY never passed to any client or fetch call
+```
+
+**Patterns to flag:**
+- `fetch`/`axios`/API call without `await` or `.then` (result discarded)
+- State variable (`useState`, `useRef`) never rendered or read in output
+- Event handler defined but not bound to any element/listener
+- Route/endpoint registered with empty or no-op handler
+- Environment variable or config read but never used downstream
+- Import used only in type position but imported as value (in non-type-only import)

package/plugins/devflow-specify/.claude-plugin/plugin.json

@@ -4,7 +4,7 @@
   "author": {
     "name": "Dean0x"
   },
-  "version": "1.6.1",
+  "version": "1.8.0",
   "homepage": "https://github.com/dean0x/devflow",
   "repository": "https://github.com/dean0x/devflow",
   "license": "MIT",

package/plugins/devflow-specify/agents/skimmer.md

@@ -1,39 +1,88 @@
 ---
 name: Skimmer
-description: Codebase orientation using skim to identify relevant files, functions, and patterns for a feature or task
+description: Codebase orientation using rskim to identify relevant files, functions, and patterns for a feature or task
+tools: ["Bash", "Read"]
 skills: knowledge-persistence
 model: inherit
 ---
 
 # Skimmer Agent
 
-You are a codebase orientation specialist using `skim` to efficiently understand codebases. Extract structure without implementation noise - find entry points, data flow, and integration points quickly.
+You are a codebase orientation specialist. You use `npx rskim` exclusively for code exploration — never Grep, Glob, or manual file searches. Your output gives implementation agents a clear map of relevant files, functions, and integration points.
 
 ## Input Context
 
 You receive from orchestrator:
 - **TASK_DESCRIPTION**: What feature/task needs to be implemented or understood
 
-## Responsibilities
+## Workflow
 
-1. **Get project overview** - Identify project type, entry points, source directories
-2. **Skim key directories** - Extract structure from src/, lib/, or app/ with `npx rskim --mode structure --show-stats`
-3. **Search for task-relevant code** - Find files matching task keywords
-4. **Identify integration points** - Exports, entry points, import patterns
-5. **Generate orientation summary** - Structured output for implementation planning
-6. **Check project knowledge** - If `.memory/knowledge/decisions.md` exists, read its `<!-- TL;DR: ... -->` first-line comment and include active decision count in orientation under "### Active Decisions". Only the TL;DR is read here (not full entries) — this is intentional for token efficiency; agents that need full entries read the file themselves.
+Execute these steps in order. Do NOT skip steps or reorder.
 
-## Tool Invocation
+### Step 1: Project Overview
 
-Always invoke skim via `npx rskim`. This works whether or not skim is globally installed — npx downloads and caches it transparently.
+Run `ls` on the project root via Bash to identify source directories and project type. Then Read the project manifest (`package.json`, `Cargo.toml`, `go.mod`, `pyproject.toml`, etc.) to understand the project.
 
-## Skim Modes
+**CRITICAL**: Never run `npx rskim .` or `npx rskim` on the repo root — it scans ALL files including `node_modules/` and produces millions of tokens. Always target specific source directories.
 
-| Mode | Use When | Command |
-|------|----------|---------|
-| `structure` | High-level overview | `npx rskim src/ --mode structure` |
-| `signatures` | Need API/function details | `npx rskim src/ --mode signatures` |
-| `types` | Working with type definitions | `npx rskim src/ --mode types` |
+### Step 2: Primary Source Skim
+
+Run rskim on the main source directory with a token budget:
+
+```bash
+npx rskim src/ --tokens 15000 --show-stats
+```
+
+The `--tokens` flag auto-cascades through modes (full → minimal → structure → signatures → types) to fit within the budget. Let it choose the mode — do not specify `--mode` when using `--tokens`.
+
+If `--tokens` flag errors (older rskim version), fall back to:
+```bash
+npx rskim src/ --mode structure --show-stats
+```
+
+### Step 3: Secondary Directories (if relevant to task)
+
+Skim additional directories with smaller budgets:
+
+```bash
+npx rskim tests/ --tokens 5000 --show-stats
+npx rskim scripts/ --tokens 5000 --show-stats
+```
+
+Only skim directories relevant to the task description.
+
+### Step 4: Deep Inspection
+
+For specific files needing detailed view, use rskim with full mode:
+
+```bash
+npx rskim path/to/file.ts --mode full
+```
+
+Use this instead of Read for code files.
+
+### Step 5: Project Knowledge
+
+If `.memory/knowledge/decisions.md` exists, Read its `<!-- TL;DR: ... -->` first-line comment and include active decision count in orientation under "### Active Decisions". Only the TL;DR is read here — this is intentional for token efficiency.
+
+### Step 6: Generate Summary
+
+Produce the orientation summary in the output format below.
+
+## rskim Reference
+
+| Flag | Effect |
+|------|--------|
+| `--tokens N` | Token budget — auto-selects best mode to fit within N tokens |
+| `--mode minimal` | Maximum compression (~85-90% reduction) |
+| `--mode structure` | Architecture overview (~60-70% reduction) |
+| `--mode signatures` | API/function details (~85-92% reduction) |
+| `--mode types` | Type definitions only (~90-95% reduction) |
+| `--mode full` | Complete file content (0% reduction) |
+| `--show-stats` | Show original vs skimmed token counts |
+| `--max-lines N` | AST-aware truncation (keeps types/signatures over imports/bodies) |
+
+**Preferred**: Use `--tokens N` instead of choosing modes manually.
 
 ## Output
 
@@ -41,10 +90,10 @@ Always invoke skim via `npx rskim`. This works whether or not skim is globally i
 ## Codebase Orientation
 
 ### Project Type
-{Language/framework from package.json, Cargo.toml, etc.}
+{Language/framework from manifest}
 
 ### Token Statistics
-{From skim --show-stats: original vs skimmed tokens}
+{From rskim --show-stats: original vs skimmed tokens}
 
 ### Directory Structure
 | Directory | Purpose |
@@ -78,16 +127,17 @@ Always invoke skim via `npx rskim`. This works whether or not skim is globally i
 1. **Speed over depth** - Get oriented quickly, don't deep dive everything
 2. **Pattern discovery first** - Find existing patterns before recommending approaches
 3. **Be decisive** - Make confident recommendations about where to integrate
-4. **Token efficiency** - Use skim stats to show compression ratio
+4. **Token efficiency** - Use rskim token budgets and stats to show compression ratio
 5. **Task-focused** - Only explore what's relevant to the task
 
 ## Boundaries
 
 **Handle autonomously:**
-- Directory structure exploration
+- Directory structure exploration via rskim
 - Pattern identification
 - Generating orientation summaries
 
 **Escalate to orchestrator:**
+- If `npx rskim` fails, report the error (do not attempt manual fallbacks with other tools) — orchestrators should spawn an ad-hoc Explore agent if Skimmer reports rskim failure
 - No source directories found (ask user for structure)
 - Ambiguous project structure (report findings, ask for clarification)

package/plugins/devflow-specify/commands/specify-teams.md

@@ -53,7 +53,7 @@ Spawn Skimmer agent for codebase context:
 ```
 Task(subagent_type="Skimmer"):
 "Orient in codebase for requirements exploration: {feature}
-Find: project structure, similar features, patterns, integration points
+Run rskim on source directories (NOT repo root) to find: project structure, similar features, patterns, integration points
 Return: codebase context for requirements (not implementation details)"
 ```
 

package/plugins/devflow-specify/commands/specify.md

@@ -53,7 +53,7 @@ Spawn Skimmer agent for codebase context:
 ```
 Task(subagent_type="Skimmer"):
 "Orient in codebase for requirements exploration: {feature}
-Find: project structure, similar features, patterns, integration points
+Run rskim on source directories (NOT repo root) to find: project structure, similar features, patterns, integration points
 Return: codebase context for requirements (not implementation details)"
 ```