@precisionutilityguild/liquid-shadow 1.0.7 → 1.0.10

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (40) hide show
  1. package/README.md +3 -3
  2. package/dist/data/migrations/000_baseline.sql +27 -0
  3. package/dist/data/migrations/013_file_claims.sql +18 -0
  4. package/dist/data/migrations/014_tribunal_state.sql +24 -0
  5. package/dist/data/migrations/015_repo_level_handoffs_nullable.sql +52 -0
  6. package/dist/data/migrations/016_repair_tribunal_artifact_fk.sql +58 -0
  7. package/dist/entry/cli/index.js +597 -495
  8. package/dist/entry/ember/index.js +109 -32
  9. package/dist/entry/mcp/server.js +443 -347
  10. package/dist/entry/tribunal/index.js +650 -0
  11. package/dist/index.js +441 -345
  12. package/dist/logic/parser/index.js +16 -14
  13. package/dist/skills/shadow_audit/SKILL.md +22 -30
  14. package/dist/skills/shadow_chronicle/SKILL.md +16 -29
  15. package/dist/skills/shadow_continue/SKILL.md +37 -53
  16. package/dist/skills/shadow_coordinate/SKILL.md +46 -0
  17. package/dist/skills/shadow_crystallize/SKILL.md +13 -27
  18. package/dist/skills/shadow_mission/SKILL.md +27 -41
  19. package/dist/skills/shadow_onboard/SKILL.md +26 -35
  20. package/dist/skills/shadow_research/SKILL.md +15 -23
  21. package/dist/skills/shadow_sync/SKILL.md +18 -9
  22. package/dist/skills/shadow_synthesize/SKILL.md +14 -36
  23. package/dist/skills/shadow_trace_impact/SKILL.md +30 -50
  24. package/dist/skills/shadow_understand/SKILL.md +37 -52
  25. package/dist/skills/shadow_workspace/SKILL.md +17 -17
  26. package/dist/web-manifest.json +16 -6
  27. package/package.json +1 -1
  28. package/skills/shadow_audit/SKILL.md +22 -30
  29. package/skills/shadow_chronicle/SKILL.md +16 -29
  30. package/skills/shadow_continue/SKILL.md +37 -53
  31. package/skills/shadow_coordinate/SKILL.md +46 -0
  32. package/skills/shadow_crystallize/SKILL.md +13 -27
  33. package/skills/shadow_mission/SKILL.md +27 -41
  34. package/skills/shadow_onboard/SKILL.md +26 -35
  35. package/skills/shadow_research/SKILL.md +15 -23
  36. package/skills/shadow_sync/SKILL.md +18 -9
  37. package/skills/shadow_synthesize/SKILL.md +14 -36
  38. package/skills/shadow_trace_impact/SKILL.md +30 -50
  39. package/skills/shadow_understand/SKILL.md +37 -52
  40. package/skills/shadow_workspace/SKILL.md +17 -17
@@ -3,39 +3,25 @@ name: crystallize
3
3
  description: Compress a mission's intent logs into a dense crystal summary for token-efficient briefings. Use when a mission has accumulated many raw logs, when briefings are too verbose, or when the user asks about log compression, crystallization, or context reduction.
4
4
  ---
5
5
 
6
- # Intent Log Crystallization
6
+ # Crystallize
7
7
 
8
- Compress raw intent logs into a single crystal summary node. The crystal replaces verbose raw logs in briefings, reducing token usage while preserving the mission's key decisions, context, and consequences.
8
+ Compress raw intent logs into a crystal so briefings stay useful instead of noisy.
9
9
 
10
- ## When to Crystallize
10
+ ## Core calls
11
11
 
12
- - A mission has **10+ raw intent logs** and briefings are getting verbose.
13
- - Mid-mission, before requesting a detailed briefing keeps `atmosphere` altitude lean.
14
- - Before synthesis (optional) produces cleaner ADRs from compressed input.
15
- - The briefing at `atmosphere` altitude already prefers crystals over raw logs (`findByMissionPreferCrystal`), so crystallizing makes those briefings significantly leaner.
12
+ - Mission-level compression: `shadow_ops_crystallize({ repoPath, missionId })`
13
+ - Verify the result: `shadow_ops_briefing({ repoPath, scope: "mission", missionId, altitude: "atmosphere" })`
14
+ - Cross-mission theme compression: `shadow_ops_crystallize_theme({ repoPath, theme, missionIds?, limit? })`
16
15
 
17
- ## Workflow
16
+ ## When to use it
18
17
 
19
- 1. **Crystallize**: `shadow_ops_crystallize` (missionId, repoPath) — Compresses all raw logs into one crystal node. Raw logs are marked as `absorbed`.
20
- 2. **Verify**: `shadow_ops_briefing` (scope: "mission", missionId, altitude: "atmosphere", repoPath) — Crystal should appear in `recent_activity` instead of raw logs.
21
-
22
- ## Precise Tooling
23
-
24
- | Action | Atomic Tool | Usage |
25
- | :--------------- | :--------------------------------------------- | :-------------------------------------- |
26
- | **Crystallize** | `shadow_ops_crystallize` | missionId, repoPath — compress raw logs |
27
- | **Check Status** | `shadow_ops_briefing` (altitude: "atmosphere") | Verify crystal appears in activity |
28
- | **Full Logs** | `shadow_ops_briefing` (altitude: "ground") | Still shows raw logs if needed |
29
-
30
- ## What the Crystal Contains
31
-
32
- - Mission name and ID
33
- - Count of compressed logs and symbols
34
- - Log types present (decision, fix, discovery, blocker)
35
- - Structured breakdown: decisions, context, consequences, recommendations
18
+ - A mission has many raw logs and `atmosphere` briefings are getting bloated.
19
+ - You want cleaner synthesis input before closing a mission.
20
+ - You want to surface repeating patterns across missions with `theme`.
36
21
 
37
22
  ## Notes
38
23
 
39
24
  - Crystallization is **idempotent**: if no new raw logs exist, it reports `already_crystallized`.
40
- - New logs added after crystallization remain as raw until the next crystallize call.
41
- - Raw logs are **not deleted** they're marked as absorbed. `ground` altitude still shows them.
25
+ - Raw logs are not deleted; they are marked as absorbed.
26
+ - New logs stay raw until the next crystallize call.
27
+ - `shadow_ops_crystallize_theme` takes `theme`, not `query`.
@@ -1,53 +1,39 @@
1
1
  ---
2
2
  name: mission
3
- description: Define the objective, strategy, and success criteria for a new development mission. Use when planning strategic initiatives, creating missions, setting up development goals, or when the user asks about mission planning, strategic alignment, or outcome contracts.
3
+ description: Define the objective, strategy, and success criteria for a mission. Use when planning new work, shaping initiatives, writing outcome contracts, or aligning a task before execution starts.
4
4
  ---
5
5
 
6
- # Mission Strategy & Setup
6
+ # Mission
7
7
 
8
- Define the objective, strategy, and success criteria for a new mission. This workflow is for **Strategic Alignment and Planning**.
8
+ This skill is for planning. It stops at "ready to execute."
9
9
 
10
- > **IMPORTANT**: This workflow stops at the "Ready to Execute" state. For implementation and automated execution, use **/continue**.
10
+ ## Start
11
11
 
12
- ## Workflow
12
+ 1. `shadow_ops_context({ repoPath, compact: true })`
13
+ 2. If needed, expand with:
14
+ - `shadow_recon_topography({ repoPath })`
15
+ - `shadow_ops_briefing({ repoPath, scope: "project", altitude: "ground" })`
16
+ - `shadow_ops_chronicle({ repoPath, limit: 10 })`
17
+ 3. Reuse prior intelligence when available:
18
+ - `shadow_ops_handoff_read({ repoPath, missionId?, kind?, query? })`
19
+ - `shadow_ops_crystallize_theme({ repoPath, theme, missionIds? })`
13
20
 
14
- 1. **Session Context**: `shadow_ops_context` (repoPath) — **ONE CALL** for hologram + chronicle(5) + briefing (with relevance-ranked `next_work_candidates`). Check existing candidates and recent decisions before creating new work.
15
- 2. **Optional Expanded Context** (only if needed):
16
- - `shadow_recon_topography` (repoPath) — Detailed layer breakdown to align goal with architecture.
17
- - `shadow_ops_chronicle` (limit: 10, repoPath) — More historical ADRs if 5 isn't enough.
18
- - `shadow_ops_briefing` (scope: "project", altitude: "ground", repoPath) — Full detail with analytics, collisions, and working sets.
19
- 3. **Strategic Plan**: `shadow_ops_plan` (name, goal, outcomeContract, ...).
20
- - **Strategy DAG**: Define logical steps and verification rules.
21
- - **Initiative vs Mission**: Decide if this is a parent (Initiative) or a leaf (Mission). Parent missions auto-complete via cascade when all children finish.
22
- 4. **Alignment**: Present the plan to the user. Do not begin execution until the user approves the strategy.
21
+ ## Create the mission
23
22
 
24
- ## Precise Tooling
23
+ Use `shadow_ops_plan` with the fields that matter:
25
24
 
26
- | Setup Action | Precise Tool Call | Usage |
27
- | :-------------------- | :----------------------------------------- | :-------------------------------------------------------------------------------------------------- |
28
- | **Session Start** | `shadow_ops_context` | **START HERE** — hologram + chronicle + briefing in one call |
29
- | **Establish Plan** | `shadow_ops_plan` | Create the mission and strategy. |
30
- | **Architectural Map** | `shadow_recon_topography` | Contextualize the target layers (if context wasn't enough). |
31
- | **Detailed Briefing** | `shadow_ops_briefing` (altitude: "ground") | Full analytics, collisions, working sets. |
32
- | **Lean Briefing** | `shadow_ops_briefing` (altitude: "orbit") | Counts + candidates only (~200 tokens). |
33
- | **Graph View** | `shadow_ops_graph` | Visualize the initiative's hierarchy. |
34
- | **Theme Patterns** | `shadow_ops_crystallize_theme` | Before planning: surface recurring themes across past missions to avoid repeating solved problems. |
35
- | **Prior Handoffs** | `shadow_ops_handoff_read` | In multi-agent contexts: retrieve typed findings from a prior RECON agent before defining strategy. |
36
- | **Event Mesh** | `shadow_analyze_mesh` | When planning event-driven or API work: map all HTTP routes, socket events, pubsub topics. |
25
+ - `name`: short, concrete title
26
+ - `goal`: what changes and why
27
+ - `outcomeContract`: binary success test
28
+ - `strategy`: JSON step graph when the work has multiple stages
29
+ - `workingSet`: expected files or directories
30
+ - `templateId`: `refactoring`, `feature`, or `bug-fix`
31
+ - `parentId`: when this mission belongs under an initiative
37
32
 
38
- _Note: **Always start with `shadow_ops_context`** for instant mission landscape + architectural context. Ensure the `outcomeContract` is binary and verifiable. Parent initiatives auto-cascade on child completion — no manual closing needed._
33
+ ## Planning rules
39
34
 
40
- ## Briefing Altitude Levels
41
-
42
- - **`orbit`** (~200 tokens): Counts + relevance-ranked candidates only. Use for quick checks.
43
- - **`atmosphere`** (default): Strategy graphs, crystal summaries, hierarchy, analytics.
44
- - **`ground`** (full): Raw logs, working sets, collision analysis, ancestor activity.
45
-
46
- ## Intent Logging (Strategic Quality)
47
-
48
- Capture the "Why" and "How" during the planning phase to ensure the final ADR has architectural depth.
49
-
50
- - **Decision Logs**: Capture why a specific strategy or library was chosen.
51
- - **Discovery Logs**: Record insights found during initial reconnaissance.
52
-
53
- **Hand-off**: Once the mission is planned and logged, the setup phase is over. Execute via `/continue`.
35
+ - Prefer a leaf mission when one deliverable can be completed in one run.
36
+ - Use a parent initiative only when the work is intentionally split into child missions.
37
+ - Keep `outcomeContract` verifiable. "Looks good" is not a contract.
38
+ - If API or event boundaries matter, use `shadow_analyze_mesh({ repoPath, topic, type? })` with a concrete route or topic fragment.
39
+ - Present the plan for approval before execution. Use `/continue` for the actual implementation pass.
@@ -1,39 +1,30 @@
1
1
  ---
2
2
  name: onboard
3
- description: Initialize and analyze a new repository for deep intelligence by building semantic index, syncing state, activating git hooks, and establishing missions. Use when onboarding to a new repository, initializing Shadow Engine, setting up git hooks, or when the user asks about repository setup, initialization, or first-time configuration.
3
+ description: Initialize and analyze a repository for Shadow workflows. Use when onboarding a repo, bootstrapping indexes and hooks, checking intelligence health, or preparing the first mission.
4
4
  ---
5
5
 
6
- # Repository Onboarding
7
-
8
- Initialize and analyze a new repository for deep intelligence.
9
-
10
- ## Workflow
11
-
12
- 1. **Semantic Init**: `shadow_recon_onboard` (repoPath) — **Only run once** per repo to build the baseline. Auto-populates the hologram.
13
- 2. **Read Hologram**: `shadow_recon_hologram` (repoPath) — Get instant architectural context (~1300 tokens: topography + gravity zones).
14
- 3. **Unified Sync**: `shadow_sync_trace` (repoPath) — **The One-Stop Shop**. Performs indexing + ghost analysis + mission re-hydration.
15
- 4. **Active Briefing**: `shadow_ops_briefing` (scope: "project", altitude: "atmosphere", repoPath) — Resumes the shared backlog with relevance-ranked candidates.
16
- - Use `altitude: "orbit"` for a lean overview (~200 tokens), or `altitude: "ground"` for full detail.
17
- 5. **Architectural Deep Dive** (optional):
18
- - `shadow_recon_topography` (repoPath) — View layers (Entry/Logic/Data/Utility/Test).
19
- - `shadow_ops_chronicle` (limit: 5, repoPath) — Narrative feed.
20
- - `shadow_analyze_mesh` (repoPath) If repo is event-driven: map HTTP routes, socket events, pubsub topics immediately.
21
- - `shadow_env_diagnose` (repoPath) — Verify environment health: hooks installed, index state, ember daemon status.
22
- 6. **Hooks Activation**: `shadow_env_hooks` (action: "install", repoPath) installs post-commit and **post-checkout** hooks. Post-checkout fires incremental reindex in background on every branch switch.
23
- 7. **Establish Mission**: `shadow_ops_plan` (name, goal, repoPath).
24
-
25
- ## Precise Tooling
26
-
27
- | Action | Atomic Tool |
28
- | :---------------- | :----------------------------------------------------------------------------------- |
29
- | **Index** | `shadow_recon_onboard` |
30
- | **Hologram** | `shadow_recon_hologram` (repoPath) |
31
- | **Layers** | `shadow_recon_topography` |
32
- | **History** | `shadow_ops_chronicle` (limit: 10) |
33
- | **Resume (lean)** | `shadow_ops_briefing` (scope: "project", altitude: "orbit") |
34
- | **Resume (full)** | `shadow_ops_briefing` (scope: "project", altitude: "atmosphere") |
35
- | **Hooks** | `shadow_env_hooks` (action: "install") |
36
- | **Env Health** | `shadow_env_diagnose` (repoPath) — hooks status, index state, ember warming progress |
37
- | **Event Mesh** | `shadow_analyze_mesh` (repoPath) — event-driven repos: routes + topics surface |
38
-
39
- _Note: Always use absolute paths for `repoPath`. Call `shadow_recon_hologram` immediately after init for instant architectural context. `shadow_env_hooks` now installs both post-commit and post-checkout hooks — branch switches will auto-reindex in background via Ember daemon._
6
+ # Onboard
7
+
8
+ Use this skill when a repository needs its first Shadow pass or when a fresh clone needs to be made operational.
9
+
10
+ ## Core workflow
11
+
12
+ 1. `shadow_recon_onboard({ repoPath })`
13
+ 2. `shadow_recon_hologram({ repoPath, compact: true })`
14
+ 3. `shadow_sync_trace({ repoPath })`
15
+ 4. `shadow_ops_health({ repoPath })`
16
+ 5. `shadow_ops_context({ repoPath, compact: true })`
17
+
18
+ ## Useful follow-ups
19
+
20
+ - `shadow_recon_topography({ repoPath })` for layer breakdown.
21
+ - `shadow_ops_chronicle({ repoPath, limit: 5 })` for recent decisions.
22
+ - `shadow_env_diagnose({ repoPath })` for hooks, index, and daemon health.
23
+ - `shadow_env_hooks({ repoPath, action: "install", enableAutoRefresh: true, enableSymbolHealing: true })`
24
+ - `shadow_ops_plan({ repoPath, name, goal, outcomeContract? })` for the first mission.
25
+
26
+ ## Rules
27
+
28
+ - Always use an absolute `repoPath`.
29
+ - `shadow_recon_onboard` is the baseline bootstrap; `shadow_sync_trace` is the normal follow-up maintenance pass.
30
+ - Do not call `shadow_analyze_mesh` without a concrete `topic`.
@@ -1,34 +1,26 @@
1
1
  ---
2
2
  name: research
3
- description: Conduct high-signal research for external dependencies by combining local context, web search, and Context7 documentation. Use when researching libraries, checking integration examples, verifying versions, or when the user asks about external dependencies, library documentation, or integration patterns.
3
+ description: Research external dependencies without losing local context. Use when checking library usage, verifying versions, finding integration examples, or comparing official documentation against what the repo already does.
4
4
  ---
5
5
 
6
- # External Research
6
+ # Research
7
7
 
8
- High-signal research for external dependencies.
8
+ Start local, then verify externally.
9
9
 
10
- ## 🚀 Workflow
10
+ ## Local first
11
11
 
12
- 1. **Local Context**: `shadow_search_concept` (query: "library name", repoPath). Find existing integration examples.
13
- 2. **Web Search**: Use the `WebSearch` tool for official docs and latest versions.
14
- 3. **Deep Intel (Context7)**: resolve-library-id, query-docs (server: user-context7).
15
- 4. **Integration Check**: `shadow_inspect_file` (filePath, detailLevel: "signatures", repoPath).
16
- 5. **Log Findings**: `shadow_ops_log` (type: "discovery", content, repoPath).
12
+ - `shadow_search_concept({ repoPath, query, compact: true })` for existing patterns.
13
+ - `shadow_search_path({ repoPath, query, ranked: true })` for likely integration files.
14
+ - `shadow_search_config({ repoPath, key?, query?, showUsage: true })` for env and config hooks.
15
+ - `shadow_analyze_deps({ repoPath, filePath, direction: "imports" | "imported_by" })` to see how the dependency sits in the graph.
16
+ - `shadow_inspect_file({ repoPath, filePath, detailLevel: "signatures" })` for a quick local API read.
17
17
 
18
- ## 🛠 Precise Tooling
18
+ ## External verification
19
19
 
20
- | Discovery Layer | Atomic Tool |
21
- | :----------------- | :-------------------------------------------------------------------------- |
22
- | **Local Usage** | `shadow_search_concept` (query, **compact: true** for broad search) |
23
- | **File Discovery** | `shadow_search_path` (query, **ranked: true**) — gravity-sorted with layers |
24
- | **Config Check** | `shadow_search_config` (key, **showUsage: true**) — with usage counts |
25
- | **External Docs** | context7 tools (user-context7) |
26
- | **Relational** | `shadow_analyze_deps` (filePath, direction) |
20
+ - Use the host model's documentation or web tools to read official vendor docs and primary sources.
21
+ - Check the exact installed version in `package.json`, lockfiles, or existing imports before trusting examples.
22
+ - Prefer official docs over blogs, and repo-local patterns over generic snippets.
27
23
 
28
- ## 💡 Intelligence Options
24
+ ## Closeout
29
25
 
30
- - **`shadow_search_concept` with `compact: true`**: Returns file paths + scores without snippets (~60% token savings). Use for broad exploration.
31
- - **`shadow_search_path` with `ranked: true`**: Results sorted by gravity (high-import files first) with layer classification. Reveals architecturally important files.
32
- - **`shadow_search_config` with `showUsage: true`**: Shows usage counts per config var and identifies orphaned vars (defined but never used in code).
33
-
34
- _Note: Always check `package.json` for the exact version before querying Context7 to ensure documentation alignment._
26
+ - `shadow_ops_log({ repoPath, missionId?, type: "discovery", content, filePath? })` when the research affects an ongoing mission.
@@ -3,16 +3,25 @@ name: sync
3
3
  description: 'Sync index and mission state after external changes. Day-to-day: index + NanoRepair run automatically when MCP tools (search, inspect, etc.) trigger reindex. Use trace after git pull/checkout/merge (or rely on hooks); use index deep:true for full rebuild.'
4
4
  ---
5
5
 
6
- # Repository Synchronization
6
+ # Sync
7
7
 
8
- **Day-to-day:** Index and NanoRepair run automatically when you use MCP tools (search, inspect, analyze, etc.) and a reindex occurs. No manual sync needed for edits or renames.
8
+ Day-to-day, Shadow often reindexes on demand. Use manual sync when the repository changed outside the normal flow.
9
9
 
10
- ## When to run sync manually
10
+ ## Prefer these calls
11
11
 
12
- | Situation | Action |
13
- | :-------------------------------- | :----------------------------------------------------------------- |
14
- | **After git pull/checkout/merge** | `shadow_sync_trace` (repoPath) — or rely on Git hooks if installed |
15
- | **Full rebuild (corruption)** | `shadow_sync_index` (repoPath; use deep: true if supported) |
16
- | **Repair only (rare)** | `shadow_sync_repair` (repoPath) |
12
+ - After `pull`, `checkout`, `merge`, or large rebases:
13
+ - `shadow_sync_trace({ repoPath, sinceCommit?, enableContextPivot?, enableMergeSentinel? })`
14
+ - For an explicit rebuild:
15
+ - `shadow_sync_index({ repoPath, deep: true })`
16
+ - For repair only:
17
+ - `shadow_sync_repair({ repoPath })`
17
18
 
18
- **Note:** `trace` does index + ghost analysis + NanoRepair + lifecycle + mission re-hydration. Hooks run it on commit/checkout/merge.
19
+ ## Health checks
20
+
21
+ - `shadow_ops_health({ repoPath })`
22
+ - `shadow_env_diagnose({ repoPath })`
23
+
24
+ ## Rules
25
+
26
+ - Prefer `shadow_sync_trace` over `shadow_sync_index` unless you specifically want a rebuild.
27
+ - Use `deep: true` sparingly; it is the expensive option.
@@ -3,46 +3,24 @@ name: synthesize
3
3
  description: Distill mission logs into Architectural Decision Records (ADRs) and persist them to the Shadow Engine and Git Notes. Use when completing missions, creating ADRs, synthesizing architectural decisions, or when the user asks about decision records, mission completion, or architectural documentation.
4
4
  ---
5
5
 
6
- # Architectural Synthesis
6
+ # Synthesize
7
7
 
8
- Distill mission logs into an Architectural Decision Record (ADR) and persist it to the Shadow Engine.
8
+ Use this skill when a mission needs to become durable project memory.
9
9
 
10
- > **AUTO-PILOT ACTIVE**: Synthesis is **automatically triggered** when a mission status is set to `completed` via `shadow_ops_track`. The system handles: ADR distillation (recursive for child missions), Git Notes persistence, and **cascade parent completion** (if all siblings are done, the parent auto-completes and synthesizes too).
10
+ ## Primary path
11
11
 
12
- ## Workflow
12
+ - Complete the mission:
13
+ - `shadow_ops_track({ repoPath, missionId, status: "completed" })`
14
+ - Verify the synthesized record:
15
+ - `shadow_ops_chronicle({ repoPath, limit: 5 })`
13
16
 
14
- 1. **Complete Mission**: `shadow_ops_track` (missionId, status: "completed", repoPath).
15
- - The Shadow Engine will automatically:
16
- - Distill all intent logs (recursive for child missions).
17
- - Format the ADR using markdown and **Liquid Anchors**.
18
- - Persist the record to SQLite and **Git Notes**.
19
- - **Cascade**: If all sibling missions under the same parent are completed, the parent mission auto-completes with its own ADR synthesis.
20
- 2. **Verify**: Check the synthesized record via `shadow_ops_chronicle` (limit: 5, repoPath).
21
- 3. **Manual Synthesis**: Use `shadow_ops_synthesize` only to **re-generate** an existing record or for specific partial distillations.
22
- 4. **Pre-synthesis Compression** (optional): For missions with many raw logs, `shadow_ops_crystallize` (missionId, repoPath) compresses logs into a crystal summary before synthesis for cleaner ADRs.
17
+ ## Secondary tools
23
18
 
24
- ## Precise Tooling
19
+ - `shadow_ops_synthesize({ repoPath, missionId })` only when you need to regenerate the ADR after the mission is already complete.
20
+ - `shadow_ops_crystallize({ repoPath, missionId })` before completion if the mission has many raw logs.
21
+ - `shadow_ops_crystallize_theme({ repoPath, theme, missionIds? })` when you want a cross-mission architectural thread.
25
22
 
26
- | Action | Atomic Tool | Usage |
27
- | :-------------------- | :--------------------------------------- | :---------------------------------------------------------------- |
28
- | **Complete & Seal** | `shadow_ops_track` (status: "completed") | **Primary**. Triggers auto-synthesis + cascade. |
29
- | **Manual Distill** | `shadow_ops_synthesize` | Re-run synthesis manually (re-gen only). |
30
- | **Crystallize First** | `shadow_ops_crystallize` | Compress raw logs before synthesis. |
31
- | **Theme Crystallize** | `shadow_ops_crystallize_theme` | Cross-mission: cluster semantic themes across ALL missions' logs. |
32
- | **View Chronicle** | `shadow_ops_chronicle` | View the combined narrative feed. |
23
+ ## Rules
33
24
 
34
- _Note: Synthesis consolidation includes all child missions recursively. Cascade parent completion propagates upward through the entire hierarchy._
35
-
36
- ## Cascade Parent Completion
37
-
38
- When the last child mission under a parent is completed:
39
-
40
- 1. Parent status is set to `completed`
41
- 2. A system intent log records the cascade event
42
- 3. Parent ADR is synthesized (recursive child distillation)
43
- 4. Parent is synced to Git Notes
44
- 5. If the parent itself has a parent, the cascade continues upward
45
-
46
- ## Tooling Strategy
47
-
48
- Synthesis is the final commit of the mission's logic into the repository's permanent history. Avoid manual markdown files for ADRs; trust the **Git Notes** architecture to preserve the "Story of the Code."
25
+ - Completion auto-triggers synthesis and parent cascade behavior.
26
+ - Do not maintain parallel ADR markdown files unless the user explicitly wants one.
@@ -3,53 +3,33 @@ name: trace-impact
3
3
  description: Map the blast radius of a change by analyzing impact, flow traces, cross-repo dependencies, and boundary maps. Use when analyzing change impact, assessing risk, tracing dependencies, or when the user asks about change impact, blast radius, or dependency analysis.
4
4
  ---
5
5
 
6
- # Impact Analysis
7
-
8
- Map the blast radius of a change using the full Shadow analyze toolkit.
9
-
10
- ## 🚀 Workflow
11
-
12
- 1. **Session Context**: `shadow_ops_context` (repoPath) **ONE CALL** for hologram + chronicle + briefing. Check if symbol is in gravity zones.
13
- 2. **Impact (Blast Radius)**: `shadow_analyze_impact` (symbolName, filePath, depth: 3, repoPath) — ALL affected files.
14
- 3. **Dependencies**:
15
- - `shadow_analyze_deps` (filePath, direction: "imported_by", repoPath) — Who imports this?
16
- - `shadow_analyze_deps` (filePath, direction: "imports", repoPath) — What does it import?
17
- 4. **Flow Trace**: `shadow_analyze_flow` (symbolName, filePath, repoPath) — Execution path.
18
- 5. **Health Check**:
19
- - `shadow_analyze_debt` (mode: "circular-deps", repoPath) — Any import cycles?
20
- - `shadow_analyze_debt` (mode: "dead-code", limit: 50, repoPath) Unused exports?
21
- 6. **Cross-Repo Check** (if multi-repo):
22
- - `shadow_workspace_fuse` (repoPaths, repoPath).
23
- - `shadow_search_symbol` (query, limit: 50, repoPath).
24
- 7. **Boundary Map**: `shadow_recon_topography` (repoPath) Layer crossing check.
25
- 8. **Log Risk**: `shadow_ops_log` (missionId, type: "discovery", content, symbolName, repoPath).
26
-
27
- ## 🛠 Precise Tooling
28
-
29
- | Impact Layer | Atomic Tool |
30
- | :------------------- | :------------------------------------------------------------------------- |
31
- | **Session Start** 🚀 | `shadow_ops_context` (repoPath) — **START HERE** for context |
32
- | **Hologram** | `shadow_recon_hologram` (repoPath) — if you need standalone |
33
- | **Blast Radius** | `shadow_analyze_impact` (symbolName, depth: 3) |
34
- | **Dependents** | `shadow_analyze_deps` (filePath, direction: "imported_by") |
35
- | **Dependencies** | `shadow_analyze_deps` (filePath, direction: "imports") |
36
- | **Flow Path** | `shadow_analyze_flow` (symbolName, filePath) |
37
- | **Circular Deps** | `shadow_analyze_debt` (mode: "circular-deps") |
38
- | **Dead Code** | `shadow_analyze_debt` (mode: "dead-code", **confidenceThreshold: "high"**) |
39
- | **File Discovery** | `shadow_search_path` (query, **ranked: true**) — gravity-sorted |
40
- | **Workspace Fuse** | `shadow_workspace_fuse` (repoPaths, repoPath) |
41
- | **Topography** | `shadow_recon_topography` |
42
-
43
- ## 💡 Intelligence Options
44
-
45
- - **`shadow_search_path` with `ranked: true`**: Find related files sorted by gravity (high-import files first) with layer classification. Helps identify which affected files are architecturally critical.
46
- - **`shadow_analyze_debt` confidence levels**: Use `confidenceThreshold: "high"` to focus on likely dead code, avoiding noise from test fixtures and migrations.
47
-
48
- _Note: **Start with `shadow_ops_context`** for instant gravity zones + architectural context. Use depth higher than 3 for impact analysis only if the symbol is a fundamental primitive (e.g., RepositoryFactory)._
49
-
50
- ## 🛠 Risk Classification
51
-
52
- - **Critical Risk**: Symbol in gravity zones (top 10) + >20 dependents + crosses layers
53
- - **High Risk**: >10 dependents OR crosses layers (e.g., Test -> Logic)
54
- - **Medium Risk**: 5-10 dependents within same layer
55
- - **Low Risk**: <5 dependents, same layer, no circular deps
6
+ # Trace Impact
7
+
8
+ Use this skill to answer "what breaks if we touch this?"
9
+
10
+ ## Core workflow
11
+
12
+ 1. `shadow_ops_context({ repoPath, compact: true })`
13
+ 2. `shadow_analyze_impact({ repoPath, symbolName, filePath?, depth: 3 })`
14
+ 3. `shadow_analyze_deps({ repoPath, filePath, direction: "imported_by" })`
15
+ 4. `shadow_analyze_deps({ repoPath, filePath, direction: "imports" })`
16
+ 5. `shadow_analyze_flow({ repoPath, filePath, symbolName? })`
17
+
18
+ ## Add precision
19
+
20
+ - `shadow_analyze_explain_diff({ repoPath, baseCommit?, headCommit?, staged? })` for a semantic read of an actual diff.
21
+ - `shadow_analyze_type_graph({ repoPath, symbolName, filePath?, direction?, relationship? })` when the change is type-heavy.
22
+ - `shadow_analyze_debt({ repoPath, mode: "circular-deps" })` for cycle risk.
23
+ - `shadow_recon_topography({ repoPath })` for layer-crossing risk.
24
+ - `shadow_workspace_fuse({ repoPaths, name? })` before cross-repo analysis.
25
+ - `shadow_analyze_mesh({ repoPath, topic, includeCrossRepo: true })` when the affected boundary is a known route or event.
26
+
27
+ ## Closeout
28
+
29
+ - `shadow_ops_log({ repoPath, missionId?, type: "discovery", content, symbolName?, filePath? })`
30
+ - `shadow_ops_handoff({ repoPath, missionId?, kind: "impact_map", findings, risks?, gaps? })`
31
+
32
+ ## Rules
33
+
34
+ - Keep `depth: 3` by default; only widen for foundational primitives.
35
+ - `shadow_analyze_mesh` requires a concrete `topic`.
@@ -3,55 +3,40 @@ name: understand
3
3
  description: Find the high-signal path to understanding complex logic through intent retrieval, topological placement, relational analysis, and mechanics inspection. Use when understanding architecture, analyzing complex code, tracing logic flow, or when the user asks about how something works, architectural patterns, or code comprehension.
4
4
  ---
5
5
 
6
- # Architectural Understanding
7
-
8
- Find the high-signal path to understanding complex logic.
9
-
10
- ## Workflow
11
-
12
- 1. **Session Context (The Fast Lane)**: `shadow_ops_context` (repoPath) **ONE CALL** returns hologram + chronicle(5) + briefing (relevance-ranked candidates).
13
- - Skip to step 3 if you have what you need from context alone.
14
- 2. **Optional Expanded Context** (only if shadow_ops_context wasn't enough):
15
- - `shadow_recon_topography` (repoPath) — Detailed layer breakdown beyond hologram summary.
16
- - `shadow_recon_tree` (subPath: "src/services", maxDepth: 2, repoPath) — Visual file hierarchy.
17
- - `shadow_ops_briefing` (scope: "mission", missionId, altitude: "ground") — Full mission detail with raw logs, working set, collisions.
18
- 3. **Relational Analysis (The Who)**:
19
- - `shadow_analyze_impact` (symbolName, filePath, depth: 3, repoPath) — Blast radius.
20
- - `shadow_analyze_deps` (filePath, direction: "imported_by", repoPath) — Who depends on this?
21
- - `shadow_search_concept` (query, repoPath) Semantic search.
22
- - `shadow_analyze_mesh` (repoPath) — When the system is event-driven: map all HTTP routes, socket events, pubsub topics and their producers/consumers.
23
- - `shadow_analyze_type_graph` (filePath, repoPath) When understanding a type system: interface/class inheritance chains.
24
- 4. **Mechanics (The How)**:
25
- - **For Logic**: `shadow_analyze_flow` (symbolName, filePath, repoPath) Trace execution.
26
- - **For Objects**: `shadow_inspect_file` (filePath, detailLevel: "signatures", repoPath) — All exports.
27
- - **For Symbol Deep Dive**: `shadow_inspect_symbol` (symbolName, filePath, context: "full", repoPath) — With deps.
28
- - **For Change History**: `shadow_analyze_explain_diff` (fromCommit, toCommit, repoPath) — Semantic narrative of what changed and why between commits.
29
- 5. **Synthesis**: `shadow_ops_log` (missionId, type: "discovery", content, symbolName, repoPath).
30
-
31
- ## Precise Tooling
32
-
33
- | Discovery Layer | Atomic Tool |
34
- | :----------------- | :--------------------------------------------------------------------------------------------------- |
35
- | **Session Start** | `shadow_ops_context` (repoPath) — **START HERE** |
36
- | **Hologram** | `shadow_recon_hologram` (repoPath) if you need standalone hologram |
37
- | **History** | `shadow_ops_chronicle` (limit: 5) — if you need more than 5 from context |
38
- | **Layers** | `shadow_recon_topography` — detailed breakdown |
39
- | **Mission Detail** | `shadow_ops_briefing` (altitude: "ground") — full logs + working set |
40
- | **Blast Radius** | `shadow_analyze_impact` (symbolName, depth: 3) |
41
- | **Dependents** | `shadow_analyze_deps` (filePath, direction: "imported_by") |
42
- | **Flow Trace** | `shadow_analyze_flow` (symbolName, filePath) |
43
- | **Structure** | `shadow_inspect_file` (detailLevel: "signatures") |
44
- | **Deep Dive** | `shadow_inspect_symbol` (context: "full") |
45
- | **File Discovery** | `shadow_search_path` (query, **ranked: true**) — gravity-sorted results with layer classification |
46
- | **Event Mesh** | `shadow_analyze_mesh` (repoPath) — HTTP routes, socket events, pubsub topics + producers/consumers |
47
- | **Type Graph** | `shadow_analyze_type_graph` (filePath) — interface/class inheritance chains |
48
- | **Explain Diff** | `shadow_analyze_explain_diff` (fromCommit, toCommit) — semantic narrative of changes between commits |
49
-
50
- _Note: **ALWAYS start with `shadow_ops_context`** for instant architectural context + history + mission state in ONE call. Use `context: "definition"` for token-efficient single symbol inspection._
51
-
52
- ## Intelligence Options
53
-
54
- - **`shadow_search_path` with `ranked: true`**: Results sorted by gravity (high-import files first) with layer classification (Entry/Logic/Data). Use when you need to find the most architecturally important files matching a pattern.
55
- - **`shadow_search_concept` with `compact: true`**: Omits code snippets for ~60% token savings. Use for broad exploration before deep dives.
56
- - **Briefing altitude levels**: Use `orbit` for quick status, `atmosphere` for strategy + crystals, `ground` for raw logs + collisions.
57
- - **`shadow_ops_crystallize`**: If a mission has excessive raw logs, crystallize them first for leaner briefings.
6
+ # Understand
7
+
8
+ Use this skill to build the shortest reliable path from "what is this?" to "I can explain or change it."
9
+
10
+ ## Start broad
11
+
12
+ 1. `shadow_ops_context({ repoPath, compact: true })`
13
+ 2. Expand only as needed:
14
+ - `shadow_recon_tree({ repoPath, subPath?, maxDepth? })`
15
+ - `shadow_recon_topography({ repoPath })`
16
+ - `shadow_ops_briefing({ repoPath, scope: "mission", missionId, altitude: "ground" })`
17
+
18
+ ## Relational analysis
19
+
20
+ - `shadow_search_concept({ repoPath, query, compact: true })`
21
+ - `shadow_search_symbol({ repoPath, query, matchMode? })`
22
+ - `shadow_analyze_impact({ repoPath, symbolName, filePath?, depth: 3 })`
23
+ - `shadow_analyze_deps({ repoPath, filePath, direction: "imported_by" })`
24
+ - `shadow_analyze_type_graph({ repoPath, symbolName, filePath?, direction?, relationship? })`
25
+ - `shadow_analyze_mesh({ repoPath, topic, type? })` when you have a concrete route or event fragment
26
+
27
+ ## Mechanics
28
+
29
+ - `shadow_inspect_file({ repoPath, filePath, detailLevel: "signatures" })`
30
+ - `shadow_inspect_symbol({ repoPath, symbolName, filePath?, context: "definition" | "full" })`
31
+ - `shadow_analyze_flow({ repoPath, filePath, symbolName? })`
32
+ - `shadow_analyze_explain_diff({ repoPath, baseCommit?, headCommit?, staged? })`
33
+
34
+ ## Closeout
35
+
36
+ - `shadow_ops_log({ repoPath, missionId?, type: "discovery", content, symbolName?, filePath? })`
37
+
38
+ ## Rules
39
+
40
+ - Start broad and narrow down; do not jump straight to full-symbol inspection unless you already know the target.
41
+ - `shadow_analyze_type_graph` requires `symbolName`.
42
+ - `shadow_analyze_mesh` requires `topic`.
@@ -3,28 +3,28 @@ name: workspace
3
3
  description: Manage multi-repository workspaces and cross-repo mission links using the Shadow Engine. Use when working with multiple repositories, federated search across repos, linking missions across repos, or when the user asks about workspace management, multi-repo workflows, or cross-repository dependencies.
4
4
  ---
5
5
 
6
- # Workspace Orchestration
6
+ # Workspace
7
7
 
8
8
  Manage multi-repository workspaces and cross-repo mission links using the Shadow Engine.
9
9
 
10
- ## 🚀 Workflow
10
+ ## Core calls
11
11
 
12
- 1. **List Workspaces**: `shadow_workspace_list` (repoPath, repoPaths).
13
- 2. **Federated Search**: `shadow_workspace_fuse` (repoPath, repoPaths).
14
- 3. **Link Missions**: `shadow_workspace_link` (parentRepoPath, parentMissionId, childRepoPath, childMissionId, relationship, repoPath).
15
- 4. **Verify Graph**: `shadow_ops_graph` (missionId, depth, repoPath).
12
+ - List active work across repos:
13
+ - `shadow_workspace_list({ repoPaths, status? })`
14
+ - Build a fused search index:
15
+ - `shadow_workspace_fuse({ repoPaths, name? })`
16
+ - Link missions across repos:
17
+ - `shadow_workspace_link({ parentRepoPath, parentMissionId, childRepoPath, childMissionId, relationship })`
18
+ - Visualize a repo's mission graph:
19
+ - `shadow_ops_graph({ repoPath, missionId?, depth?, format? })`
16
20
 
17
- ## 🛠 Precise Tooling
21
+ ## After fusion
18
22
 
19
- | Action | Atomic Tool | Example |
20
- | :------------ | :---------------------- | :----------------------------------------------- |
21
- | **List** | `shadow_workspace_list` | `{ repoPath, repoPaths: [...] }` |
22
- | **Fuse** | `shadow_workspace_fuse` | `{ repoPath, repoPaths: [...] }` |
23
- | **Link** | `shadow_workspace_link` | `{ parentMissionId: 1, childMissionId: 2, ... }` |
24
- | **Visualize** | `shadow_ops_graph` | `{ missionId: 1, depth: 3, repoPath }` |
23
+ - Use the normal `shadow_search_*` and `shadow_analyze_*` tools inside the participating repos.
24
+ - For routes and events that cross repo boundaries, use:
25
+ - `shadow_analyze_mesh({ repoPath, topic, includeCrossRepo: true })`
25
26
 
26
- _Note: Use fused search after `shadow_workspace_fuse` to look up concepts across all repositories simultaneously._
27
+ ## Rules
27
28
 
28
- ## 🛠 Tooling Strategy
29
-
30
- Use **`shadow_workspace_fuse`** early in multi-repo sessions to unlock "X-Ray" vision across boundaries.
29
+ - `shadow_workspace_list` and `shadow_workspace_fuse` take `repoPaths`, not `repoPath`.
30
+ - `shadow_workspace_link` uses explicit parent and child repo paths; there is no shared `repoPath` parameter.