Skip to content

codingapi/coding-marketplace

BranchesTags

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

27 Commits
.claude-plugin
.claude-plugin
 
 
plugins
plugins
 
 
.gitignore
.gitignore
 
 
CLAUDE.md
CLAUDE.md
 
 
LICENSE
LICENSE
 
 
README.md
README.md
 
 

Repository files navigation

coding-marketplace

一套面向 Claude Code 的 RepoWiki 驱动开发 工作流插件市场。先写文档、再写代码 —— 每一行代码变更都由 docs/ 下的结构化文档驱动产生。通过 三条任务入口（需求 / Bug / 调整）→ 计划 → 执行 → 提交 → 文档更新 的标准化流程，把人工审核决策与 AI 自动化执行结合，并在关键环节用 pnpm / mvn 指令代替模型猜测以提升确定性。

核心理念：RepoWiki 驱动开发

graph LR
    A["📝 文档<br/>docs/"] -->|驱动| B["💻 代码变更<br/>git worktree"]
    B -->|提交后更新| A
    A -->|AI 读取上下文| C["🤖 Claude Code"]
    C -->|按文档执行| B
Loading

文档是事实来源（Source of Truth），代码是文档的产物。

  • 每条工作流都从 docs/ 下的文档开始，到 docs/ 下的文档更新结束，形成闭环
  • AI 读取已有文档（需求/架构/组件）作为上下文，生成新文档（设计/计划），再按计划执行代码变更
  • 代码提交后，反向更新架构和组件文档，保持 docs/ 与代码始终同步
  • 人工在每个关键节点审核把关，AI 绝不自动提交

前置条件

使用本插件市场前，目标项目必须满足以下条件：

工具环境：

  • Claude Code CLI 已安装并登录
  • Git 已初始化（git init）
  • 前端项目：Node.js + pnpm
  • 后端项目：JDK + Maven

项目脚手架（必须提前完成）：

目标项目必须已通过团队脚手架初始化完整的模块化结构，本插件市场不负责项目初始化：

  • 前端：通过团队脚手架初始化 pnpm workspace monorepo，包含 pnpm-workspace.yaml、各 package 入口 index.ts、TypeScript 配置
  • 后端：通过团队脚手架初始化 Maven 多模块工程，包含根 pom.xml 的 <modules> 声明，按团队约定划分公共模块与业务模块

初始化 docs/ 目录：

项目脚手架应已包含 docs/ 目录。若未包含，手动创建：

mkdir -p docs/{requirements,bugs,changes,design,plan,architecture,components,todo}

快速开始

graph TD
    A["添加插件市场"] --> B["安装插件"]
    B --> C{"项目类型"}
    C -->|前端| D["commons + frontend"]
    C -->|后端| E["commons + backend"]
    D --> F["/generate-requirement 需求描述"]
    E --> F
    F --> G["人工补充需求细节"]
    G --> H["docs/requirements/<br/>生成了带编码的需求文档 ✅"]
Loading

1. 添加插件市场

在目标项目目录下，通过 git 方式添加插件市场：

/plugin marketplace add git@github.com:codingapi/coding-marketplace.git

2. 安装插件

前端项目安装 commons + frontend：

/plugin install commons@coding-marketplace
/plugin install frontend@coding-marketplace

后端项目安装 commons + backend：

/plugin install commons@coding-marketplace
/plugin install backend@coding-marketplace

3. 创建第一个任务

# 新需求
/generate-requirement 用户登录功能

# Bug 修复
/generate-bug 登录后跳转错误

# 调整任务
/generate-change 统一全局异常返回格式

插件体系

插件 定位 技术体系 适用项目
commons 三条任务入口 + 执行/提交/清理流程 + 组件索引重建 通用 所有项目
frontend 前端 write-design / write-design-plan / write-architecture / write-components（自有 + 三方统一）/ write-bugfix-plan / write-change-plan pnpm monorepo / TypeScript 前端项目
backend 后端 write-design / write-design-plan / write-architecture / write-components（自有 + 三方统一）/ write-bugfix-plan / write-change-plan Maven 多模块 / Java 后端项目

安装规则：前端项目安装 commons + frontend，后端项目安装 commons + backend。

⚠ frontend 与 backend 插件互斥：两者定义了同名 skill（write-design / write-design-plan / write-architecture / write-components / write-bugfix-plan / write-change-plan 共 6 个），同时安装会导致 /write-design 等命令调用歧义。请按项目类型只装其一。

三条工作流

工作流总览

graph TD
    subgraph 任务入口
        R["/generate-requirement<br/>需求描述"]
        B["/generate-bug<br/>Bug 描述"]
        C["/generate-change<br/>调整描述"]
    end

    subgraph 文档编写
        R --> R1["人工补充需求细节"]
        R1 --> D["/write-design"]
        D --> D1["人工审核设计"]
        D1 --> P1["/write-design-plan"]
        P1 --> P1a["人工审核计划"]
        B --> B1["人工补充 Bug 细节"]
        B1 --> P2["/write-bugfix-plan"]
        P2 --> P2a["人工审核计划"]
        C --> C1["人工补充调整细节"]
        C1 --> P3["/write-change-plan"]
        P3 --> P3a["人工审核计划"]
    end

    subgraph 执行与提交
        P1a --> E["/execute-plan<br/>git worktree 隔离执行"]
        P2a --> E
        P3a --> E
        E --> E1["人工测试验证"]
        E1 --> CO["/commit-work<br/>worktree 内 commit + push 代码"]
    end

    subgraph 文档更新
        CO --> X["退出 worktree<br/>回到主仓库工作区<br/>（保持当前分支即可）"]
        X --> U["/write-architecture<br/>/write-components {module} {组件}<br/>（按需更新 docs/）"]
        U --> U1["人工审核 →<br/>主仓库当前分支独立 commit + push"]
    end

    subgraph 清理
        U1 --> CL["/cleanup-worktree"]
    end
Loading

每个步骤后都需要人工确认才能进入下一步。AI 绝不自动提交代码。三条流程在 execute-plan 阶段汇聚，共享后续执行与提交能力。

⚠ 文档编写位置约束：/write-* / /generate-* 系列必须在主仓库工作区调用，禁止在 worktree 内运行——SKILL 内置硬守卫会拒绝执行。具体落到哪条本地分支由用户当下决定，SKILL 不做约束。代码提交（worktree 内）与文档提交（主仓库内）是两步独立 commit，不要求合并到同一 commit。

新需求流程

sequenceDiagram
    participant H as 人工
    participant AI as Claude Code
    participant D as docs/
    participant G as git

    H->>AI: /generate-requirement 需求描述
    AI->>D: 创建 requirements/{code}-{name}.md
    H->>D: 补充需求细节（验收标准/范围/依赖）
    H->>AI: /write-design {code}
    Note right of AI: 读取 需求+架构+组件 文档
    AI->>D: 创建 design/{code}-{name}.md
    H->>D: 审核设计方案
    H->>AI: /write-design-plan {code}
    AI->>D: 创建 plan/{code}-design-{name}.md
    H->>D: 审核实施计划
    H->>AI: /execute-plan {code}
    AI->>G: 创建 worktree + 分支
    AI->>G: 按计划执行代码变更
    H->>G: 人工测试
    H->>AI: /commit-work {code}
    AI->>G: worktree 内提交并推送代码
    Note over H: 退出 worktree，回到主仓库工作区<br/>（保持当前分支即可）
    H->>AI: /write-architecture（按需）
    AI->>D: 主仓库内更新 architecture/
    H->>AI: /write-components {module} {组件}（按需）
    AI->>D: 主仓库内更新 components/
    H->>G: 主仓库当前分支 commit + push 文档
    H->>AI: /cleanup-worktree {code}
    AI->>G: 清理 worktree
Loading

文字版：

/generate-requirement → 人工补充
  → /write-design {code}        → 人工审核
    → /write-design-plan {code} → 人工审核
      → /execute-plan {code}    → 人工测试
        → /commit-work {code}（worktree 内提交代码）
          → 退出 worktree 回到主仓库（当前分支即可）
            → /write-architecture（按需）→ /write-components {module} {组件}（按需，自动重建索引）
              → 主仓库当前分支 commit + push 文档（与代码是两步独立提交）
                → /cleanup-worktree {code}

Bug 流程

sequenceDiagram
    participant H as 人工
    participant AI as Claude Code
    participant D as docs/
    participant G as git

    H->>AI: /generate-bug Bug 描述
    AI->>D: 创建 bugs/{code}-{name}.md
    H->>D: 补充 Bug 细节（重现步骤/期望/实际/影响范围）
    H->>AI: /write-bugfix-plan {code}
    Note right of AI: 读取 Bug+架构+组件 文档
    AI->>D: 创建 plan/{code}-bugfix-{name}.md
    H->>D: 审核修复计划
    H->>AI: /execute-plan {code}
    AI->>G: worktree 中执行修复
    H->>G: 人工回归验证
    H->>AI: /commit-work {code}
    AI->>G: worktree 内提交并推送代码
    Note over H: 退出 worktree，回到主仓库工作区
    H->>AI: /write-architecture（按需）
    AI->>D: 主仓库内更新 architecture/
    H->>AI: /write-components {module} {组件}（按需）
    AI->>D: 主仓库内更新 components/
    H->>G: 主仓库当前分支 commit + push 文档
    H->>AI: /cleanup-worktree {code}
    AI->>G: 清理 worktree
Loading

文字版：

/generate-bug → 人工补充（重现步骤、期望/实际、影响范围）
  → /write-bugfix-plan {code} → 人工审核
    → /execute-plan {code} → 人工回归验证
      → /commit-work {code}（worktree 内提交代码）
        → 退出 worktree 回到主仓库（当前分支即可）
          → /write-architecture（按需）→ /write-components {module} {组件}（按需，自动重建索引）
            → 主仓库当前分支 commit + push 文档
              → /cleanup-worktree {code}

调整任务流程

sequenceDiagram
    participant H as 人工
    participant AI as Claude Code
    participant D as docs/
    participant G as git

    H->>AI: /generate-change 调整描述
    AI->>D: 创建 changes/{code}-{name}.md
    H->>D: 补充调整细节（现状/目标/范围）
    H->>AI: /write-change-plan {code}
    Note right of AI: 读取 调整+架构+组件 文档
    AI->>D: 创建 plan/{code}-change-{name}.md
    H->>D: 审核调整计划
    H->>AI: /execute-plan {code}
    AI->>G: worktree 中执行调整
    H->>G: 人工验证
    H->>AI: /commit-work {code}
    AI->>G: worktree 内提交并推送代码
    Note over H: 退出 worktree，回到主仓库工作区
    H->>AI: /write-architecture（按需）
    AI->>D: 主仓库内更新 architecture/
    H->>AI: /write-components {module} {组件}（按需）
    AI->>D: 主仓库内更新 components/
    H->>G: 主仓库当前分支 commit + push 文档
    H->>AI: /cleanup-worktree {code}
    AI->>G: 清理 worktree
Loading

文字版：

/generate-change → 人工补充（现状、目标、范围）
  → /write-change-plan {code} → 人工审核
    → /execute-plan {code} → 人工验证
      → /commit-work {code}（worktree 内提交代码）
        → 退出 worktree 回到主仓库（当前分支即可）
          → /write-architecture（按需）→ /write-components {module} {组件}（按需，自动重建索引）
            → 主仓库当前分支 commit + push 文档
              → /cleanup-worktree {code}

全部技能一览（19 个）

表格中的命令签名是简化形式，便于快速一览；完整 argument-hint 以各 SKILL 的 frontmatter 为准。所有 write-* 都支持 {文件名}.md {调整意见} 调整模式（详见各 SKILL 的"调用模式"段）。

Commons 插件（7）

技能 模型 说明
/generate-requirement [描述] | {code} 补充描述 haiku 创建需求文档（预填充关联模块）或补充已有文档
/generate-bug [描述] | {code} 补充描述 haiku 创建 Bug 文档（预填充关联模块）或补充已有文档
/generate-change [描述] | {code} 补充描述 haiku 创建调整任务文档（预填充影响范围）或补充已有文档
/execute-plan {code} haiku 读取计划，在 git worktree 中执行代码变更
/commit-work {code} haiku 人工审核通过后，提交并推送 worktree 代码
/cleanup-worktree {code} haiku 代码合入后清理 worktree 目录（不删除分支）
/rebuild-components-index haiku 重建 docs/components/index.md 索引（组件文档写入后由插件级 hook 自动触发，也可手动触发）

Frontend 插件（6）

技能 模型 说明
/write-design {code} opus 基于需求+架构+组件索引，编写前端详细设计方案（含线框图与组件清单）
/write-design-plan {code} opus 基于设计文档（pnpm 指令驱动依赖分析），编写前端实施计划
/write-architecture [module] [base-branch] opus 用 pnpm 指令驱动的模块识别，更新前端架构文档
/write-components {package} {组件} opus 自有 + 三方统一：workspace 内走 export 校验 + 源码分析；三方走 node_modules .d.ts 分析；命名脚本计算文件名 + 由 PostToolUse hook 自动重建索引
/write-bugfix-plan {code} opus 基于 Bug + 架构 + 组件索引，编写修复计划（pnpm 指令驱动）
/write-change-plan {code} opus 基于调整任务 + 架构 + 组件索引，编写调整计划（pnpm 指令驱动）

Backend 插件（6）

技能 模型 说明
/write-design {code} opus 基于需求+架构+组件索引，编写后端详细设计方案
/write-design-plan {code} opus 基于设计文档（mvn 指令驱动依赖分析），编写后端实施计划
/write-architecture [module] [base-branch] opus 用 mvn 指令驱动的模块识别，更新后端架构文档
/write-components {module} {组件类} opus 自有 + 三方统一：workspace 内走 module 源码分析；三方走 mvn dependency:sources 解压源码 jar；命名脚本计算文件名 + 由 PostToolUse hook 自动重建索引
/write-bugfix-plan {code} opus 基于 Bug + 架构 + 组件索引，编写修复计划（mvn 指令驱动）
/write-change-plan {code} opus 基于调整任务 + 架构 + 组件索引，编写调整计划（mvn 指令驱动）

前后端 write-design 输出形态差异

虽然命令同名，前后端 write-design 产出的设计文档章节有意分化，反映各自技术栈关注点：

章节 前端 design 后端 design
业务流程 ✅ 六列体验流程表（含心理感受 / 痛点） ✅ 四列流程表（行为 / 系统响应 / 数据变更）
页面规格 + 线框图 + 组件清单 ✅（核心章节） — 不涉及
数据库表设计 — 不涉及 ✅（含字段 / 索引）
配置变更（application.yml / 迁移脚本） — 不涉及 ✅
关键对象设计 Props / State / Context 类名 / 包路径 / 数据库映射
对象交互设计 组件通信 / 状态流转 Controller → Service → DAO 调用链
接口设计 API 契约（前端视角） 完整接口契约（请求 Body / 响应 Body）

这是设计差异，不是 bug。 前端关注 UI 拼装与组件复用，后端关注数据建模与服务编排。

编码一致性

6位数字编码在 requirements / bugs / changes 三个命名空间中全局唯一。generate-* 系列会同时检查三个目录避免冲突。

requirements/{code}-{name}.md → design/{code}-{name}.md → plan/{code}-design-{name}.md
bugs/{code}-{name}.md → plan/{code}-bugfix-{name}.md
changes/{code}-{name}.md → plan/{code}-change-{name}.md
最终 → branch/{code}-{name} → worktree/{code}-{name}

plan 文件名中的 design / bugfix / change 标识来源流程，便于在 docs/plan/ 中直观区分。

核心设计原则

指令可控依赖

涉及模块识别、依赖关系分析的 skill 必须 调用 pnpm / mvn 指令获取权威结果，而非仅读 pnpm-workspace.yaml / pom.xml 或凭文件名推断。这避免模型猜错或浪费时间，把"事实"交给构建工具。

  • 前端：pnpm -r list、pnpm -F <pkg> list、pnpm why <pkg>
  • 后端：mvn help:evaluate、mvn -pl <m> dependency:tree、mvn dependency:tree -Dincludes=...

适用的 skill：write-architecture、write-design-plan、write-bugfix-plan、write-change-plan。

脚本化优先（"指令可控依赖"在文档侧的延伸）

凡是可以被脚本化的逻辑（文件名计算、索引扫描重建、固定格式解析、跨文件元数据提取等）一律落到脚本文件，不允许 SKILL prompt 自己分析推导。脚本分两层：

  • 插件级（plugins/<plugin>/scripts/*.py）：由 hooks 或多个 SKILL 共享的脚本，如 rebuild_components_index.py

  • SKILL 级（plugins/<plugin>/skills/<skill>/scripts/*.py）：仅单一 SKILL 使用的脚本，如 component_filename.py

  • 语言：统一 Python 3，仅依赖标准库（无第三方包），保证 macOS / Linux / Windows 跨平台行为一致

  • 调用方式：SKILL.md 用相对 markdown link 引用脚本；执行时通过 ${CLAUDE_PLUGIN_ROOT} 定位脚本路径，Bash 直接 python3 执行

  • 唯一事实来源：脚本即规则。SKILL 不允许重复实现脚本逻辑（如自己拼接文件名、自己扫描目录、自己解析 metadata）

  • 跨 SKILL 共享：因 /plugin install 后插件目录不连通，需共享逻辑的脚本（如 component_filename.py）在每个消费 SKILL 下持有同名同内容副本；插件级脚本（如 rebuild_components_index.py）同样在 commons / frontend / backend 各持一份

三方组件本地分析

write-components 的三方分支 必须基于项目实际依赖的本地代码分析（前端读 node_modules/，后端读 Maven 源码 jar），不允许使用 WebSearch / WebFetch。不同版本 API 差异大，文档必须与项目实际版本一致。源码 jar 不可用时直接终止，不允许基于 class 元信息或网上文档"推断"写文档。

组件索引（docs/components/index.md）

docs/components/index.md 是下游 SKILL（write-design / write-design-plan / write-bugfix-plan / write-change-plan）查阅"项目里有哪些组件可用"的唯一入口：

  • 由 /rebuild-components-index 维护；plugins/{frontend,backend}/hooks/hooks.json 定义了 PostToolUse hook，组件文档写入后自动触发重建
  • 表格列：组件模块 | 组件名称 | 组件描述（应用场景） | 文档地址
  • "组件描述"优先从文档 YAML frontmatter description 字段提取；frontmatter 缺失时 fallback 到 ## 何时使用 段首句
  • 下游 SKILL 禁止 全量扫描 docs/components/*.md，必须先读 index.md 选出相关条目，再选读详情

模型策略

  • opus（强模型）：write-design、write-design-plan、write-bugfix-plan、write-change-plan、write-architecture、write-components
  • haiku（轻模型）：generate-* 系列、execute-plan、commit-work、cleanup-worktree、rebuild-components-index

docs/ 目录规范（扁平化）

安装了本插件市场的项目需要维护如下目录结构，所有子目录下只允许平铺 .md，禁止嵌套子目录：

docs/
├── requirements/     # {code}-{name}.md                    需求
├── bugs/             # {code}-{name}.md                    Bug 反馈
├── changes/          # {code}-{name}.md                    调整任务
├── design/           # {code}-{name}.md                    详细设计（仅需求走）
├── plan/             # {code}-{source}-{name}.md           实施计划（source = design / bugfix / change）
├── architecture/     # {module}.md                         架构文档
├── components/       # {module}_{组件}.md + index.md       组件文档（自有 + 三方扁平共享）+ 自动维护索引
└── todo/             # index.md                            任务安排（人工维护）

components/ 命名空间扁平：文件名规则 {module 中的 ':' 和 '/' 替换为 '__'}_{组件}.md（由 scripts/component_filename.py 计算），module 已嵌入文件名故同名组件不会撞名；元数据冲突时由 /write-components 在写入前直接终止。组件文档写入后由插件级 PostToolUse hook 自动触发 /rebuild-components-index 重建 index.md。

组件判定标准

write-components 是强参形式 /write-components {module} {组件}（或调整模式 /write-components {文件名}.md {调整意见}），由用户显式锁定范围；自有 + 三方统一处理，SKILL 自动判定来源：

  • 前端 - 自有：{module} = workspace 内 package.json#name（如 @coding-flow/flow-engine）；{组件} 必须在该 package 的入口 export 导出图里——未导出 SKILL 直接终止
  • 前端 - 三方：{module} = node_modules/ 下的包名（如 antd、@cloudbase:js-sdk）；跳过 export 校验，分析 .d.ts 类型定义
  • 后端 - 自有：{module} = workspace 内 Maven artifactId（如 springboot-starter-data）；{组件} 优先 FQCN，mvn help:evaluate 校验 module 存在；命名前缀不再硬性约束
  • 后端 - 三方：{module} = 项目 pom 已声明依赖的 artifactId（如 mybatis）；mvn dependency:sources 拉源码 jar 解压分析；源码不可用直接终止
  • 文件命名脚本：scripts/component_filename.py 是事实来源，例：
    • @cloudbase:js-sdk demo → @cloudbase__js-sdk_demo.md
    • flow-engine-framework GroovyScriptBind → flow-engine-framework_GroovyScriptBind.md
    • antd Button → antd_Button.md
  • 分析以指定类/组件为锚点向外扩展一层（子组件、Props 引用类型、配置类、SPI 注解、工具类等），呈现"组件整体"
  • 三方分支必须基于本地依赖代码分析，禁用 WebSearch / WebFetch

文件结构

coding-marketplace/
├── .claude-plugin/
│   └── marketplace.json              # 市场注册
├── CLAUDE.md
├── README.md
└── plugins/
    ├── commons/
    │   ├── .claude-plugin/plugin.json
    │   └── skills/
    │       ├── generate-requirement/SKILL.md
    │       ├── generate-bug/SKILL.md
    │       ├── generate-change/SKILL.md
    │       ├── execute-plan/SKILL.md
    │       ├── commit-work/SKILL.md
    │       ├── cleanup-worktree/SKILL.md
    │       └── rebuild-components-index/
    │           ├── SKILL.md
    │           └── scripts/
    │               ├── component_filename.py
    │               └── rebuild_components_index.py
    ├── frontend/
    │   ├── .claude-plugin/plugin.json
    │   ├── scripts/
    │   │   └── rebuild_components_index.py
    │   ├── hooks/
    │   │   └── hooks.json
    │   └── skills/
    │       ├── write-design/
    │       │   ├── SKILL.md
    │       │   └── templates/template.md
    │       ├── write-design-plan/
    │       │   ├── SKILL.md
    │       │   └── templates/template.md
    │       ├── write-architecture/
    │       │   ├── SKILL.md
    │       │   └── templates/template.md
    │       ├── write-components/
    │       │   ├── SKILL.md
    │       │   ├── templates/template.md
    │       │   └── scripts/
    │       │       └── component_filename.py
    │       ├── write-bugfix-plan/
    │       │   ├── SKILL.md
    │       │   └── templates/template.md
    │       └── write-change-plan/
    │           ├── SKILL.md
    │           └── templates/template.md
    └── backend/
        ├── .claude-plugin/plugin.json
        ├── scripts/
        │   └── rebuild_components_index.py
        ├── hooks/
        │   └── hooks.json
        └── skills/
            ├── write-design/
            │   ├── SKILL.md
            │   └── templates/template.md
            ├── write-design-plan/
            │   ├── SKILL.md
            │   └── templates/template.md
            ├── write-architecture/
            │   ├── SKILL.md
            │   └── templates/template.md
            ├── write-components/
            │   ├── SKILL.md
            │   ├── templates/template.md
            │   └── scripts/
            │       └── component_filename.py
            ├── write-bugfix-plan/
            │   ├── SKILL.md
            │   └── templates/template.md
            └── write-change-plan/
                ├── SKILL.md
                └── templates/template.md

开发约束

前端约束

  • 模块化管理：采用 pnpm workspace monorepo，所有 package 在 pnpm-workspace.yaml 中声明
  • 语言：TypeScript
  • 组件导出：只有 package 入口文件 (index.ts) 中 export 的组件才算公共组件，允许其他 package 依赖
  • 指令可控依赖：涉及模块识别与依赖分析时，必须调用 pnpm -r list、pnpm -F <pkg> list、pnpm why <pkg> 等指令获取权威结果，不得凭文件名推断

后端约束

  • 模块化管理：采用 Maven 多模块工程，所有 module 在根 pom.xml 的 <modules> 中声明
  • 语言：Java
  • 组件文档：/write-components {module} {组件类} 强参形式调用，{module} 须为 workspace 内可解析的 artifactId；命名前缀由各团队自定，SKILL 不再硬性约束
  • 指令可控依赖：涉及模块识别与依赖分析时，必须调用 mvn dependency:tree、mvn -pl <m> dependency:tree 等指令获取权威结果，不得凭 pom.xml 推断

通用约束

  • docs/ 扁平存储：所有子目录下只允许平铺 .md 文件，禁止嵌套子目录
  • 编码唯一性：6 位数字编码在 requirements / bugs / changes 三个命名空间中全局唯一
  • 人工审核：每个步骤完成后需要人工确认才能进入下一步，AI 绝不自动提交代码

代码管理原则

  • execute-plan 使用 git worktree 在隔离环境中执行，不影响主工作区
  • 每一步完成后需要人工审核，绝不自动提交
  • 代码提交通过 commit-work 统一执行，确保提交规范化
  • worktree 使用完毕后通过 cleanup-worktree 清理

文档编写位置约束

  • /write-* 与 /generate-* 系列必须在主仓库工作区调用，禁止在 worktree 内运行——SKILL 内置硬守卫（基于 git rev-parse --git-dir 与 --git-common-dir 比对）会直接拒绝执行
  • 文档落到哪条本地分支由用户当下决定，SKILL 不强制约束
  • 代码提交（worktree 内）与文档提交（主仓库内）是两步独立 commit，不要求合并到同一 commit；执行顺序遵循 commit-work → 退出 worktree → write-* → 文档 commit/push → cleanup-worktree

About

No description, website, or topics provided.

Resources

Readme

License

Apache-2.0 license
Activity
Custom properties

Stars

0 stars

Watchers

0 watching

Forks

0 forks
Report repository

Releases 1

v0.0.1 Latest
Apr 28, 2026

Packages

 
 
 

Contributors

Languages