feat(skills): hint directory parameter for monorepo MCP tool calls

CLAUDE.md

@@ -17,7 +17,7 @@ hooks/
   scripts/
     analyze.sh         # Runs dart analyze on modified .dart files
     block-cli-workarounds.sh  # Prevents direct CLI bypass via Bash
-    check-vgv-cli.sh   # Validates VGV CLI installed and >= 1.1.0
+    check-vgv-cli.sh   # Validates VGV CLI installed and >= 1.2.0
     format.sh          # Runs dart format on modified .dart files
     vgv-cli-common.sh  # Shared utilities for VGV CLI hook scripts
     warn-missing-mcp.sh  # Warns at session start if VGV CLI is missing/outdated
@@ -78,13 +78,13 @@ The `hooks/` directory contains SessionStart, PreToolUse, and PostToolUse hooks
 
 These run **when a session begins**:
 
-- `warn-missing-mcp.sh` — checks if Very Good CLI is installed and >= 1.1.0; outputs a warning to Claude's context if missing or outdated (non-blocking)
+- `warn-missing-mcp.sh` — checks if Very Good CLI is installed and >= 1.2.0; outputs a warning to Claude's context if missing or outdated (non-blocking)
 
 ### PreToolUse Hooks
 
 These run **before** a tool call is executed:
 
-- `mcp__very-good-cli__.*` matcher → `check-vgv-cli.sh` — validates that the Very Good CLI is installed and at version >= 1.1.0; exits 2 on failure (blocking)
+- `mcp__very-good-cli__.*` matcher → `check-vgv-cli.sh` — validates that the Very Good CLI is installed and at version >= 1.2.0; exits 2 on failure (blocking)
 - `Bash` matcher → `block-cli-workarounds.sh` — prevents direct CLI bypass of VGV CLI commands through the Bash tool; exits 2 on failure (blocking)
 
 Both PreToolUse scripts share common utilities from `vgv-cli-common.sh`.

hooks/scripts/vgv-cli-common.sh

@@ -1,9 +1,9 @@
 #!/bin/bash
 # Shared helpers for Very Good CLI version checks and hook deny responses.
 
-MIN_VERSION="1.1.0"
+MIN_VERSION="1.2.0"
 MIN_MAJOR=1
-MIN_MINOR=1
+MIN_MINOR=2
 MIN_PATCH=0
 
 deny() {

skills/create-project/SKILL.md

@@ -37,7 +37,7 @@ Use `AskUserQuestion` to collect only what you cannot infer. Batch questions int
 ### Step 3: Create and Set Up
 
 1. Create the project using the Very Good CLI MCP server
-2. Install dependencies using the Very Good CLI MCP server
+2. Install dependencies using the Very Good CLI MCP server — pass `directory: '<path-to-created-project>'` to `packages_get` so it runs against the new project, not the workspace root
 
 ---
 
@@ -87,7 +87,7 @@ Use `AskUserQuestion` to collect only what you cannot infer. Batch questions int
 ### Dependencies fail to install after creation
 
 - Verify the Dart SDK is installed and on PATH
-- Try running from the project root directory
+- Pass `directory: '<path-to-created-project>'` to `packages_get` so it targets the new project
 
 ---
 

skills/layered-architecture/SKILL.md

@@ -371,7 +371,7 @@ Flavors change only the configuration (base URLs, API keys) — the architecture
 5. Implement the client class in `lib/src/<name>_api_client.dart`
 6. Create the package barrel file `lib/<name>_api_client.dart` exporting `src/` contents
 7. Write unit tests in `test/` mirroring `lib/` structure — see the **testing** skill
-8. Use `very_good_cli` MCP server tool `test` from the package directory
+8. Use `very_good_cli` MCP server tool `test` against the package directory — pass `directory: 'packages/<name>_api_client'` to scope the run
 
 ### Adding a New Repository
 

skills/layered-architecture/references/testing.md

@@ -153,7 +153,7 @@ void main() {
 
 ## Running Tests Recursively
 
-From the monorepo root, test all packages at once using the `very_good_cli` MCP server tool `test`: `-r --min-coverage 100`
+From the monorepo root, test all packages at once using the `very_good_cli` MCP server tool `test`: `-r --min-coverage 100`. When the Dart/Flutter project is in a subdirectory of the workspace (e.g. `mobile/`), pass `directory: 'mobile'` so the tool runs against the project root.
 
 This recursively finds and runs tests in every package (data clients, repositories, and the root app).
 

skills/license-compliance/SKILL.md

@@ -24,6 +24,7 @@ Dependency license auditor for Dart and Flutter projects — verifies that all p
 Apply these standards to ALL license compliance work:
 
 - **Run `packages_check_licenses` MCP tool** on the target project directory with `licenses: true` to display full license information
+- **Pass `directory` to the MCP tool when the project is not at the workspace root** — monorepos with the project in a subdirectory (e.g. `mobile/`) require `directory: 'mobile'`
 - **A missing license is not "no license"** — it means "all rights reserved" by default; always flag
 - **Transitive dependencies matter** — a permissive package that depends on a GPL package still carries the GPL obligation
 - **Flag for manual review when in doubt** — never assume compliance without a clear license identifier
@@ -45,7 +46,7 @@ Apply these standards to ALL license compliance work:
 
 ### 1. Run License Check
 
-Call the `packages_check_licenses` MCP tool on the target project directory.
+Call the `packages_check_licenses` MCP tool on the target project directory. When the project lives in a subdirectory of the workspace (e.g. `mobile/` in a monorepo), pass that path via the `directory` parameter.
 
 ### 2. Categorize Results
 

skills/testing/SKILL.md

@@ -26,6 +26,7 @@ Apply these standards to ALL test work:
 - **Test behavior, not properties** — widget tests focus on functional outcomes; static visual properties validated via golden tests
 - **Use `pumpApp` test helper** — wrap widgets via shared helper in `test/helpers/pump_app.dart`; never inline `pumpWidget(MaterialApp(...))`
 - **Tag all golden tests** — annotate with `TestTag.golden` so goldens can run/update independently
+- **Pass `directory` to the `test` MCP tool when the project is not at the workspace root** — monorepos with the Flutter project in a subdirectory (e.g. `mobile/`) require `directory: 'mobile'`; omit it only when `pubspec.yaml` is at the workspace root
 
 ## Test Structure