菜单
Use when a new feature, improvement, or breaking change has been implemented. Adds an entry to docs/releases/ so it appears in the in-product admin changelog.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Scaffold a new AI app config JSON file in contents/apps/ that passes the project's Zod schema validation. Use when creating a new AI application for the iHub platform.
Guide for securing API endpoints with proper input validation, path traversal prevention, and parameter sanitization. Auto-invoked when working on route handlers or API endpoints.
Analyze a codebase and recommend Claude Code automations (hooks, subagents, skills, plugins, MCP servers). Use when user asks for automation recommendations, wants to optimize their Claude Code setup, mentions improving Claude Code workflows, asks how to first set up Claude Code for a project, or wants to know what Claude Code features they should use.
Create a new versioned config migration in server/migrations/ following the project's Flyway-style pattern. Use when adding new required/default fields to config files, renaming/restructuring fields, or adding default entries to providers.json, groups.json, tools.json, sources.json, etc.
Produce deep, long-form blog posts (1,800–2,500+ words) by interviewing the user first, researching the topic, architecting the structure, then writing. Use this skill whenever the user wants to create a blog post, write an article, draft a long-form piece, or asks for help turning their expertise into written content. Also trigger when the user says things like "help me write about," "I want to blog about," "turn this into a post," "ghostwrite," "interview me," or "write-up." Do NOT use for short social media posts, email drafts, or documentation — only for substantive blog-style content.
| name | document-feature |
| description | Use when a new feature, improvement, or breaking change has been implemented. Adds an entry to docs/releases/ so it appears in the in-product admin changelog. |
| user-invocable | true |
When a feature, improvement, or breaking change is implemented, add an entry to the appropriate
Markdown file under docs/releases/.
Read the current version from server/package.json → version field.
If the version contains a build suffix (e.g. fix-issue-1137-lVuXg) look for the nearest clean
semver tag in the git log: git tag --sort=-version:refname | head -5.
Use the highest existing docs/releases/ subdirectory name as a fallback.
docs/releases/{version}/
features.md New capabilities (admin-facing and end-user-facing)
breaking-changes.md Changes that require admin action after upgrade
If the version directory does not exist yet, create it and both files with an empty heading:
# Features — {version}
# Breaking Changes — {version}
Each entry is a ## level heading. Keep it product-oriented — what changed and what it enables,
not implementation details.
## Short Title
One or two sentences describing what this does and why it matters to admins or users.
- Key detail 1
- Key detail 2
**Before upgrading:** Migration step if any (breaking changes only).
Include a configuration or API example only when admins need to take action.
features.md for that version to avoid duplication.## entry to the appropriate file.Use this skill proactively whenever you implement:
Skip for: pure refactors with no visible behavior change, dependency bumps, test additions, comment/documentation-only changes.