feat(skills): add type:skill manifest for verbatim directory copying#1851
Merged
alexeyv merged 6 commits intobmad-code-org:mainfrom Mar 8, 2026
Merged
feat(skills): add type:skill manifest for verbatim directory copying#1851alexeyv merged 6 commits intobmad-code-org:mainfrom
alexeyv merged 6 commits intobmad-code-org:mainfrom
Conversation
alexeyv
commented
Mar 8, 2026
src/bmm/workflows/bmad-quick-flow/bmad-quick-dev-new-preview/workflow.md
Outdated
Show resolved
Hide resolved
Collaborator
Author
Smoke Test ResultsAll manual test plan items verified. Tested by installing from the PR branch into a clean A) Skill installs correctly
B) Right shape
C) Reinstall wipes and replaces
D) Relative path resolution (one-shot mode)Path chain: step-01 → step-03 → step-04 → step-05
E) Relative path resolution (plan-code-review mode)Path chain: step-01 → step-02 → step-03 → step-04 → step-05
|
Contributor
|
@coderabbitai review |
🤖 Augment PR SummarySummary: Adds support for “verbatim” skill installs driven by a new Changes:
Technical Notes: Reuses shared skill-manifest helpers ( 🤖 Was this summary useful? React with 👍 or 👎 |
![augmentcode[bot]](https://avatars.githubusercontent.com/in/1027498?s=60&v=4){kind=small}
📝 WalkthroughWalkthroughThis PR introduces skill manifest infrastructure to the installer system, including CSV-based skill artifact installation, path normalization in a newly named workflow, and type detection utilities. It creates a bmad-quick-dev-new-preview workflow with relative path resolution, adds skill manifest support to the manifest generator and IDE installer, and includes design-contract tests for the install_to_bmad flag. Changes
Sequence DiagramsequenceDiagram
participant ManGen as ManifestGenerator
participant Scanning as Workflow Scanning
participant Util as skill-manifest Utils
participant CSVOut as skill-manifest.csv
participant IDE as ConfigDrivenIdeSetup
participant Parser as CSV Parser
participant Install as installVerbatimSkills
ManGen->>Scanning: Scan workflows
Scanning->>Util: getArtifactType(manifest)
Util-->>Scanning: "skill" | "workflow"
alt artifact is skill
Scanning->>ManGen: Add to this.skills[]
else artifact is workflow
Scanning->>ManGen: Add to workflows list
end
ManGen->>CSVOut: writeSkillManifest(skills[])
CSVOut-->>IDE: skill-manifest.csv
IDE->>Parser: Parse CSV
Parser-->>IDE: skill records
IDE->>Install: installVerbatimSkills(records)
Install->>Install: Per record: validate, copy files
Install->>Util: getInstallToBmad(manifest)
Util-->>Install: true | false
alt install_to_bmad === false
Install->>Install: cleanup source directory
end
Install-->>IDE: skills count
Estimated code review effort🎯 4 (Complex) | ⏱️ ~60 minutes Possibly related PRs
Suggested reviewers
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 7
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
src/bmm/workflows/bmad-quick-flow/bmad-quick-dev-new-preview/workflow.md (1)
2-3:⚠️ Potential issue | 🟡 MinorFrontmatter
namelacksbmad-prefix but directory uses it.The
name: quick-dev-new-previewdoesn't include thebmad-prefix, but the directory is namedbmad-quick-dev-new-previewand the agent trigger expectsbmad-quick-dev-new-preview. This inconsistency could cause confusion when correlating skill names in manifests, skill CSVs, and user-facing documentation.Consider aligning the
namewith the directory/canonicalId for consistency:-name: quick-dev-new-preview +name: bmad-quick-dev-new-preview🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/bmm/workflows/bmad-quick-flow/bmad-quick-dev-new-preview/workflow.md` around lines 2 - 3, Update the frontmatter `name` value from "quick-dev-new-preview" to "bmad-quick-dev-new-preview" so it matches the directory/canonical id and the agent trigger expectations; locate the `name` key in the workflow frontmatter and replace its value, and then scan related manifests/skill CSVs for any remaining references to the old name to keep all identifiers consistent (e.g., canonicalId, skill CSV entries, agent trigger config).
🧹 Nitpick comments (8)
tools/cli/installers/lib/core/manifest-generator.js (1)
121-124: Expose the new skill count ingenerateManifests()results.You're generating
skill-manifest.csvhere, but callers still get noskillscount back. That makes the new artifact type invisible to summary, logging, and assertion code.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@tools/cli/installers/lib/core/manifest-generator.js` around lines 121 - 124, The generateManifests() flow builds manifestFiles but doesn't return the new skill count; update generateManifests() to include a skills count in its result by having writeSkillManifest(cfgDir) return the number of skills (or an object containing count) and then add that value to the returned summary (e.g., result.skills = skillCount). Ensure writeSkillManifest and any callers (manifestFiles assembly) propagate that returned count so summary/logging/assertion code can observe the new skill artifact count.test/test-install-to-bmad.js (1)
84-128: Add one installer-level test for the behavior this PR actually introduced.These checks cover the helper layer only. They still never touch
_config-driven.js, so regressions in CSV parsing, verbatim copying, generatedSKILL.md, stale-file cleanup, orinstall_to_bmad=falsepruning will pass this suite.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@test/test-install-to-bmad.js` around lines 84 - 128, The current tests only exercise helper functions (loadSkillManifest, getInstallToBmad) and never run the installer logic in _config-driven.js; add a new installer-level test in test/test-install-to-bmad.js that executes the actual install pipeline (e.g., invoke the entrypoint that runs installVerbatimSkills / the _config-driven.js flow) against a temporary skill dir and CSV to assert CSV parsing, verbatim copying, generated SKILL.md behavior, pruning of install_to_bmad: false entries, and stale-file cleanup; ensure the test creates a realistic CSV/manifest, runs the installer code path introduced by this PR, and asserts on filesystem side effects (presence/absence of copied files and SKILL.md) rather than only calling getInstallToBmad/loadSkillManifest.tools/cli/installers/lib/ide/shared/skill-manifest.js (1)
48-90: Collapse manifest-entry resolution into one helper.
getCanonicalId(),getArtifactType(), andgetInstallToBmad()now each carry their own single-entry/direct-key/fallback-key lookup chain. That duplication is already enough to drift the moment one path adds another extension or fallback rule. Resolve the manifest entry once, then read fields from it.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@tools/cli/installers/lib/ide/shared/skill-manifest.js` around lines 48 - 90, Create a single helper (e.g., resolveManifestEntry(manifest, filename)) that encapsulates the lookup chain (return manifest.__single for single-entry, then manifest[filename], then the fallback keys derived from baseName such as `${baseName}.agent.yaml` and `${baseName}.xml`) and returns the resolved entry or null; then change getCanonicalId, getArtifactType, and getInstallToBmad to call that helper once and read the needed fields (id/type/install_to_bmad with existing defaults) from the returned entry instead of duplicating the lookup logic in each function.src/bmm/workflows/bmad-quick-flow/bmad-quick-dev-new-preview/workflow.md (4)
46-51: Step-file architecture documentation doesn't specify path resolution semantics.The Workflow Architecture section (lines 42-66) extensively documents step processing rules but says nothing about how relative paths in step files should be resolved. Given the shift from
{installed_path}to./, this is now a critical runtime behavior that should be documented.Add a clarifying rule under "Step Processing Rules":
5. **RESOLVE PATHS**: Relative paths (`./`) resolve from the skill root directory, not the step file location🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/bmm/workflows/bmad-quick-flow/bmad-quick-dev-new-preview/workflow.md` around lines 46 - 51, Add a new rule to the "Step Processing Rules" section in workflow.md clarifying path resolution: under the existing list (after "Append-Only Building" or within the "Workflow Architecture" block) insert a numbered item titled "RESOLVE PATHS" that states relative paths (`./`) resolve from the skill root directory (not the step file location) and note the change from `{installed_path}` to `./`; ensure the phrasing matches surrounding style and numbering/formatting of the existing list.
70-79: Configuration loading assumes_bmadstructure without fallback.Line 72-78 expect specific config keys and paths (e.g.,
{main_config},project_context,CLAUDE.md). If_bmad/bmm/config.yamlis missing or malformed, there's no error handling or default behavior specified.While this may be out of scope for this PR, the shift to verbatim skill copying makes this a more likely failure mode since the skill and its dependencies are now in separate directories with independent lifecycles.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/bmm/workflows/bmad-quick-flow/bmad-quick-dev-new-preview/workflow.md` around lines 70 - 79, Configuration loading assumes the `_bmad` layout and lacks validation/fallbacks for missing or malformed `{main_config}` (e.g., `_bmad/bmm/config.yaml`) and optional files like `project_context` or `CLAUDE.md`; add robust validation in the config-loading routine so `project_name`, `planning_artifacts`, `implementation_artifacts`, `user_name`, `communication_language`, `document_output_language`, `user_skill_level`, and `date` are checked and defaulted when missing, detect and handle parse errors for `{main_config}`, attempt to load `**/project-context.md` and CLAUDE.md only if present, and provide clear fallback defaults and error/log messages (use the same loader function or method that reads `{main_config}` and the code paths that reference `project_context`/`CLAUDE.md` to implement these checks).
84-89: Mixed path resolution strategies create implicit architecture dependency.Lines 84 and 89 now use
./relative paths for local skill files, while lines 4, 7-8, and 11 retain{project-root}/_bmad/...for external dependencies. This creates an undocumented architectural constraint: the skill in.claude/skills/depends on_bmad/being present with the expected structure.While this dependency may be satisfied by the installer's default behavior, it's not obvious from reading this file alone. A developer modifying installation behavior or a user manually copying the skill directory would have no indication of this dependency.
Add a comment near the frontmatter documenting the external dependency:
# External dependencies (require _bmad/ installation): # - main_config, advanced_elicitation, party_mode_exec, adversarial_review_task🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/bmm/workflows/bmad-quick-flow/bmad-quick-dev-new-preview/workflow.md` around lines 84 - 89, Add a short documented note in the frontmatter of workflow.md describing the external _bmad/ dependency so readers know local skill files (e.g., the entries referenced by `templateFile` and `wipFile` and the skill in `.claude/skills/`) require the `_bmad/` installation; update the frontmatter (near the top) to include a brief "External dependencies" comment listing the required modules `main_config`, `advanced_elicitation`, `party_mode_exec`, and `adversarial_review_task` so maintainers/users see the implicit architecture constraint without scanning other files.
85-86:wipFilestill uses{implementation_artifacts}placeholder while peers migrated to relative paths.Line 85-86 retain the
{implementation_artifacts}placeholder forwipFileanddeferred_work_file. This is presumably intentional (these write to the project's artifacts directory, not the skill directory), but the asymmetry withtemplateFileusing./may confuse readers.A brief inline comment explaining why these remain placeholder-based while
templateFileis relative would improve clarity.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/bmm/workflows/bmad-quick-flow/bmad-quick-dev-new-preview/workflow.md` around lines 85 - 86, The wipFile and deferred_work_file entries still use the {implementation_artifacts} placeholder while templateFile uses a relative ./ path; add a brief inline comment next to the wipFile and deferred_work_file lines explaining that these intentionally target the project's artifacts directory (not the skill directory) and therefore remain placeholder-based for runtime substitution, to avoid confusion with templateFile's relative path.src/bmm/workflows/bmad-quick-flow/bmad-quick-dev-new-preview/bmad-skill-manifest.yaml (1)
1-1: Manifest deviates from documented convention and lacks validation.The file contains only
type: skillwith nocanonicalIdordescription. While the generator code derives these from the directory name andworkflow.md, this deviates from the established convention that bmad-skill-manifest.yaml files have exactly three fields.Additionally, there's no validation that
type: skillis a recognized value. A typo liketype: skilwould cause the workflow to be treated as a regular workflow entry (or worse, silently ignored), with no error surfacing until runtime behavior diverges.Consider one of:
- Add explicit
descriptionfield to make the manifest self-documenting and compliant with existing convention- Add schema validation in the manifest loader to reject unrecognized
typevaluesBased on learnings, manifests should have "canonicalId, type, and description" fields.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/bmm/workflows/bmad-quick-flow/bmad-quick-dev-new-preview/bmad-skill-manifest.yaml` at line 1, The manifest currently only contains "type: skill" which breaks the convention of manifest files having canonicalId, type, and description and lacks validation for allowed type values; update the bmad-skill-manifest.yaml to include explicit canonicalId and description fields (derived from the directory/workflow.md as needed) and add schema validation in the manifest loader to reject unrecognized type values (e.g., validate that type === "skill" and throw a clear error on typos), ensuring the loader returns a helpful error when canonicalId, type, or description are missing or invalid.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In
`@src/bmm/workflows/bmad-quick-flow/bmad-quick-dev-new-preview/steps/step-02-plan.md`:
- Line 5: The frontmatter key templateFile referencing './tech-spec-template.md'
relies on an implicit skill-root-relative path resolution which is undocumented
and fragile; add a short developer comment or update the workflow architecture
docs clarifying that templateFile paths beginning with './' are resolved
relative to the skill root (not the step file location), and include an example
showing './tech-spec-template.md' resolves to the skill root template so future
maintainers understand the convention.
In `@tools/cli/installers/lib/core/manifest-generator.js`:
- Line 24: The ManifestGenerator is not clearing stale skills between runs
because this.skills is only initialized once; update the code to reset the
skills array at the start of each manifest run—e.g., add this.skills = [] at the
beginning of the method that starts manifest generation (such as
collectWorkflows or the public generateManifest/run method) or mirror the
existing behavior for this.workflows by clearing this.skills inside
collectWorkflows before appending new entries; reference the ManifestGenerator
class and the this.skills property when making the change.
- Around line 248-265: The current early return path in the artifact-type
handling for skills (inside getArtifactType check) pushes to this.skills but
uses continue, which prevents adding the skill's file entry to this.files and
causes writeFilesManifest()/generateManifests() fallback to omit skill files;
modify the skill branch in manifest-generator.js so that after
this.skills.push(...) it also adds the corresponding file record to this.files
(same shape used in the normal path) instead of skipping with continue, ensuring
generateManifests()/writeFilesManifest() include skill source files in
files-manifest.csv; refer to getArtifactType, this.skills.push, this.files.push,
generateManifests, and writeFilesManifest when making the change.
In `@tools/cli/installers/lib/ide/_config-driven.js`:
- Around line 705-714: The code is deleting original skill sources by removing
sourceDir (computed from bmadDir and record.path) when record.install_to_bmad
=== 'false', which mutates the source tree other installs rely on; change the
cleanup to avoid deleting sourceDir—either skip removal entirely for records
with install_to_bmad === 'false' or remove the per-target install directory
instead (compute target-specific path rather than using bmadDir/ sourceDir);
update the block that references records, bmadFolderName, bmadDir, sourceFile,
sourceDir and the fs.remove call accordingly so only the appropriate target
artifact is removed and not the shared source.
- Line 123: The early return when artifact_types is an empty array prevents
installVerbatimSkills() from running for skill-only targets; change the guard so
you only return early when artifact_types is empty AND there are no skills to
install, otherwise continue and call installVerbatimSkills() (and aggregate its
results into the returned results object), ensuring the results object
(agents/workflows/tasks/tools/skills) is updated correctly after
installVerbatimSkills() completes.
- Around line 655-670: The CSV-derived values can escape intended roots; before
touching the fs, resolve and validate paths: compute absoluteSource =
path.resolve(bmadDir, relativePath) and ensure path.relative(bmadDir,
absoluteSource) does not start with '..' and that
absoluteSource.startsWith(path.resolve(bmadDir)); also validate canonicalId is a
single path segment (no path.sep, no '..', not absolute) and derive skillDir as
path.resolve(targetPath, canonicalId) then ensure
path.relative(path.resolve(targetPath), skillDir) does not start with '..'
before calling fs.pathExists, fs.remove, or copying; if any check fails, skip
the record and log a warning.
- Around line 688-700: The code currently writes SKILL.md (skillMd using
frontmatterYaml) before copying source files and hardcodes "workflow.md", which
allows a source SKILL.md to overwrite the generated file and breaks
non-“workflow.md” entry names; move the SKILL.md generation and fs.writeFile to
after the fs.copy loop and replace the hardcoded "workflow.md" reference with
detection of the actual workflow entry (e.g., search sourceDir for workflow.yaml
or files matching /^workflow(-.*)?\.md$/ and use that discovered filename when
composing the message), ensure you still skip copying bmad-skill-manifest.yaml,
and reference the same discovered entry filename variable when building skillMd
so the generated SKILL.md won’t be overwritten and supports
workflow.yaml/workflow-*.md names (use symbols frontmatterYaml, skillMd,
SKILL.md, entries, fs.copy, sourceDir, destPath to locate and update the code).
---
Outside diff comments:
In `@src/bmm/workflows/bmad-quick-flow/bmad-quick-dev-new-preview/workflow.md`:
- Around line 2-3: Update the frontmatter `name` value from
"quick-dev-new-preview" to "bmad-quick-dev-new-preview" so it matches the
directory/canonical id and the agent trigger expectations; locate the `name` key
in the workflow frontmatter and replace its value, and then scan related
manifests/skill CSVs for any remaining references to the old name to keep all
identifiers consistent (e.g., canonicalId, skill CSV entries, agent trigger
config).
---
Nitpick comments:
In
`@src/bmm/workflows/bmad-quick-flow/bmad-quick-dev-new-preview/bmad-skill-manifest.yaml`:
- Line 1: The manifest currently only contains "type: skill" which breaks the
convention of manifest files having canonicalId, type, and description and lacks
validation for allowed type values; update the bmad-skill-manifest.yaml to
include explicit canonicalId and description fields (derived from the
directory/workflow.md as needed) and add schema validation in the manifest
loader to reject unrecognized type values (e.g., validate that type === "skill"
and throw a clear error on typos), ensuring the loader returns a helpful error
when canonicalId, type, or description are missing or invalid.
In `@src/bmm/workflows/bmad-quick-flow/bmad-quick-dev-new-preview/workflow.md`:
- Around line 46-51: Add a new rule to the "Step Processing Rules" section in
workflow.md clarifying path resolution: under the existing list (after
"Append-Only Building" or within the "Workflow Architecture" block) insert a
numbered item titled "RESOLVE PATHS" that states relative paths (`./`) resolve
from the skill root directory (not the step file location) and note the change
from `{installed_path}` to `./`; ensure the phrasing matches surrounding style
and numbering/formatting of the existing list.
- Around line 70-79: Configuration loading assumes the `_bmad` layout and lacks
validation/fallbacks for missing or malformed `{main_config}` (e.g.,
`_bmad/bmm/config.yaml`) and optional files like `project_context` or
`CLAUDE.md`; add robust validation in the config-loading routine so
`project_name`, `planning_artifacts`, `implementation_artifacts`, `user_name`,
`communication_language`, `document_output_language`, `user_skill_level`, and
`date` are checked and defaulted when missing, detect and handle parse errors
for `{main_config}`, attempt to load `**/project-context.md` and CLAUDE.md only
if present, and provide clear fallback defaults and error/log messages (use the
same loader function or method that reads `{main_config}` and the code paths
that reference `project_context`/`CLAUDE.md` to implement these checks).
- Around line 84-89: Add a short documented note in the frontmatter of
workflow.md describing the external _bmad/ dependency so readers know local
skill files (e.g., the entries referenced by `templateFile` and `wipFile` and
the skill in `.claude/skills/`) require the `_bmad/` installation; update the
frontmatter (near the top) to include a brief "External dependencies" comment
listing the required modules `main_config`, `advanced_elicitation`,
`party_mode_exec`, and `adversarial_review_task` so maintainers/users see the
implicit architecture constraint without scanning other files.
- Around line 85-86: The wipFile and deferred_work_file entries still use the
{implementation_artifacts} placeholder while templateFile uses a relative ./
path; add a brief inline comment next to the wipFile and deferred_work_file
lines explaining that these intentionally target the project's artifacts
directory (not the skill directory) and therefore remain placeholder-based for
runtime substitution, to avoid confusion with templateFile's relative path.
In `@test/test-install-to-bmad.js`:
- Around line 84-128: The current tests only exercise helper functions
(loadSkillManifest, getInstallToBmad) and never run the installer logic in
_config-driven.js; add a new installer-level test in
test/test-install-to-bmad.js that executes the actual install pipeline (e.g.,
invoke the entrypoint that runs installVerbatimSkills / the _config-driven.js
flow) against a temporary skill dir and CSV to assert CSV parsing, verbatim
copying, generated SKILL.md behavior, pruning of install_to_bmad: false entries,
and stale-file cleanup; ensure the test creates a realistic CSV/manifest, runs
the installer code path introduced by this PR, and asserts on filesystem side
effects (presence/absence of copied files and SKILL.md) rather than only calling
getInstallToBmad/loadSkillManifest.
In `@tools/cli/installers/lib/core/manifest-generator.js`:
- Around line 121-124: The generateManifests() flow builds manifestFiles but
doesn't return the new skill count; update generateManifests() to include a
skills count in its result by having writeSkillManifest(cfgDir) return the
number of skills (or an object containing count) and then add that value to the
returned summary (e.g., result.skills = skillCount). Ensure writeSkillManifest
and any callers (manifestFiles assembly) propagate that returned count so
summary/logging/assertion code can observe the new skill artifact count.
In `@tools/cli/installers/lib/ide/shared/skill-manifest.js`:
- Around line 48-90: Create a single helper (e.g.,
resolveManifestEntry(manifest, filename)) that encapsulates the lookup chain
(return manifest.__single for single-entry, then manifest[filename], then the
fallback keys derived from baseName such as `${baseName}.agent.yaml` and
`${baseName}.xml`) and returns the resolved entry or null; then change
getCanonicalId, getArtifactType, and getInstallToBmad to call that helper once
and read the needed fields (id/type/install_to_bmad with existing defaults) from
the returned entry instead of duplicating the lookup logic in each function.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: d0f425c1-0c70-4e20-9e62-e6e1fd446aeb
⛔ Files ignored due to path filters (1)
src/bmm/module-help.csvis excluded by!**/*.csv
📒 Files selected for processing (15)
src/bmm/agents/quick-flow-solo-dev.agent.yamlsrc/bmm/workflows/bmad-quick-flow/bmad-quick-dev-new-preview/bmad-skill-manifest.yamlsrc/bmm/workflows/bmad-quick-flow/bmad-quick-dev-new-preview/steps/step-01-clarify-and-route.mdsrc/bmm/workflows/bmad-quick-flow/bmad-quick-dev-new-preview/steps/step-02-plan.mdsrc/bmm/workflows/bmad-quick-flow/bmad-quick-dev-new-preview/steps/step-03-implement.mdsrc/bmm/workflows/bmad-quick-flow/bmad-quick-dev-new-preview/steps/step-04-review.mdsrc/bmm/workflows/bmad-quick-flow/bmad-quick-dev-new-preview/steps/step-05-present.mdsrc/bmm/workflows/bmad-quick-flow/bmad-quick-dev-new-preview/tech-spec-template.mdsrc/bmm/workflows/bmad-quick-flow/bmad-quick-dev-new-preview/workflow.mdsrc/bmm/workflows/bmad-quick-flow/quick-dev-new-preview/bmad-skill-manifest.yamlsrc/core/tasks/help.mdtest/test-install-to-bmad.jstools/cli/installers/lib/core/manifest-generator.jstools/cli/installers/lib/ide/_config-driven.jstools/cli/installers/lib/ide/shared/skill-manifest.js
💤 Files with no reviewable changes (1)
- src/bmm/workflows/bmad-quick-flow/quick-dev-new-preview/bmad-skill-manifest.yaml
src/bmm/workflows/bmad-quick-flow/bmad-quick-dev-new-preview/steps/step-02-plan.md
Outdated
Show resolved
Hide resolved
…pying Introduce `type: skill` in bmad-skill-manifest.yaml to signal the installer to copy entire skill directories verbatim into IDE skill directories, replacing the launcher-based approach. Changes: - skill-manifest.js: fix single-entry detection for type-only manifests, add getArtifactType export - manifest-generator.js: collect type:skill entries separately, write skill-manifest.csv, derive canonicalId from directory name - _config-driven.js: add installVerbatimSkills with YAML-safe SKILL.md generation, stale file cleanup, and warning on parse failures - Rename quick-dev-new-preview to bmad-quick-dev-new-preview so directory name is the canonical ID - Update workflow.md installed_path to reference IDE skill base directory Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
…kill Skills resolve paths relative to the skill root directory per the open agent standard, so the installed_path variable is unnecessary. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Add install_to_bmad flag to skill manifests (default true) enabling skills to opt out of _bmad/ copy while retaining .claude/skills/ installation. Support skill:<canonicalId> references in module-help.csv workflow-file column. Fix stale quick-dev-new-preview directory references in agent YAML and help catalog. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Unit tests against getInstallToBmad and loadSkillManifest that nail down the 4 core design decisions for the install_to_bmad flag. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
alexeyv
force-pushed
the
feat/quick-dev-as-skill
branch
from
56d4954 to
6aa67d7
Compare
- Reset this.skills and this.files in ManifestGenerator to prevent stale data when instance is reused across multiple manifest runs - Allow targets with empty artifact_types to still install verbatim skills by checking skill_format before short-circuiting Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
- Fix step-02-plan.md templateFile path (./tech-spec-template.md → ../tech-spec-template.md) - Teach validate-file-refs.js to skip skill: prefixed references in CSV Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This was referenced Mar 8, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
type: skillinbmad-skill-manifest.yaml— signals the installer to copy the entire skill directory verbatim into IDE skill directories instead of generating a tiny launcher SKILL.mdcanonicalIdis derived from the directory name (no need to store it in the manifest)type: skillentries into a newskill-manifest.csv(excluded fromworkflow-manifest.csv)SKILL.md, cleans stale files on reinstallquick-dev-new-previewworkflow to the new self-contained skill formatTest plan
.claude/skills/bmad-quick-dev-new-preview/contains workflow.md, steps/, tech-spec-template.md, and auto-generated SKILL.md_config/workflow-manifest.csvhas no quick-dev-new-preview entry_config/skill-manifest.csvhas the entry with correct canonicalId🤖 Generated with Claude Code