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

文档是事实来源（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/>生成了带编码的需求文档 ✅"]

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

每个步骤后都需要人工确认才能进入下一步。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

文字版：

/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

文字版：

/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

文字版：

/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

Name		Name	Last commit message	Last commit date
.claude-plugin		.claude-plugin
plugins		plugins
.gitignore		.gitignore
CLAUDE.md		CLAUDE.md
LICENSE		LICENSE
README.md		README.md

Uh oh!

Latest commit

History

Folders and files

Repository files navigation

coding-marketplace

核心理念：RepoWiki 驱动开发

前置条件

快速开始

1. 添加插件市场

2. 安装插件

3. 创建第一个任务

插件体系

三条工作流

工作流总览

新需求流程

Bug 流程

调整任务流程

全部技能一览（19 个）

Commons 插件（7）

Frontend 插件（6）

Backend 插件（6）

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

编码一致性

核心设计原则

指令可控依赖

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

三方组件本地分析

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

模型策略

docs/ 目录规范（扁平化）

组件判定标准

文件结构

开发约束

前端约束

后端约束

通用约束

代码管理原则

文档编写位置约束

About

Resources

Stars

Watchers

Forks

Releases

Packages

Contributors

Languages

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