chore: scaffold multi-channel monorepo#1
Conversation
Restructure from single-package scaffold to a minimal Bun workspace monorepo + plugin marketplace skeleton. Five deliverable channels with living docs per directory, no published modules yet. - Add workspaces: ["packages/*"] to package.json, drop src/ exports - Create top-level skills/ plugins/ agents/ packages/ with README each - Add .claude-plugin/marketplace.json stub (name: solenix-agents) - Add AGENTS.md for agent-facing repo guidance - Rewrite root README.md as 5-channel index - Rewrite CONTRIBUTING.md with add-a-thing recipes + maintainer posture - Clean tsconfig.json, stub typecheck/test scripts until first package - Delete empty src/ tree Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
📝 WalkthroughWalkthroughThe project is transitioning from a monolithic TypeScript package with direct exports and path aliases to a monorepo workspace architecture. This shift introduces separate distribution channels for skills, skill packs, plugins, MCP servers, and CLI bridges, accompanied by comprehensive documentation defining standards, conventions, and directory layouts for each channel type. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 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 |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 028d13a15b
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "Codex (@codex) review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "Codex (@codex) address that feedback".
| "types": "./dist/index.d.ts", | ||
| "files": ["dist", "README.md"], | ||
| "scripts": { | ||
| "build": "bun build ./src/cli.ts --outdir ./dist --target node", |
There was a problem hiding this comment.
src/index.ts in package template
The package.json template declares main: "./dist/index.js" and types: "./dist/index.d.ts", but the recommended build script only compiles src/cli.ts. If contributors follow this recipe, published packages will be missing the documented library entrypoint and type declarations, so imports from @solenix/mcp-* can fail at runtime/type-resolution time. Update the template to build both entrypoints (or remove main/types for CLI-only packages).
Useful? React with 👍 / 👎.
| "sourceMap": true | ||
| }, | ||
| "include": ["src/**/*.ts"], | ||
| "files": [], |
There was a problem hiding this comment.
files: [] from shared tsconfig
Setting files: [] in the base tsconfig disables automatic source discovery, so any new package config that only extends this file will typecheck zero files unless it explicitly adds include. Because the repo docs tell contributors to extend the root config, this creates a high-risk false-green path where tsc --noEmit passes without checking package code.
Useful? React with 👍 / 👎.
![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
🧹 Nitpick comments (4)
package.json (1)
14-15: Stub scripts exit 0 — fine for now, but CI should not mistake this for passing coverage.
echo '…'returns exit code 0, so any CI job wired tobun run test/bun run typecheckwill report green with zero real checks. That matches the PR's intent ("stub until first package lands"), but it's worth wiring a TODO or a guard so the stubs get replaced the moment the firstpackages/*entry lands — otherwise a future PR can silently land broken TS and CI will still be green.Consider at minimum making the stubs self-deleting-by-convention, e.g.:
- "test": "echo 'No tests yet — per-package tests will run via workspaces once packages land.'", - "typecheck": "echo 'No TS sources yet — typecheck activates when first package lands.'" + "test": "bun run --filter '*' test 2>/dev/null || echo 'No packages with tests yet.'", + "typecheck": "tsc -p tsconfig.json --noEmit"The second form runs the empty-files tsconfig (valid no-op today, real check tomorrow) without needing a follow-up PR to "turn typecheck on."
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@package.json` around lines 14 - 15, The current npm scripts "test" and "typecheck" are no-op echoes which always exit 0; change them to guard by detecting whether any workspace packages exist and only keep the no-op when none are present, otherwise run the real checks (e.g. run the repo test harness or TS typecheck). Update the "test" and "typecheck" script entries so they: 1) detect presence of packages/* (or a sentinel like PACKAGES_PRESENT or a TODO file) and if found invoke the real test/typecheck commands, and 2) otherwise print the stub message and exit 0; this ensures CI fails once actual packages land and avoids silent green builds while preserving the current stub behavior.plugins/README.md (2)
9-24: Add language identifier to fenced code block.The directory tree code block should specify a language identifier (e.g.,
textorplaintext) to satisfy markdown linters and improve rendering consistency.📝 Proposed fix
-``` +```text plugins/ └── my-plugin/🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@plugins/README.md` around lines 9 - 24, The fenced directory-tree code block in plugins/README.md is missing a language identifier; update the opening fence for the block that starts with "plugins/" (the directory tree under the README) from ``` to ```text (or ```plaintext) so markdown linters and renderers treat it as plain text; keep the block content unchanged and ensure the closing fence remains ``` to preserve the tree formatting.
44-51: Clarify version precedence to avoid confusion.The marketplace.json example shows
"version": "0.1.0"(line 49), but the plugin.json example above (line 31) also includes a version field. This contradicts the guidance at line 57 that says "Setversionin ONE place". Readers following both examples sequentially will set version in both places, then need to backtrack.Consider either:
- Removing
"version"from one of the two examples and adding a comment explaining where it should go, or- Adding a note immediately after line 51 referencing the gotcha at line 57
📋 Example clarification
Option 1: Remove from marketplace example and add comment:
{ "name": "my-plugin", "source": "my-plugin", - "description": "Same description as plugin.json", - "version": "0.1.0" + "description": "Same description as plugin.json" + // version is inherited from plugin.json — see Gotchas below }Option 2: Add immediate reference after the example:
}Note: See "Gotchas" below about version precedence when set in both files.
</details> <details> <summary>🤖 Prompt for AI Agents</summary>Verify each finding against the current code and only fix it if needed.
In
@plugins/README.mdaround lines 44 - 51, The README shows a conflicting
"version" field in both the plugin.json example and the marketplace.json example
(the marketplace example JSON includes "version": "0.1.0") which contradicts the
guidance in the "Gotchas" section to set version in ONE place; fix by either
removing the "version" property from the marketplace.json example or by leaving
it but adding a one-line note immediately after the marketplace example that
references the "Gotchas" section and clarifies version precedence (mentioning
the "version" field, the plugin.json example, the marketplace.json example, and
the "Gotchas" section so readers know where to look).</details> </blockquote></details> <details> <summary>packages/README.md (1)</summary><blockquote> `17-28`: **Add language identifier to fenced code block.** The directory tree code block should specify a language identifier (e.g., `text` or `plaintext`) to satisfy markdown linters and improve rendering consistency. <details> <summary>📝 Proposed fix</summary> ```diff -``` +```text packages/ └── mcp-foo/🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/README.md` around lines 17 - 28, The fenced code block that shows the directory tree should include a language identifier to satisfy linters; update the markdown block that contains the directory tree (the triple-backtick block containing "packages/ └── mcp-foo/ ... README.md") by adding a language token such as "text" or "plaintext" immediately after the opening ``` so the block starts with ```text.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.claude-plugin/marketplace.json:
- Around line 3-6: The manifest currently hard-codes a personal email under the
JSON keys owner.name ("Solenix") and owner.email ("jagerdcooper@gmail.com");
replace that personal address with a role-based or generic contact (for example
"agents@solenix.dev" or "oss@solenix.dev") or a non-personal placeholder before
shipping to avoid exposing PII—update owner.email in
.claude-plugin/marketplace.json and ensure any README or metadata referencing
the same address is changed consistently.
In `@CONTRIBUTING.md`:
- Around line 41-44: Update the CONTRIBUTING.md step that tells contributors to
edit .claude-plugin/marketplace.json by adding a one-line note that this file is
generated and should not be manually edited; reference the generated file name
`.claude-plugin/marketplace.json`, mention the generator script
`sync-marketplace.ts` (or the generator that will produce the file from
`plugins/*`), and point to `AGENTS.md` as the canonical guideline so
contributors know this is an interim instruction only.
In `@packages/README.md`:
- Line 45: The current example build script only compiles cli.ts but the sample
package.json exposes both a CLI and a library (main/types ->
index.js/index.d.ts); update the example to either show two explicit build steps
(one for the library entry index.ts and one for the CLI entry cli.ts) or replace
the single "build" script to compile both entry points (index.ts and src/cli.ts)
so both the library (index.js/index.d.ts) and the CLI binary are emitted;
reference the build script name ("build") and the entry files ("src/cli.ts",
"index.ts") and the package.json fields ("main", "types") when making the
change.
In `@plugins/README.md`:
- Line 33: The example author entry contains a real-looking email
("jagerdcooper@gmail.com"); update the JSON author object in the README (the
"author" object with "name": "Solenix" and "email") to use a clearly fake
placeholder email (e.g., user@example.com or name@example.com) so the example
does not contain a real address.
In `@README.md`:
- Around line 52-59: The README's Development section claims real typecheck/test
commands but package.json currently contains echo stubs; update package.json so
the "typecheck" npm script runs a real TypeScript check (e.g. set "typecheck" to
"tsc -p tsconfig.json --noEmit" so it’s a no-op against an empty files list) and
change the "test" script from the echo stub to the actual test runner used by
the repo (e.g. "bun test" or "vitest" as appropriate); then ensure the README
Development commands match those real scripts ("bun run typecheck" and "bun run
test") and that tsconfig.json exists/points at the correct project config.
- Around line 11-12: Update the README table entry for "Skills" and "Skill
packs" to use the documented skills CLI syntax: replace the incorrect `npx
skills add NutraForgeTechnologies/agents/skills/<name>` example with the
shorthand `npx skills add owner/repo` and add the variant for installing a
specific skill from the NutraForgeTechnologies repo using `npx skills add
NutraForgeTechnologies/agents --skill <skill-name>` (or reference the full repo
path); update both the "Skills" and "Skill packs" rows to reflect this correct
usage.
In `@skills/README.md`:
- Around line 53-56: Update the `name` rule in the Skills README so it allows
lowercase letters, digits, and hyphens but forbids leading/trailing or
consecutive hyphens; replace the current "lowercase + hyphens only" guidance for
`name` with the precise regex constraint (e.g., use the pattern
^[a-z0-9]+(-[a-z0-9]+)*$) so the `name` field description matches Anthropic's
SKILL.md and can be enforced by CI.
---
Nitpick comments:
In `@package.json`:
- Around line 14-15: The current npm scripts "test" and "typecheck" are no-op
echoes which always exit 0; change them to guard by detecting whether any
workspace packages exist and only keep the no-op when none are present,
otherwise run the real checks (e.g. run the repo test harness or TS typecheck).
Update the "test" and "typecheck" script entries so they: 1) detect presence of
packages/* (or a sentinel like PACKAGES_PRESENT or a TODO file) and if found
invoke the real test/typecheck commands, and 2) otherwise print the stub message
and exit 0; this ensures CI fails once actual packages land and avoids silent
green builds while preserving the current stub behavior.
In `@packages/README.md`:
- Around line 17-28: The fenced code block that shows the directory tree should
include a language identifier to satisfy linters; update the markdown block that
contains the directory tree (the triple-backtick block containing "packages/ └──
mcp-foo/ ... README.md") by adding a language token such as "text" or
"plaintext" immediately after the opening ``` so the block starts with ```text.
In `@plugins/README.md`:
- Around line 9-24: The fenced directory-tree code block in plugins/README.md is
missing a language identifier; update the opening fence for the block that
starts with "plugins/" (the directory tree under the README) from ``` to ```text
(or ```plaintext) so markdown linters and renderers treat it as plain text; keep
the block content unchanged and ensure the closing fence remains ``` to preserve
the tree formatting.
- Around line 44-51: The README shows a conflicting "version" field in both the
plugin.json example and the marketplace.json example (the marketplace example
JSON includes "version": "0.1.0") which contradicts the guidance in the
"Gotchas" section to set version in ONE place; fix by either removing the
"version" property from the marketplace.json example or by leaving it but adding
a one-line note immediately after the marketplace example that references the
"Gotchas" section and clarifies version precedence (mentioning the "version"
field, the plugin.json example, the marketplace.json example, and the "Gotchas"
section so readers know where to look).
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 94cfd8bf-2f50-4b11-a35d-52e353fca0a0
📒 Files selected for processing (11)
.claude-plugin/marketplace.jsonAGENTS.mdCONTRIBUTING.mdREADME.mdagents/README.mdpackage.jsonpackages/README.mdplugins/README.mdskills/README.mdsrc/index.tstsconfig.json
💤 Files with no reviewable changes (1)
- src/index.ts
📜 Review details
🧰 Additional context used
📓 Path-based instructions (5)
.claude-plugin/marketplace.json
📄 CodeRabbit inference engine (AGENTS.md)
Do not manually edit .claude-plugin/marketplace.json; it should be regenerated from plugins/* using a generator script
Files:
.claude-plugin/marketplace.json
*/README.md
📄 CodeRabbit inference engine (AGENTS.md)
Each directory (skills/, plugins/, agents/, packages/) must have its own README.md with format specs and recipes for adding new items
Files:
skills/README.mdagents/README.mdpackages/README.mdplugins/README.md
**/*
📄 CodeRabbit inference engine (AGENTS.md)
Use kebab-case exclusively for skill, plugin, package, and MCP server names
Do not ship secrets, API keys, or example values that look real in skills, plugins, MCPs, or any code
Files:
skills/README.mdagents/README.mdtsconfig.jsonpackages/README.mdCONTRIBUTING.mdAGENTS.mdpackage.jsonREADME.mdplugins/README.md
AGENTS.md
📄 CodeRabbit inference engine (AGENTS.md)
Read AGENTS.md before doing substantive work on skills, plugins, MCPs, CLIs, or subagents in this repo
Files:
AGENTS.md
plugins/**
📄 CodeRabbit inference engine (AGENTS.md)
Do not reference files outside a plugin root with '../' paths; use ${CLAUDE_PLUGIN_ROOT} environment variable in hooks to avoid breaking cached paths
Files:
plugins/README.md
🧠 Learnings (1)
📓 Common learnings
Learnt from: CR
Repo: NutraForgeTechnologies/agents
Timestamp: 2026-04-19T17:21:50.052Z
Learning: Load the 'context-engineering' skill before editing any SKILL.md, AGENT.md, or plugin.json file
Learnt from: CR
Repo: NutraForgeTechnologies/agents
Timestamp: 2026-04-19T17:21:50.052Z
Learning: Load the 'skill-creator' skill in addition to 'context-engineering' when adding or editing skills under skills/
Learnt from: CR
Repo: NutraForgeTechnologies/agents
Timestamp: 2026-04-19T17:21:50.052Z
Learning: Use conventional commits with prefixes (feat:, fix:, docs:, refactor:, test:, chore:) for all commit messages
Learnt from: CR
Repo: NutraForgeTechnologies/agents
Timestamp: 2026-04-19T17:21:50.052Z
Learning: Use TDD (Test-Driven Development) for code in MCPs and CLIs; skills are prose and do not require tests
Learnt from: CR
Repo: NutraForgeTechnologies/agents
Timestamp: 2026-04-19T17:21:50.052Z
Learning: Keep the repo minimal; do not create shared-config packages, .changesets/, or Turborepo configuration until there are real published packages to version
Learnt from: CR
Repo: NutraForgeTechnologies/agents
Timestamp: 2026-04-19T17:21:50.052Z
Learning: Use main-context-plans-subagents-execute pattern for delegation: main context plans and names, subagents port/draft specific components
Learnt from: CR
Repo: NutraForgeTechnologies/agents
Timestamp: 2026-04-19T17:21:50.052Z
Learning: Keep documentation ('living docs') accurate by updating relevant directory READMEs whenever introducing new patterns or conventions
Learnt from: CR
Repo: NutraForgeTechnologies/agents
Timestamp: 2026-04-19T17:21:50.052Z
Learning: Use one concern per PR; do not bundle unrelated features (e.g., new skill + refactor of CONTRIBUTING) in a single pull request
🪛 LanguageTool
CONTRIBUTING.md
[grammar] ~52-~52: Ensure spelling is correct
Context: ...th name: "@solenix/mcp-<name>", bin, type: "module" 3. Add src/cli.ts (stdio entry), `src/index....
(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)
🪛 markdownlint-cli2 (0.22.0)
skills/README.md
[warning] 13-13: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
[warning] 26-26: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
agents/README.md
[warning] 20-20: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
packages/README.md
[warning] 17-17: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
AGENTS.md
[warning] 7-7: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
README.md
[warning] 19-19: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
plugins/README.md
[warning] 9-9: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
🔇 Additional comments (3)
tsconfig.json (1)
27-27: LGTM —"files": []is a valid placeholder for a project with no sources yet.TypeScript accepts an empty
filesarray and will simply have nothing to compile, which matches the stubtypecheckscript. Once the first package lands, you'll likely want to convert this to a solution-style root tsconfig withreferences: [...]per workspace package rather than adding globs back here.agents/README.md (1)
1-51: LGTM — clear subagent vs skill distinction.The decision table and directory layout are unambiguous, and the frontmatter example matches the Claude Code subagent conventions referenced in
AGENTS.md. No issues.AGENTS.md (1)
39-44: LGTM — "Do Not" section codifies the right invariants.The no-
../-in-plugins rule, the "don't ship secrets / example values that look real" rule, and the marketplace hand-edit caveat all align with the retrieved learnings and the coding guidelines. Worth noting that the marketplace.json currently shipped in this PR contains a real personal email (flagged separately on that file) — this doc correctly forbids that pattern going forward.
| "owner": { | ||
| "name": "Solenix", | ||
| "email": "jagerdcooper@gmail.com" | ||
| }, |
There was a problem hiding this comment.
Personal email hard-coded in shipped manifest.
jagerdcooper@gmail.com is a real-looking personal email being committed to a public OSS manifest. As per coding guidelines: "Do not ship secrets, API keys, or example values that look real in skills, plugins, MCPs, or any code." Even if this is the maintainer's address, consider using a role-based alias (e.g., agents@solenix.dev, oss@…) to avoid PII exposure, scraping, and long-term inbox lock-in to one contributor.
🛡️ Suggested change
"owner": {
"name": "Solenix",
- "email": "jagerdcooper@gmail.com"
+ "email": "oss@solenix.dev"
},📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| "owner": { | |
| "name": "Solenix", | |
| "email": "jagerdcooper@gmail.com" | |
| }, | |
| "owner": { | |
| "name": "Solenix", | |
| "email": "oss@solenix.dev" | |
| }, |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.claude-plugin/marketplace.json around lines 3 - 6, The manifest currently
hard-codes a personal email under the JSON keys owner.name ("Solenix") and
owner.email ("jagerdcooper@gmail.com"); replace that personal address with a
role-based or generic contact (for example "agents@solenix.dev" or
"oss@solenix.dev") or a non-personal placeholder before shipping to avoid
exposing PII—update owner.email in .claude-plugin/marketplace.json and ensure
any README or metadata referencing the same address is changed consistently.
| 3. Add an entry to [.claude-plugin/marketplace.json](./.claude-plugin/marketplace.json): | ||
| ```json | ||
| { "name": "<your-plugin>", "source": "<your-plugin>", "description": "...", "version": "0.1.0" } | ||
| ``` |
There was a problem hiding this comment.
Marketplace-edit instruction conflicts with the coding guideline / AGENTS.md.
Step 3 tells contributors to hand-edit .claude-plugin/marketplace.json, but the repo guideline states that file "should be regenerated from plugins/* using a generator script," and AGENTS.md line 42 also hedges with "hand-edit for now; a sync-marketplace.ts script will land with the first plugin." Once the generator lands, this recipe will silently go stale and external contributors will produce merge conflicts against the generated file.
Suggest adding a one-liner noting the interim nature:
-3. Add an entry to [.claude-plugin/marketplace.json](./.claude-plugin/marketplace.json):
+3. Add an entry to [.claude-plugin/marketplace.json](./.claude-plugin/marketplace.json)
+ (interim — will be regenerated by `sync-marketplace.ts` once that script lands):As per coding guidelines: "Do not manually edit .claude-plugin/marketplace.json; it should be regenerated from plugins/* using a generator script".
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| 3. Add an entry to [.claude-plugin/marketplace.json](./.claude-plugin/marketplace.json): | |
| ```json | |
| { "name": "<your-plugin>", "source": "<your-plugin>", "description": "...", "version": "0.1.0" } | |
| ``` | |
| 3. Add an entry to [.claude-plugin/marketplace.json](./.claude-plugin/marketplace.json) | |
| (interim — will be regenerated by `sync-marketplace.ts` once that script lands): |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@CONTRIBUTING.md` around lines 41 - 44, Update the CONTRIBUTING.md step that
tells contributors to edit .claude-plugin/marketplace.json by adding a one-line
note that this file is generated and should not be manually edited; reference
the generated file name `.claude-plugin/marketplace.json`, mention the generator
script `sync-marketplace.ts` (or the generator that will produce the file from
`plugins/*`), and point to `AGENTS.md` as the canonical guideline so
contributors know this is an interim instruction only.
| "types": "./dist/index.d.ts", | ||
| "files": ["dist", "README.md"], | ||
| "scripts": { | ||
| "build": "bun build ./src/cli.ts --outdir ./dist --target node", |
There was a problem hiding this comment.
Build command may be incomplete for dual-export packages.
The build script only compiles cli.ts, but the example package.json also declares a library export (main and types pointing to index.js and index.d.ts). If a package provides both a CLI binary and a library export (as shown in the directory layout at lines 23-24), the build command should compile both entry points.
Consider either:
- Documenting separate build commands for library vs CLI packages, or
- Updating the example build script to handle both
index.tsandcli.tswhen both are present
🔧 Example fix for dual-export build
"scripts": {
- "build": "bun build ./src/cli.ts --outdir ./dist --target node",
+ "build": "bun build ./src/index.ts ./src/cli.ts --outdir ./dist --target node",
"test": "bun test",Or split into separate recipes for CLI-only vs dual-export packages.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| "build": "bun build ./src/cli.ts --outdir ./dist --target node", | |
| "build": "bun build ./src/index.ts ./src/cli.ts --outdir ./dist --target node", |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@packages/README.md` at line 45, The current example build script only
compiles cli.ts but the sample package.json exposes both a CLI and a library
(main/types -> index.js/index.d.ts); update the example to either show two
explicit build steps (one for the library entry index.ts and one for the CLI
entry cli.ts) or replace the single "build" script to compile both entry points
(index.ts and src/cli.ts) so both the library (index.js/index.d.ts) and the CLI
binary are emitted; reference the build script name ("build") and the entry
files ("src/cli.ts", "index.ts") and the package.json fields ("main", "types")
when making the change.
| "name": "my-plugin", | ||
| "version": "0.1.0", | ||
| "description": "Brief plugin description.", | ||
| "author": { "name": "Solenix", "email": "jagerdcooper@gmail.com" }, |
There was a problem hiding this comment.
Replace real-looking email with a placeholder.
The example contains what appears to be a real email address. As per coding guidelines, avoid shipping example values that look real to prevent confusion and potential misuse.
🔒 Proposed fix
- "author": { "name": "Solenix", "email": "jagerdcooper@gmail.com" },
+ "author": { "name": "Your Name", "email": "your-email@example.com" },📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| "author": { "name": "Solenix", "email": "jagerdcooper@gmail.com" }, | |
| "author": { "name": "Your Name", "email": "your-email@example.com" }, |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@plugins/README.md` at line 33, The example author entry contains a
real-looking email ("jagerdcooper@gmail.com"); update the JSON author object in
the README (the "author" object with "name": "Solenix" and "email") to use a
clearly fake placeholder email (e.g., user@example.com or name@example.com) so
the example does not contain a real address.
| | **Skills** | Agent capabilities loaded on demand (markdown + optional scripts). | `npx skills add NutraForgeTechnologies/agents/skills/<name>` | | ||
| | **Skill packs** | Meta-skills bundling related sub-skills via `.subSkills/`. | Same as skills. | |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
npm "skills" CLI add subcommand install skill from GitHub repo path
💡 Result:
The "skills" CLI (installed via npm i skills or used with npx skills) provides an add subcommand to install skills from GitHub repositories. Use GitHub shorthand like owner/repo, full URLs, or local paths. To install a skill from a GitHub repo path: npx skills add owner/repo-name Examples: - Shorthand: npx skills add vercel-labs/agent-skills (fetches from https://github.com/vercel-labs/agent-skills) - Full URL: npx skills add https://github.com/vercel-labs/agent-skills - Specific branch/subpath: npx skills add https://github.com/vercel-labs/agent-skills/tree/main/skills/web-design-guidelines - Local path: npx skills add ./my-local-skills Options: - -g, --global: Install globally (~/.agents/skills/) - -a, --agent claude-code cursor: Target specific agents - -s, --skill skill-name: Install specific skill (or '*' for all) - -y, --yes: Skip prompts The CLI detects SKILL.md files in standard locations (root, skills/, etc.) and symlinks/copies them to agent directories like .cursor/skills/. This is the primary "skills" CLI from vercel-labs/skills (v1.5.1 as of Apr 2026). Note: skills-npm is a separate tool for npm-packaged skills, not matching the GitHub focus.
Citations:
- 1: https://www.npmjs.com/package/skills
- 2: https://registry.npmjs.org/skills
- 3: https://dev.to/toyama0919/managing-ai-agent-skills-with-npx-skills-a-practical-guide-2an8
- 4: https://github.com/vercel-labs/add-skill
- 5: https://redirect.github.com/vercel-labs/skills
- 6: https://github.com/vercel-labs/skills/tree/main
- 7: https://github.com/vercel-labs/skills
Update the install command syntax to match the skills CLI documentation.
The skills CLI on npm does exist and supports installing from GitHub repos, but the syntax in the README is incorrect. The CLI uses shorthand format npx skills add owner/repo, not owner/repo/skills/<name>. For installing a specific skill, use npx skills add NutraForgeTechnologies/agents --skill <skill-name> or reference the full repo path. Update the table entry to reflect the correct documented usage.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@README.md` around lines 11 - 12, Update the README table entry for "Skills"
and "Skill packs" to use the documented skills CLI syntax: replace the incorrect
`npx skills add NutraForgeTechnologies/agents/skills/<name>` example with the
shorthand `npx skills add owner/repo` and add the variant for installing a
specific skill from the NutraForgeTechnologies repo using `npx skills add
NutraForgeTechnologies/agents --skill <skill-name>` (or reference the full repo
path); update both the "Skills" and "Skill packs" rows to reflect this correct
usage.
| ## Development | ||
|
|
||
| See [CONTRIBUTING.md](./CONTRIBUTING.md) for guidelines. | ||
| ```bash | ||
| bun install # install workspace dependencies | ||
| bun run lint # Biome check | ||
| bun run typecheck # tsc --noEmit | ||
| bun test # bun test (vitest/bun test in packages) | ||
| ``` |
There was a problem hiding this comment.
Development section contradicts the actual scripts in package.json.
The comments here claim bun run typecheck runs tsc --noEmit and bun test runs package tests, but the scripts in package.json are currently echo stubs. A reader copy-pasting these commands will believe typecheck/tests are passing when nothing is being checked. Either align the comments with the stub reality, or (preferred) flip typecheck to a real tsc -p tsconfig.json --noEmit (it's a valid no-op against "files": []) so the docs stay truthful.
📝 Minimal doc-only fix
bun install # install workspace dependencies
bun run lint # Biome check
-bun run typecheck # tsc --noEmit
-bun test # bun test (vitest/bun test in packages)
+bun run typecheck # stub until first package lands
+bun test # stub until first package lands🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@README.md` around lines 52 - 59, The README's Development section claims real
typecheck/test commands but package.json currently contains echo stubs; update
package.json so the "typecheck" npm script runs a real TypeScript check (e.g.
set "typecheck" to "tsc -p tsconfig.json --noEmit" so it’s a no-op against an
empty files list) and change the "test" script from the echo stub to the actual
test runner used by the repo (e.g. "bun test" or "vitest" as appropriate); then
ensure the README Development commands match those real scripts ("bun run
typecheck" and "bun run test") and that tsconfig.json exists/points at the
correct project config.
| **Rules:** | ||
| - `name` (required) — 1-64 chars, lowercase + hyphens only, must match the directory name | ||
| - `description` (required) — 1-1024 chars | ||
| - `license`, `metadata`, `compatibility`, `allowed-tools` — optional |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
Anthropic Claude Agent Skills SKILL.md frontmatter name and description validation rules
💡 Result:
Anthropic Claude Agent Skills use SKILL.md files with YAML frontmatter at the top. The core fields are name and description, following the Agent Skills open standard with Anthropic-specific extensions. name (optional, recommended): - Max 64 characters - Lowercase letters (a-z), numbers (0-9), hyphens (-) only - No leading/trailing hyphens, no consecutive hyphens (--) - Defaults to directory name if omitted - Cannot contain reserved words like "anthropic" or "claude" - No XML tags (< >) description (required/recommended): - Non-empty - Max 1024 characters - Describes what the skill does AND when to use it (e.g., trigger phrases) - No XML tags - Used by Claude for automatic invocation; should use third-person verbs - Truncated at ~1536 chars in listings Validation occurs via Claude Code's validator, which enforces the open standard fields (name, description, compatibility, license, metadata) but may warn on Claude-specific extensions like allowed-tools. Official sources confirm these rules in Claude API docs, Claude Code docs, and agentskills.io spec.
Citations:
- 1: https://platform.claude.com/docs/en/agents-and-tools/agent-skills/best-practices
- 2: https://platform.claude.com/docs/en/agents-and-tools/agent-skills/overview
- 3: https://agentskills.io/specification
- 4: https://code.claude.com/docs/en/skills?835f38dd_page=2
- 5: https://code.claude.com/docs/en/skills?target=_blank
Update README.md rules to match Anthropic's published SKILL.md constraints.
The stated limits are correct (name 1–64 chars, description 1–1024 chars), but the name rule is incomplete. Anthropic's spec requires lowercase letters, digits, and hyphens only—and forbids leading/trailing hyphens and consecutive hyphens. The current rule "lowercase + hyphens only" permits invalid formats like -foo- or --.
Tighten the guidance to: ^[a-z0-9]+(-[a-z0-9]+)*$ so your CI validator has a precise spec to enforce.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@skills/README.md` around lines 53 - 56, Update the `name` rule in the Skills
README so it allows lowercase letters, digits, and hyphens but forbids
leading/trailing or consecutive hyphens; replace the current "lowercase +
hyphens only" guidance for `name` with the precise regex constraint (e.g., use
the pattern ^[a-z0-9]+(-[a-z0-9]+)*$) so the `name` field description matches
Anthropic's SKILL.md and can be enforced by CI.
1 participant
Summary
Restructure the repo from single-package scaffold → minimal Bun workspace monorepo + Claude Code plugin marketplace skeleton. Five deliverable channels (skills, skill packs, plugins, MCP servers, CLIs) with living docs per directory. No published modules yet — next PRs port specific skills from
~/.claude/skills/intoskills/.workspaces: ["packages/*"]topackage.json; dropsrc/exports blockskills/ plugins/ agents/ packages/each with a livingREADME.md(frontmatter spec + recipe).claude-plugin/marketplace.jsonstub (marketplace name:solenix-agents, empty plugins array)AGENTS.mdfor agent-facing repo guidanceREADME.mdas 5-channel indexCONTRIBUTING.mdwith add-a-thing recipes + curated-maintainer posturetsconfig.json; stubtypecheck+testscripts until the first package landssrc/treeTest plan
bun installcleanbun run lintpasses (Biome)bun run typecheckpasses (stub)bun run testpasses (stub)README.md→ understand the 5 channelsOut of scope (next)
~/.claude/skills/🤖 Generated with Claude Code
Summary by CodeRabbit
New Features
Documentation