bmad-module-skill-forge 8.0.0 → 9.0.0

package/.claude-plugin/marketplace.json

@@ -30,7 +30,7 @@
       "name": "skill-forge",
       "source": "./",
       "description": "Evidence-based agent skills compiler with progressive capability tiers (Quick/Forge/Forge+/Deep).",
-      "version": "8.0.0",
+      "version": "9.0.0",
       "author": {
         "name": "Armel"
       },

package/docs/_data/pinned.yaml

@@ -32,7 +32,7 @@
 # Enforced two ways: (1) release.yaml bumps this line in the same commit
 # as package.json + marketplace.json on every release; (2) validate-docs-drift.js
 # cross-checks this value against package.json.version and fails on mismatch.
-skf_version: "8.0.0"
+skf_version: "9.0.0"
 
 # Path to the oh-my-skills repo, resolved relative to this repo's root.
 # Override at runtime with the OMS environment variable if oh-my-skills
@@ -51,8 +51,8 @@ skills:
     source_commit: "ba3631f2ed363a6ea50d649c34c56885af6b36fe"
     source_ref: "v1.6.2"
     upstream_commit_date: "2026-09-29"
-    # null: the strict SKF 7.0.0 re-test of the version that ships
-    # (20261106T224257Z-45558de5) is blocked by the hard gate, so it records no score.
+    # null: the strict SKF 8.0.0 re-test of the version that ships
+    # (20261107T112455Z-eec853d0) is blocked by the hard gate, so it records no score.
     test_score: null
     test_mode: "naive"
     confidence_tier: "Deep"
@@ -66,7 +66,7 @@ skills:
     source_commit: "5fe4f37a526e51516655832ec9814e7ca24ade9a"
     source_ref: "v1.0.0"
     upstream_commit_date: "2026-04-22"
-    # strict SKF 7.0.0 re-test of the version that ships (20261106T225304Z-494ddfa2)
+    # strict SKF 8.0.0 re-test of the version that ships (20261107T115927Z-5db1615d)
     test_score: 100.0
     test_mode: "naive"
     confidence_tier: "Deep"
@@ -80,8 +80,8 @@ skills:
     source_commit: "e486d3826bcd40c52db1c766966d1c8ec16df6cb"
     source_ref: "v10.3.5"
     upstream_commit_date: "2026-04-07"
-    # strict SKF 7.0.0 re-test of the version that ships (20261106T235200Z-cc17d5d0)
-    test_score: 98.23
+    # strict SKF 8.0.0 re-test of the version that ships (20261107T112449Z-0cc4693c)
+    test_score: 100.0
     test_mode: "naive"
     confidence_tier: "Deep"
     source_authority: "community"
@@ -94,7 +94,7 @@ skills:
     source_commit: "a5ffb45be05335d2c547436664cfbfb8c22d04df"
     source_ref: "HEAD"
     upstream_commit_date: "2026-03-22"
-    # strict SKF 7.0.0 re-test of the version that ships (20261106T225241Z-1907bdd0)
+    # strict SKF 8.0.0 re-test of the version that ships (20261107T112452Z-65994952)
     test_score: 100.0
     test_mode: "naive"
     confidence_tier: "Deep"

package/docs/verifying-a-skill.md

@@ -44,13 +44,13 @@ Provenance maps live in `forge-data/{skill}/{version}/provenance-map.json` in th
 
 This is the published entry for cognee's `search` in oh-my-skills' [`forge-data/oms-cognee/1.6.2/provenance-map.json`](https://github.com/armelhbobdad/oh-my-skills/blob/main/forge-data/oms-cognee/1.6.2/provenance-map.json), shortened to its first two parameters (`search` takes 27). It points at line 41, where `async def search(` is defined at cognee v1.6.2's commit (`ba3631f2`), and the skill's `SKILL.md` cites `[AST:cognee/api/v1/search/search.py:L41]`. Its labels follow the tool that read it: an ast-grep match gives `T1`, `ast-grep`, the node kind its rule matched and an `[AST:]` citation. An export read by eye instead, because ast-grep could not parse its file, an ast-grep call that failed or timed out left its file unread, or no rule matched it, gets `T1-low`, `source-read`, no node kind and an `[SRC:]` citation, at every forge tier.
 
-The 1.6.2 map passes the [line, label and citation checks](#workflow-time-enforcement) that SKF 3.0.0 added. Under SKF 4.0.0 a strict test passed the skill at 99%. SKF 7.0.0's Test Skill found real errors in it, all since fixed by hand against the pinned source, and still blocks it on two false positives: it compares the skill's forms of the lightweight `cognee.pipelines.run_pipeline` with the dataset orchestrator of the same name ([#918](https://github.com/armelhbobdad/bmad-module-skill-forge/issues/918)). So the skill has no score (see [the scores](#the-scores-including-the-ones-we-lose)). The older map next to it, [`forge-data/oms-cognee/1.0.0/provenance-map.json`](https://github.com/armelhbobdad/oh-my-skills/blob/main/forge-data/oms-cognee/1.0.0/provenance-map.json), was compiled before labels followed the tool and still shows what those checks catch. It records `search` as `source-read` but labels it `T1`, and it points at line 26, the blank line above the definition, while that version's `SKILL.md` cites `[AST:cognee/api/v1/search/search.py:L27]`. A source read is `T1-low` with an `[SRC:]` citation, and its line is 27, the `def` line at v1.0.0.
+The 1.6.2 map passes the [line, label and citation checks](#workflow-time-enforcement) that SKF 3.0.0 added. Under SKF 4.0.0 a strict test passed the skill at 99%. SKF 7.0.0's Test Skill found real errors in it, all since fixed by hand against the pinned source, and SKF 8.0.0 still blocks it on two false positives: it compares the skill's forms of the lightweight `cognee.pipelines.run_pipeline` with the dataset orchestrator of the same name ([#918](https://github.com/armelhbobdad/bmad-module-skill-forge/issues/918)). So the skill has no score (see [the scores](#the-scores-including-the-ones-we-lose)). The older map next to it, [`forge-data/oms-cognee/1.0.0/provenance-map.json`](https://github.com/armelhbobdad/oh-my-skills/blob/main/forge-data/oms-cognee/1.0.0/provenance-map.json), was compiled before labels followed the tool and still shows what those checks catch. It records `search` as `source-read` but labels it `T1`, and it points at line 26, the blank line above the definition, while that version's `SKILL.md` cites `[AST:cognee/api/v1/search/search.py:L27]`. A source read is `T1-low` with an `[SRC:]` citation, and its line is 27, the `def` line at v1.0.0.
 
 ### 3. Visit the upstream repo at the pinned commit
 
 Open `{source_repo}` at `{source_commit}`, jump to `{source_file}` line `{source_line}`. The signature in `SKILL.md` should match what you see in the source.
 
-If it doesn't, **that's a bug**. For a skill you built, Test Skill (`@Ferris TS`) rates a signature mismatch as a Critical gap, which stops the test at its [hard gate](#hard-gate). It compares only what a signature writes: a component by its props alone, so `FC<P>` and `(props: P) => JSX.Element` are one signature, and a type or a return type the skill does not write, or type arguments it leaves out (`dict` against `dict[str, Any]`), are not compared. When the skill documents a name in several places, such as a brief usage in `SKILL.md` and a full props list in a reference file, each form that lists parameters or gives a usage is compared, and a `const` holding a component, such as a `forwardRef(...)` result, is compared by the usage or declaration the skill writes for it. Two differences a caller never meets are rated lower and still count as matching: a renamed parameter in a TypeScript, JavaScript, Go, Rust, Java, C or C++ file, whose callers pass arguments by position, is a Low gap, and an optional parameter left out of a signature the skill labels partial (such as `Props (simplified)`) is an Info observation. A renamed Python parameter stays Critical, because Test Skill cannot see which parameters a caller must pass by position, and so does a renamed Vue component prop, which callers set by name. Update Skill (`@Ferris US`) with `--from-test-report` repairs the gaps a test report lists. If you think SKF extracted it wrong, [open an issue](https://github.com/armelhbobdad/bmad-module-skill-forge/issues/new/choose). Falsifiability isn't a feature. It's the whole deal.
+If it doesn't, **that's a bug**. For a skill you built, Test Skill (`@Ferris TS`) rates a signature mismatch as a Critical gap, which stops the test at its [hard gate](#hard-gate). It compares only what a signature writes: a component by its props alone, so `FC<P>` and `(props: P) => JSX.Element` are one signature, and a type or a return type the skill does not write, or type arguments it leaves out (`dict` against `dict[str, Any]`), are not compared. When the skill documents a name in several places, such as a brief usage in `SKILL.md` and a full props list in a reference file, each form that lists parameters, gives a usage or states a return type is compared, and a `const` holding a component, such as a `forwardRef(...)` result, is compared by the usage or declaration the skill writes for it. When the source declares two functions of one name, a form is compared only with the one its own `[AST:]` or `[SRC:]` citation names, at a line or in a range that holds its line or a later one before the next declaration the extraction records in that file. Test Skill reads that citation on the form's line, or on the next non-blank line unless that line writes the name itself, and, for a form in a code block, in a comment just above it in the block or, when the block documents no other form of the name, in a comment on the block's first non-blank line or on the first non-blank line after the block, unless that line writes the name. A line that writes two forms of the name that differ, such as a table row that quotes the other function's form as a contrast, gives none of those forms a citation. A form whose citations name neither function, or both, is compared as before, with the declarations the package exports. Two differences a caller never meets are rated lower and still count as matching: a renamed parameter in a TypeScript, JavaScript, Go, Rust, Java, C or C++ file, whose callers pass arguments by position, is a Low gap, and an optional parameter left out of a signature the skill labels partial (such as `Props (simplified)`) is an Info observation. A renamed Python parameter stays Critical, because Test Skill cannot see which parameters a caller must pass by position, and so does a renamed Vue component prop, which callers set by name. Update Skill (`@Ferris US`) with `--from-test-report` repairs the gaps a test report lists. If you think SKF extracted it wrong, [open an issue](https://github.com/armelhbobdad/bmad-module-skill-forge/issues/new/choose). Falsifiability isn't a feature. It's the whole deal.
 
 ### Workflow-time enforcement
 
@@ -95,14 +95,14 @@ SKF 5.0.0 to 7.0.0 put every signature rule in one file that every judge reads,
 
 Every fix was made by hand against the pinned source. Each round's fixes were reviewed before its test, except the last one-row storybook correction.
 
-Today, on a strict SKF 7.0.0 test of the version each one ships, three skills pass and one is blocked. The oms-storybook-react-vite and oms-uitripled passes turn on calls the rules leave open: the storybook report writes its calls down, while the uitripled run passed three button components as matches without recording how it read them ([#932](https://github.com/armelhbobdad/bmad-module-skill-forge/issues/932)). The judges also still read some cases differently from run to run: three oms-uitripled lines were matches in one run and Critical gaps in the next, with no change to the lines. Every report, the failing ones included, is kept: in the skill's `forge-data/` folder, or, for the reverted oms-storybook-react-vite repair, in oh-my-skills' git history. Even a passing report names the drift it found:
+Today, on a strict SKF 8.0.0 test of the version each one ships, three skills pass, all at 100%, and one is blocked. On unchanged text, 8.0.0 raised oms-storybook-react-vite from 98.23% to 100%, because a star re-export from another package now adds no name ([#926](https://github.com/armelhbobdad/bmad-module-skill-forge/issues/926)), and a written rule ([#932](https://github.com/armelhbobdad/bmad-module-skill-forge/issues/932)) now settles the three oms-uitripled forms its 7.0.0 pass rested on without recording them; uitripled stays at 100%. The first 8.0.0 run of oms-cocoindex counted `ExceptionContext`, named only inside another export's type, as undocumented (99.37%), a reader's call the inventory contract does not settle ([#967](https://github.com/armelhbobdad/bmad-module-skill-forge/issues/967)); oh-my-skills then documented it. Every pass still rests on calls the reader or the judge makes where the rules leave the case open, and each report now writes them down, with how it counted them: storybook's turns on how the split-body check reads two different exports that share a name, uitripled's on an em-dash placeholder in a Default cell read as empty, and cocoindex's on a call to a decorator instance compared with its `__call__`. The judges also still read some cases differently from run to run: three oms-uitripled lines were matches in one 7.0.0 run and Critical gaps in the next, with no change to the lines. Every report, the failing ones included, is kept: in the skill's `forge-data/` folder, or, for the reverted oms-storybook-react-vite repair, in oh-my-skills' git history. Even a passing report names the drift it found:
 
 | Skill | Score | What the report discloses |
 |---|---|---|
-| [oms-cocoindex](https://github.com/armelhbobdad/oh-my-skills/blob/main/forge-data/oms-cocoindex/1.0.0/test-report-oms-cocoindex-20261106T225304Z-494ddfa2.md) | **100%** | 72/72 exports of the root barrel (7.0.0 applies the brief's `scope.exclude` before it decides the source is one Python package, not a Cargo workspace), 46/46 signatures. Type Coverage is 1/1: the root exports Test Skill restores when the brief's doc globs match no file carry no kind, so the category counts a single type ([#913](https://github.com/armelhbobdad/bmad-module-skill-forge/issues/913)). Left open: 11 Medium stale-documentation gaps on connector exports that the reconcile counts outside the surface ([#912](https://github.com/armelhbobdad/bmad-module-skill-forge/issues/912)), a brief glob that matches no file and a barrel count. |
-| [oms-cognee](https://github.com/armelhbobdad/oh-my-skills/blob/main/forge-data/oms-cognee/1.6.2/test-report-oms-cognee-20261106T224257Z-45558de5.md) | **blocked** | 2 Critical false positives: the test compares the skill's two forms of the lightweight `cognee.pipelines.run_pipeline` with the orchestrator of the same name, the only `run_pipeline` its surface holds ([#918](https://github.com/armelhbobdad/bmad-module-skill-forge/issues/918)). Every other check passes: 92/92 exports of the `cognee/__init__.py` barrel at pinned commit `ba3631f2` (v1.6.2), 70 of 71 signature names and 35/35 types. External Validation is 90%: skill-check finds the `SKILL.md` body over its 5,000-token budget. |
-| [oms-storybook-react-vite](https://github.com/armelhbobdad/oh-my-skills/blob/main/forge-data/oms-storybook-react-vite/10.3.5/test-report-oms-storybook-react-vite-20261106T235200Z-cc17d5d0.md) | **98.23%** | Counted on the brief's `scope.tier_a_include` set. Export Coverage reads 100% against the stored count of 370; this run read 389 names into the set, 376 of them documented. Type Coverage is 134/147: 13 `@vitest/spy` types that `storybook/test` re-exports with `export type *` are undocumented, and the run before it read that line as six names and scored 100% ([#926](https://github.com/armelhbobdad/bmad-module-skill-forge/issues/926)). 177/177 signatures. The pass also turns on how the split-body check reads two different exports that share a name ([#927](https://github.com/armelhbobdad/bmad-module-skill-forge/issues/927)). |
-| [oms-uitripled](https://github.com/armelhbobdad/oh-my-skills/blob/main/forge-data/oms-uitripled/0.1.0/test-report-oms-uitripled-20261106T225241Z-1907bdd0.md) | **100%** | 327/327 exports against the stored count for the brief's `scope.include` union, 269/269 signatures and 42/42 types. The pass also turns on three forms the report passes without comment: three button components documented with their source declarations, `...props` rest element included, which the run judged as matches. Read strictly, each would be a Critical gap ([#932](https://github.com/armelhbobdad/bmad-module-skill-forge/issues/932)). |
+| [oms-cocoindex](https://github.com/armelhbobdad/oh-my-skills/blob/main/forge-data/oms-cocoindex/1.0.0/test-report-oms-cocoindex-20261107T115927Z-5db1615d.md) | **100%** | 72/72 exports of the root barrel (since 7.0.0 the brief's `scope.exclude` applies before the source is read as one Python package, not a Cargo workspace), 48/48 signatures. Type Coverage is 1/1: the root exports Test Skill restores when the brief's doc globs match no file carry no kind, so the category counts a single type ([#913](https://github.com/armelhbobdad/bmad-module-skill-forge/issues/913)). The report records how it read `@coco.fn(...)`, a call to a decorator instance, compared with the instance's `__call__`. The first 8.0.0 run counted `ExceptionContext`, named only inside another export's type, as undocumented (99.37%; [#967](https://github.com/armelhbobdad/bmad-module-skill-forge/issues/967)); oh-my-skills documented it. Left open: 11 Medium stale-documentation gaps on connector exports that the reconcile counts outside the surface ([#912](https://github.com/armelhbobdad/bmad-module-skill-forge/issues/912)), a brief glob that matches no file and a barrel count. |
+| [oms-cognee](https://github.com/armelhbobdad/oh-my-skills/blob/main/forge-data/oms-cognee/1.6.2/test-report-oms-cognee-20261107T112455Z-eec853d0.md) | **blocked** | 2 Critical false positives: the test compares the skill's two forms of the lightweight `cognee.pipelines.run_pipeline` with the orchestrator of the same name, the only `run_pipeline` its surface holds ([#918](https://github.com/armelhbobdad/bmad-module-skill-forge/issues/918); the fix, [#956](https://github.com/armelhbobdad/bmad-module-skill-forge/pull/956), is not in 8.0.0). Every other check passes: 92/92 exports of the `cognee/__init__.py` barrel at pinned commit `ba3631f2` (v1.6.2), 74 of 75 signature names and 35/35 types. External Validation is 90%: skill-check finds the `SKILL.md` body over its 5,000-token budget. |
+| [oms-storybook-react-vite](https://github.com/armelhbobdad/oh-my-skills/blob/main/forge-data/oms-storybook-react-vite/10.3.5/test-report-oms-storybook-react-vite-20261107T112449Z-0cc4693c.md) | **100%** | Counted on the brief's `scope.tier_a_include` set: 370/370 exports, 180/180 signatures (66 of them Testing Library bindings whose parameters are typed in another package, counted as matching without comparison under 8.0.0's rule, [#925](https://github.com/armelhbobdad/bmad-module-skill-forge/issues/925)), 128/128 types. Under 7.0.0 the run read `export type * from '@vitest/spy'` as 19 names, 13 of them undocumented (98.23%); 8.0.0 counts none ([#926](https://github.com/armelhbobdad/bmad-module-skill-forge/issues/926)). The pass turns on how the split-body check reads two different exports that share a name, core's and React's `composeStories`: read as one export, they would be a High gap ([#927](https://github.com/armelhbobdad/bmad-module-skill-forge/issues/927)). |
+| [oms-uitripled](https://github.com/armelhbobdad/oh-my-skills/blob/main/forge-data/oms-uitripled/0.1.0/test-report-oms-uitripled-20261107T112452Z-65994952.md) | **100%** | 327/327 exports against the stored count for the brief's `scope.include` union, 269/269 signatures and 42/42 types. The report records the call the pass rests on, an em-dash placeholder in two props tables' Default column read as an empty cell as Create Skill's own format writes it (read as a value, two Critical gaps), and one the 100% rests on: seven primitives named only on import lines, counted as documented (without them, Export Coverage would be 97.86%). |
 
 Perfection is suspicious. Visible fallibility is trustworthy. SKF writes down the edges it can't score cleanly, so you can read them and decide for yourself whether the remaining coverage is enough for your use case.
 
@@ -118,7 +118,7 @@ Removing the stored count made the next run name every undocumented export. It m
 
 A strict SKF 4.0.0 test of the version that shipped then ([report](https://github.com/armelhbobdad/oh-my-skills/blob/main/forge-data/oms-storybook-react-vite/10.3.5/test-report-oms-storybook-react-vite-20261103T131516Z-6e2b972a.md)) covered all of those fixes. It was blocked on 4 Critical gaps: two compared the React portable-stories wrappers with core's functions, and two were older real errors no earlier run had flagged. So oh-my-skills published no score instead of quoting the earlier number.
 
-SKF 7.0.0 measures the skill against the names its brief lists. Its first test found 63.78% of them documented. The next rounds documented the 134 missing names and fixed the errors the tests and reviews found, by hand against the pinned source. A strict test of the version that ships now passes at 98.23% ([report](https://github.com/armelhbobdad/oh-my-skills/blob/main/forge-data/oms-storybook-react-vite/10.3.5/test-report-oms-storybook-react-vite-20261106T235200Z-cc17d5d0.md)). Nothing was hidden: every report on the way is kept.
+SKF 7.0.0 measures the skill against the names its brief lists. Its first test found 63.78% of them documented. The next rounds documented the 134 missing names and fixed the errors the tests and reviews found, by hand against the pinned source. A strict SKF 7.0.0 test of the version that ships passed at 98.23%, and the same text passes a strict SKF 8.0.0 test at 100% ([report](https://github.com/armelhbobdad/oh-my-skills/blob/main/forge-data/oms-storybook-react-vite/10.3.5/test-report-oms-storybook-react-vite-20261107T112449Z-0cc4693c.md)). Nothing was hidden: every report on the way is kept.
 
 That's the pattern SKF asks you to trust: when scoring can't reach 100%, the report says so, cites the line, and leaves a fingerprint for the next audit.
 
@@ -135,7 +135,7 @@ The score is a weighted sum of up to five categories. The weights below are the
 | Category | Weight | What it measures |
 |---|---|---|
 | **Export Coverage** | 36% | Percentage of source exports documented in `SKILL.md` |
-| **Signature Accuracy** | 22% | Documented function signatures match actual source signatures (parameter names, types, order, return types). A renamed parameter in a TypeScript, JavaScript, Go, Rust, Java, C or C++ file, whose callers pass every argument by position, still matches, and so does a signature the skill labels partial that leaves out only optional parameters. A component is compared by its props alone, a type or return type a signature does not write is not compared, and each form a name is documented in is compared on its own |
+| **Signature Accuracy** | 22% | Documented function signatures match actual source signatures (parameter names, types, order, return types). A renamed parameter in a TypeScript, JavaScript, Go, Rust, Java, C or C++ file, whose callers pass every argument by position, still matches, and so does a signature the skill labels partial that leaves out only optional parameters. A component is compared by its props alone, a type or return type a signature does not write is not compared, and each form a name is documented in is compared on its own, with the declaration its own citation names when the source has two of that name |
 | **Type Coverage** | 14% | Types and interfaces referenced in exports are fully documented |
 | **Coherence** | 18% | Cross-references resolve, integration patterns are complete (contextual mode only) |
 | **External Validation** | 10% | skill-check quality score (0–100), averaged with the Tessl Review score (0–100) when you opt in to Tessl Review |

package/docs/workflows.md

@@ -597,7 +597,7 @@ To run these without questions, pass their inputs as flags. Analyze Source takes
 
 Every workflow ships a `customize.toml` with settings you can change. Do not edit that file: updates overwrite it. Put your changes in `_bmad/custom/<skill-name>.toml` (shared with your team) or `_bmad/custom/<skill-name>.user.toml` (just for you), for example `_bmad/custom/skf-test-skill.toml`. Start the file with a `[workflow]` line, as the bundled file does: a setting above it is ignored without a warning. A single value replaces the default; a list adds to it.
 
-These overrides are read by BMAD Method's customization script, which the BMAD Method installer adds. Every workflow, and Ferris, runs that script through `uv` when it starts. When the script cannot run, the run prints one warning, `[activation/warn] customization_resolver_unavailable: <reason>`, and uses the bundled defaults, ignoring `_bmad/custom/`. A workflow also adds a warning naming `customization_resolver_unavailable` and its reason to the run's warnings, in the result envelope and result file of a run that writes them (Campaign logs it in its decision log, a `--quiet` or headless Setup Forge run shows it only in its envelope, and an interactive Export Skill run only prints it). In a project with SKF alone, that script is missing, so every run warns `customization_resolver_unavailable: not found` and uses the bundled defaults. On a BMAD core older than 6.11.0, whose script reads the overrides of the nearest folder holding `_bmad` or `.git`, from the workflow's own folder up, SKF still applies them when that folder is this project, and otherwise warns `customization_resolver_unavailable: BMAD core before 6.11.0: ...`, naming the folder that script would read and the upgrade to 6.11.0 or later.
+These overrides are read by BMAD Method's customization script, which the BMAD Method installer adds. Every workflow, and Ferris, runs that script through `uv` when it starts. When the script cannot run, the run prints one warning, `[activation/warn] customization_resolver_unavailable: <reason>`, and uses the bundled defaults, ignoring `_bmad/custom/`. A workflow also adds a warning naming `customization_resolver_unavailable` and its reason to the run's warnings, in the result envelope and result file of a run that writes them (Campaign logs it in its decision log, a `--quiet` or headless Setup Forge run shows it only in its envelope, and an interactive Export Skill run only prints it). In a project with SKF alone, that script is missing, so every run warns `customization_resolver_unavailable: not found` and uses the bundled defaults. When SKF's own helper is missing, as in an incomplete SKF install, the run warns `customization_resolver_unavailable: SKF helper skf-resolve-customization.py not found` instead: reinstall SKF. On a BMAD core older than 6.11.0, whose script reads the overrides of the nearest folder holding `_bmad` or `.git`, from the workflow's own folder up, SKF still applies them when that folder is this project, and otherwise warns `customization_resolver_unavailable: BMAD core before 6.11.0: ...`, naming the folder that script would read and the upgrade to 6.11.0 or later.
 
 Ferris reads `_bmad/custom/skf-forger.toml` and `_bmad/custom/skf-forger.user.toml` the same way when he starts, under an `[agent]` line, as his bundled file does (a `[workflow]` table there is ignored). An override there can add `activation_steps_prepend`, which runs once his config is loaded, `persistent_facts` (a `!` entry drops each earlier entry it names) and `activation_steps_append`, which runs after his greeting. His name, title and the other agent roster values stay as shipped, and he has no `on_complete`. When the script cannot run, the warning line opens his greeting.
 

package/package.json

@@ -1,7 +1,7 @@
 {
   "$schema": "https://json.schemastore.org/package.json",
   "name": "bmad-module-skill-forge",
-  "version": "8.0.0",
+  "version": "9.0.0",
   "description": "BMAD module — Turn code and docs into instructions AI agents can actually follow. Progressive capability tiers (Quick/Forge/Forge+/Deep).",
   "keywords": [
     "bmad",

package/src/shared/scripts/skf-extract-public-api.py

@@ -457,8 +457,9 @@ them). A namespace with `members` is diffed as its members: each is found
 when a recipe found its name, or its `local` one, in its file (one with
 no file by its name alone, as a public name is), and has no row of its
 own when a public name (or another namespace's member) has its name and
-file; one with null `members`, and a member that is such a module, is no
-gap. In a family with no entry point, or only empty ones, every name the
+file; a member's own outside_scope row names its namespace (`namespace`);
+one with null `members`, and a member that is such a module, is no gap.
+In a family with no entry point, or only empty ones, every name the
 recipes found is public. A JS/TS module exports, besides the names the
 recipes match, those its column-0 `export` statements declare in a form
 no recipe matches, read from its text: `export let`, `export declare
@@ -582,7 +583,8 @@ Output JSON (stdout, or -o):
                                "local", "file", "line"}, ...],  # by name, then file
         "internal": [{"name", "language", "source_file", "source_line"}, ...],
         "extraction_gaps": [{"name", "language", "entry", "file", "line"}, ...],
-        "outside_scope": [{"name", "language", "entry", "file", "line"}, ...]},
+        "outside_scope": [{"name", "language", "entry", "file", "line",
+                           "namespace"}, ...]},  # namespace: a member's row only
     "reexport_targets": [{"name", "language", "local", "from", "entry",
                           "file", "line", "via"}, ...],
     "counts": {"exports_public_api": N,  # (family, name, file) keys
@@ -4439,9 +4441,11 @@ def entry_point_diff(exports: list[dict], surfaces: dict[str, _Surface], entries
     `members` has each member diffed in its place, found when a recipe
     found its name, or its `local` one, in its file, and given no row of
     its own when a declared name has its name and file (or another
-    namespace gave it one); one whose members are unknown (None), or a
-    member that is such a module (`opaque`), is no gap. In a family with
-    no entry point, or only empty ones, every export is public."""
+    namespace gave it one), else a row that names the namespace
+    (`namespace`, which only an outside_scope row writes out); one whose
+    members are unknown (None), or a member that is such a module
+    (`opaque`), is no gap. In a family with no entry point, or only empty
+    ones, every export is public."""
     statuses: dict[str, str] = {}
     public: dict[tuple[str, str], dict] = {}
     internal: list[dict] = []
@@ -4495,7 +4499,7 @@ def entry_point_diff(exports: list[dict], surfaces: dict[str, _Surface], entries
                     continue
                 given.add(key)
                 row = {"name": member["name"], "entry": info["entry"], "file": member["file"],
-                       "line": member["line"]}
+                       "line": member["line"], "namespace": info["name"]}
                 (gaps if member["file"] is None or member["file"] in in_scope else outside).append((family, row))
     return statuses, public, internal, gaps, outside, others
 
@@ -4946,8 +4950,11 @@ def run_full(args: argparse.Namespace) -> tuple[dict, int]:
             "extraction_gaps": [{"name": info["name"], "language": family, "entry": info["entry"],
                                  "file": info["file"], "line": info["line"]}
                                 for family, info in sorted(gaps, key=lambda g: (g[1]["name"], g[0]))],
+            # a namespace's member names its namespace (#969); a declared name's row keeps five keys
             "outside_scope": [{"name": info["name"], "language": family, "entry": info["entry"],
-                               "file": info["file"], "line": info["line"]}
+                               "file": info["file"], "line": info["line"],
+                               **({"namespace": info["namespace"]} if isinstance(info.get("namespace"), str)
+                                  and info["namespace"] else {})}
                               for family, info in sorted(outside, key=lambda g: (g[1]["name"], g[0]))],
         },
         "reexport_targets": [