Communitygithub.com

niksavis/basicly

一个编码智能体框架,不仅传递指令,还传递工作流与状态:将单个YAML目录投射到每个智能体的原生配置中,结合确定性循环、工作树隔离与串行合并队列,并在提交时强制执行门控。

basicly 是什么?

basicly 是一个面向编码智能体的框架,它强调工作流与状态的传递,而不仅仅是指令。其核心概念是将一个集中的YAML目录映射到每个智能体(如Claude Code、Cursor等)的原生配置中,从而实现配置的标准化和可移植性。它定义了一个确定性的执行循环,包含工作树隔离和串行合并队列,确保变更安全、有序地集成。门控机制在提交时自动检查,例如Node.js环境的一致性(如WSL下的非交互式shell问题)和npm依赖的规范性,从而防止因环境差异导致的构建失败。basicly 适用于追求高效、可靠、可复现的编码流程的开发团队,尤其适合需要管理多个智能体并确保代码质量一致性的场景。该框架通过自动化工作流和强制性的检查,减少了人工干预,提高了开发效率。

兼容平台~Claude Code~Codex CLI~Cursor
npx skills add niksavis/basicly

在你喜欢的 AI 中提问

打开一个已预加载此 Agent Skill 的新对话。

文档

Node

本仓库中的 Node 使用范围很窄,但至关重要:markdownlint git 钩子运行 npx --no-install markdownlint-cli2,解析 package.json / package-lock.json 中锁定的 markdownlint-cli2 devDependency。如果 PATH 上指向了错误的 Node,该钩子就会失败并阻止提交。

WSL 非交互式 shell 陷阱(最容易踩的坑)

登录 shell 会加载你的 profile,从而加载版本管理器(nvm)并将仓库的 Node 添加到 PATH。 而非交互式 shell——脚本、后台任务、由无头智能体启动的 git 钩子——不会加载该 profile, 因此 npx/node 可能会解析到通过 WSL 互操作访问的 Windows Node 安装,而不是 Linux 版本。 随后,markdownlint(以及任何基于 Node 的钩子)会在错误的 Node 下运行,或者直接失败—— 这种情况只会在脚本和后台任务中发生,而你直接在终端提交时永远不会遇到。

修复方法:在通过脚本或后台任务提交或推送之前,将仓库的 Node 添加到 PATH 上。 具体方法详见 references/wsl-node-path.md。

npm 卫生

  • 使用 npm ci(而非 npm install)从 package-lock.json 进行可重现的安装;将 lockfile 与任何依赖变更一起提交。
  • npx --no-install <tool> 运行已锁定的本地 devDependency,并拒绝静默地从网络获取不同版本——请保留 --no-install。
  • 保持 Node 占用最小化:本仓库有意只提供一个 devDependency。添加依赖是一项需要确认的变更,而非本能反应。

相关技能