指导开发者新增可持久化的业务记忆类型:按需选择 Markdown、SQLite 和 LanceDB,确定 Markdown 文件策略,再配置所需的架构、仓库和写入器。
- 新增可持久化的业务记忆类型
- 设计存储层组合
- 连接 Markdown 原文与检索索引
检查当前 Git 改动和近期提交记录,再按 Conventional Commits 格式创建聚焦的提交。可只暂存相关文件,并处理钩子检查失败的问题。
Stage and create a Conventional Commits message for the current change
实测评分 未实测
查看安装方法检查当前改动、已暂存的差异和近期提交记录,然后指导创建一个聚焦于单项逻辑改动的提交。提交说明遵循 Conventional Commits 格式,包括 feat 或 fix 等类型、可选范围,以及简短的改动摘要。重大变更和相关议题可写在正文或页脚中。如果工作区混有无关改动,只暂存属于本次提交的文件。
提交前想检查差异并与现有提交记录的写法保持一致时,可以使用此技能。如果提交说明会由钩子检查,或需要避免将不同改动误放进同一提交,也适合使用。
commit-msg 钩子使用 gitlint 检查提交说明。不要使用 --no-verify;钩子失败时应修复原因后重新提交。不要将机密、生成文件或尚未完成的改动直接提交到受保护的 main 分支。
本介绍由 AI(OpenAI Codex)根据公开的 SKILL.md 撰写。准确的规格请查看下方原文。
AI 根据 SKILL.md 的内容检查了需要注意的操作和使用前提。评分只依据实际运行的结果(实测对比)。
不计入评分。 由 AI(OpenAI Codex)于 2026年10月29日 评估。仅供参考,安装前请同时查看原文。
安装前可以查看交给 AI 代理的指令内容。
Create a well-formed commit following the Conventional Commits
standard. The format is enforced by gitlint in the commit-msg hook.
Run git status and git diff (and git diff --staged) to see what changed.
Review recent history for style: git log --oneline -10.
Group the change into a single focused commit. If the working tree mixes
unrelated changes, stage selectively (git add -p / specific paths) rather
than committing everything at once.
Write the message in Conventional Commits form:
<type>[(scope)][!]: <imperative summary, ≤72 chars>
<optional body: what & why, wrapped at 72>
<optional footer: BREAKING CHANGE: …, Refs: #123>
Never use --no-verify. If pre-commit hooks fail, fix the cause and re-commit.
Do not commit secrets, generated artifacts, or work-in-progress directly to
the protected main branch.
| Type | Use for |
|---|---|
feat | new feature |
fix | bug fix |
refactor | behavior-preserving restructure |
test | add / update tests |
docs | documentation |
style | formatting only |
perf | performance |
chore | config / build / tooling |
build | build system or dependencies |
ci | CI configuration |
revert | revert a previous commit |
type.scope is optional: fix(search): …. A ! before the colon (or a
BREAKING CHANGE: footer) marks a breaking change.还没有评价。欢迎分享你的使用感受。
无需登录即可发表。欢迎分享使用感受、提问,或说明在哪些环境下无法运行。
还没有评论。来写第一条吧。
指导开发者新增可持久化的业务记忆类型:按需选择 Markdown、SQLite 和 LanceDB,确定 Markdown 文件策略,再配置所需的架构、仓库和写入器。
在更新后的 `main` 分支上创建用途明确的 Git 分支,并按改动类型选择前缀,如功能、修复、文档、CI、维护或重构,再添加简短的小写连字符名称。
使用 GitHub CLI `gh`,按仓库模板将当前分支的改动提交为面向 `main` 的拉取请求。创建前运行 `make ci`,通过后推送分支并填写改动摘要、所属领域、验证结果、检查清单和审阅备注。
指导将 everos 新版本发布到 PyPI,包括更新版本号和变更日志、创建触发自动工作流的标签,并完成审批。工作流上传后,还需检查并发布 GitHub Release 草稿。