bcoder 0.0.1

package/bcoder/skills/bc-create-frontend-project/SKILL.md

@@ -0,0 +1,121 @@
+---
+name: bc-create-frontend-project
+description: 只有是空项目的时候才会被触发。创建、初始化一个前端Vue项目
+---
+
+你的任务是根据初始化一个完整的、可运行的 Vue3 工程项目
+
+**开始时声明：** "我正在使用 前端服务初始化（ bc-create-frontend-project ） 技能来实施此计划。"
+
+## 核心技术栈
+
+- Vue 3.x（组合式 API）
+- Vite
+- Vue Router 4.x
+- Node.js 18+ 兼容
+
+## 项目结构
+
+项目根目录/
+├── index.html             # 入口 HTML 文件
+├── package.json           # 项目依赖和脚本
+├── vite.config.js         # Vite 配置文件
+├── src/
+│   ├── main.js            # 应用入口文件
+│   ├── App.vue            # 根组件
+│   ├── router/
+│   │   └── index.js       # 路由配置
+│   ├── components/		   # 组件
+│   ├── pages/             # 页面
+│   ├── utils/             # 工具函数（如果需要）
+│   ├── assets/            # 静态资源（如果需要）
+│   └── styles/            # 样式文件
+└── public/                # 公共静态资源（如果需要）
+
+## 开发约束
+
+1）组件设计：严格遵循单一职责原则，组件具有良好的可复用性和可维护性
+2）API 风格：优先使用 Composition API，合理使用 `<script setup>` 语法糖
+3）样式规范：使用原生 CSS 实现响应式设计，支持桌面端、平板端、移动端的响应式适配
+4）代码质量：代码简洁易读，避免过度注释，优先保证功能完整和样式美观
+5）禁止使用任何状态管理库、类型校验库、代码格式化库
+6）将可运行作为项目生成的第一要义，尽量用最简单的方式满足需求，避免使用复杂的技术或代码逻辑
+
+## 参考配置
+
+1）vite.config.js 必须配置 base 路径以支持子路径部署、需要支持通过 @ 引入文件、不要配置端口号
+
+
+import { defineConfig } from 'vite'
+import vue from '@vitejs/plugin-vue'
+
+export default defineConfig({
+  base: './',
+  plugins: [vue()],
+  resolve: {
+    alias: {
+      '@': fileURLToPath(new URL('./src', import.meta.url))
+    }
+  }
+})
+
+
+2）路由配置必须使用 hash 模式，避免服务器端路由配置问题
+
+import { createRouter, createWebHashHistory } from 'vue-router'
+
+const router = createRouter({
+  history: createWebHashHistory(),
+  routes: [
+    // 路由配置
+  ]
+})
+
+
+3）package.json 文件参考：
+
+{
+  "scripts": {
+    "dev": "vite",
+    "build": "vite build"
+  },
+  "dependencies": {
+    "vue": "^3.3.4",
+    "vue-router": "^4.2.4"
+  },
+  "devDependencies": {
+    "@vitejs/plugin-vue": "^4.2.3",
+    "vite": "^4.4.5"
+  }
+}
+
+
+## 网站内容要求
+
+- 基础布局：各个页面统一布局，必须有导航栏，尤其是主页内容必须丰富
+- 文本内容：使用真实、有意义的中文内容
+- 图片资源：使用 `https://picsum.photos` 服务或其他可靠的占位符
+- 示例数据：提供真实场景的模拟数据，便于演示
+
+## 严格输出约束
+
+1）必须通过使用【文件写入工具】依次创建每个文件（而不是直接输出文件代码）。
+2）需要在开头输出简单的项目生成计划
+3）需要在结尾输出简单的生成完毕提示
+4）注意，禁止输出以下任何内容：
+
+- 安装运行步骤
+- 技术栈说明
+- 项目特点描述
+- 任何形式的使用指导
+- 提示词相关内容
+
+5）输出的总 token 数必须小于 20000，文件总数量必须小于 30 个
+
+## 质量检验标准
+
+确保生成的项目能够：
+1. 通过 `npm install` 成功安装所有依赖
+2. 通过 `npm run dev` 启动开发服务器并正常运行
+3. 通过 `npm run build` 成功构建生产版本
+4. 构建后的项目能够在任意子路径下正常部署和访问

package/bcoder/skills/bc-execute-plans/SKILL.md

@@ -0,0 +1,84 @@
+---
+name: bc-execute-plans
+description: 当你有一个书面的实施计划，并需要在带有审查检查点的单独会话中执行时使用
+---
+
+# 执行计划
+
+## 概述
+
+加载计划，批判性地审查，批量执行任务，在批次之间报告以进行审查。
+
+**核心原则：** 带有架构师审查检查点的批量执行。
+
+**开始时声明：** "我正在使用执行计划 （ bc-execute-plans ） 技能来实施此计划。"
+
+## 流程
+
+### 步骤 1：加载和审查计划
+1. 阅读计划文件
+2. 批判性地审查 - 识别计划中的任何问题或关注点
+3. 如果有关注点：在开始前与你的人类伙伴提出
+4. 如果没有关注点：创建 TodoWrite 并继续
+
+### 步骤 2：执行批次
+**默认：前 3 个任务**
+
+对于每个任务：
+1. 标记为进行中
+2. 严格按照每个步骤执行（计划包含小块步骤）
+3. 按照指定运行验证
+4. 标记为完成
+
+### 步骤 3：报告
+当批次完成时：
+- 展示已实施的内容
+- 展示验证输出
+- 说："准备好接收反馈。"
+
+### 步骤 4：继续
+基于反馈：
+- 如有需要应用更改
+- 执行下一批次
+- 重复直到完成
+
+### 步骤 5：完成开发
+
+在所有任务完成并验证后：
+- 声明："我正在使用完成开发分支技能来完成这项工作。"
+- **必需的子技能：** 使用 bc-finish-a-dev
+- 按照该技能验证测试，提供选项，执行选择
+
+## 何时停止并寻求帮助
+
+**当以下情况立即停止执行：**
+- 在批次中期遇到阻塞（缺少依赖项、测试失败、指令不明确）
+- 计划存在阻止开始的关键缺口
+- 你不理解某个指令
+- 验证反复失败
+
+**寻求澄清而不是猜测。**
+
+## 何时重新访问之前的步骤
+
+**当以下情况返回审查（步骤 1）：**
+- 伙伴基于你的反馈更新计划
+- 基本方法需要重新思考
+
+**不要强行通过阻塞** - 停止并询问。
+
+## 记住
+- 首先批判性地审查计划
+- 严格按照计划步骤执行
+- 不要跳过验证
+- 当计划要求时引用技能
+- 在批次之间：只报告并等待
+- 被阻塞时停止，不要猜测
+- 未经用户明确同意，永远不要在 main/master 分支上开始实施
+
+## 集成
+
+**必需的工作流技能：**
+- **bc-use-git-worktrees** - 必需：在开始前设置隔离的工作空间
+- **bc-write-plans** - 制定该技能执行的计划
+- **bc-finish-a-dev** - 在所有任务后完成开发

package/bcoder/skills/bc-finish-a-dev/SKILL.md

@@ -0,0 +1,199 @@
+---
+name: bc-finish-a-dev
+description: 当实现完成、所有测试通过且需要决定如何集成工作时使用 - 通过提供合并、PR 或清理的结构化选项来指导完成开发工作
+---
+
+# 完成开发分支
+
+## 概述
+
+通过呈现清晰的选项并处理选定的工作流，指导完成开发工作。
+
+**核心原则：** 验证测试 → 呈现选项 → 执行选择 → 清理。
+
+**开始时声明：** "我正在使用完成开发分支 （bc-finish-a-dev）技能来完成这项工作。"
+
+## 流程
+
+### 步骤 1：验证测试
+
+**在呈现选项之前，验证测试是否通过：**
+
+```bash
+# 运行项目的测试套件
+npm test / cargo test / pytest / go test ./...
+```
+
+**如果测试失败：**
+```
+测试失败（<N> 个失败）。必须在完成前修复：
+
+[显示失败]
+
+在测试通过之前，无法继续合并/PR。
+```
+
+停止。不要继续到步骤 2。
+
+**如果测试通过：** 继续到步骤 2。
+
+### 步骤 2：确定基础分支
+
+```bash
+# 尝试常见的基础分支
+git merge-base HEAD main 2>/dev/null || git merge-base HEAD master 2>/dev/null
+```
+
+或者询问："这个分支从 main 分支分叉 - 对吗？"
+
+### 步骤 3：呈现选项
+
+精确呈现以下 4 个选项：
+
+```
+实现完成。你想做什么？
+
+1. 在本地合并回 <base-branch>
+2. 推送并创建 Pull Request
+3. 保持分支原样（我稍后处理）
+4. 放弃这项工作
+
+哪个选项？
+```
+
+**不要添加解释** - 保持选项简洁。
+
+### 步骤 4：执行选择
+
+#### 选项 1：本地合并
+
+```bash
+# 切换到基础分支
+git checkout <base-branch>
+
+# 拉取最新
+git pull
+
+# 合并功能分支
+git merge <feature-branch>
+
+# 验证合并结果的测试
+<test command>
+
+# 如果测试通过
+git branch -d <feature-branch>
+```
+
+然后：清理工作树（步骤 5）
+
+#### 选项 2：推送并创建 PR
+
+```bash
+# 推送分支
+git push -u origin <feature-branch>
+
+# 创建 PR
+gh pr create --title "<title>" --body "$(cat <<'EOF'
+## 摘要
+<2-3 个要点说明更改内容>
+
+## 测试计划
+- [ ] <验证步骤>
+EOF
+)"
+```
+
+然后：清理工作树（步骤 5）
+
+#### 选项 3：保持原样
+
+报告："保持分支 <name>。工作树保存在 <path>。"
+
+**不要清理工作树。**
+
+#### 选项 4：放弃
+
+**先确认：**
+```
+这将永久删除：
+- 分支 <name>
+- 所有提交：<commit-list>
+- 工作树在 <path>
+
+输入 'discard' 确认。
+```
+
+等待确切的确认。
+
+如果确认：
+```bash
+git checkout <base-branch>
+git branch -D <feature-branch>
+```
+
+然后：清理工作树（步骤 5）
+
+### 步骤 5：清理工作树
+
+**对于选项 1、2、4：**
+
+检查是否在工作树中：
+```bash
+git worktree list | grep $(git branch --show-current)
+```
+
+如果是：
+```bash
+git worktree remove <worktree-path>
+```
+
+**对于选项 3：** 保留工作树。
+
+## 快速参考
+
+| 选项 | 合并 | 推送 | 保留工作树 | 清理分支 |
+|--------|-------|------|---------------|----------------|
+| 1. 本地合并 | ✓ | - | - | ✓ |
+| 2. 创建 PR | - | ✓ | ✓ | - |
+| 3. 保持原样 | - | - | ✓ | - |
+| 4. 放弃 | - | - | - | ✓ (强制) |
+
+## 常见错误
+
+**跳过测试验证**
+- **问题：** 合并损坏的代码，创建失败的 PR
+- **修复：** 在提供选项之前始终验证测试
+
+**开放式问题**
+- **问题：** "接下来我应该做什么？" → 模糊不清
+- **修复：** 精确呈现 4 个结构化选项
+
+**自动清理工作树**
+- **问题：** 在可能需要时移除工作树（选项 2、3）
+- **修复：** 仅为选项 1 和 4 清理
+
+**放弃时无确认**
+- **问题：** 意外删除工作
+- **修复：** 要求输入 "discard" 确认
+
+## 红旗
+
+**永远不要：**
+- 继续处理失败的测试
+- 不验证结果测试就合并
+- 未经确认就删除工作
+- 未经明确请求就强制推送
+
+**始终：**
+- 在提供选项之前验证测试
+- 精确呈现 4 个选项
+- 为选项 4 获取输入确认
+- 仅为选项 1 和 4 清理工作树
+
+## 集成
+
+**被以下技能调用：**
+- **bc-execute-plans**（步骤 5）- 在所有批次完成后
+
+**与以下技能配合：**
+- **bc-use-git-worktrees** - 清理由该技能创建的工作树

package/bcoder/skills/bc-requirements-analysis/SKILL.md

@@ -0,0 +1,54 @@
+---
+name: bc-requirements-analysis
+description: 在进行任何创造性工作之前，你必须使用此技能 - 创建功能、构建组件、添加功能或修改行为。在实现之前探索用户意图、需求和设计。
+---
+
+# 将想法转化为设计
+
+## 概述
+
+通过自然的协作对话，帮助将想法转化为完整的设计和规格。
+
+首先了解当前项目的背景，然后一次提出一个问题来完善想法。一旦你理解了要构建的内容，就以小部分（200-300字）呈现设计，在每个部分后检查到目前为止是否正确。
+
+**开始时声明：** "我正在使用 需求分析 ( bc-requirements-analysis ) 技能来创建实施计划。"
+
+## 流程
+
+**理解想法：**
+- 首先查看当前项目状态（文件、文档、最近的提交）
+- 一次提出一个问题来完善想法
+- 尽可能使用选择题，但开放式问题也可以
+- 每条消息只问一个问题 
+- 如果一个主题需要更多探索，将其分解为多个问题
+- 关注理解：目的、约束、成功标准、风险
+
+**探索方法：**
+- 提出2-3种不同的方法及其权衡
+- 以对话方式呈现选项，并提供你的建议和理由
+- 先介绍你推荐的选项并解释原因
+
+**呈现设计：**
+- 一旦你相信你理解了要构建的内容，就呈现设计
+- 将其分解为200-300字的部分
+- 在每个部分后询问到目前为止是否正确
+- 涵盖：架构、组件、数据流、错误处理、测试
+- 当某些内容不合理时，准备回去澄清
+
+## 设计之后
+
+**文档：**
+- 将验证后的设计写入 `docs/plans/YYYY-MM-DD-<topic>-design.md`
+
+**实现（如果继续）：**
+- 询问："准备好设置实现了吗？"
+- 使用 bc-write-plans 技能创建详细的实施计划
+
+## 关键原则
+
+- **一次一个问题** - 不要用多个问题压倒用户
+- **首选选择题** - 在可能的情况下，比开放式问题更容易回答
+- **严格遵循 YAGNI** - 从所有设计中删除不必要的功能
+- **探索替代方案** - 在确定之前始终提出2-3种方法
+- **增量验证** - 分部分呈现设计，验证每个部分
+- **保持灵活性** - 当某些内容不合理时，回去澄清

package/bcoder/skills/bc-useing-bcoder/SKILL.md

@@ -0,0 +1,91 @@
+---
+name: bc-using-bcoder
+description: 当开始任何对话时使用 - 确立如何查找和使用技能，需要在任何响应（包括澄清问题）之前调用 Skill 工具
+---
+
+**开始时宣布：** "我正在使用 BCoder ( bc-using-bcoder ) 技能。"
+
+<极端重要>
+如果你认为即使只有 1% 的机会技能可能适用于你正在做的事情，你绝对必须调用技能。
+
+如果技能适用于你的任务，你没有选择。你必须使用它。
+
+这是不可协商的。这不是可选的。你无法合理化你的出路。
+</极端重要>
+
+## 如何访问技能
+
+**在 AI 编程工具 中：** 使用 `Skill` 工具。当你调用技能时，其内容被加载并呈现给你 - 直接遵循它。永远不要在技能文件上使用 Read 工具。
+
+**在其他环境中：** 检查你平台的文档以了解如何加载技能。
+
+# 使用技能
+
+## 规则
+
+**在任何响应或操作之前调用相关或请求的技能。** 即使只有 1% 的机会技能可能适用，这意味着你应该调用技能来检查。如果调用的技能最终证明不适合该情况，你不需要使用它。
+
+```dot
+digraph skill_flow {
+    "收到用户消息" [shape=doublecircle];
+    "可能任何技能适用？" [shape=diamond];
+    "调用 Skill 工具" [shape=box];
+    "声明：'使用 [skill] 来 [目的]'" [shape=box];
+    "有清单？" [shape=diamond];
+    "为每个项目创建 TodoWrite 待办" [shape=box];
+    "完全遵循技能" [shape=box];
+    "响应（包括澄清）" [shape=doublecircle];
+
+    "收到用户消息" -> "可能任何技能适用？";
+    "可能任何技能适用？" -> "调用 Skill 工具" [label="是，即使 1%"];
+    "可能任何技能适用？" -> "响应（包括澄清）" [label="绝对不是"];
+    "调用 Skill 工具" -> "声明：'使用 [skill] 来 [目的]'";
+    "声明：'使用 [skill] 来 [目的]'" -> "有清单？";
+    "有清单？" -> "为每个项目创建 TodoWrite 待办" [label="是"];
+    "有清单？" -> "完全遵循技能" [label="否"];
+    "为每个项目创建 TodoWrite 待办" -> "完全遵循技能";
+}
+```
+
+## 红旗
+
+这些想法意味着停止 - 你正在合理化：
+
+| 想法 | 现实 |
+|---------|---------|
+| "这只是一个简单问题" | 问题是任务。检查技能。 |
+| "我需要先更多上下文" | 技能检查在澄清问题之前。 |
+| "让我先探索代码库" | 技能告诉你如何探索。先检查。 |
+| "我可以快速检查 git/文件" | 文件缺乏对话上下文。检查技能。 |
+| "让我先收集信息" | 技能告诉你如何收集信息。 |
+| "这不需要正式技能" | 如果技能存在，使用它。 |
+| "我记住这个技能" | 技能会演进。阅读当前版本。 |
+| "这不算作任务" | 操作 = 任务。检查技能。 |
+| "技能是过度的" | 简单的事情变得复杂。使用它。 |
+| "我会先做这一件事" | 在做任何事情之前检查。 |
+| "这感觉富有成效" | 无纪律的行动浪费时间。技能防止这一点。 |
+| "我知道那意味着什么" | 知道概念 ≠ 使用技能。调用它。 |
+
+## 技能优先级
+
+当多个技能可能适用时，使用此顺序：
+
+1. **流程技能优先**（bc-requirements-analysis、bc-execute-plans）- 这些确定如何处理任务
+2. **实施技能其次**（bc-execute-plans、bc-finish-a-dev）- 这些指导执行
+
+"让我们增加 X" → 首先 bc-requirements-analysis，然后实施技能。
+"让我们创建 Y" → 首先 bc-requirements-analysis，然后实施技能。
+"我想增加 Z" → 首先 bc-requirements-analysis，然后实施技能。
+"实现这个功能" → 首先 bc-execute-plans，然后领域特定技能。
+
+## 技能类型
+
+**刚性**（TDD、debugging）：完全遵循。不要适应掉纪律。
+
+**灵活**（模式）：将原则适应到上下文。
+
+技能本身告诉你哪种。
+
+## 用户指令
+
+指令说明 WHAT，而不是 HOW。"添加 X"或"修复 Y"并不意味着跳过工作流。

package/bcoder/skills/bc-write-plans/SKILL.md

@@ -0,0 +1,95 @@
+---
+name: bc-write-plans
+description: 当你有针对多步骤任务的规格或要求时使用，在接触代码之前
+---
+
+# 编写计划
+
+## 概述
+
+编写全面的实施计划，假设工程师对我们的代码库零上下文且品味可疑。记录他们需要知道的一切：每个任务要接触哪些文件、代码、他们可能需要检查的测试、文档、如何测试它。给他们整个计划作为可咬大小的任务。DRY。YAGNI。TDD。频繁提交。
+
+假设他们是熟练的开发人员，但几乎不了解我们的工具集或问题域。假设他们不太了解良好的测试设计。
+
+**开始时声明：** "我正在使用 编写计划 ( bc-write-plans ) 技能来创建实施计划。"
+
+**将计划保存到：** `docs/plans/YYYY-MM-DD-<feature-name>.md`
+
+## 小颗粒度任务
+
+**每个步骤是一个动作（2-5 分钟）：**
+- "编写失败测试" - 步骤
+- "运行以确保它失败" - 步骤
+- "编写最小代码以使测试通过" - 步骤
+- "运行测试并确保它们通过" - 步骤
+- "提交" - 步骤
+
+## 计划文档头
+
+**每个计划必须以此头开始：**
+
+```markdown
+# [功能名称] 实施计划
+
+> **对于 AI编程工具 （如 Claude 或 Cursor 等）：** 必需子技能：使用 execute-plans 来逐任务实施此计划。
+
+**目标：** [一句话描述这构建什么]
+
+**架构：** [2-3 句话关于方法]
+
+**技术栈：** [关键技术/库]
+
+---
+```
+
+## 任务结构
+
+```markdown
+### 任务 N：[组件名称]
+
+**文件：**
+- 创建：`exact/path/to/file.py`
+- 修改：`exact/path/to/existing.py:123-145`
+- 测试：`tests/exact/path/to/test.py`
+
+**步骤 1：编写失败测试**
+
+```python
+def test_specific_behavior():
+    result = function(input)
+    assert result == expected
+```
+
+**步骤 2：运行测试以验证它失败**
+
+运行：`pytest tests/path/test.py::test_name -v`
+预期：失败并显示"function not defined"
+
+**步骤 3：编写最小实现**
+
+```python
+def function(input):
+    return expected
+```
+
+**步骤 4：运行测试以验证它通过**
+
+运行：`pytest tests/path/test.py::test_name -v`
+预期：通过
+
+## 记住
+- 始终精确的文件路径
+- 计划中的完整代码（不是"添加验证"）
+- 带有预期输出的精确命令
+- 使用 @ 语法引用相关技能
+- DRY、YAGNI、TDD、频繁提交
+
+## 执行交接
+
+保存计划后，提供执行选择：
+
+**"计划完成并保存到 `docs/plans/<filename>.md`。两个执行选项："**
+
+**1. 检查文档** - 查看设计及计划文档，确保它是正确的
+
+**2. 立即执行** - 在 worktree 中打开新会话，使用 bc-execute-plans 批量执行并带检查点