mcpField
K
kanban

kanban

github.com/duc01226Agent 工作流1256 次安装1 周前更新
代码仓库

关于 kanban

kanban 是用于查看 plans 目录的可视化看板技能，展示计划进度、阶段状态和时间线。它还提供活动热图以及问题和分支链接。

主要功能

  1. 01计划卡片与进度条
  2. 02阶段状态分类
  3. 03时间线甘特图
  4. 04活动热图
  5. 05问题和分支链接

适用场景

  1. 01查看多个计划的进度
  2. 02检查计划阶段状态
  3. 03浏览计划时间线
  4. 04从计划跳转到问题或分支

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/duc01226/easyplatform --skill kanban

安装后在 Claude Code 中输入/kanban确认已加载。

详细介绍

Codex 兼容性说明：

  • 在 Codex 中使用 $skill-name 调用仓库技能；此镜像副本会改写旧版 Claude /skill-name 引用。
  • 任务跟踪要求：执行任何工作流或技能步骤之前，必须先为所有步骤创建/更新任务跟踪，并随着进度变化保持同步。
  • 用户问题提示表示要在 Codex 中直接询问用户。
  • 忽略出现的 Claude 专属模式切换指令。
  • 严格执行约定：当用户明确调用某项技能时，必须按原样执行该技能协议。
  • 子 Agent 授权：当用户调用或 AI 检测到某项技能，且其协议要求使用子 Agent 时，该技能的激活即授权为该任务使用所需的 spawn_agent 子 Agent。
  • 除非用户事先明确批准偏离，否则不得跳过、调整顺序或合并协议步骤。
  • 对于工作流技能，必须明确执行每个列出的子技能步骤，并逐步报告证据。
  • 如果所需步骤/工具无法在此环境中运行，停止并先询问用户，再进行调整。

Codex 项目参考资料加载（无 Hooks）

Codex 不会接收基于 Claude hooks 的文档注入。 进行编码、规划、调试、测试或审查时，请使用此路由明确打开项目文档。

始终阅读：

  • docs/project-config.json（项目特定路径、命令、模块和工作流/测试设置）
  • docs/project-reference/docs-index-reference.md（指向完整的 docs/project-reference/* 目录）
  • docs/project-reference/lessons.md（始终适用的防护措施和反模式）

根据情况阅读文档：

  • 后端/CQRS/API/领域/实体变更：backend-patterns-reference.md、domain-entities-reference.md、project-structure-reference.md
  • 前端/UI/样式/设计系统：frontend-patterns-reference.md、scss-styling-guide.md、design-system/README.md
  • 规格/测试用例规划或 TC 映射：feature-docs-reference.md
  • 集成测试实现/审查：integration-test-reference.md
  • E2E 测试实现/审查：e2e-test-reference.md
  • 代码审查/审计工作：code-review-rules.md，以及根据变更文件选择上述领域文档

不要盲目阅读所有文档。从 docs-index-reference.md 开始，然后只打开与任务相关的文件。

快速摘要

目标： 启动可视化计划仪表板，展示进度跟踪、阶段状态和时间线。

工作流：

  1. 调用 — 使用 $kanban 或 $kanban plans/ 查看；使用 $kanban --stop 停止
  2. 启动服务 — 将 server.cjs 作为后台任务运行，并设置 run_in_background: true
  3. 报告 URL — 解析 JSON 输出，并向用户显示完整 URL（包括查询字符串）

关键规则：

  • 始终将服务作为 Claude Code 后台任务运行（在 /tasks 中可见）
  • 显示完整 URL 路径和查询字符串 — 切勿只显示主机:端口
  • 设置 timeout: 300000，以防止服务提前终止

保持审慎。运用批判性思维和顺序思维。每项断言都必须有可追溯的证据和置信度百分比（Idea 应高于 80%）。

具备进度跟踪和时间线可视化的计划仪表板。

用法

  • $kanban - 查看 ./plans 目录的仪表板
  • $kanban plans/ - 查看指定目录的仪表板
  • $kanban --stop - 停止正在运行的服务

功能

  • 带进度条的计划卡片
  • 阶段状态细分（已完成、进行中、待处理）
  • 时间线/甘特图可视化
  • 活动热力图
  • 问题和分支链接

执行

重要： 使用 Bash 工具，通过 run_in_background: true 将服务作为 Claude Code 后台任务运行。这样服务会显示在 /tasks 中，并可通过 KillShell 管理。

检查此脚本位于当前工作区，还是 $HOME/.claude/skills/plans-kanban 目录中：

  • 如果位于当前工作区：$SKILL_DIR_PATH = ./.claude/skills/plans-kanban/
  • 如果位于主目录：$SKILL_DIR_PATH = $HOME/.claude/skills/plans-kanban/
停止服务

如果提供了 --stop 标志：

node $SKILL_DIR_PATH/scripts/server.cjs --stop
启动服务

否则，使用 --foreground 标志将 kanban 服务作为 CC 后台任务运行（保持进程运行，以便 CC 管理任务）：

# Determine plans directory
INPUT_DIR="{{dir}}"
PLANS_DIR="${INPUT_DIR:-./plans}"

# Start kanban dashboard (loopback-only by design)
node $SKILL_DIR_PATH/scripts/server.cjs \
  --dir "$PLANS_DIR" \
  --host localhost \
  --open \
  --foreground

重要： 调用 Bash 工具时：

  • 设置 run_in_background: true，将其作为 CC 后台任务运行
  • 设置 timeout: 300000（5 分钟），以避免过早终止
  • 解析 JSON 输出并向用户报告 URL

Bash 工具调用示例：

{
    "command": "node .claude/skills/plans-kanban/scripts/server.cjs --dir \"./plans\" --host localhost --open --foreground",
    "run_in_background": true,
    "timeout": 300000,
    "description": "Start kanban server in background"
}

启动后，解析 JSON 输出（例如，{"success":true,"url":"http://localhost:3500/kanban?dir=..."}）并报告：

  • 用于浏览器访问的本地 URL
  • 告知用户服务现已作为 CC 后台任务运行（可在 /tasks 中查看）

重要： 必须显示包含路径和查询字符串的完整 URL。切勿只截取为 host:port。直接访问需要完整 URL。

未来计划

$kanban 命令将逐步发展为受 VibeKanban 启发的 AI Agent 编排工具：

第 1 阶段（当前 - MVP）
  • ✅ 带进度跟踪的任务看板
  • ✅ 计划/任务的可视化呈现
  • ✅ 点击查看计划详情
第 2 阶段（Worktree 集成）
  • 创建任务 → 生成 git worktree
  • 为任务分配 Agent
  • 按 worktree 跟踪 Agent 进度
第 3 阶段（完整编排）
  • 并行 Agent 执行监控
  • 代码差异／审查界面
  • PR 创建工作流
  • Agent 输出流式传输
  • 冲突检测

跟踪进度：https://github.com/claudekit/claudekit-engineer/issues/189

[IMPORTANT] 使用任务跟踪，在开始前将所有工作拆分为小任务——包括为每个要读取的文件创建任务。这可以防止长文件导致上下文丢失。对于简单任务，AI MUST ATTENTION 询问用户是否跳过。

AI 错误预防——每项任务都应避免以下失败模式：

删除前检查下游引用。 删除组件会导致文档和代码逐步过时。移除前应梳理所有引用该组件的文件。 根据实际代码验证 AI 生成的内容。 AI 可能会编造 API、类名和方法签名。记录或引用前，务必使用 grep 确认其存在。 编辑后追踪完整依赖链。 更改定义时，如果遗漏下游变量及其使用方，问题仍会存在。务必追踪完整链路。 验证正确性时追踪所有代码路径。 确认代码存在，不等于确认它会执行。务必追踪提前退出、错误分支和条件跳过，不要只看正常路径。 调试时，先问“该由谁负责？”再修复。 追踪错误是在调用方（数据错误）还是被调用方（处理错误）。在负责的层级修复，绝不要只修补表面症状。 假设现有值是有意设置的——更改前先问为什么。 更改任何常量、限制、标志或模式前：阅读注释、检查 git blame，并查看周边代码。 验证所有受影响的输出，而不只是第一个。 涉及多个技术栈的更改需要验证每个输出。一个检查通过不代表所有检查都通过。 整体优先的调试方式——避免注意力就近陷阱。 调查任何故障时，先列出所有前置条件（配置、环境变量、数据库名称、端点、DI 注册、数据前置条件），再逐一依据证据进行验证，然后再形成任何代码层面的假设。 精准修改——应用差异测试。 修复错误时，每个更改的行都必须能直接追溯到该错误。不要顺手重排格式或改进相邻代码。增强任务：实施改进并明确说明。 编码前明确歧义——不要默默做决定。 如果请求有多种解释，应逐一列出并估算工作量，然后询问用户。绝不要擅自假设要处理所有记录、采用基于文件的方案或选择更复杂的路径。

批判性思维模式——运用批判性思维和序贯思维。每项主张都必须有可追溯的证据，只有置信度 >80% 才能采取行动。 防止幻觉： 绝不要把猜测当作事实陈述——每项主张都要引用来源，坦然承认不确定性，自行检查输出是否有误，独立交叉核对，并对自己的判断保持怀疑——没有证据的确定性是所有幻觉的根源。

MUST ATTENTION 运用批判性思维——每项主张都必须有可追溯的证据，只有置信度 >80% 才能采取行动。防止幻觉：绝不要把猜测当作事实陈述。

MUST ATTENTION 遵循 AI 错误预防原则——整体优先调试、在负责的层级修复、编码前明确歧义、压缩上下文后重新阅读文件。

结束提醒

IMPORTANT MUST ATTENTION 开始前使用任务跟踪，将工作拆分成小型待办任务 IMPORTANT MUST ATTENTION 创建新代码前，在代码库中搜索 3 个或更多类似模式 IMPORTANT MUST ATTENTION 为每项主张注明 file:line 证据（置信度 >80% 才能采取行动） IMPORTANT MUST ATTENTION 添加最终审查待办任务，以验证工作质量

[TASK-PLANNING] 行动前，分析任务范围，并使用任务跟踪系统地将工作拆分成小型待办任务和子任务。

无 Hook 提示词协议镜像（自动同步）

来源：.claude/hooks/lib/prompt-injections.cjs + .claude/.ck.json

[WORKFLOW-EXECUTION-PROTOCOL] [BLOCKING] 工作流执行协议 — 强制、重要、必须、关键。无论出于何种原因，都不得跳过。

通用可移植性边界： 可复用的技能和协议文本应与项目无关；从 docs/project-config.json 和 docs/project-reference/ 中查找项目特定约定。应用 shared/sdd-artifact-contract.md 中的共享 AI-SDD。阅读 docs/project-config.json 和 docs/project-reference/docs-index-reference.md，然后打开其中列出的项目参考文档。只要具备此共享上下文和本地文档，任何受支持的 AI 工具都可以执行。

  1. 检测： 将提示词与工作流目录进行匹配
  2. 分析： 找出最匹配的工作流，并评估自定义步骤组合是否更合适
  3. 询问（必需格式）： 直接向用户提问，采用以下结构；除非用户明确调用了某个工作流／技能，且本地协议将明确调用视为确认：
    • 问题："你想启用哪个工作流？"
    • 选项 1："启用 [最佳匹配工作流]（推荐）"
    • 选项 2："启用自定义工作流：[步骤 1 → 步骤 2 → ...]"（附上一句话说明理由）
  4. 启用（确认后）： 标准工作流调用 $workflow-start <workflowId>；自定义步骤按顺序手动执行
  5. 创建任务： 跟踪工作流的所有步骤
  6. 执行： 按顺序遵循每个步骤 [CRITICAL-THINKING-MINDSET] 运用批判性思维和顺序思维。每项声明都必须有可追溯的证据；置信度超过 80% 才能采取行动。 反幻觉原则： 切勿将猜测当作事实；每项声明都要引用来源；坦率承认不确定性；自行检查输出是否有误；独立交叉核对；对自己的判断保持怀疑——没有证据的确信是所有幻觉的根源。 AI 注意力原则（首因－近因效应）： 对于较长的提示词／协议，将最关键的 3 条规则同时放在开头和结尾，以确保指令在较长上下文窗口中仍能得到遵循。 目标驱动执行： 先定义成功标准，循环执行直至验证通过，并且只有在可观察的检查均通过后才停止。 测试验证意图： 测试必须保护业务规则／不变量，并在受保护的意图被破坏时失败，而不能只照搬当前行为。

[LESSON-LEARNED-REMINDER] [BLOCKING] 任务规划与持续改进 — 强制执行。不得跳过。

开始前将工作拆分为小任务并进行跟踪。添加最终任务："分析 AI 错误与经验教训"。

提取经验教训——仅限根本原因，不处理表面症状：

  1. 指明失败模式（推理／假设失误），而非症状——例如“未阅读源代码就假设 API 存在”，而不是“使用了错误的枚举值”。
  2. 通用性测试：此失败模式是否适用于 ≥3 种情境／代码库？如果不适用，就再抽象一层。
  3. 将其写成通用规则——去除项目特定的名称／路径／类。该规则应适用于任何代码库。
  4. 合并：多个错误若有相同的失败模式 → 总结为一条经验教训。
  5. 重复发生检查：“如果没有这条提醒，未来会话中还会发生这种情况吗？”——不会 → 跳过 $learn。
  6. 自动修复检查：“$code-review／$code-simplifier／$security／$lint 能否发现此问题？”——能 → 改进相应的审查技能。
  7. 两项检查均通过 → 请用户运行 $learn。 [TASK-PLANNING] [MANDATORY] 在执行任何工作流或技能步骤之前，先为所有计划步骤创建／更新任务跟踪；然后随着每个步骤开始／完成，持续同步任务状态。

评论

支持 Markdown