云看板 breakstring/cfKanban

cfKanban

cfKanban 是一套面向 Agent 协作方式的轻量自托管 Kanban。你让 Agent 部署和操作它；同一个 Cloudflare Worker 也会提供可供人类直接使用的中英双语 Web 看板。

核心只需要一个 Cloudflare Worker 和一个 D1 数据库；Issue 附件可选用私有 R2 存储。不需要独立服务器、Pages project 或 KV namespace。公共 CLI 复用 Skills runtime 和 Service 规则。

看看它如何工作

https://github.com/user-attachments/assets/94b3d30b-a1a7-4ad2-9924-838a8317d3bb

正式发行

首次安装和新部署默认使用最新正式发行。你不需要选择或填写版本号；Agent 从官方稳定发行入口发现版本，校验并固定准确工件后，再准备安装或部署计划。已有可信且兼容的 Skills 可以继续复用，加入项目不会顺带升级服务器。

本地技能更新与云端实例升级是独立动作。测试版、历史版和源码开发仅在明确选择时使用；稳定发行不可用或校验失败时，Agent 会说明原因，不会改用开发快照。

发行压缩包不包含 Node.js 可执行程序。Skill bundle 包含四个 Skills 和共享 JavaScript helper modules，由用户已有的兼容 Node.js 运行；支持公共 CLI 的发行还包含其预构建入口。Service bundle 包含构建后的 Worker、Web assets、migrations、contracts 和 Wrangler 配置骨架。Agent 会根据获准计划生成私有配置，普通用户无需手动解压或修改工件。

CLI 任务指南介绍终端使用、安装、日常、管理与部署。CLI 正在本源码分支准备，命令是否可用需核对实际安装的已验证发行；本地 CLI 更新和 Instance 升级分别执行。

你需要准备什么

在支持的 Agent 宿主中使用需要：

- 能够加载 Skills、读取 HTTPS 文档并运行本地 Node.js 脚本；
- 兼容的 Node.js 环境，以及可持久保存身份的私有存储；
- 能够访问官方发行下载；使用 Git 来源安装时还需要 Git 访问能力。

Agent 按当前宿主支持的 Skill 目录或插件机制安装。部分宿主需要安装后新开会话才能加载技能。

自行部署到 Cloudflare 时还需要：

- 一个有权创建一个 Worker 和一个 D1 数据库的 Cloudflare 账户；
- 兼容的 Node.js 与 Wrangler 环境。cfkanban-deploy 会先检查已有工具；Wrangler 不可用时，只有在展示并获得独立安装计划授权后，才能把固定版本的 Wrangler package 安装到 ~/.cfkanban/tool-runtime/。它不会内嵌或安装 Node.js；
- 你希望 cfKanban 使用的 Owner display name。Agent 不能从操作系统账号或 Git identity 猜测这个名称。

安装 Skills

把下面这句话交给你的 Agent：

请阅读 https://github.com/breakstring/cfKanban/releases/latest/download/install.zh-CN.md，为我安装 cfKanban 最新正式发行的 Skills。

Agent 会识别当前宿主、检查已有安装，并解释所需本地变更。支持兼容 Git plugin 或 marketplace 来源的宿主，可以跟随只承载已公开正式发行的默认 main 分支；Codex 是其中一个例子，普通安装不传 --ref。通过本地 Skill 目录加载的宿主，安装包含共享 runtime 的完整已验证 bundle。两种方式都须核对所选发行和实际安装文件。安装本身不会部署或升级 Cloudflare 实例，也不授予应用权限。

如果 Git 来源安装固定在旧 tag，让 Agent 将已注册来源切换到默认分支，再更新宿主安装。只修改复制的命令不会改变已保存设置；本地目录安装继续使用 bundle 更新流程。保留私有 .cfkanban/ 身份和部署记录。两种安装都不会因发布了新版而自动更新，提出更新请求后，再按宿主要求刷新或新开会话。

cfKanban 包含四个 Skills：一个入门指南和三个操作技能：

| Skill | 适合交给它的任务 |
| $cfkanban-howto | 先了解日常使用、Owner 管理和部署分别能做什么，以及应该如何提问。 |
| $cfkanban | 加入 Project，并处理 Issue、Comment 和 Web 看板中的日常工作。 |
| $cfkanban-admin | 创建看板，以及管理 Project、邀请、访问权限和 Owner 设置。 |
| $cfkanban-deploy | 部署、更新、续做或恢复一套 cfKanban。 |

通常你只需用自然语言告诉 Skill 想做什么。内置 .mjs 命令是 Agent 使用的确定性工具，普通用户无需手工运行。

安装后：先用 Howto 了解怎么使用

宿主加载技能后，建议先让只读使用指南带你入门：

请使用 $cfkanban-howto 介绍 cfKanban 怎么用、我的需求应该交给哪个技能，并给我几个可以直接使用的例子。

也可以问得更具体：“我已经加入一个项目，怎样查看我的任务、创建 Issue、修改状态和添加评论？”Howto 会解释可用操作并推荐下一步使用的技能；询问使用方法不会执行这些操作。

随后按自己的情况继续：

- 收到已有项目的邀请：按加入步骤操作，不需要自行部署 Cloudflare。
- 已经有项目访问权限：让 $cfkanban 查看某个项目中自己未完成的任务，或打开看板。
- 希望自己托管实例：按部署步骤操作，再以 Owner 身份创建第一个看板。

Howto 是推荐的入门入口，不是必经的初始化步骤；如果已经知道要做什么，可以直接使用对应操作技能。更多例子见 Agent Skills 指南。

让 Agent 帮你部署

技能加载后，只说这一句话就够了：

请使用 $cfkanban-deploy 为我部署一套 cfKanban。

你不需要理解或说出 manifest、digest、preflight、deployment plan、migration、rollback journal 这些术语。Skill 会自动完成这些工作：先做只读检查，用普通语言告诉你当前能做什么、还缺什么，只询问真正缺少的信息，并在安装或部署任何内容前展示准确影响。

如果需要登录 Cloudflare，Skill 会把它作为一份独立的小计划展示；获批后再打开对应的浏览器或 device flow。完成登录不会创建 Worker 或 D1 数据库，真正的部署计划仍会在后面单独请求确认。

Agent 默认发现最新正式发行，在计划中固定准确版本、来源和摘要；执行途中不会因出现新版而更换目标。

需要完整的逐步路径时，请把部署指南交给 Agent。它会明确说明 Skill 安装、环境检查、授权、部署、读回和恢复，不要求 Agent 从这份通用 README 自己猜流程。

部署 Skill 会替你处理什么

Skill 负责：

1. 确认准确的发行版本，并检查文件没有被替换；
2. 检查当前电脑，尽量复用已有的兼容 Node.js 与 Wrangler；
3. 优先复用 journal/receipt 中的准确认证目标，或让 Wrangler 解析当前私有部署/config 上下文；只有用户明确指定时才考虑其他 profile，并由私有配置固定准确 account；
4. 在请求确认前，说明会创建哪些资源、修改哪些本地内容、可能的费用和恢复边界；
5. 获得确认后才创建一个 Worker、一个 D1 数据库和内置 Web 应用；
6. 完成后读回验证，再报告部署成功。

默认计划只在 workers.dev 创建一个 Worker 和一个 D1。custom domain、付费服务、破坏性 migration、资源接管或替换，以及权限变化都必须生成新的明确计划并重新授权。

得到第一个真正可用的看板

部署验证完成后，可以新建任务或继续使用已安装的 Skills：

1. 让 $cfkanban-admin 验证 Owner identity，按你选择的显示名称创建一个 Workspace、一个 Project，读回两者，再创建 Owner Web launch。
2. 专用 launch 命令默认直接打开看板，不返回一次性 URL。长期 Credential 不会进入浏览器或 URL。
3. 让 $cfkanban 创建第一条 Issue，或直接通过 Agent 在这个 Project 中工作。
4. 需要其他人或 Agent 加入时，让 $cfkanban-admin 创建邀请，并明确目标 Project 和 reader 或 writer 权限；专用命令默认把一次性话术复制到剪贴板，不写普通 stdout。

给用户的提示词仍然可以很短：

请使用 $cfkanban-admin 创建我的第一个 cfKanban 看板。

Skill 会验证 Owner，询问还缺少的 Workspace 与 Project 显示名称，说明每次写入、读回结果，然后提供 Web 看板入口。

加入别人已有的 cfKanban Project

安装或复用 Skills，让宿主完成加载，然后把一次性 Invite URL 交给你的 Agent：

加入指南同时覆盖尚未安装 Skill 的接收方，并分别说明 Project Invite 与 Public Join 路径。

请使用 $cfkanban 加入这个 Project：<邀请链接>

Skill 会先检查邀请，说明要加入的 Project 和权限，并且只在缺少信息或需要确认时询问你。条件允许时，它会复用你在该实例已有的身份；否则只询问显示名称，把 pending Credential 直接写入私有本地状态，兑换 Invite，验证 /api/v1/me，并且只在读回匹配后提升 Credential。不要把长期 Credential 粘贴进聊天、环境变量、命令参数、代码仓库或浏览器存储。

本地数据与安全边界

cfKanban 自己拥有的持久本地数据统一使用当前执行环境用户的私有目录：

~/.cfkanban/
instances/ # trusted instance metadata、Credentials、journals、receipts service-releases/ # verified immutable Service deployment bundles skill-releases/ # verified immutable Skill releases 与 active pointer tool-runtime/ # 隔离的固定版本 Wrangler package；不包含 Node.js runtime

宿主发现入口、marketplace 配置和 plugin cache 仍放在对应 Agent 宿主管理的目录；它们是可丢弃的宿主投影，不是 cfKanban 状态，也不是 canonical release 真相源。Windows 原生和 WSL2 使用各自独立的用户目录，绝不自动混用。

参与开发

源码开发与测试环境

main 保持在已公开正式发行的 commit。开发使用 feat/ 或 fix/ 分支，直接在项目主目录切换分支即可，额外 Git worktree 是可选项。从开发分支发布准确 RC，在测试实例验收；之后构建并发布正式工件，校验通过后再将 main 推进到同一正式 commit。

日常开发技能时，让 Agent 读取当前分支的 SKILL.md，并从该 checkout 执行脚本。指引修改后重新读取；源码编辑不会自动刷新已安装技能或当前任务。需要验证宿主发现与加载时，按该宿主支持的本地目录布局加载，或临时把现有插件来源切到准确 checkout；两种方式都保留共享 runtime 和相对路径。

对于支持 plugin 的 Codex，本地安装示例如下：

cd /absolute/path/to/cfKanban
codex plugin marketplace add .
codex plugin add cfkanban-agent-skills@cfkanban

在 Codex 中，若已注册 cfkanban，先核对来源，按支持的来源切换流程处理，再执行上述命令，不得静默覆盖。宿主加载测试结束后，恢复原来的正常安装或其已验证正式更新；没有插件机制的宿主使用自己的 Skill 发现方式，不需要单独的开发插件。

源码测试记录分支、commit 和未提交状态。开发 checkout 或本地修改不代表已验证发行；main 作为分发来源，其实际安装内容仍须与所选已公开发行匹配。测试版或历史版必须明确选择，已发布 tag 和工件不可覆盖。当前 Skill 不提供冻结源码事实的远端部署计划，源码评估应在 Cloudflare 写入前停止。

本项目采用本地隔离开发环境，并将 cfkanban.dev 作为持久的公开测试、演示和自用实例。网站可以运行测试版；GitHub stable 仍是用户自行部署的推荐发行。演示站中的真实数据继续遵循原有迁移、权限与恢复保护，仅创建测试 Project 不能隔离部署或迁移。维护者可以使用仅在本仓库提供的 project-release 技能准备发行，并在授权范围内升级网站。同一套兼容 Skills 可以操作多套明确选择的实例。

按准确 lockfile 安装依赖并运行完整仓库验证：

npm ci
npm run validate

npm run validate 包含 typecheck、单元与集成测试、OpenAPI/error 检查、生成物漂移检查、本地 D1 验证、无 Credential 的 CI policy 检查、Web build 和 Worker dry-run build。它不会登录 Cloudflare，也不会写入远端资源。

源码维护者发布 GitHub 附件时，使用Release 发布与中断恢复流程。该工具先验证 draft，再单独公开；它不是用户部署或 Skill 更新入口。

建议从文档导航、产品简报、用户 Storyboard、Agent Skills 指南和实施计划开始；冻结的技术合同位于 docs/specs/。

友情链接