用途：为 GitHub 仓库搭建结构化的贡献收集层，把「坏了，请修」这类模糊反馈变成可执行的 Issue 报告。
主要能力：在 .github/ISSUE_TEMPLATE/ 下生成 Issue 表单，例如 bug_report.yml（版本与复现步骤为必填、按需环境下拉、日志用 render: shell、自动打 bug 标签）和 feature_request.yml（先问问题与动机再谈做法、标签 enhancement）；生成 config.yml，设置 blank_issues_disabled: true，并用 contact_links 把提问路由到 Discussions/SUPPORT、把安全问题路由到私密报告；生成单个 .github/PULL_REQUEST_TEMPLATE.md，含简短可执行清单（跑过测试、更新文档、关联 Issue、不提交 .local/密钥文件）；创建表单引用的标签，包括 good first issue 与 help wanted。
使用方式：先阅读 references/issue-forms-reference.md 获取准确 schema 与带注释示例，不要凭记忆写表单。仅该目录下的 .yml/.yaml 会渲染，且表单只在默认分支生效。校验用 bash "${CLAUDE_SKILL_DIR}/scripts/validate_forms.sh"，脚本用 check-jsonschema --builtin-schema vendor.github-issue-forms 校验每个表单，schema 违规即失败。
限制：CONTRIBUTING/SECURITY/SUPPORT 等文字文件、已有 Issue 的分诊与关闭、stale-bot 自动化、合并前的审查/检查要求、Discussions 本身的配置均不在范围内（链接到 Discussions 属于范围内）。config.yml 不是 Issue 表单，schema 不同，不应交给表单校验器。表单不渲染通常依次是目录错误、用 .md 而非 .yml、不在默认分支、schema 违规。多 PR 模板时 GitHub 无选择界面，需用 ?template=name.md 查询参数，建议保留一个默认模板。必填项应限于报告者能回答的内容。规模要匹配：每月仅两三个 Issue 的个人项目最多用一个 bug 表单即可。