بنقرة واحدة
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='表用途说明';