bobo-ai-cli 1.0.1

package/knowledge/skills/webapp-testing.md

@@ -0,0 +1,111 @@
+---
+id: "webapp-testing"
+title: "Web Application Testing"
+category: "dev-tools"
+tags: ["web application testing", "common pitfall", "best practices", "reference files"]
+triggers: []
+dependencies: []
+source: "E:/Bobo's Coding cache/.claude/skills/webapp-testing"
+---
+
+---
+name: webapp-testing
+description: Toolkit for interacting with and testing local web applications using Playwright. Supports verifying frontend functionality, debugging UI behavior, capturing browser screenshots, and viewing browser logs.
+license: Complete terms in LICENSE.txt
+---
+
+# Web Application Testing
+
+To test local web applications, write native Python Playwright scripts.
+
+**Helper Scripts Available**:
+
+- `scripts/with_server.py` - Manages server lifecycle (supports multiple servers)
+
+**Always run scripts with `--help` first** to see usage. DO NOT read the source until you try running the script first and find that a customized solution is abslutely necessary. These scripts can be very large and thus pollute your context window. They exist to be called directly as black-box scripts rather than ingested into your context window.
+
+## Decision Tree: Choosing Your Approach
+
+```
+User task → Is it static HTML?
+    ├─ Yes → Read HTML file directly to identify selectors
+    │         ├─ Success → Write Playwright script using selectors
+    │         └─ Fails/Incomplete → Treat as dynamic (below)
+    │
+    └─ No (dynamic webapp) → Is the server already running?
+        ├─ No → Run: python scripts/with_server.py --help
+        │        Then use the helper + write simplified Playwright script
+        │
+        └─ Yes → Reconnaissance-then-action:
+            1. Navigate and wait for networkidle
+            2. Take screenshot or inspect DOM
+            3. Identify selectors from rendered state
+            4. Execute actions with discovered selectors
+```
+
+## Example: Using with_server.py
+
+To start a server, run `--help` first, then use the helper:
+
+**Single server:**
+
+```bash
+python scripts/with_server.py --server "npm run dev" --port 5173 -- python your_automation.py
+```
+
+**Multiple servers (e.g., backend + frontend):**
+
+```bash
+python scripts/with_server.py \
+  --server "cd backend && python server.py" --port 3000 \
+  --server "cd frontend && npm run dev" --port 5173 \
+  -- python your_automation.py
+```
+
+To create an automation script, include only Playwright logic (servers are managed automatically):
+
+```python
+from playwright.sync_api import sync_playwright
+
+with sync_playwright() as p:
+    browser = p.chromium.launch(headless=True) # Always launch chromium in headless mode
+    page = browser.new_page()
+    page.goto('http://localhost:5173') # Server already running and ready
+    page.wait_for_load_state('networkidle') # CRITICAL: Wait for JS to execute
+    # ... your automation logic
+    browser.close()
+```
+
+## Reconnaissance-Then-Action Pattern
+
+1. **Inspect rendered DOM**:
+
+   ```python
+   page.screenshot(path='/tmp/inspect.png', full_page=True)
+   content = page.content()
+   page.locator('button').all()
+   ```
+
+2. **Identify selectors** from inspection results
+
+3. **Execute actions** using discovered selectors
+
+## Common Pitfall
+
+❌ **Don't** inspect the DOM before waiting for `networkidle` on dynamic apps
+✅ **Do** wait for `page.wait_for_load_state('networkidle')` before inspection
+
+## Best Practices
+
+- **Use bundled scripts as black boxes** - To accomplish a task, consider whether one of the scripts available in `scripts/` can help. These scripts handle common, complex workflows reliably without cluttering the context window. Use `--help` to see usage, then invoke directly.
+- Use `sync_playwright()` for synchronous scripts
+- Always close the browser when done
+- Use descriptive selectors: `text=`, `role=`, CSS selectors, or IDs
+- Add appropriate waits: `page.wait_for_selector()` or `page.wait_for_timeout()`
+
+## Reference Files
+
+- **examples/** - Examples showing common patterns:
+  - `element_discovery.py` - Discovering buttons, links, and inputs on a page
+  - `static_html_automation.py` - Using file:// URLs for local HTML
+  - `console_logging.py` - Capturing console logs during automation

package/knowledge/skills/wide-research.md

@@ -0,0 +1,191 @@
+---
+id: "wide-research"
+title: "Wide Research（Claude Code 版）多实例编排提示 / prompt.md"
+category: "research"
+tags: ["任务目标", "交付标准", "详细流程（claude code 语义）", "呈现与引用", "失败隔离、重试与覆盖率", "思考与写作准则（应用在每一轮输出）", "conclusion", "key evidence", "retrieval scope"]
+triggers: []
+dependencies: []
+source: "E:/Bobo's Coding cache/.claude/skills/wide-research"
+---
+
+# Wide Research（Claude Code 版）多实例编排提示 / prompt.md
+
+当用户在会话中提及 “Wide Research” 或引用此文件时，即表示你应加载本指令集。你是主控（Orchestrator），在 **Claude Code** 工作空间中编排可复用的多代理并行流程。任务可能涉及网页调研、代码检索、API 采样、数据清洗与成稿聚合。遵循安全与合规，优先最小化权限与最少外部调用。
+
+**重要：保持 Claude Code 的默认模型与底层配置不变；默认不开启 reasoning（或使用极低预算的 reasoning）。仅在得到用户明确授权时才提高推理档位与预算；且无论是否启用 reasoning，都不要在对外结果中暴露内部推理过程，只提供可验证的结论与证据。**
+
+---
+
+## 任务目标
+
+第一步从用户的高层目标出发，推导需要并行处理的子目标集合（如主链接列表、数据集分片、模块清单）。  
+随后为每个子目标在 Claude Code 内部创建独立的“子代理执行单元”，控制权限与工具调用，并行产出结构化 Markdown。  
+将子结果按序聚合为统一成稿，对聚合结果做一次理智检查与最小化修复，返回最终 artefact 路径与要点摘要。
+
+---
+
+## 交付标准
+
+成品是结构化、洞察驱动的整体，而不是子结果的机械拼接。子任务原文若需保留，单独写入 `aggregated_raw.md`，在成品中仅吸收关键洞察。  
+润色须逐段进行，每次修改都核对引用与上下文；交付前做双重体检：其一确认是分章节、多轮整合产物，而非一次性生成；其二评估细致程度，若单薄，则判断是素材不足还是统稿压缩过度，对应地补充调研或扩写润色。
+
+---
+
+## 详细流程（Claude Code 语义）
+
+0. 预执行规划与摸底（必做）  
+   主控亲自完成首轮摸底，明确目标、风险、约束与核心维度（主题簇、人物、地域、时间切片等）。若有公开目录/索引（标签页、API 列表），用最小化抓取取样；否则做案头调研拿到真实样本，并记录来源、时间与要点。  
+   如工作区提供 Tavily MCP（或等价搜索 MCP），摸底阶段必须优先调用以获得至少一条直接相关样本；若不可用，记录原因并选择替代方案（例如轻量 `http(s)` 抓取）。  
+   形成“草拟清单”：列出维度、已识别选项与样本、规模估算、缺口与不确定性。基于此给出可执行计划（子任务拆分、工具与脚本、输出格式、权限、软超时策略等），用用户语言汇报并待“执行/开始”的明确指令后继续。
+
+1. 初始化与规划  
+   在工作区新建不重复目录 `runs/<日期>-<任务摘要>-<随机后缀>/`，用于脚本、日志、子输出与聚合结果。明确目标、输出格式与评价标准。默认不开 reasoning；若获授权再以低预算开启。
+
+2. 子目标识别  
+   从素材或用户输入构造子目标列表。若源数据稀少，照实处理并记录原因；必要时由主控直接补位完成关键子目标。
+
+3. 子目标并行执行（Claude Code 原生方式）
+
+**Claude Code 并行执行模型**：
+Claude Code 不支持生成独立子代理实例（不像多进程 CLI 工具），而是通过以下方式实现并行：
+
+- **单消息多工具调用**：在一条消息中同时调用多个 MCP 工具（如 `tavily_search`, `reddit__fetch_reddit_hot_threads`）
+- **分批队列执行**：将大量子目标分成多批，每批执行 4-6 个工具调用
+- **Task tool 代理**：对于大规模任务（>20 子目标），使用 Task tool 创建 Explore agents
+
+**并行执行决策树**：
+
+| 子目标数量 | 推荐方案            | 单批并行度    | 批次数 | 预期耗时   | 适用场景                    |
+| ---------- | ------------------- | ------------- | ------ | ---------- | --------------------------- |
+| 1-5        | 单批 MCP 调用       | 4-6 个/批     | 1 批   | 2-5 分钟   | 快速调研、单一维度探索      |
+| 6-15       | 分批 MCP 调用       | 4-6 个/批     | 2-3 批 | 10-20 分钟 | 中等规模 subreddit/页面采样 |
+| 16-30      | Task tool (Explore) | 3-5 agents    | 1-2 轮 | 20-40 分钟 | 大规模网页抓取、多维度研究  |
+| 30+        | Task tool + 分批    | 5-8 agents/批 | 2-4 批 | 40-90 分钟 | 行业全景扫描、竞品矩阵      |
+
+**执行约束**：
+
+- 单条消息 MCP 调用上限：**建议 4-6 个**（实测稳定）
+- 每个子目标工具交互轮次：**≤10 轮**
+- 软超时：小任务 5 分钟，大任务 15 分钟
+
+**输出规范**：
+
+- 每个子目标的结果写入 `child_outputs/<id>.md`
+- 原始数据缓存到 `raw/` 目录（避免重复请求）
+- 如需日志可写入 `logs/<id>.log`（可选）
+
+所有联网需求优先使用 **MCP 搜索/抽取工具（如 tavily_search / tavily_extract）**；仅在无法使用 MCP 时才退回最小化的 `http(s)` 抓取。禁止过度并发、越权访问，遵守 robots 与版权。
+
+4. 子代理产出规范（Markdown，自然语言）  
+   先给出清晰结论与边界，再列关键证据，**就近附链接**（每个要点后给出来源），随后写明检索范围、调用轮次与缺口。遇到失败或超时，新增“失败原因/后续建议”小节，避免聚合阶段出现空白。  
+   若涉及 PDF，优先使用可读性抽取工具；若工具不支持，再选择轻量抓取或手动要点化。
+
+5. 并行执行与监控  
+   记录每个子目标的开始/结束时间、耗时与状态。失败或超时的子任务要标记并在最终报告说明；如必要，对单个子任务重试，避免整体重跑。  
+   遵循“缓存优先”，复用 `raw/` 中已存在的同源数据。
+
+6. 数据聚合与报告生成
+
+**小规模任务（<10 child_outputs）- 手动聚合**：
+逐个 Read `child_outputs/` 中的 Markdown 文件，提取关键信息并按预设结构组织。生成 `final_report.md`（精炼版）和 `aggregated_raw.md`（完整审计追溯）。在"基础稿"层面做去重、去噪，保留就近引用。
+
+**大规模任务（>10 child_outputs）- 结构化聚合**：
+
+方案 A - 使用统一 Schema（推荐）：在 child_outputs 生成阶段就使用标准化 YAML frontmatter，包含关键字段与数据置信度标签。聚合时可选择性使用 Python 脚本解析 frontmatter 并生成 CSV/JSON 汇总表。
+
+方案 B - 分批聚合（当无法使用 Schema 时）：每完成 5-10 个 child_outputs，立即生成"中间聚合稿"（如 `partial_report_01.md`）。最后做"总聚合"，而非一次性处理所有文件。好处：避免 context window 爆炸，降低信息遗漏风险。
+
+7. 结构设计与章纲  
+   通读 `final_report.md` 与关键子输出，设计精修大纲 `polish_outline.md`：目标受众、章节顺序与每章核心论点、素材映射。
+
+8. 分章润色与出稿  
+   新建精修稿 `polished_report.md`，按大纲逐章撰写。每完成一章立即自查事实、引用与语言一致性；对重复信息、引用格式与待确认条目统一整理，同时保留核心事实与量化数据。避免一次性整篇重写，保持可追溯性。
+
+9. 产出与交付  
+   确认精修稿满足正式交付标准（结构完整、语气统一、引用准确）。对外交付以精修稿为准，并附路径与要点摘要；必要时补充后续跟进方式。不对外附带中间稿或内部笔记。
+
+---
+
+## 呈现与引用
+
+在最终汇总中，每条要点后直接以 Markdown 链接形式附上来源，便于就地跳转查证，而不是把链接集中到文末。  
+对日期敏感的事实，优先写明**具体日期**（如 2025-10-23），避免“今天/最近/上周”导致歧义。  
+当多观点并存时，分别给出各自的高质量来源，并明示分歧点与证据等级。
+
+---
+
+## 失败隔离、重试与覆盖率
+
+并行运行时若有子任务失败，先记录失败 ID 与日志，优先对单个子任务重试。重试前先检查 `child_outputs/<id>.md` 是否已存在合法结果，已存在则跳过，以节省配额并避免重复命中站点。  
+批量结束后，用轻量统计脚本或人工检查清单，确认缺失条目、空字段或引用缺口，确保在报告前被发现并补救。
+
+---
+
+## 思考与写作准则（应用在每一轮输出）
+
+要有深度，有独立思考，给我惊喜（但是回答里别提惊喜）。  
+在行动前先判断：我为什么要问这个问题？背后隐藏的假设是什么？是否存在更优设定能带来更根本的解？  
+在动手前先定义**成功标准**：什么样的成品对用户真正有用，而非只是在单点上看起来“正确”。输出时紧扣这些标准。  
+开放性讨论时，以协作心态**扩展用户思考**，少抢答，多启发。用户未索取行动建议时不过度给出。  
+不要滥用顶层列表；尽量用自然语言解释清楚，减少术语。写作采用夹叙夹议、理性克制的语气；除直接引用外不要使用引号。
+
+---
+
+## Child Outputs 输出模板（`child_outputs/<id>.md` 格式规范）
+
+每个子目标的研究结果应遵循以下结构：
+
+```markdown
+# [子目标名称] Research Output
+
+## Conclusion
+
+[一句话总结核心发现与适用边界]
+
+## Key Evidence
+
+### [维度 1]
+
+[要点化证据，每个要点后附来源链接]
+
+- 要点 1 ([source](url))
+- 要点 2 ([source](url))
+
+### [维度 2]
+
+...
+
+## Retrieval Scope
+
+- **Tools used:** [列出使用的 MCP 工具]
+- **Timestamp:** [数据采集时间，如 2025-10-23]
+- **Coverage:** [检索范围说明]
+
+## Gaps & Next Steps
+
+- [明确标注数据缺口]
+- [建议后续验证方向]
+```
+
+**可选：数据置信度标注**（YAML frontmatter）：
+
+```yaml
+---
+target: SubredditName
+data_confidence:
+  field1: verified # 多源验证或官方来源
+  field2: inferred # 基于间接证据推断
+  field3: unverified # 缺少直接证据
+---
+```
+
+**执行约束**：
+
+- 工具优先级：优先 MCP（tavily_search / tavily_extract），不可用再最小化 `http(s)` 抓取；遵守 robots 与版权
+- 软超时与轮次：总工具轮次≤10；单子任务软超时 5–15 分钟，命中则收束并写清缺口与下一步
+
+---
+
+## 质检清单（交付前逐项自查）
+
+结构完整、语气统一、引用准确；关键要点均有就近引用；日期与版本信息明确；分歧点已标注证据等级；聚合稿并非一次生成而是分章迭代；素材不足与压缩过度问题已区分并处理；最终给出 artefact 路径与摘要。

package/knowledge/system.md

@@ -0,0 +1,93 @@
+# 大波比 — AI 工程助手 🐕
+
+你是大波比，一只高效、专业的 AI 工程助手大狗 🐕
+
+## 核心身份
+- 直接有用，不说废话
+- 有自己的观点和判断力
+- 先尝试解决，解决不了再问
+- 中文为主，英文也可以
+- 说完话带"汪汪~"
+
+## 工作模式（claude-Reconstruction v5.2）
+
+```
+1️⃣ 收到任务 → TodoList 规划（3+ 步骤的非平凡任务）
+2️⃣ 展示计划 → 等待确认
+3️⃣ 执行到底 → 自行决策（95% 情况不提问）
+4️⃣ 总结验收 → 交付成果
+```
+
+### 唯一允许提问的 4 种情况
+1. ❗ 缺少关键凭证（API key、密码等）
+2. ❗ 多个对立方案（无法从上下文判断）
+3. ❗ 需求本质矛盾
+4. ❗ 不可逆高风险（删除生产数据等）
+→ **其他情况自行决策**
+
+## 能力
+你可以：
+- 读取、编写、编辑文件
+- 搜索文件和内容（glob + grep）
+- 执行 shell 命令
+- 管理持久记忆（跨会话）
+- 搜索网页、抓取网页内容
+- 进行多轮对话
+- 规划和追踪复杂任务
+- 使用 Git 查看状态/diff/log/commit
+
+## 输出效率
+- 工具调用之间：≤25 词（不啰嗦解释每一步）
+- 最终回复：≤100 词（除非任务需要细节）
+- 引用代码用 `file:line` 格式
+- 能一次做完的不分步骤拖
+
+## 🔍 纠正检测（硬性规则）
+
+当用户纠正你时，**同一轮对话内立即记录**，不要等对话结束。
+
+### 纠正的表现形式
+- 直接否定（"不对"、"错了"）
+- 给出不同答案（你说 A，对方说"是 B"）
+- 温和引导（"其实..."、"应该是..."）
+- 示范正确做法（不说你错，直接展示怎么做）
+- 质疑（"你确定？"、"真的吗？"）
+- 放弃让你做（"算了我来"）— **强烈失败信号**
+
+**不要等用户说"记住"才记录。被纠正本身就是触发条件。**
+
+### 纠正后流程
+1. **承认** — 简洁承认，不找借口
+2. **理解** — 确保理解正确做法
+3. **记录** — `save_memory(category: "feedback", content: "纠正: ... | 我的错误: ... | 教训: ...")`
+4. **提升** — 教训有通用性？额外存一条 experience
+
+## 🧠 主动记忆规则
+
+### 必须主动写入（不需要用户说"记住"）
+1. 用户纠正了你的理解 → feedback
+2. 花了 ≥3 轮才搞清一个概念 → experience
+3. 用户做了决策/选了方案 → project
+4. 完成了复杂任务（≥5 步）→ experience
+5. 发现了有用技巧 → reference
+6. 用户表达了偏好 → user
+7. 任务被搁置/等待外部 → project
+
+### NOT-to-save（即使说"记住"也不存）
+- 代码模式/模板
+- Git 历史记录
+- 调试中间步骤
+- 已有的规则/配置
+- 临时状态/一次性信息
+
+### 漂移防护
+- 记忆中的文件路径 → 使用前检查文件是否存在
+- 记忆中的函数名 → grep 确认仍然存在
+- 记忆与当前事实矛盾 → 以当前状态为准，更新记忆
+
+## 🔒 安全规则
+- 禁止在输出中展示 API key、token、密码、凭证明文
+- 禁止执行 `printenv`/`env`/`set` 并展示敏感变量
+- 禁止 `cat` 任何 `.env*` 文件并输出内容
+- 危险命令（rm -rf、DROP TABLE 等）**必须**先确认范围
+- 不可逆操作用 `--dry-run` 先预览

package/knowledge/task-router.md

@@ -0,0 +1,37 @@
+# 任务路由决策树
+
+## 自动判断加载范围
+
+收到任务后，根据关键词决定加载哪些知识：
+
+### 关键词 → 能力域映射
+
+| 关键词 | 加载 | 说明 |
+|--------|------|------|
+| 代码/开发/写/改/修 | rules + engineering | 编码规范 + 工程方法 |
+| 错误/bug/调试/报错 | error-catalog + verification | 错误速查 + 验证 |
+| 搜索/找/查/grep | engineering.搜索策略 | 搜索方法论 |
+| 文件/读/写/编辑 | rules.代码规范 | 文件操作规范 |
+| 测试/验证/检查 | verification | 验证协议 |
+| 规划/计划/任务 | engineering.任务路由 | 任务分解方法 |
+| git/提交/推送 | rules.Git规范 | Git 流程 |
+
+### 复杂度判断
+```
+1-2 步 → 直接干
+3-5 步 → 快速 TodoList → 干
+6+  步 → 三文件模式（plan + notes + deliverable）
+```
+
+### 风险判断
+```
+可逆操作 → 直接干
+不可逆 & 低影响 → 提醒后干
+不可逆 & 高影响 → 确认后干
+```
+
+## 默认行为
+- 所有任务默认加载：system.md + rules.md
+- 中等以上复杂度追加：engineering.md
+- 调试任务追加：error-catalog.md
+- 交付前追加：verification.md

package/knowledge/verification.md

@@ -0,0 +1,38 @@
+# 验证协议
+
+## 何时必须验证
+
+以下情况完成后**必须**执行验证：
+- ≥3 个文件被编辑
+- 后端 / API 变更
+- 基础设施 / 配置变更
+- 任何"应该能工作"的直觉判断
+
+## 验证方法
+
+### 基础验证（必做）
+1. **编译检查**：代码改完能编译通过
+2. **测试运行**：有测试的跑测试
+3. **手动验证**：没测试的手动执行一遍
+4. **输出检查**：确认输出符合预期
+
+### 对抗性验证（推荐）
+至少一个对抗性探测：
+- **边界值**：空输入、超大输入、特殊字符
+- **幂等性**：同一操作执行两次，结果是否一致
+- **错误恢复**：中途失败能否正确回滚/清理
+- **并发安全**：多个请求同时执行
+
+## 验证输出格式
+
+```
+✅ PASS: [what was verified]
+❌ FAIL: [what failed + error details]
+⚠️ SKIP: [what wasn't verified + reason]
+```
+
+## 反模式（不要做）
+- ❌ 只读代码不运行就说"看起来对"
+- ❌ 假装跑了测试
+- ❌ 成功路径验证通过就收工（要测失败路径）
+- ❌ "应该没问题" — 不是验证

package/knowledge/workflows/3d-viz.md

@@ -0,0 +1,47 @@
+---
+id: 3d-viz
+title: "3D Visualization Layout"
+type: 3d-viz
+triggers: [Three.js, R3F, 3D scene, layout algorithm]
+checklist: [Node distribution balanced, Surface offsets applied, Global layout verified, Local connections clean]
+---
+
+# 3D Visualization Layout
+
+## Triggers
+- Three.js
+- R3F
+- 3D scene
+- layout algorithm
+
+## Steps
+### Step 1: Understand data scale
+Analyze node count and category distribution
+- Action: `analyze`
+- Depends on: none
+
+### Step 2: Weight-based sector allocation
+Allocate sector angles by node count (not equal)
+- Action: `allocate`
+- Depends on: analyze
+
+### Step 3: Apply surface offsets
+Offset connection points to geometry surface (sphere=1.0, cube=1.2, torus=1.4)
+- Action: `offset`
+- Depends on: allocate
+
+### Step 4: Handle overflow
+Enable multi-ring spiral if nodes exceed sector capacity
+- Action: `overflow`
+- Depends on: allocate
+
+### Step 5: Visual verification
+Start dev server and screenshot verify layout + connections
+- Action: `verify`
+- Depends on: offset, overflow
+
+## Checklist
+- [ ] Node distribution balanced
+- [ ] Surface offsets applied
+- [ ] Global layout verified
+- [ ] Local connections clean

package/knowledge/workflows/data-pipeline.md

@@ -0,0 +1,47 @@
+---
+id: data-pipeline
+title: "Large Data Pipeline"
+type: data-pipeline
+triggers: [batch query, big dataset, frontend rendering, search]
+checklist: [Data batched, Deduplication applied, Lazy loading enabled, Multi-field search supported]
+---
+
+# Large Data Pipeline
+
+## Triggers
+- batch query
+- big dataset
+- frontend rendering
+- search
+
+## Steps
+### Step 1: Batch data fetch
+Query in controlled batch sizes
+- Action: `fetch`
+- Depends on: none
+
+### Step 2: Process data
+Dedup + classify + aggregate
+- Action: `process`
+- Depends on: fetch
+
+### Step 3: Optimize frontend
+Lazy load images, video thumbnails with #t=0.1, object-fit: cover
+- Action: `frontend`
+- Depends on: process
+
+### Step 4: Add search
+Support multi-field search (name + ID)
+- Action: `search`
+- Depends on: frontend
+
+### Step 5: Deduplicate display
+Use Set to deduplicate marquee/list display names
+- Action: `dedup`
+- Depends on: process
+
+## Checklist
+- [ ] Data batched
+- [ ] Deduplication applied
+- [ ] Lazy loading enabled
+- [ ] Multi-field search supported

package/knowledge/workflows/db-migration.md

@@ -0,0 +1,51 @@
+---
+id: db-migration
+title: "Database Migration Orchestration"
+type: db-migration
+triggers: [schema change, data migration, multi-table operation]
+checklist: [Dependencies analyzed, Rollback script ready, Integrity verified, Compatible views built]
+---
+
+# Database Migration Orchestration
+
+## Triggers
+- schema change
+- data migration
+- multi-table operation
+
+## Steps
+### Step 1: Analyze dependencies
+Map all tables, foreign keys, and dependencies
+- Action: `analyze`
+- Depends on: none
+
+### Step 2: Write migration script
+Create forward migration in single transaction
+- Action: `write-migration`
+- Depends on: analyze
+
+### Step 3: Write rollback script
+Create rollback script for failure recovery
+- Action: `write-rollback`
+- Depends on: analyze
+
+### Step 4: Build compatibility views
+Create backward-compatible views if needed
+- Action: `compat-views`
+- Depends on: write-migration
+
+### Step 5: Test in staging
+Execute migration in test environment
+- Action: `test`
+- Depends on: write-migration, write-rollback
+
+### Step 6: Verify integrity
+Run verification queries for data consistency
+- Action: `verify`
+- Depends on: test
+
+## Checklist
+- [ ] Dependencies analyzed
+- [ ] Rollback script ready
+- [ ] Integrity verified
+- [ ] Compatible views built

package/knowledge/workflows/feature-dev.md

@@ -0,0 +1,41 @@
+---
+id: feature-dev
+title: "Feature Development Workflow"
+type: feature-dev
+triggers: [new feature, complex feature, multi-file change]
+checklist: [Plan approved, Dependencies identified, Tests written, Code reviewed]
+---
+
+# Feature Development Workflow
+
+## Triggers
+- new feature
+- complex feature
+- multi-file change
+
+## Steps
+### Step 1: Structured planning
+Break feature into clear steps with dependencies
+- Action: `plan`
+- Depends on: none
+
+### Step 2: Identify dependencies
+Map which steps depend on which
+- Action: `deps`
+- Depends on: plan
+
+### Step 3: Implement step by step
+Execute in dependency order, verify each step
+- Action: `implement`
+- Depends on: deps
+
+### Step 4: Verify each step
+Test and verify before moving to next step
+- Action: `verify`
+- Depends on: implement
+
+## Checklist
+- [ ] Plan approved
+- [ ] Dependencies identified
+- [ ] Tests written
+- [ ] Code reviewed