mirror of
https://github.com/alirezarezvani/claude-skills.git
synced 2026-10-08 03:07:51 +00:00
1851c8fb09
Same root cause as #587/#591 — Claude Code's runtime loader rejects array-form skills paths like ["./content-production", "./ai-seo", ...] even when each entry is a valid subdirectory containing SKILL.md. `claude plugin validate` accepts them but the loader does not. The proven canonical layout (used by self-improving-agent in #536): <plugin>/ ├── .claude-plugin/plugin.json skills: "./skills" └── skills/ ├── <skill-1>/SKILL.md ├── <skill-2>/SKILL.md └── ... Restructured 9 multi-skill domain plugins: - business-growth (4 skills moved) - c-level-advisor (28) - engineering (36) - engineering-team (32) - finance (2) - marketing-skill (43) - product-team (12) - project-management (8) - ra-qm-team (13) Also fixed standalone plugins that had root SKILL.md + ./skills/ subdir (agenthub, autoresearch-agent, executive-mentor, playwright-pro). The loader rejected them despite skills="./skills" because of the conflicting root SKILL.md (compare self-improving-agent which works because PR #536 moved its root SKILL.md). Moved each root SKILL.md into ./skills/<name>/. Restored standalone plugin folders to their original paths after the multi-skill restructure swept them into parent skills/ directories (marketplace.json source paths require original locations). Removed 7 orphaned marketplace entries that pointed to skill folders without their own plugin.json (content-creator, demand-gen, fullstack-engineer, aws-architect, product-manager, scrum-master, skill-security-auditor) — these were already non-functional. Bumped patch versions on every changed plugin and synced marketplace.json. Marketplace now lists 29 working plugins (down from 36). After merge: users run `/plugin marketplace update claude-code-skills` followed by `/plugin update --all` to pick up the working layout.
34 lines
867 B
Markdown
34 lines
867 B
Markdown
# OpenAPI Extraction Guide
|
|
|
|
## Goal
|
|
|
|
Turn stable API operations into stable MCP tools with clear names and reliable schemas.
|
|
|
|
## Extraction Rules
|
|
|
|
1. Prefer `operationId` as tool name.
|
|
2. Fallback naming: `<method>_<path>` sanitized to snake_case.
|
|
3. Pull `summary` for tool description; fallback to `description`.
|
|
4. Merge path/query parameters into `inputSchema.properties`.
|
|
5. Merge `application/json` request-body object properties when available.
|
|
6. Preserve required fields from both parameters and request body.
|
|
|
|
## Naming Guidance
|
|
|
|
Good names:
|
|
|
|
- `list_customers`
|
|
- `create_invoice`
|
|
- `archive_project`
|
|
|
|
Avoid:
|
|
|
|
- `tool1`
|
|
- `run`
|
|
- `get__v1__customer___id`
|
|
|
|
## Schema Guidance
|
|
|
|
- `inputSchema.type` must be `object`.
|
|
- Every `required` key must exist in `properties`.
|
|
- Include concise descriptions on high-risk fields (IDs, dates, money, destructive flags).
|