@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.
- package/README.md +3 -3
- package/dist/data/migrations/000_baseline.sql +27 -0
- package/dist/data/migrations/013_file_claims.sql +18 -0
- package/dist/data/migrations/014_tribunal_state.sql +24 -0
- package/dist/data/migrations/015_repo_level_handoffs_nullable.sql +52 -0
- package/dist/data/migrations/016_repair_tribunal_artifact_fk.sql +58 -0
- package/dist/entry/cli/index.js +597 -495
- package/dist/entry/ember/index.js +109 -32
- package/dist/entry/mcp/server.js +443 -347
- package/dist/entry/tribunal/index.js +650 -0
- package/dist/index.js +441 -345
- package/dist/logic/parser/index.js +16 -14
- package/dist/skills/shadow_audit/SKILL.md +22 -30
- package/dist/skills/shadow_chronicle/SKILL.md +16 -29
- package/dist/skills/shadow_continue/SKILL.md +37 -53
- package/dist/skills/shadow_coordinate/SKILL.md +46 -0
- package/dist/skills/shadow_crystallize/SKILL.md +13 -27
- package/dist/skills/shadow_mission/SKILL.md +27 -41
- package/dist/skills/shadow_onboard/SKILL.md +26 -35
- package/dist/skills/shadow_research/SKILL.md +15 -23
- package/dist/skills/shadow_sync/SKILL.md +18 -9
- package/dist/skills/shadow_synthesize/SKILL.md +14 -36
- package/dist/skills/shadow_trace_impact/SKILL.md +30 -50
- package/dist/skills/shadow_understand/SKILL.md +37 -52
- package/dist/skills/shadow_workspace/SKILL.md +17 -17
- package/dist/web-manifest.json +16 -6
- package/package.json +1 -1
- package/skills/shadow_audit/SKILL.md +22 -30
- package/skills/shadow_chronicle/SKILL.md +16 -29
- package/skills/shadow_continue/SKILL.md +37 -53
- package/skills/shadow_coordinate/SKILL.md +46 -0
- package/skills/shadow_crystallize/SKILL.md +13 -27
- package/skills/shadow_mission/SKILL.md +27 -41
- package/skills/shadow_onboard/SKILL.md +26 -35
- package/skills/shadow_research/SKILL.md +15 -23
- package/skills/shadow_sync/SKILL.md +18 -9
- package/skills/shadow_synthesize/SKILL.md +14 -36
- package/skills/shadow_trace_impact/SKILL.md +30 -50
- package/skills/shadow_understand/SKILL.md +37 -52
- 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
|
-
#
|
|
6
|
+
# Crystallize
|
|
7
7
|
|
|
8
|
-
Compress raw intent logs into a
|
|
8
|
+
Compress raw intent logs into a crystal so briefings stay useful instead of noisy.
|
|
9
9
|
|
|
10
|
-
##
|
|
10
|
+
## Core calls
|
|
11
11
|
|
|
12
|
-
-
|
|
13
|
-
-
|
|
14
|
-
-
|
|
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
|
-
##
|
|
16
|
+
## When to use it
|
|
18
17
|
|
|
19
|
-
|
|
20
|
-
|
|
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
|
-
-
|
|
41
|
-
-
|
|
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
|
|
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
|
|
6
|
+
# Mission
|
|
7
7
|
|
|
8
|
-
|
|
8
|
+
This skill is for planning. It stops at "ready to execute."
|
|
9
9
|
|
|
10
|
-
|
|
10
|
+
## Start
|
|
11
11
|
|
|
12
|
-
|
|
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
|
-
|
|
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
|
-
|
|
23
|
+
Use `shadow_ops_plan` with the fields that matter:
|
|
25
24
|
|
|
26
|
-
|
|
27
|
-
|
|
28
|
-
|
|
29
|
-
|
|
30
|
-
|
|
31
|
-
|
|
32
|
-
|
|
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
|
-
|
|
33
|
+
## Planning rules
|
|
39
34
|
|
|
40
|
-
|
|
41
|
-
|
|
42
|
-
-
|
|
43
|
-
-
|
|
44
|
-
-
|
|
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
|
|
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
|
-
#
|
|
7
|
-
|
|
8
|
-
|
|
9
|
-
|
|
10
|
-
##
|
|
11
|
-
|
|
12
|
-
1.
|
|
13
|
-
2.
|
|
14
|
-
3.
|
|
15
|
-
4.
|
|
16
|
-
|
|
17
|
-
|
|
18
|
-
|
|
19
|
-
|
|
20
|
-
|
|
21
|
-
|
|
22
|
-
|
|
23
|
-
|
|
24
|
-
|
|
25
|
-
|
|
26
|
-
|
|
27
|
-
|
|
28
|
-
|
|
29
|
-
|
|
30
|
-
|
|
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:
|
|
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
|
-
#
|
|
6
|
+
# Research
|
|
7
7
|
|
|
8
|
-
|
|
8
|
+
Start local, then verify externally.
|
|
9
9
|
|
|
10
|
-
##
|
|
10
|
+
## Local first
|
|
11
11
|
|
|
12
|
-
|
|
13
|
-
|
|
14
|
-
|
|
15
|
-
|
|
16
|
-
|
|
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
|
-
##
|
|
18
|
+
## External verification
|
|
19
19
|
|
|
20
|
-
|
|
21
|
-
|
|
22
|
-
|
|
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
|
-
##
|
|
24
|
+
## Closeout
|
|
29
25
|
|
|
30
|
-
-
|
|
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
|
-
#
|
|
6
|
+
# Sync
|
|
7
7
|
|
|
8
|
-
|
|
8
|
+
Day-to-day, Shadow often reindexes on demand. Use manual sync when the repository changed outside the normal flow.
|
|
9
9
|
|
|
10
|
-
##
|
|
10
|
+
## Prefer these calls
|
|
11
11
|
|
|
12
|
-
|
|
13
|
-
|
|
14
|
-
|
|
15
|
-
|
|
16
|
-
|
|
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
|
-
|
|
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
|
-
#
|
|
6
|
+
# Synthesize
|
|
7
7
|
|
|
8
|
-
|
|
8
|
+
Use this skill when a mission needs to become durable project memory.
|
|
9
9
|
|
|
10
|
-
|
|
10
|
+
## Primary path
|
|
11
11
|
|
|
12
|
-
|
|
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
|
-
|
|
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
|
-
|
|
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
|
-
|
|
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
|
-
|
|
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
|
|
7
|
-
|
|
8
|
-
|
|
9
|
-
|
|
10
|
-
##
|
|
11
|
-
|
|
12
|
-
1.
|
|
13
|
-
2.
|
|
14
|
-
3.
|
|
15
|
-
|
|
16
|
-
|
|
17
|
-
|
|
18
|
-
|
|
19
|
-
|
|
20
|
-
|
|
21
|
-
|
|
22
|
-
|
|
23
|
-
|
|
24
|
-
|
|
25
|
-
|
|
26
|
-
|
|
27
|
-
##
|
|
28
|
-
|
|
29
|
-
|
|
30
|
-
|
|
31
|
-
|
|
32
|
-
|
|
33
|
-
|
|
34
|
-
|
|
35
|
-
|
|
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
|
-
#
|
|
7
|
-
|
|
8
|
-
|
|
9
|
-
|
|
10
|
-
##
|
|
11
|
-
|
|
12
|
-
1.
|
|
13
|
-
|
|
14
|
-
|
|
15
|
-
- `shadow_recon_topography
|
|
16
|
-
- `
|
|
17
|
-
|
|
18
|
-
|
|
19
|
-
|
|
20
|
-
|
|
21
|
-
|
|
22
|
-
|
|
23
|
-
|
|
24
|
-
|
|
25
|
-
|
|
26
|
-
|
|
27
|
-
|
|
28
|
-
|
|
29
|
-
|
|
30
|
-
|
|
31
|
-
|
|
32
|
-
|
|
33
|
-
|
|
34
|
-
|
|
35
|
-
|
|
36
|
-
|
|
37
|
-
|
|
38
|
-
|
|
39
|
-
|
|
40
|
-
|
|
41
|
-
|
|
42
|
-
|
|
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
|
|
6
|
+
# Workspace
|
|
7
7
|
|
|
8
8
|
Manage multi-repository workspaces and cross-repo mission links using the Shadow Engine.
|
|
9
9
|
|
|
10
|
-
##
|
|
10
|
+
## Core calls
|
|
11
11
|
|
|
12
|
-
|
|
13
|
-
|
|
14
|
-
|
|
15
|
-
|
|
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
|
-
##
|
|
21
|
+
## After fusion
|
|
18
22
|
|
|
19
|
-
|
|
20
|
-
|
|
21
|
-
|
|
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
|
-
|
|
27
|
+
## Rules
|
|
27
28
|
|
|
28
|
-
|
|
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.
|