bmad-module-skill-forge 0.7.0 → 0.7.1
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/docs/how-it-works.md +2 -0
- package/package.json +1 -1
- package/src/knowledge/ccc-bridge.md +2 -1
- package/src/knowledge/overview.md +1 -0
- package/src/knowledge/progressive-capability.md +2 -0
- package/src/knowledge/qmd-registry.md +1 -1
- package/src/knowledge/skf-knowledge-index.csv +1 -0
- package/src/knowledge/tool-resolution.md +55 -0
- package/src/workflows/analyze-source/steps-c/step-04-map-and-detect.md +2 -2
- package/src/workflows/audit-skill/steps-c/step-01-init.md +1 -1
- package/src/workflows/audit-skill/steps-c/step-02-re-index.md +3 -1
- package/src/workflows/audit-skill/steps-c/step-03-structural-diff.md +2 -2
- package/src/workflows/audit-skill/steps-c/step-04-semantic-diff.md +1 -1
- package/src/workflows/audit-skill/steps-c/step-05-severity-classify.md +1 -1
- package/src/workflows/brief-skill/steps-c/step-02-analyze-target.md +1 -1
- package/src/workflows/create-skill/data/extraction-patterns.md +7 -1
- package/src/workflows/create-skill/data/source-resolution-protocols.md +1 -1
- package/src/workflows/create-skill/data/tier-degradation-rules.md +1 -1
- package/src/workflows/create-skill/steps-c/step-01-load-brief.md +1 -1
- package/src/workflows/create-skill/steps-c/step-02b-ccc-discover.md +4 -0
- package/src/workflows/create-skill/steps-c/step-03-extract.md +4 -0
- package/src/workflows/create-skill/steps-c/step-04-enrich.md +2 -0
- package/src/workflows/create-stack-skill/data/manifest-patterns.md +23 -1
- package/src/workflows/create-stack-skill/steps-c/step-01-init.md +2 -0
- package/src/workflows/create-stack-skill/steps-c/step-02-detect-manifests.md +2 -1
- package/src/workflows/create-stack-skill/steps-c/step-03-rank-and-confirm.md +3 -1
- package/src/workflows/create-stack-skill/steps-c/step-04-parallel-extract.md +26 -7
- package/src/workflows/create-stack-skill/steps-c/step-05-detect-integrations.md +5 -1
- package/src/workflows/setup-forge/steps-c/step-01b-ccc-index.md +4 -2
- package/src/workflows/update-skill/steps-c/step-02-detect-changes.md +1 -1
- package/src/workflows/update-skill/steps-c/step-03-re-extract.md +3 -1
- package/src/workflows/update-skill/steps-c/step-05-validate.md +1 -1
package/docs/how-it-works.md
CHANGED
|
@@ -332,6 +332,8 @@ Export injects a managed section between markers:
|
|
|
332
332
|
| **`qmd_bridge`** | QMD (local search) | BM25 keyword search, vector semantic search, collection indexing |
|
|
333
333
|
| **`doc_fetcher`** | Environment web tools | Remote documentation fetching for T3-confidence content. Tool-agnostic — uses whatever web fetching is available (Firecrawl, WebFetch, curl, etc.). Output quarantined as T3. |
|
|
334
334
|
|
|
335
|
+
Bridge names are **conceptual interfaces** used throughout workflow steps. Each bridge resolves to concrete MCP tools, CLI commands, or fallback behavior depending on the IDE environment. See [`src/knowledge/tool-resolution.md`](https://github.com/armelhbobdad/bmad-module-skill-forge/blob/main/src/knowledge/tool-resolution.md) for the complete resolution table.
|
|
336
|
+
|
|
335
337
|
### Conflict Resolution
|
|
336
338
|
|
|
337
339
|
When tools disagree, higher priority wins for instructions. Lower priority is preserved as annotations:
|
package/package.json
CHANGED
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
{
|
|
2
2
|
"$schema": "https://json.schemastore.org/package.json",
|
|
3
3
|
"name": "bmad-module-skill-forge",
|
|
4
|
-
"version": "0.7.
|
|
4
|
+
"version": "0.7.1",
|
|
5
5
|
"description": "BMAD module — Turn code and docs into instructions AI agents can actually follow. Progressive capability tiers (Quick/Forge/Forge+/Deep).",
|
|
6
6
|
"keywords": [
|
|
7
7
|
"bmad",
|
|
@@ -2,7 +2,7 @@
|
|
|
2
2
|
|
|
3
3
|
## Principle
|
|
4
4
|
|
|
5
|
-
`ccc_bridge.*` references in workflow steps are **conceptual interfaces**, not callable functions. They describe a semantic code discovery operation to perform. Use the `ccc` MCP server tools (when available) or `ccc` CLI commands to execute these operations. See the TOOL/SUBPROCESS FALLBACK rule — if ccc is unavailable, the calling step falls back to direct ast-grep or source reading without ccc pre-discovery.
|
|
5
|
+
`ccc_bridge.*` references in workflow steps are **conceptual interfaces**, not callable functions. They describe a semantic code discovery operation to perform. Use the `ccc` MCP server tools (when available) or `ccc` CLI commands to execute these operations. See the TOOL/SUBPROCESS FALLBACK rule — if ccc is unavailable, the calling step falls back to direct ast-grep or source reading without ccc pre-discovery. For the complete bridge-to-tool resolution table covering all IDE environments, see [tool-resolution.md](tool-resolution.md).
|
|
6
6
|
|
|
7
7
|
## Rationale
|
|
8
8
|
|
|
@@ -103,6 +103,7 @@ To prevent excessive daemon calls, workflow steps cap ccc queries:
|
|
|
103
103
|
|
|
104
104
|
## Related Fragments
|
|
105
105
|
|
|
106
|
+
- [tool-resolution.md](tool-resolution.md) — canonical bridge-to-tool and subprocess-to-tool mapping per IDE
|
|
106
107
|
- [progressive-capability.md](progressive-capability.md) — Forge+ tier definition and positive framing
|
|
107
108
|
- [confidence-tiers.md](confidence-tiers.md) — why ccc does not create a new confidence tier
|
|
108
109
|
- [qmd-registry.md](qmd-registry.md) — the parallel but separate registry for QMD collections
|
|
@@ -31,6 +31,7 @@ With knowledge files:
|
|
|
31
31
|
| [manual-section-integrity.md](manual-section-integrity.md) | \[MANUAL\] marker preservation and merge algorithm | CS, US, AS, TS, EX |
|
|
32
32
|
| [qmd-registry.md](qmd-registry.md) | Progressive QMD collection registry and collection gate principle | SF, BS, CS, US, AS |
|
|
33
33
|
| [ccc-bridge.md](ccc-bridge.md) | ccc_bridge interface, indexing lifecycle, Forge+ discovery-before-extraction | SF, AN, CS, SS, US, AS |
|
|
34
|
+
| [tool-resolution.md](tool-resolution.md) | Bridge-to-tool and subprocess-to-tool mapping per IDE environment | CS, QS, SS, US, AS, AN, BS, RA |
|
|
34
35
|
| [architecture-verification.md](architecture-verification.md) | Pre-code verification pipeline, integration verdicts, iteration loop | VS, RA, SS |
|
|
35
36
|
| [doc-fetcher.md](doc-fetcher.md) | T3 external documentation fetching, quarantine rules, tool-agnostic | CS, QS |
|
|
36
37
|
| [split-body-strategy.md](split-body-strategy.md) | Selective vs full split-body, detection pattern, agent accuracy | CS, QS, US, TS, EX |
|
|
@@ -84,6 +84,8 @@ Deep: "Full intelligence pipeline — AST verification plus GitHub exploration
|
|
|
84
84
|
- **Forge+:** Identical extraction to Forge, plus ccc semantic pre-discovery narrows the file set before ast-grep runs. For large codebases, `ccc_bridge.search()` produces a ranked candidate list. ast-grep operates on that list rather than the full tree. All results remain T1 (AST-verified) — ccc is upstream, not in the extraction chain.
|
|
85
85
|
- **Deep:** Identical extraction to Forge, plus QMD enrichment in a separate step. T2 annotations layer on top of the T1 base without replacing it.
|
|
86
86
|
|
|
87
|
+
*Bridge names (`gh_bridge`, `ast_bridge`, `ccc_bridge`, `qmd_bridge`) are conceptual interfaces. See [tool-resolution.md](tool-resolution.md) for concrete tool resolution per IDE.*
|
|
88
|
+
|
|
87
89
|
**Key Points:**
|
|
88
90
|
- Extraction quality increases with tier, but every tier produces complete output
|
|
89
91
|
- Forge and Deep share the same extraction core — Deep adds enrichment, not better parsing
|
|
@@ -21,7 +21,7 @@ The progressive registry solves all three by indexing **curated workflow artifac
|
|
|
21
21
|
| Role | Workflow | Responsibility |
|
|
22
22
|
| --- | --- | --- |
|
|
23
23
|
| **Producer** | brief-skill, create-skill | Creates QMD collections from workflow artifacts and registers them in forge-tier.yaml |
|
|
24
|
-
| **Consumer** | audit-skill, update-skill | Reads the registry, discovers collections by skill name and type, queries via qmd_bridge |
|
|
24
|
+
| **Consumer** | audit-skill, update-skill, create-stack-skill | Reads the registry, discovers collections by skill name and type, queries via qmd_bridge (see [tool-resolution.md](tool-resolution.md) for concrete resolution) |
|
|
25
25
|
| **Janitor** | setup-forge | Cross-references live QMD collections against the registry, cleans orphans and stale entries |
|
|
26
26
|
|
|
27
27
|
### Registry Schema
|
|
@@ -12,3 +12,4 @@ qmd-registry,QMD Collection Registry,"Progressive registry architecture — prod
|
|
|
12
12
|
doc-fetcher,Doc Fetcher,"T3 external documentation — tool-agnostic URL fetching, quarantine rules, conflict resolution","doc-fetcher,t3,external,documentation,quarantine",extended,knowledge/doc-fetcher.md
|
|
13
13
|
architecture-verification,Architecture Verification,"Pre-code verification pipeline — VS/RA/SS-compose lifecycle, integration verdicts, coverage analysis, iteration loop","architecture,verification,stack,feasibility,integration,vs,ra,ss,compose",core,knowledge/architecture-verification.md
|
|
14
14
|
split-body-strategy,Split-Body Strategy,"Selective split guidance — detection pattern, recommended approach, impact on tessl scores and snippet anchors","split-body,selective-split,references,body-size",core,knowledge/split-body-strategy.md
|
|
15
|
+
tool-resolution,Tool Resolution,"Bridge-to-tool and subprocess-to-tool mapping — ast_bridge, ccc_bridge, qmd_bridge, gh_bridge resolution per IDE, subprocess Pattern 1-4 definitions","bridge,tools,resolution,subprocess,mcp,cli,ide",core,knowledge/tool-resolution.md
|
|
@@ -0,0 +1,55 @@
|
|
|
1
|
+
# Tool Resolution
|
|
2
|
+
|
|
3
|
+
Bridge names (`ast_bridge`, `ccc_bridge`, `qmd_bridge`, `gh_bridge`) and subprocess patterns (Pattern 1–4) used throughout SKF workflows are **conceptual interfaces**, not callable functions. This document provides the canonical mapping from abstract names to concrete tools per IDE environment.
|
|
4
|
+
|
|
5
|
+
## Bridge Resolution Table
|
|
6
|
+
|
|
7
|
+
| Bridge | Operation | Claude Code | Cursor | CLI | Fallback |
|
|
8
|
+
|--------------|----------------------------------|------------------------------------------------------------------|----------------|----------------------------------------------------|----------------------------------|
|
|
9
|
+
| `ast_bridge` | `scan_definitions()` | `mcp__ast-grep__find_code` or `mcp__ast-grep__find_code_by_rule` | ast-grep MCP | `sg run` / `ast-grep -p` | Source reading (T1-low) |
|
|
10
|
+
| `ast_bridge` | `detect_co_imports()` | `mcp__ast-grep__find_code_by_rule` with co-import YAML rule | ast-grep MCP | `ast-grep -p 'import $$$' --json=stream` | grep-based co-import count |
|
|
11
|
+
| `ccc_bridge` | `search(query, root, top_k)` | `/ccc` skill search | ccc MCP server | `ccc search "{query}" --path {root} --top {top_k}` | Skip silently |
|
|
12
|
+
| `ccc_bridge` | `ensure_index(root)` | `/ccc` skill indexing | ccc MCP server | `ccc init` + `ccc index {root}` | Skip silently |
|
|
13
|
+
| `ccc_bridge` | `status()` | `/ccc` skill status | ccc MCP server | `ccc --help` + `ccc doctor` | Unavailable = `tools.ccc: false` |
|
|
14
|
+
| `qmd_bridge` | `search(query)` | `mcp__plugin_qmd-plugin_qmd__search` | qmd MCP server | `qmd search "{query}"` | Skip enrichment |
|
|
15
|
+
| `qmd_bridge` | `vector_search(query)` | `mcp__plugin_qmd-plugin_qmd__vector_search` | qmd MCP server | `qmd vector_search "{query}"` | Use BM25 search only |
|
|
16
|
+
| `gh_bridge` | `list_tree(owner, repo, branch)` | `gh api repos/{owner}/{repo}/git/trees/{branch}?recursive=1` | gh CLI | `gh api ...` | Direct file listing if local |
|
|
17
|
+
| `gh_bridge` | `read_file(owner, repo, path)` | `gh api repos/{owner}/{repo}/contents/{path}` | gh CLI | `gh api ...` | Direct file read if local |
|
|
18
|
+
|
|
19
|
+
## Subprocess Pattern Definitions
|
|
20
|
+
|
|
21
|
+
Workflow steps reference "subprocess" execution with numbered patterns. These map to concrete mechanisms per IDE:
|
|
22
|
+
|
|
23
|
+
| Pattern | Purpose | Claude Code | Cursor | CLI |
|
|
24
|
+
|----------------------------------------|-------------------------------------------------------|----------------------------------------------------------------------|-----------------------------------|------------------------------------|
|
|
25
|
+
| **Pattern 1** (grep/search) | Search across files for imports, co-imports | Grep tool or Bash with `rg` | Built-in search | `grep` / `rg` |
|
|
26
|
+
| **Pattern 2** (per-file deep analysis) | Deep analysis of individual files or units | Agent tool (sequential per unit) | Sequential analysis | Per-unit script |
|
|
27
|
+
| **Pattern 3** (data operations) | QMD queries, severity classification, data transforms | Main thread (Read + process) | Main thread | Script |
|
|
28
|
+
| **Pattern 4** (parallel execution) | Parallel per-library extraction, parallel diffing | Agent tool with multiple parallel calls or `run_in_background: true` | Parallel requests (IDE-dependent) | `xargs -P` or background processes |
|
|
29
|
+
|
|
30
|
+
### max_parallel_generation
|
|
31
|
+
|
|
32
|
+
Referenced by Pattern 4 steps. Defines the maximum concurrent subprocess spawns:
|
|
33
|
+
|
|
34
|
+
| Environment | Recommended Value | Notes |
|
|
35
|
+
|-------------|----------------------------------|-----------------------------------------------------------------------|
|
|
36
|
+
| Claude Code | 3–5 | Concurrent Agent tool calls; higher values may cause context pressure |
|
|
37
|
+
| Cursor | IDE-dependent | Follow Cursor's agent concurrency limits |
|
|
38
|
+
| CLI | CPU core count or user-specified | Use `xargs -P {n}` or equivalent |
|
|
39
|
+
|
|
40
|
+
## Resolution Protocol
|
|
41
|
+
|
|
42
|
+
When a workflow step references a bridge name or subprocess pattern:
|
|
43
|
+
|
|
44
|
+
1. **Identify** the bridge name (`ast_bridge`, `ccc_bridge`, etc.) or pattern number (Pattern 1–4)
|
|
45
|
+
2. **Check tool availability** in `{sidecar_path}/forge-tier.yaml` → `tools.*` section
|
|
46
|
+
3. **Resolve** using the tables above — use the first available option in priority order: MCP tool → CLI command → Fallback
|
|
47
|
+
4. **Apply fallback** if no resolution is available — fallbacks are always defined and never block the workflow
|
|
48
|
+
5. **Log degradation** when falling back — note the reason in context for the evidence report
|
|
49
|
+
|
|
50
|
+
## Related Fragments
|
|
51
|
+
|
|
52
|
+
- [ccc-bridge.md](ccc-bridge.md) — CCC semantic discovery interface and lifecycle
|
|
53
|
+
- [progressive-capability.md](progressive-capability.md) — Quick/Forge/Forge+/Deep tier philosophy
|
|
54
|
+
- [confidence-tiers.md](confidence-tiers.md) — T1/T1-low/T2/T3 trust model and citation formats
|
|
55
|
+
- [qmd-registry.md](qmd-registry.md) — QMD collection producer/consumer/janitor architecture
|
|
@@ -33,7 +33,7 @@ To analyze each qualifying unit's export surface and import graph, detect cross-
|
|
|
33
33
|
|
|
34
34
|
### Step-Specific Rules:
|
|
35
35
|
|
|
36
|
-
- 🎯 Use subprocess optimization (Pattern 2
|
|
36
|
+
- 🎯 Use subprocess optimization (Pattern 2 — per-unit deep analysis): In Claude Code, use Agent tool for each unit sequentially. In CLI, use a per-unit script. See [knowledge/tool-resolution.md](../../../knowledge/tool-resolution.md)
|
|
37
37
|
- 💬 DO NOT BE LAZY — For EACH qualifying unit, perform thorough export surface analysis
|
|
38
38
|
- 🚫 FORBIDDEN to make recommendations in this step (that's step 05)
|
|
39
39
|
- 📋 Tier-aware depth: Quick (file-level exports), Forge (AST export analysis), Deep (AST + semantic relationships)
|
|
@@ -82,7 +82,7 @@ DO NOT BE LAZY — For EACH qualifying unit, launch a subprocess (or analyze in
|
|
|
82
82
|
- **Quick tier:** Count files by type, identify index/barrel files, list directory structure
|
|
83
83
|
- **Forge tier:** Parse export statements, identify public API surface, count exported functions/classes/types
|
|
84
84
|
- **Forge+ tier:** All Forge analysis plus:
|
|
85
|
-
- If `tools.ccc` is true: run `ccc_bridge.search("{unit_name} exports public API", top_k=15)` to discover semantically relevant files beyond directory scan
|
|
85
|
+
- If `tools.ccc` is true: run `ccc_bridge.search("{unit_name} exports public API", top_k=15)` — **Tool resolution:** `/ccc` skill search (Claude Code), ccc MCP server (Cursor), or `ccc search` CLI; see [knowledge/tool-resolution.md](../../../knowledge/tool-resolution.md) — to discover semantically relevant files beyond directory scan
|
|
86
86
|
- Merge CCC-discovered files with scoped file list — files from CCC that are within the unit's directory are added to the analysis queue
|
|
87
87
|
- Record CCC signals in per-unit findings: top 3 CCC-ranked file names (or "—" if no ccc results)
|
|
88
88
|
- **Deep tier:** All Forge analysis plus:
|
|
@@ -83,7 +83,7 @@ Load `{sidecar_path}/forge-tier.yaml` to detect available tools.
|
|
|
83
83
|
|
|
84
84
|
**If found:**
|
|
85
85
|
- Extract tier level: Quick / Forge / Forge+ / Deep
|
|
86
|
-
- Extract available tools: gh_bridge, ast_bridge, qmd_bridge
|
|
86
|
+
- Extract available tools: gh_bridge, ast_bridge, qmd_bridge — see [knowledge/tool-resolution.md](../../../knowledge/tool-resolution.md) for concrete tool resolution per IDE
|
|
87
87
|
|
|
88
88
|
**Apply tier override:** Read `{sidecar_path}/preferences.yaml`. If `tier_override` is set and is a valid tier value (Quick, Forge, Forge+, or Deep), use it instead of the detected tier.
|
|
89
89
|
|
|
@@ -78,6 +78,8 @@ Based on forge tier detected in Step 01:
|
|
|
78
78
|
- Query qmd_bridge for temporal context: when exports were added, modification history, usage frequency
|
|
79
79
|
- Confidence labels: T1 for structural, T2 for temporal context
|
|
80
80
|
|
|
81
|
+
**Tool resolution:** `gh_bridge` → `gh api` commands or direct file I/O if local. `ast_bridge` → ast-grep MCP tools (`find_code`, `find_code_by_rule`) or `ast-grep` CLI. `qmd_bridge` → QMD MCP tools (`search`, `vector_search`) or `qmd` CLI. See [knowledge/tool-resolution.md](../../../knowledge/tool-resolution.md).
|
|
82
|
+
|
|
81
83
|
### 2. Scan Source Files
|
|
82
84
|
|
|
83
85
|
Identify all source files in the source directory that contain public exports.
|
|
@@ -148,7 +150,7 @@ Skip this section. Temporal context requires Deep tier.
|
|
|
148
150
|
|
|
149
151
|
For each export in the skill baseline that was NOT found at its recorded file path during re-extraction (potential "deleted" export):
|
|
150
152
|
|
|
151
|
-
1. Run `ccc_bridge.search("{export_name}", source_root, top_k=5)` to find candidate current locations
|
|
153
|
+
1. Run `ccc_bridge.search("{export_name}", source_root, top_k=5)` — **Tool resolution:** Use `/ccc` skill search (Claude Code), ccc MCP server (Cursor), or `ccc search "{export_name}" --path {source_root} --top 5` (CLI) — to find candidate current locations
|
|
152
154
|
2. If CCC returns files containing the export name:
|
|
153
155
|
- Run ast-grep verification on each candidate file
|
|
154
156
|
- If verified at a new location: reclassify from "deleted" to "moved" with the new file:line reference
|
|
@@ -33,7 +33,7 @@ Compare the original provenance map extractions from create-skill against the cu
|
|
|
33
33
|
- 🎯 Focus only on structural comparison — added/removed/changed exports
|
|
34
34
|
- 🚫 FORBIDDEN to classify severity — that happens in Step 05
|
|
35
35
|
- 🚫 FORBIDDEN to suggest remediation — that happens in Step 06
|
|
36
|
-
- 💬 Use subprocess Pattern 4 (parallel
|
|
36
|
+
- 💬 Use subprocess Pattern 4 (parallel): In Claude Code, use multiple parallel Agent tool calls or `run_in_background: true`. In Cursor, use parallel requests (IDE-dependent). In CLI, use `xargs -P` or background processes. See [knowledge/tool-resolution.md](../../../knowledge/tool-resolution.md)
|
|
37
37
|
- ⚙️ If subprocess unavailable, compare categories sequentially in main thread
|
|
38
38
|
|
|
39
39
|
## EXECUTION PROTOCOLS:
|
|
@@ -70,7 +70,7 @@ Normalize both sets for comparison:
|
|
|
70
70
|
|
|
71
71
|
### 2. Detect Added Exports
|
|
72
72
|
|
|
73
|
-
**Launch subprocess (Pattern 4 — parallel execution):**
|
|
73
|
+
**Launch subprocess (Pattern 4 — parallel execution):** In Claude Code, use multiple parallel Agent tool calls. In CLI, use `xargs -P` or equivalent.
|
|
74
74
|
|
|
75
75
|
Find exports that exist in current scan but NOT in provenance map.
|
|
76
76
|
|
|
@@ -33,7 +33,7 @@ Compare QMD knowledge context between the original skill creation and current st
|
|
|
33
33
|
- 🎯 Focus only on semantic/meaning-level changes via QMD context
|
|
34
34
|
- 🚫 FORBIDDEN to classify severity — that happens in Step 05
|
|
35
35
|
- 🚫 FORBIDDEN to repeat structural findings from Step 03
|
|
36
|
-
- 💬 Use subprocess Pattern 3 (data operations) when available for QMD queries
|
|
36
|
+
- 💬 Use subprocess Pattern 3 (data operations — main thread Read + process in Claude Code, script in CLI) when available for QMD queries. See [knowledge/tool-resolution.md](../../../knowledge/tool-resolution.md)
|
|
37
37
|
- ⚙️ If subprocess unavailable, query QMD in main thread
|
|
38
38
|
- 🔀 CONDITIONAL: Skip entire analysis at Quick/Forge/Forge+ tier — append skip notice only
|
|
39
39
|
|
|
@@ -34,7 +34,7 @@ Grade every drift finding from Steps 03 and 04 by severity level (CRITICAL/HIGH/
|
|
|
34
34
|
- 🎯 Focus only on classifying severity of existing findings
|
|
35
35
|
- 🚫 FORBIDDEN to discover new drift items — only classify what Steps 03-04 found
|
|
36
36
|
- 🚫 FORBIDDEN to suggest remediation — that happens in Step 06
|
|
37
|
-
- 💬 Use subprocess Pattern 3 (data operations) to load severity rules and classify
|
|
37
|
+
- 💬 Use subprocess Pattern 3 (data operations — main thread Read + process in Claude Code, script in CLI) to load severity rules and classify. See [knowledge/tool-resolution.md](../../../knowledge/tool-resolution.md)
|
|
38
38
|
- ⚙️ If subprocess unavailable, load rules and classify in main thread
|
|
39
39
|
|
|
40
40
|
## EXECUTION PROTOCOLS:
|
|
@@ -135,7 +135,7 @@ Based on detected language, identify public API surface:
|
|
|
135
135
|
|
|
136
136
|
If `tools.ccc` is true in forge-tier.yaml, supplement the module listing with a semantic discovery pass:
|
|
137
137
|
|
|
138
|
-
Run `ccc_bridge.search("{repo_name} public API exports modules", source_path, top_k=10)
|
|
138
|
+
Run `ccc_bridge.search("{repo_name} public API exports modules", source_path, top_k=10)` — **Tool resolution:** `/ccc` skill search (Claude Code), ccc MCP server (Cursor), or `ccc search` CLI. See [knowledge/tool-resolution.md](../../../knowledge/tool-resolution.md).
|
|
139
139
|
|
|
140
140
|
If results are returned, display:
|
|
141
141
|
|
|
@@ -28,7 +28,13 @@ Source reading via gh_bridge — infer exports from file structure and content.
|
|
|
28
28
|
|
|
29
29
|
Structural extraction via ast-grep — verified exports with line-level citations.
|
|
30
30
|
|
|
31
|
-
> **Note:** `ast_bridge.*`, `qmd_bridge.*`, and `ccc_bridge.*` references below are **conceptual interfaces**, not callable functions.
|
|
31
|
+
> **Note:** `ast_bridge.*`, `qmd_bridge.*`, and `ccc_bridge.*` references below are **conceptual interfaces**, not callable functions. Resolve them as follows:
|
|
32
|
+
> - `ast_bridge.*` → ast-grep MCP tools (`mcp__ast-grep__find_code`, `mcp__ast-grep__find_code_by_rule`) or `ast-grep` CLI
|
|
33
|
+
> - `qmd_bridge.*` → QMD MCP tools (`mcp__plugin_qmd-plugin_qmd__search`, `vector_search`) or `qmd` CLI
|
|
34
|
+
> - `ccc_bridge.*` → `/ccc` skill (Claude Code), ccc MCP server (Cursor), or `ccc` CLI
|
|
35
|
+
> - `gh_bridge.*` → `gh api` commands or direct file I/O for local sources
|
|
36
|
+
>
|
|
37
|
+
> See [knowledge/tool-resolution.md](../../../knowledge/tool-resolution.md) for the complete resolution table. Also see the AST Extraction Protocol section below and the TOOL/SUBPROCESS FALLBACK rule for dispatch details.
|
|
32
38
|
|
|
33
39
|
### Strategy
|
|
34
40
|
|
|
@@ -135,4 +135,4 @@ Update the working version in context to the source version. Record the mismatch
|
|
|
135
135
|
|
|
136
136
|
**If no version file is found or version cannot be extracted:** keep `brief.version` as-is. No warning needed.
|
|
137
137
|
|
|
138
|
-
**If source is remote and accessed via Quick tier (gh_bridge, no local files):** attempt to read the version file via `gh_bridge.read_file(owner, repo, "{version_file}")` for the primary version file of the detected language. If the read fails, keep `brief.version`.
|
|
138
|
+
**If source is remote and accessed via Quick tier (gh_bridge, no local files):** attempt to read the version file via `gh_bridge.read_file(owner, repo, "{version_file}")` — resolved as `gh api repos/{owner}/{repo}/contents/{version_file}` or direct file read if local (see [knowledge/tool-resolution.md](../../../knowledge/tool-resolution.md)) — for the primary version file of the detected language. If the read fails, keep `brief.version`.
|
|
@@ -20,7 +20,7 @@ When `source_repo` is a remote URL (GitHub URL or owner/repo format) and the tie
|
|
|
20
20
|
- The extraction step MUST warn the user explicitly before degrading
|
|
21
21
|
- **create-skill:** Warning must include actionable guidance — clone locally and update `source_repo` in the brief to the local path
|
|
22
22
|
- **update-skill:** Warning must include actionable guidance — clone locally, re-run [CS] Create Skill with the local path to regenerate provenance data, then re-run the update
|
|
23
|
-
- Extraction proceeds using Quick tier strategy (source reading via gh_bridge)
|
|
23
|
+
- Extraction proceeds using Quick tier strategy (source reading via gh_bridge — resolved as `gh api` commands or direct file I/O; see [knowledge/tool-resolution.md](../../../knowledge/tool-resolution.md))
|
|
24
24
|
- All results labeled T1-low with `[SRC:...]` citations
|
|
25
25
|
- The degradation reason is recorded in the evidence report
|
|
26
26
|
|
|
@@ -114,7 +114,7 @@ Halt with specific error: "Brief validation failed: missing required field `{fie
|
|
|
114
114
|
**If `source_type: "docs-only"`:** Skip source resolution. Set `source_location: null` in context. Proceed directly to section 5 (Report Initialization) — docs-only skills have no source to resolve.
|
|
115
115
|
|
|
116
116
|
**If source_repo is a GitHub URL or owner/repo format:**
|
|
117
|
-
- Verify repository exists via `gh_bridge.list_tree(owner, repo, branch)`
|
|
117
|
+
- Verify repository exists via `gh_bridge.list_tree(owner, repo, branch)` — **Tool resolution:** `gh api repos/{owner}/{repo}/git/trees/{branch}?recursive=1` or direct file listing if local; see [knowledge/tool-resolution.md](../../../knowledge/tool-resolution.md)
|
|
118
118
|
- If branch not specified, detect default branch
|
|
119
119
|
- Store resolved: owner, repo, branch, file tree
|
|
120
120
|
|
|
@@ -75,6 +75,8 @@ Read `ccc_index` from forge-tier.yaml:
|
|
|
75
75
|
- If `ccc_index.status` is `"stale"`: display brief note — "CCC index is stale — discovery results may miss recent changes." Continue to section 3.
|
|
76
76
|
- If `ccc_index.status` is `"none"` or `"failed"`: attempt lazy indexing via `ccc_bridge.ensure_index(source_root)`. If indexing succeeds, continue to section 3. If indexing fails, set `{ccc_discovery: []}` and auto-proceed to section 5.
|
|
77
77
|
|
|
78
|
+
**Tool resolution for ccc_bridge.ensure_index:** Use `/ccc` skill indexing (Claude Code), ccc MCP server (Cursor), or `ccc init` + `ccc index {source_root}` (CLI). See [knowledge/tool-resolution.md](../../../knowledge/tool-resolution.md).
|
|
79
|
+
|
|
78
80
|
### 3. Construct Semantic Query
|
|
79
81
|
|
|
80
82
|
Build the discovery query from the brief data:
|
|
@@ -91,6 +93,8 @@ Where:
|
|
|
91
93
|
|
|
92
94
|
Run `ccc_bridge.search(query, source_root, top_k=20)`:
|
|
93
95
|
|
|
96
|
+
**Tool resolution for ccc_bridge.search:** Use `/ccc` skill search (Claude Code), ccc MCP server (Cursor), or `ccc search "{query}" --path {source_root} --top 20` (CLI). See [knowledge/tool-resolution.md](../../../knowledge/tool-resolution.md).
|
|
97
|
+
|
|
94
98
|
**If search succeeds:**
|
|
95
99
|
|
|
96
100
|
Store results as `{ccc_discovery: [{file, score, snippet}]}` in context.
|
|
@@ -92,6 +92,8 @@ Load `{sourceResolutionData}` completely. Follow the **Remote Source Resolution*
|
|
|
92
92
|
5. Infer types from JSDoc, docstrings, type annotations
|
|
93
93
|
6. Confidence: All results T1-low — `[SRC:{file}:L{line}]`
|
|
94
94
|
|
|
95
|
+
**Tool resolution for gh_bridge:** Use `gh api repos/{owner}/{repo}/git/trees/{branch}?recursive=1` for list_tree, `gh api repos/{owner}/{repo}/contents/{path}` for read_file. If source is local, use direct file listing/reading instead. See [knowledge/tool-resolution.md](../../../knowledge/tool-resolution.md).
|
|
96
|
+
|
|
95
97
|
**Forge/Forge+/Deep Tier (AST available):**
|
|
96
98
|
|
|
97
99
|
**CCC Discovery Integration (Forge+ and Deep with ccc only):**
|
|
@@ -115,6 +117,8 @@ If `{ccc_discovery}` is empty or not in context: proceed with existing file orde
|
|
|
115
117
|
5. Build extraction rules YAML data for reproducibility
|
|
116
118
|
6. Confidence: All results T1 — `[AST:{file}:L{line}]`
|
|
117
119
|
|
|
120
|
+
**Tool resolution for ast_bridge:** Use ast-grep MCP tools (`mcp__ast-grep__find_code`, `mcp__ast-grep__find_code_by_rule`) as specified in the AST Extraction Protocol above, or `ast-grep` CLI. For `detect_co_imports`, use `find_code_by_rule` with a co-import YAML rule scoped to the libraries list. See [knowledge/tool-resolution.md](../../../knowledge/tool-resolution.md).
|
|
121
|
+
|
|
118
122
|
**If AST tool is unavailable at Forge/Deep tier** (see `{tierDegradationRulesData}` for full rules):
|
|
119
123
|
|
|
120
124
|
⚠️ **Warn the user explicitly:** "AST tools are unavailable — extraction will use source reading (T1-low). Run [SF] Setup Forge to detect and configure AST tools for T1 confidence."
|
|
@@ -96,6 +96,8 @@ For each function, derive the **module context** from the extraction inventory's
|
|
|
96
96
|
|
|
97
97
|
4. **Semantic migration context:** `qmd_bridge.vector_search("{module_context} {function_name} migration deprecated")` — adds semantic matches (synonyms, paraphrases) that BM25 keyword search may miss. Merge results with search #3, deduplicating by document ID. If `vector_search` fails (VRAM, GPU driver, model loading), discard silently — the BM25 results from search #3 provide baseline coverage.
|
|
98
98
|
|
|
99
|
+
**Tool resolution for qmd_bridge:** Use QMD MCP tools — `mcp__plugin_qmd-plugin_qmd__search` for BM25 search, `mcp__plugin_qmd-plugin_qmd__vector_search` for semantic search (Claude Code). Cursor: qmd MCP server. CLI: `qmd search "{query}"` / `qmd vector_search "{query}"`. See [knowledge/tool-resolution.md](../../../knowledge/tool-resolution.md).
|
|
100
|
+
|
|
99
101
|
**For each QMD result:**
|
|
100
102
|
|
|
101
103
|
- Create a T2 annotation: `[QMD:{collection}:{doc}]`
|
|
@@ -20,6 +20,28 @@
|
|
|
20
20
|
3. Normalize names across ecosystems (e.g., `@scope/package` → `package`)
|
|
21
21
|
4. Deduplicate across multiple manifests
|
|
22
22
|
|
|
23
|
+
## Scan Exclusion Patterns
|
|
24
|
+
|
|
25
|
+
When scanning for manifest files, ALWAYS exclude these directories from glob results:
|
|
26
|
+
|
|
27
|
+
**Dependency/Vendor Directories:**
|
|
28
|
+
- `node_modules/`
|
|
29
|
+
- `.venv/` / `venv/` / `.env/`
|
|
30
|
+
- `vendor/` (PHP Composer, Go modules)
|
|
31
|
+
- `Pods/` (iOS CocoaPods)
|
|
32
|
+
|
|
33
|
+
**Build Output Directories:**
|
|
34
|
+
- `dist/` / `build/` / `out/`
|
|
35
|
+
- `target/` (Rust, Java/Maven)
|
|
36
|
+
- `__pycache__/`
|
|
37
|
+
- `.next/` / `.nuxt/` / `.output/`
|
|
38
|
+
|
|
39
|
+
**Hidden and VCS Directories:**
|
|
40
|
+
- `.git/`
|
|
41
|
+
- Any directory starting with `.` (except project root hidden config files like `.csproj`)
|
|
42
|
+
|
|
43
|
+
**Monorepo Note:** For monorepo structures (e.g., `packages/*/package.json`), the depth 0-1 scan rule already limits scope. If monorepo manifest detection is needed at deeper levels, these exclusions become critical to prevent scanning dependency trees within each package.
|
|
44
|
+
|
|
23
45
|
## Filtering Rules
|
|
24
46
|
|
|
25
47
|
- Exclude dev-only dependencies unless they appear in production imports
|
|
@@ -32,4 +54,4 @@
|
|
|
32
54
|
For each dependency, count distinct files that import it:
|
|
33
55
|
- Use grep patterns from Import Pattern column
|
|
34
56
|
- Count unique file paths, not total import statements
|
|
35
|
-
- Exclude test files, config files, and build artifacts from count
|
|
57
|
+
- Exclude test files (`*/test/*`, `*_test.*`, `*.spec.*`, `*.test.*`), config files (`*.config.*`, `.eslintrc`, etc.), and build artifacts (`dist/`, `build/`, `node_modules/`, `target/`, `__pycache__/`) from count
|
|
@@ -84,6 +84,8 @@ Extract:
|
|
|
84
84
|
- **Forge+:** ast_bridge + ccc_bridge (ccc semantic co-import augmentation) — ccc available for step-05
|
|
85
85
|
- **Deep:** qmd_bridge (QMD temporal enrichment) — required for Deep tier
|
|
86
86
|
|
|
87
|
+
See [knowledge/tool-resolution.md](../../../knowledge/tool-resolution.md) for how each bridge name resolves to concrete tools per IDE environment.
|
|
88
|
+
|
|
87
89
|
Report tool availability. If a tier-required tool is missing, downgrade tier and note:
|
|
88
90
|
|
|
89
91
|
"**Tier adjusted:** {original_tier} → {adjusted_tier} — {missing_tool} unavailable."
|
|
@@ -99,10 +99,11 @@ Store the explicit list as `raw_dependencies` and skip to [Display Detection Sum
|
|
|
99
99
|
|
|
100
100
|
Load `{manifestPatterns}` for supported ecosystem detection patterns.
|
|
101
101
|
|
|
102
|
-
Scan the project root (depth 0-1) for manifest files
|
|
102
|
+
Scan the project root (depth 0-1) for manifest files, **excluding directories listed in the Scan Exclusion Patterns section of `{manifestPatterns}`**:
|
|
103
103
|
|
|
104
104
|
- Search for each supported manifest filename
|
|
105
105
|
- Record: file path, ecosystem type, file size
|
|
106
|
+
- **Apply exclusion patterns** from `{manifestPatterns}` — skip `node_modules/`, `.venv/`, `vendor/`, `dist/`, `build/`, `target/`, `.git/`, and all hidden directories when globbing
|
|
106
107
|
- Note any unusual structures (monorepo with multiple manifests, workspace configurations)
|
|
107
108
|
|
|
108
109
|
**If no manifest files found:**
|
|
@@ -30,7 +30,7 @@ Count import frequency for each dependency across the codebase, rank by usage, a
|
|
|
30
30
|
- 🎯 Focus on counting imports, ranking, and getting user confirmation
|
|
31
31
|
- 🚫 FORBIDDEN to extract library documentation — that is step 04
|
|
32
32
|
- 💬 Present data clearly so user can make informed scope decisions
|
|
33
|
-
- 🎯 Use subprocess (Pattern 1 grep)
|
|
33
|
+
- 🎯 Use subprocess (Pattern 1 — grep/search): In Claude Code, use the Grep tool or Bash with `rg`. In Cursor, use built-in search. In CLI, use `grep`/`rg` directly. See [knowledge/tool-resolution.md](../../../knowledge/tool-resolution.md)
|
|
34
34
|
|
|
35
35
|
## EXECUTION PROTOCOLS:
|
|
36
36
|
|
|
@@ -80,6 +80,8 @@ For each dependency in `raw_dependencies`:
|
|
|
80
80
|
|
|
81
81
|
**Launch a subprocess** that runs grep across all source files in the project to count import statements for each library. Return only the counts, not file contents.
|
|
82
82
|
|
|
83
|
+
**Subprocess resolution:** Use the Grep tool (Claude Code), built-in search (Cursor), or `grep`/`rg` (CLI). See [knowledge/tool-resolution.md](../../../knowledge/tool-resolution.md).
|
|
84
|
+
|
|
83
85
|
Use ecosystem-appropriate import patterns:
|
|
84
86
|
- JavaScript/TypeScript: `import .* from ['"]library`, `require\(['"]library`
|
|
85
87
|
- Python: `import library`, `from library import`
|
|
@@ -27,7 +27,7 @@ For each confirmed dependency, extract key exports, usage patterns, and API surf
|
|
|
27
27
|
|
|
28
28
|
### Step-Specific Rules:
|
|
29
29
|
|
|
30
|
-
- 🎯 Extract per-library using Pattern 4 (parallel
|
|
30
|
+
- 🎯 Extract per-library using Pattern 4 (parallel): In Claude Code, use multiple parallel Agent tool calls or `run_in_background: true`. In Cursor, use parallel requests (IDE-dependent). In CLI, use `xargs -P` or background processes. See [knowledge/tool-resolution.md](../../../knowledge/tool-resolution.md)
|
|
31
31
|
- 💬 Each subprocess returns structured extraction, not raw file contents
|
|
32
32
|
- 🚫 FORBIDDEN to analyze cross-library integrations — that is step 05
|
|
33
33
|
- ⚙️ If parallel subprocess unavailable, extract libraries sequentially in main thread
|
|
@@ -105,14 +105,25 @@ For each library in `confirmed_dependencies`, determine extraction strategy base
|
|
|
105
105
|
- Confidence: T1 (AST-verified structural extraction)
|
|
106
106
|
|
|
107
107
|
**Deep Tier (adds to Forge):**
|
|
108
|
-
-
|
|
109
|
-
-
|
|
110
|
-
-
|
|
111
|
-
-
|
|
108
|
+
- Perform all Forge tier extractions (T1)
|
|
109
|
+
- Additionally: query existing QMD temporal collections for each library
|
|
110
|
+
- Read the `qmd_collections` registry from `{sidecar_path}/forge-tier.yaml`
|
|
111
|
+
- For each library in `confirmed_dependencies`, search for a registry entry where `skill_name` matches the library name AND `type` is `"temporal"`
|
|
112
|
+
- **If a matching temporal collection exists:**
|
|
113
|
+
- Query `qmd_bridge.search("{library_name} deprecated OR removed OR breaking change")` for deprecation context
|
|
114
|
+
- Query `qmd_bridge.search("{library_name} migration OR upgrade")` for migration patterns
|
|
115
|
+
- Query `qmd_bridge.search("{library_name} version issue OR bug OR workaround")` for version-specific warnings
|
|
116
|
+
- **Tool resolution for qmd_bridge:** Use QMD MCP tools — `mcp__plugin_qmd-plugin_qmd__search` (Claude Code), qmd MCP server (Cursor), `qmd search "{query}"` (CLI). See [knowledge/tool-resolution.md](../../../knowledge/tool-resolution.md)
|
|
117
|
+
- Classify each result as T2-past (historical) or T2-future (planned changes) per confidence-tiers.md
|
|
118
|
+
- Append temporal findings to the library's extraction as T2 annotations with `[QMD:{collection}:{doc}]` citations
|
|
119
|
+
- **If no matching temporal collection found:**
|
|
120
|
+
- Log: "No temporal collection for {library_name}. T2 enrichment skipped."
|
|
121
|
+
- Continue with T1/T1-low extraction only
|
|
122
|
+
- Confidence: T1 for structural (AST), T2 for temporal annotations (QMD-enriched)
|
|
112
123
|
|
|
113
124
|
### 2. Launch Parallel Extraction
|
|
114
125
|
|
|
115
|
-
**Launch subprocesses in parallel** (max_parallel_generation) — one per confirmed library:
|
|
126
|
+
**Launch subprocesses in parallel** (max_parallel_generation: 3–5 concurrent Agent tool calls in Claude Code, IDE-dependent in Cursor, CPU core count in CLI) — one per confirmed library:
|
|
116
127
|
|
|
117
128
|
Each subprocess:
|
|
118
129
|
1. Reads all files importing the library (from step 03 file lists)
|
|
@@ -129,7 +140,13 @@ Each subprocess:
|
|
|
129
140
|
usage_patterns: ["pattern description with file:line"],
|
|
130
141
|
confidence: "T1|T1-low|T2",
|
|
131
142
|
files_analyzed: count,
|
|
132
|
-
warnings: []
|
|
143
|
+
warnings: [],
|
|
144
|
+
temporal: {
|
|
145
|
+
deprecated_exports: ["export_name — reason [QMD:collection:doc]"],
|
|
146
|
+
migration_notes: ["note [QMD:collection:doc]"],
|
|
147
|
+
version_warnings: ["warning [QMD:collection:doc]"],
|
|
148
|
+
t2_annotation_count: count
|
|
149
|
+
}
|
|
133
150
|
}
|
|
134
151
|
```
|
|
135
152
|
|
|
@@ -161,6 +178,8 @@ For each library extraction:
|
|
|
161
178
|
|
|
162
179
|
**Results:** {success_count}/{total_count} libraries extracted
|
|
163
180
|
**Confidence distribution:** T1: {count}, T1-low: {count}, T2: {count}
|
|
181
|
+
{If Deep tier:} **T2 enrichment:** {enriched_count}/{total_count} libraries had temporal collections available
|
|
182
|
+
{If libraries without temporal > 0:} **Tip:** Run [CS] Create Skill at Deep tier for individual libraries to generate temporal collections, then re-run [SS] for full T2 enrichment.
|
|
164
183
|
{If warnings:} **Warnings:** {warning_count} issues noted
|
|
165
184
|
|
|
166
185
|
**Proceeding to integration detection...**"
|
|
@@ -29,7 +29,7 @@ Analyze co-import patterns between confirmed libraries to identify integration p
|
|
|
29
29
|
|
|
30
30
|
### Step-Specific Rules:
|
|
31
31
|
|
|
32
|
-
- 🎯 Focus on detecting cross-library patterns using Pattern 1 (grep)
|
|
32
|
+
- 🎯 Focus on detecting cross-library patterns using Pattern 1 (grep/search): In Claude Code, use the Grep tool or Bash with `rg`. In Cursor, use built-in search. In CLI, use `grep`/`rg` directly. See [knowledge/tool-resolution.md](../../../knowledge/tool-resolution.md)
|
|
33
33
|
- 🚫 FORBIDDEN to compile SKILL.md — that is step 06
|
|
34
34
|
- 💬 Integration detection is the core differentiator of stack skills vs individual skills
|
|
35
35
|
- ⚙️ If subprocess unavailable, perform grep operations in main thread
|
|
@@ -93,6 +93,8 @@ For each library pair (A, B):
|
|
|
93
93
|
|
|
94
94
|
**Launch a subprocess** that greps across all source files to find files importing BOTH library A and library B. Return only file paths and import line numbers.
|
|
95
95
|
|
|
96
|
+
**Subprocess resolution:** Use the Grep tool (Claude Code), built-in search (Cursor), or `grep`/`rg` (CLI). See [knowledge/tool-resolution.md](../../../knowledge/tool-resolution.md).
|
|
97
|
+
|
|
96
98
|
**Subprocess returns:** `{pair: [A, B], co_import_files: [{path, line_A, line_B}], count: N}`
|
|
97
99
|
|
|
98
100
|
**If subprocess unavailable:** Intersect the file lists from step 03 import counts for each pair.
|
|
@@ -105,6 +107,8 @@ If `tools.ccc` is true AND `ccc_index.status` is `"fresh"` or `"stale"` in forge
|
|
|
105
107
|
|
|
106
108
|
For each library pair that has exactly 1 co-import file (below the 2-file threshold), run `ccc_bridge.search("{libA} {libB}", source_root, top_k=10)` to find files where the two libraries interact semantically — even without explicit import co-location. If CCC returns additional files where both libraries appear, add them to the pair's co-import candidate list and re-evaluate against the 2-file threshold.
|
|
107
109
|
|
|
110
|
+
**Tool resolution for ccc_bridge.search:** Use `/ccc` skill search (Claude Code), ccc MCP server (Cursor), or `ccc search "{libA} {libB}" --path {source_root} --top 10` (CLI). See [knowledge/tool-resolution.md](../../../knowledge/tool-resolution.md).
|
|
111
|
+
|
|
108
112
|
For pairs that already qualify (2+ files), CCC is not needed for detection — but the CCC results may surface additional integration files for richer classification in section 3.
|
|
109
113
|
|
|
110
114
|
CCC failures: skip augmentation silently, proceed with grep-only results.
|
|
@@ -86,9 +86,9 @@ The `ccc index` command auto-starts the daemon when needed. Proceed with indexin
|
|
|
86
86
|
|
|
87
87
|
Attempt indexing anyway — errors will be caught below.
|
|
88
88
|
|
|
89
|
-
Run:
|
|
89
|
+
Run (CWD must be `{project-root}`):
|
|
90
90
|
```bash
|
|
91
|
-
ccc init
|
|
91
|
+
ccc init
|
|
92
92
|
```
|
|
93
93
|
|
|
94
94
|
**If init fails** (project may already be initialized): continue — this is not an error.
|
|
@@ -98,6 +98,8 @@ Then run:
|
|
|
98
98
|
ccc index
|
|
99
99
|
```
|
|
100
100
|
|
|
101
|
+
**Note:** `ccc index` can take several minutes on large codebases (1000+ files). Run with an extended timeout or in background mode. Use `ccc status` to verify completion — check that `Chunks` and `Files` counts are non-zero.
|
|
102
|
+
|
|
101
103
|
**If succeeds:**
|
|
102
104
|
- Run `ccc status` to get file count
|
|
103
105
|
- Store `{ccc_index_result: "created", ccc_indexed_path: {project-root}, ccc_last_indexed: {current ISO timestamp}, ccc_file_count: {count from status}}`
|
|
@@ -35,7 +35,7 @@ Compare current source code state against the provenance map to produce a comple
|
|
|
35
35
|
- 🎯 Focus ONLY on detecting and classifying changes — do not extract or merge
|
|
36
36
|
- 🚫 FORBIDDEN to modify any files — read-only change detection
|
|
37
37
|
- 🚫 FORBIDDEN to re-extract content — that is step 03
|
|
38
|
-
- 💬 Use subprocess
|
|
38
|
+
- 💬 Use subprocess Pattern 4 (parallel): In Claude Code, use multiple parallel Agent tool calls or `run_in_background: true`. In Cursor, use parallel requests (IDE-dependent). In CLI, use `xargs -P` or background processes. See [knowledge/tool-resolution.md](../../../knowledge/tool-resolution.md)
|
|
39
39
|
- ⚙️ If subprocess unavailable, perform comparison sequentially in main thread
|
|
40
40
|
|
|
41
41
|
## EXECUTION PROTOCOLS:
|
|
@@ -101,6 +101,8 @@ Perform tier-aware extraction on only the changed files identified in step 02, p
|
|
|
101
101
|
- QMD provides: usage patterns, historical context, related documentation
|
|
102
102
|
- Confidence: T1 for structural, T2 for semantic enrichment
|
|
103
103
|
|
|
104
|
+
**Tool resolution:** `ast_bridge` → ast-grep MCP tools (`find_code`, `find_code_by_rule`) or `ast-grep` CLI. `qmd_bridge` → QMD MCP tools (`mcp__plugin_qmd-plugin_qmd__search`, `vector_search`) or `qmd` CLI. See [knowledge/tool-resolution.md](../../../knowledge/tool-resolution.md).
|
|
105
|
+
|
|
104
106
|
### 2. Extract Changed Files
|
|
105
107
|
|
|
106
108
|
DO NOT BE LAZY — For EACH file in the change manifest with status MODIFIED, ADDED, or RENAMED, launch a subprocess that:
|
|
@@ -128,7 +130,7 @@ DO NOT BE LAZY — For EACH file in the change manifest with status MODIFIED, AD
|
|
|
128
130
|
|
|
129
131
|
Before aggregating extraction results, use CCC to assess semantic significance of changes:
|
|
130
132
|
|
|
131
|
-
1. Run `ccc_bridge.search("{skill_name}", source_root, top_k=15)` to get the skill's most semantically central files
|
|
133
|
+
1. Run `ccc_bridge.search("{skill_name}", source_root, top_k=15)` — **Tool resolution:** `/ccc` skill search (Claude Code), ccc MCP (Cursor), `ccc search` (CLI) — to get the skill's most semantically central files
|
|
132
134
|
2. Cross-reference the change manifest files with CCC results
|
|
133
135
|
3. Files appearing in BOTH the change manifest AND CCC's top results are **semantically significant changes** — flag them for priority in the merge step
|
|
134
136
|
4. Store `{ccc_significant_changes: [{file, score}]}` in context
|
|
@@ -33,7 +33,7 @@ Validate the merged skill content against the agentskills.io specification, veri
|
|
|
33
33
|
|
|
34
34
|
- 🎯 Focus ONLY on validation — do not fix issues (that's the user's choice)
|
|
35
35
|
- 🚫 FORBIDDEN to modify merged content — validation is read-only
|
|
36
|
-
- 💬 Launch parallel validation checks when subprocess available (Pattern 4)
|
|
36
|
+
- 💬 Launch parallel validation checks when subprocess available (Pattern 4): In Claude Code, use multiple parallel Agent tool calls. In Cursor, use parallel requests (IDE-dependent). In CLI, use `xargs -P`. See [knowledge/tool-resolution.md](../../../knowledge/tool-resolution.md)
|
|
37
37
|
- ⚙️ If subprocess unavailable, perform checks sequentially in main thread
|
|
38
38
|
|
|
39
39
|
## EXECUTION PROTOCOLS:
|