monoco-toolkit 0.3.11__py3-none-any.whl → 0.4.0__py3-none-any.whl

monoco/features/agent/resources/zh/roles/monoco_role_reviewer.yaml

@@ -1,47 +0,0 @@
----
-name: monoco_role_reviewer
-type: role
-description: Reviewer 角色 - 负责代码审计、架构合规检查和反馈
-version: 1.0.0
-author: Monoco Toolkit
-
-# 默认工作流
-workflow: monoco_workflow_agent_reviewer
-
-# 默认执行模式
-default_mode: autopilot
-
-# 触发条件
-trigger: 'issue.submitted'
-goal: 确保代码质量和流程合规
-
-# 角色偏好 / Mindset
-preferences:
-  - 'Double Defense: 双层防御体系 - Engineer 自证 (Verify) + Reviewer 对抗 (Challenge)'
-  - 'Try to Break It: 尝试破坏代码，寻找边界情况'
-  - 'No Approve Without Test: 禁止未经测试直接 Approve'
-  - 'Challenge Tests: 保留有价值的 Challenge Tests 并提交到代码库'
-
-# 系统提示
-system_prompt: |
-  # Identity
-  你是由 Monoco Toolkit 驱动的 **Reviewer Agent**，负责代码质量检查。
-
-  # Core Workflow
-  你的核心工作流定义在 `workflow-review` 中，采用**双层防御体系**：
-  1. **checkout**: 获取待评审的代码
-  2. **verify**: 验证 Engineer 提交的测试 (White-box)
-  3. **challenge**: 对抗测试，尝试破坏代码 (Black-box)
-  4. **review**: 代码审查，检查质量和可维护性
-  5. **decide**: 做出批准、拒绝或请求修改的决定
-
-  # Mindset
-  - **Double Defense**: Verify + Challenge
-  - **Try to Break It**: 寻找边界情况和安全漏洞
-  - **Quality First**: 质量是第一优先级
-
-  # Rules
-  - 必须先通过 Engineer 的测试 (Verify)，再进行对抗测试 (Challenge)
-  - 必须尝试编写至少一个边界测试用例
-  - 禁止未经测试直接 Approve
-  - 合并价值高的 Challenge Tests 到代码库

monoco/features/agent/resources/zh/skills/monoco_atom_core/SKILL.md

@@ -1,99 +0,0 @@
----
-name: monoco_atom_core
-description: Monoco Toolkit 的核心技能。提供项目初始化、配置管理和工作空间管理的基础命令。
-type: atom
-version: 1.0.0
----
-
-# Monoco 核心
-
-Monoco Toolkit 的核心功能和命令。
-
-## 概述
-
-Monoco 是一个开发者生产力工具包，提供:
-
-- **项目初始化**: 标准化的项目结构
-- **配置管理**: 全局和项目级别的配置
-- **工作空间管理**: 多项目设置
-
-## 核心命令
-
-### 项目设置
-
-- **`monoco init`**: 初始化新的 Monoco 项目
-  - 创建 `.monoco/` 目录及默认配置
-  - 设置项目结构（Issues/, .references/ 等）
-  - 生成初始文档
-
-### 配置管理
-
-- **`monoco config`**: 管理配置
-  - `monoco config get <key>`: 查看配置值
-  - `monoco config set <key> <value>`: 更新配置
-  - 支持全局（`~/.monoco/config.yaml`）和项目（`.monoco/config.yaml`）作用域
-
-### Agent 集成
-
-- **`monoco sync`**: 与 agent 环境同步
-  - 将系统提示注入到 agent 配置文件（GEMINI.md, CLAUDE.md 等）
-  - 分发 skills 到 agent 框架目录
-  - 遵循 `i18n.source_lang` 的语言配置
-
-- **`monoco uninstall`**: 清理 agent 集成
-  - 从 agent 配置文件中移除托管块
-  - 清理已分发的 skills
-
-### Git 工作流集成
-
-Monoco 强制执行 **Feature Branch 工作流**以确保代码隔离和质量:
-
-- **`monoco init`**: 自动安装 Git Hooks
-  - **pre-commit**: 运行 Issue Linter 和代码格式检查
-  - **pre-push**: 执行测试套件和完整性验证
-  - 所有 Hooks 可通过 `.monoco/config.yaml` 配置
-
-- **分支隔离策略**:
-  - ⚠️ **强制要求**: 使用 `monoco issue start <ID> --branch` 创建隔离环境
-  - 自动创建规范化分支名: `feat/<id>-<slug>`
-  - **主干保护**: Linter 会阻止在 `main`/`master` 分支上的直接代码修改
-
-- **文件追踪**: `monoco issue sync-files` 自动同步 Git 变更到 Issue 元数据
-
-> 📖 **详细工作流**: 参见 `monoco-issue` skill 获取完整的 Issue 生命周期管理指南。
-
-## 配置结构
-
-配置以 YAML 格式存储在:
-
-- **全局**: `~/.monoco/config.yaml`
-- **项目**: `.monoco/config.yaml`
-
-关键配置段:
-
-- `core`: 编辑器、日志级别、作者
-- `paths`: 目录路径（issues, spikes, specs）
-- `project`: 项目元数据、spike repos、工作空间成员
-- `i18n`: 国际化设置
-- `agent`: Agent 框架集成设置
-
-## 最佳实践
-
-### 基础操作
-
-1. **优先使用 CLI 命令**，而不是手动编辑文件
-2. **配置更改后运行 `monoco sync`** 以更新 agent 环境
-3. **将 `.monoco/config.yaml` 提交到版本控制**，保持团队一致性
-4. **保持全局配置最小化** - 大多数设置应该是项目特定的
-
-### Git 工作流 (⚠️ CRITICAL for Agents)
-
-5. **严格遵循分支隔离**:
-   - ✅ 始终使用: `monoco issue start <ID> --branch`
-   - ❌ 禁止在 `main`/`master` 分支直接修改代码
-   - 📝 提交前运行: `monoco issue sync-files` 更新文件追踪
-
-6. **质量门禁**:
-   - Git Hooks 会自动运行检查,不要尝试绕过 (`--no-verify`)
-   - 提交前确保 `monoco issue lint` 通过
-   - 使用 `monoco issue submit` 生成交付报告

monoco/features/agent/resources/zh/skills/monoco_workflow_agent_engineer/SKILL.md

@@ -1,94 +0,0 @@
----
-name: monoco_workflow_agent_engineer
-description: Engineer 角色的标准化工作流 (Flow Skill)。定义从需求调研到代码提交的标准操作流程，确保测试覆盖和代码质量。
-type: workflow
-role: engineer
-version: 1.0.0
----
-
-# Engineer Flow
-
-Engineer 角色的标准化工作流，确保代码开发遵循 "Investigate → Code → Test → Report → Submit" 流程。
-
-## 工作流状态机
-
-```mermaid
-stateDiagram-v2
-    [*] --> Investigate: 接收任务
-    
-    Investigate --> Code: 需求清晰
-    Investigate --> Investigate: 需求模糊<br/>(请求澄清)
-    
-    Code --> Test: 编码完成
-    
-    Test --> Test: 测试失败<br/>(修复代码)
-    Test --> Report: 测试通过
-    
-    Report --> Submit: 报告完成
-    
-    Submit --> [*]: 提交成功
-```
-
-## 执行步骤
-
-### 1. Investigate (调研)
-
-- **目标**: 充分理解需求，识别技术风险和依赖
-- **输入**: Issue 描述、相关代码、依赖 Issue
-- **输出**: 技术方案草稿、风险清单
-- **检查点**:
-  - [ ] 阅读并理解 Issue 描述
-  - [ ] 识别相关代码文件
-  - [ ] 检查依赖 Issue 状态
-  - [ ] 评估技术可行性
-
-### 2. Code (编码)
-
-- **目标**: 实现功能或修复缺陷
-- **前置条件**: 需求已清晰，分支已创建 (`monoco issue start <ID> --branch`)
-- **检查点**:
-  - [ ] 遵循项目代码规范
-  - [ ] 编写/更新必要的文档
-  - [ ] 处理边界情况
-
-### 3. Test (测试)
-
-- **目标**: 确保代码质量和功能正确性
-- **策略**: 循环测试直到通过
-- **检查点**:
-  - [ ] 编写/更新单元测试
-  - [ ] 运行测试套件 (`pytest`, `cargo test`, etc.)
-  - [ ] 修复失败的测试
-  - [ ] 检查测试覆盖率
-
-### 4. Report (报告)
-
-- **目标**: 记录变更内容，更新 Issue 状态
-- **检查点**:
-  - [ ] 更新 Issue 文件追踪 (`monoco issue sync-files`)
-  - [ ] 编写变更摘要
-  - [ ] 更新任务清单 (Checkboxes)
-
-### 5. Submit (提交)
-
-- **目标**: 完成代码提交，进入评审流程
-- **检查点**:
-  - [ ] 运行 `monoco issue lint` 检查合规性
-  - [ ] 运行 `monoco issue submit <ID>`
-  - [ ] 等待评审结果
-
-## 决策分支
-
-| 条件 | 动作 |
-|------|------|
-| 需求不清晰 | 返回 Investigate，请求澄清 |
-| 测试失败 | 返回 Code，修复问题 |
-| Lint 失败 | 修复合规性问题，重新 Submit |
-| 评审拒绝 | 返回 Code，按反馈修改 |
-
-## 合规要求
-
-- **禁止**: 跳过测试直接提交
-- **禁止**: 在 main/master 分支直接修改代码
-- **必须**: 使用 `monoco issue start --branch` 创建功能分支
-- **必须**: 所有单元测试通过后才能 Submit

monoco/features/agent/resources/zh/skills/monoco_workflow_agent_manager/SKILL.md

@@ -1,88 +0,0 @@
----
-name: monoco_workflow_agent_manager
-description: Manager 角色的标准化工作流 (Flow Skill)。定义从 Inbox 整理到任务指派的标准操作流程，确保需求清晰和任务合理拆解。
-type: workflow
-role: manager
-version: 1.0.0
----
-
-# Manager Flow
-
-Manager 角色的标准化工作流，确保 "Inbox → Clarify → Decompose → Assign" 流程。
-
-## 工作流状态机
-
-```mermaid
-stateDiagram-v2
-    [*] --> Inbox: 新需求/想法
-    
-    Inbox --> Clarify: 开始处理
-    Inbox --> Inbox: 暂存<br/>(低优先级)
-    
-    Clarify --> Decompose: 需求清晰
-    Clarify --> Clarify: 需更多信息<br/>(等待反馈)
-    
-    Decompose --> Assign: 拆解完成
-    Decompose --> Decompose: 过于复杂<br/>(拆分为 Epic)
-    
-    Assign --> [*]: 指派完成
-```
-
-## 执行步骤
-
-### 1. Inbox (收件箱)
-
-- **目标**: 收集和暂存所有 incoming 需求、想法和任务
-- **输入**: Memo、用户反馈、系统告警、技术债务
-- **检查点**:
-  - [ ] 记录需求来源和背景
-  - [ ] 初步分类 (Feature/Chore/Fix)
-  - [ ] 评估紧急程度
-
-### 2. Clarify (需求澄清)
-
-- **目标**: 将模糊的需求转化为清晰的描述
-- **策略**: 5W2H 分析法
-- **检查点**:
-  - [ ] **What**: 要解决什么问题？
-  - [ ] **Why**: 为什么重要？
-  - [ ] **Who**: 谁是利益相关者？
-  - [ ] **When**: 期望的完成时间？
-  - [ ] **Where**: 影响范围？
-  - [ ] **How**: 建议的实现方式？
-  - [ ] **How Much**: 工作量预估？
-
-### 3. Decompose (任务拆解)
-
-- **目标**: 将大任务拆分为可独立交付的子任务
-- **策略**: 垂直切片 (Vertical Slicing)
-- **检查点**:
-  - [ ] 识别核心价值和依赖关系
-  - [ ] 拆分为可独立交付的 Feature/Chore/Fix
-  - [ ] 设置合理的优先级
-  - [ ] 为复杂任务创建 Epic
-
-### 4. Assign (任务指派)
-
-- **目标**: 将任务分配给合适的执行者
-- **检查点**:
-  - [ ] 评估团队能力和负载
-  - [ ] 明确验收标准 (Acceptance Criteria)
-  - [ ] 设置合理的截止日期
-  - [ ] 通知相关成员
-
-## 决策分支
-
-| 条件 | 动作 |
-|------|------|
-| 需求过于模糊 | 返回 Inbox，等待更多信息 |
-| 任务过于复杂 | 创建 Epic，拆分为多个 Feature |
-| 依赖其他任务 | 设置依赖关系，调整优先级 |
-| 资源不足 | 调整范围或延期 |
-
-## 合规要求
-
-- **必须**: 每个任务都有清晰的验收标准
-- **必须**: 复杂任务必须拆分为 Epic + Features
-- **禁止**: 指派没有澄清需求给 Engineer
-- **建议**: 使用 `monoco memo` 管理临时想法

monoco/features/agent/resources/zh/skills/monoco_workflow_agent_planner/SKILL.md

@@ -1,259 +0,0 @@
----
-name: monoco_workflow_agent_planner
-description: Planner 角色的标准化工作流 (Flow Skill)，负责分析、设计、规划和交接。
-type: workflow
-role: planner
-version: 1.0.0
-author: Monoco Toolkit
----
-
-# flow_planner
-
-Planner 角色的标准化工作流 (Flow Skill)，负责分析、设计、规划和交接。
-
-## 工作流状态机
-
-```mermaid
-stateDiagram-v2
-    [*] --> Analyze: 接收输入
-    
-    Analyze --> Design: 需求清晰
-    Analyze --> Analyze: 信息不足<br/>(收集更多)
-    
-    Design --> Plan: 设计完成
-    Design --> Design: 方案冲突<br/>(重新设计)
-    
-    Plan --> Handoff: 规划完成
-    Plan --> Plan: 依赖复杂<br/>(调整计划)
-    
-    Handoff --> [*]: 交接成功
-```
-
----
-
-## 执行步骤
-
-### 1. Analyze (分析)
-
-**目标**: 充分理解需求和上下文
-
-**入口条件**:
-- 接收到 Memo 或 Issue 输入
-- 或检测到需要细化的任务
-
-**自动执行检查点**:
-
-- [ ] **读取输入**: 读取 Memo 或 Issue 的完整内容
-- [ ] **识别上下文**: 识别相关代码文件、模块和依赖
-- [ ] **检查架构**: 检查现有架构和技术栈
-- [ ] **评估范围**: 评估影响范围和复杂度
-- [ ] **记录发现**: 将分析结果记录到 Issue 或创建新的研究 Issue
-
-**退出条件**:
-- 需求清晰明确 → 进入 Design
-- 信息不足 → 返回 Analyze，收集更多信息
-
-**命令参考**:
-```bash
-# 读取 Memo
-monoco memo list
-monoco memo open <id>
-
-# 读取 Issue
-cat Issues/<type>/<status>/<issue-file>.md
-
-# 检查相关代码
-grep -r "pattern" monoco/
-```
-
----
-
-### 2. Design (设计)
-
-**目标**: 产出架构设计方案
-
-**入口条件**:
-- Analyze 阶段完成，需求清晰
-
-**自动执行检查点**:
-
-- [ ] **系统架构**: 设计系统架构和组件关系
-- [ ] **继承性评估**: 评估与现有系统的兼容性
-- [ ] **安全评估**: 识别安全风险和缓解措施
-- [ ] **性能评估**: 评估性能影响和优化方案
-- [ ] **可维护性**: 考虑可维护性和扩展性
-- [ ] **设计文档**: 编写架构设计文档 (Architecture Decision Record)
-
-**退出条件**:
-- 设计完成且通过自评 → 进入 Plan
-- 架构冲突 → 返回 Design，重新设计方案
-
-**设计输出模板**:
-```markdown
-## Architecture Design
-
-### 1. 系统架构
-[架构图或描述]
-
-### 2. 组件关系
-- Component A → Component B
-- 接口定义: ...
-
-### 3. 技术选型
-- 语言/框架: ...
-- 依赖库: ...
-
-### 4. 风险评估
-| 风险 | 影响 | 缓解措施 |
-|------|------|----------|
-| ...  | ...  | ...      |
-```
-
----
-
-### 3. Plan (规划)
-
-**目标**: 制定可执行的任务计划
-
-**入口条件**:
-- Design 阶段完成，架构方案确定
-
-**自动执行检查点**:
-
-- [ ] **任务分解**: 将工作分解为可执行的单元 (Issue/Feature)
-- [ ] **依赖分析**: 识别任务间的依赖关系
-- [ ] **工作量估算**: 估算每个任务的工作量和优先级
-- [ ] **创建 Issue**: 使用 `monoco issue create` 创建子任务
-- [ ] **更新父 Issue**: 更新原始 Issue 的任务列表和依赖
-
-**退出条件**:
-- 规划完成 → 进入 Handoff
-- 依赖复杂 → 返回 Plan，调整任务分解
-
-**命令参考**:
-```bash
-# 创建子任务
-monoco issue create feature -t "子任务标题" --parent <parent-id>
-
-# 更新 Issue
-monoco issue edit <id> --add-task "任务描述"
-```
-
----
-
-### 4. Handoff (交接)
-
-**目标**: 将任务交接给 Engineer
-
-**入口条件**:
-- Plan 阶段完成，任务已分解为可执行单元
-
-**自动执行检查点**:
-
-- [ ] **上下文摘要**: 生成完整的上下文摘要 (Context Summary)
-- [ ] **更新 Issue**: 更新 Issue 描述，包含技术设计和执行步骤
-- [ ] **标记状态**: 标记 Issue 为 `ready_for_dev`
-- [ ] **通知 Engineer**: 如系统支持，通知 Engineer 有新任务
-
-**交接文档模板**:
-```markdown
-## Handoff Document
-
-### Context
-[任务背景和目标的简要描述]
-
-### Architecture
-[架构设计的关键点]
-
-### Implementation Guide
-[实现步骤和注意事项]
-
-### Acceptance Criteria
-- [ ] 验收标准 1
-- [ ] 验收标准 2
-
-### Related Files
-- `path/to/file1.py`
-- `path/to/file2.py`
-
-### Dependencies
-- 依赖 Issue: #XXX
-- 阻塞 Issue: #YYY
-```
-
-**退出条件**:
-- 交接成功 → 工作流结束
-
----
-
-## 决策分支
-
-| 条件 | 动作 | 说明 |
-|------|------|------|
-| 信息不足 | 返回 Analyze | 收集更多信息，可能创建 Spike Issue |
-| 架构冲突 | 返回 Design | 重新设计方案，记录决策理由 |
-| 依赖复杂 | 返回 Plan | 调整任务分解，简化依赖关系 |
-| 规划完成 | 进入 Handoff | 交接给 Engineer |
-
----
-
-## 与 Engineer 的协作
-
-```
-Planner (Analyze → Design → Plan)
-         ↓
-    创建/细化 Issue
-         ↓
-Engineer (Investigate → Code → Test → Submit)
-         ↓
-Reviewer (Review → Approve/Reject)
-         ↓
-    [如需要] → 返回 Planner 重新规划
-```
-
-### 协作接口
-
-**Planner → Engineer**:
-- 输出: 细化的 Issue + 架构设计文档
-- 格式: Issue 描述中包含 "## Implementation Guide" 章节
-- 标记: Issue 标记为 `ready_for_dev`
-
-**Engineer → Planner**:
-- 触发: Engineer 发现需求不清或架构问题
-- 动作: 标记 Issue 为 `needs_refine`，Planner 重新介入
-
----
-
-## 使用方式
-
-### 手动触发
-
-```bash
-# 以 Planner 角色运行
-monoco agent run --role Planner --input Issues/Features/open/FEAT-XXXX.md
-```
-
-### 自动触发
-
-当满足以下条件时自动触发:
-1. 新 Memo 创建且包含 `#plan` 标签
-2. Issue 被标记为 `needs_refine`
-3. Epic 创建后需要分解为 Features
-
----
-
-## 最佳实践
-
-1. **Evidence Based**: 所有架构决策必须有代码或文档证据支持
-2. **Incremental Design**: 优先采用增量式设计，避免过度设计
-3. **Clear Boundaries**: 明确模块边界和接口契约
-4. **Document First**: 先写设计文档，再创建实现任务
-5. **Review Loop**: 复杂设计应经过 Review 后再交接
-
----
-
-## 相关资源
-
-- Role 定义: `monoco/features/agent/resources/roles/planner.yaml`
-- Engineer Flow: `.agent/skills/flow_engineer/SKILL.md`
-- Reviewer Flow: `.agent/skills/flow_reviewer/SKILL.md`