一键导入
mysql-ddl-conventions
MySQL 建表与字段规范(面向文档解析/任务类业务)。统一命名、索引、字段类型、时间戳、引擎字符集与注释要求,便于研发与 DBA 评审落地。
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
MySQL 建表与字段规范(面向文档解析/任务类业务)。统一命名、索引、字段类型、时间戳、引擎字符集与注释要求,便于研发与 DBA 评审落地。
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
契约治理三件套的「值层」。核对同一个物理契约值(MQ topic/group、OSS bucket、消息字段名/别名、内部 HTTP 路径等)在 .env/.env.example/代码生效点/Java 对端多处是否逐字相等,找出配置漂移与死值,防止消息收不到/文件取不到。本 skill 只比对「同一个值在多处是否一致」,不判断结构/语义是否破坏对端(那是结构层,转 contract-guard),也不改文档。
指导 LLM 如何使用 toLink-Rag 项目的 MQ 消息中台进行消息收发、定义新消息类型以及处理多厂商适配逻辑。
当用户认为当前模块代码实现完毕,且当前分支应为 dev,需要从 dev 基于当前修改创建规范分支、提交并发起合并到 dev 的 GitHub PR 时使用;也用于发布收口,即直接创建 dev -> master 的 release PR,不新建 release 分支。适用于“从 dev 新建分支”“把当前修改提 PR”“实现完成创建 feature/refactor 分支并 PR”“发布新版本”“dev 合并 master”等交付收口场景。本 skill 是交付链终点,并在建分支/提 PR 前执行收口门槛:测试未过、契约文档失同步、acceptance 未提升者拒绝收口。
当用户要求把需求、功能、技术方案、架构改造、故障复盘、项目治理实践或实现过程写成博客/技术文章时必须使用;尤其适用于“写一篇博客”“生成技术博客”“把这个需求写成文章”“根据这个功能写博客”“把项目实现讲清楚”等请求。使用时要基于用户给出的需求和 toLink-Rag 当前仓库的真实代码、文档、契约、配置与测试证据完成分析,默认输出 Markdown 到 `.specs/blog/《博客名称》.md`。文章须采用「少量
把项目里已有的内部组件(如 MQ 中台、解析 pipeline、缓存层、对象存储)抽象成一份「项目自有 skill」,让 AI 每次接入都自动复用该组件的架构边界与约定。读组件真实代码,提炼「架构定位 / 职责边界 / 已落地清单 / 扩展点 / 红线」五要素,按统一原型生成 SKILL.md,登记到 .ai/skills/README.md 注册表并跑校验。
当用户要提 issue、登记 bug、记录新需求时使用;自动识别所属项目,生成结构化 issue 内容,先在 Linear 建主记录、再在 GitHub 建镜像,并双向回链。用户说"提个 issue""记一下这个 bug""把这个需求登记一下""同步到 Linear 和 GitHub""别再依赖 Linear 自动同步"时都应触发,即使没有明确说出"Linear"或"GitHub"。
| name | mysql-ddl-conventions |
| description | MySQL 建表与字段规范(面向文档解析/任务类业务)。统一命名、索引、字段类型、时间戳、引擎字符集与注释要求,便于研发与 DBA 评审落地。 |
| when_to_use | 当用户要求设计新的数据库表、编写 DDL 语句、补充字段约束、添加索引、优化表结构或统一建表规范时激活。触发示例:'帮我设计一个XXX表'、'写个建表语句'、'这个表需要加什么索引'、'DDL怎么写' |
_ 分隔(snake_case),例如 file_type、markdown_content。PRIMARY KEY,无需额外命名。idx_ 开头,后接字段名,例如 idx_document_id。uk_ 开头,后接字段名,例如 uk_task_id。document_id、status、created_atcreated_at / updated_atPRIMARY KEY),避免写入性能下降与维护复杂度上升。EXPLAIN 为准):
DATE(created_at)、LOWER(col))。% 开头的模糊匹配(如 LIKE '%xxx')导致无法走索引。OR 条件容易导致索引选择不佳,必要时拆分查询或改写为 UNION ALL。VARCHAR(36) 存储 UUID,适合分布式生成、跨系统对齐与避免 ID 暴露。BIGINT AUTO_INCREMENT,适合强依赖数据库自增、有序写入与高频 join 场景。NOT NULL:
VARCHAR 存储具有明确语义的英文状态词(如 PENDING、SUCCESS),提升可读性与扩展性。VARCHAR(20)),并在业务初始化时设置 DEFAULT(例如 DEFAULT 'PENDING')。INT NOT NULL DEFAULT 0,避免聚合运算时出现异常。page_count、time_cost_ms):
INT DEFAULT NULL,并在解析成功前保持为空,以区分“尚未计算”和“确认为 0”。LONGTEXT。DEFAULT NULL,业务写入前保持为空。所有业务表建议由数据库层自动维护创建/更新时间,降低应用侧时间维护成本:
created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMPupdated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP所有新表 DDL 尾部必须显式指定:
ENGINE=InnoDB(事务与锁支持)DEFAULT CHARSET=utf8mb4(Unicode/Emoji 兼容)COLLATE=utf8mb4_unicode_ciCOMMENT。status、type)必须在注释中列举所有可能值及含义。
COMMENT '状态:PENDING, PROCESSING, SUCCESS, FAILED'COMMENT,描述表的总体业务用途。当用户要求“生成建表语句/补齐字段约束/补齐索引与注释”时,按以下模板输出并据实填充:
CREATE TABLE `your_table_name` (
-- 主键二选一:UUID 或自增(按业务选择其一,不要同时存在)
-- `id` varchar(36) NOT NULL COMMENT '主键 UUID',
-- `id` bigint NOT NULL AUTO_INCREMENT COMMENT '主键自增 ID',
`status` varchar(20) NOT NULL DEFAULT 'PENDING' COMMENT '状态',
`created_at` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
`updated_at` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',
PRIMARY KEY (`id`),
-- 业务索引示例(按真实查询模式选 3-5 个即可)
KEY `idx_status` (`status`),
KEY `idx_document_id` (`document_id`),
KEY `idx_created_at` (`created_at`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci
COMMENT='表用途说明';