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

monoco/features/i18n/resources/zh/skills/monoco_atom_i18n/SKILL.md

@@ -1,96 +0,0 @@
----
-name: monoco_atom_i18n
-description: 文档国际化质量控制。确保多语言文档保持同步。
-type: atom
-version: 1.0.0
----
-
-# 文档国际化
-
-管理 Monoco 项目文档的国际化。
-
-## 概述
-
-I18n 功能提供:
-
-- **自动扫描**缺失的翻译
-- **标准化结构**用于多语言文档
-- **质量控制**以维护文档一致性
-
-## 核心命令
-
-### 扫描缺失的翻译
-
-```bash
-monoco i18n scan
-```
-
-扫描项目中的 markdown 文件并报告缺失的翻译。
-
-**输出**:
-
-- 列出没有对应翻译的源文件
-- 显示缺少哪些目标语言
-- 遵循 `.gitignore` 和默认排除规则
-
-## 配置
-
-I18n 设置在 `.monoco/config.yaml` 中配置:
-
-```yaml
-i18n:
-  source_lang: en # 源语言代码
-  target_langs: # 目标语言代码
-    - zh
-    - ja
-```
-
-## 文档结构
-
-### 根文件（后缀模式）
-
-对于项目根目录中的文件:
-
-- 源文件: `README.md`
-- 中文: `README_ZH.md`
-- 日文: `README_JA.md`
-
-### 子目录文件（目录模式）
-
-对于 `docs/` 或其他目录中的文件:
-
-```
-docs/
-├── en/
-│   ├── guide.md
-│   └── api.md
-├── zh/
-│   ├── guide.md
-│   └── api.md
-└── ja/
-    ├── guide.md
-    └── api.md
-```
-
-## 排除规则
-
-以下内容会自动从 i18n 扫描中排除:
-
-- `.gitignore` 模式（自动遵循）
-- `.references/` 目录
-- 构建产物（`dist/`, `build/`, `node_modules/`）
-- `Issues/` 目录
-
-## 最佳实践
-
-1. **先创建英文版**: 首先用源语言编写文档
-2. **遵循命名约定**: 使用适当的模式（后缀或目录）
-3. **定期运行扫描**: 使用 `monoco i18n scan` 验证覆盖率
-4. **提交所有语言**: 将翻译保存在版本控制中
-
-## 工作流程
-
-1. 用源语言（如英语）编写文档
-2. 按照命名约定创建翻译文件
-3. 运行 `monoco i18n scan` 验证所有翻译是否存在
-4. 修复扫描报告的任何缺失翻译

monoco/features/i18n/resources/zh/skills/monoco_workflow_i18n_scan/SKILL.md

@@ -1,105 +0,0 @@
----
-name: monoco_workflow_i18n_scan
-description: I18n 扫描工作流 (Flow Skill)。定义从扫描缺失翻译到生成翻译任务的标准操作流程，确保多语言文档质量。
-type: workflow
-domain: i18n
-version: 1.0.0
----
-
-# I18n Scan Workflow
-
-I18n 扫描的标准化工作流，确保 "Scan → Identify → Generate Tasks" 流程。
-
-## 工作流状态机
-
-```mermaid
-stateDiagram-v2
-    [*] --> Scan: 触发扫描
-    
-    Scan --> Identify: 扫描完成
-    Scan --> Scan: 配置错误<br/>(修复配置)
-    
-    Identify --> GenerateTasks: 发现缺失
-    Identify --> [*]: 无缺失<br/>(完成)
-    
-    GenerateTasks --> [*]: 任务生成完成
-```
-
-## 执行步骤
-
-### 1. Scan (扫描)
-
-- **目标**: 扫描项目中所有文档，识别翻译覆盖情况
-- **输入**: 项目文件、i18n 配置
-- **输出**: 扫描报告
-- **检查点**:
-  - [ ] 检查 `.monoco/config.yaml` 中的 i18n 配置
-  - [ ] 运行 `monoco i18n scan`
-  - [ ] 确认源语言和目标语言设置正确
-  - [ ] 验证排除规则（.gitignore、build 目录等）
-
-### 2. Identify (识别缺失)
-
-- **目标**: 分析扫描结果，识别具体缺失的翻译
-- **策略**: 对比源文件和目标文件
-- **检查点**:
-  - [ ] 列出所有缺失翻译的源文件
-  - [ ] 识别缺失的目标语言
-  - [ ] 评估缺失翻译的影响范围
-  - [ ] 按优先级排序（核心文档优先）
-
-### 3. Generate Tasks (生成任务)
-
-- **目标**: 为缺失的翻译创建追踪任务
-- **策略**: 根据缺失情况创建 Issue 或备忘录
-- **检查点**:
-  - [ ] 为核心文档缺失创建 Feature Issue
-  - [ ] 为次要文档缺失创建 Memo 提醒
-  - [ ] 在 Issue 中标注需要翻译的文件路径
-  - [ ] 设置合理的优先级和截止日期
-
-## 决策分支
-
-| 条件 | 动作 |
-|------|------|
-| 配置错误 | 修复 `.monoco/config.yaml`，重新扫描 |
-| 无缺失翻译 | 流程完成，无需进一步操作 |
-| 大量缺失 | 创建 Epic，拆分为多个 Feature |
-| 关键文档缺失 | 高优先级，立即创建 Issue |
-
-## 合规要求
-
-- **必须**: 扫描前验证 i18n 配置正确
-- **必须**: 所有核心文档必须有对应翻译
-- **建议**: 定期运行扫描（如每周）
-- **建议**: 将翻译任务与功能开发绑定
-
-## 相关命令
-
-```bash
-# 扫描缺失翻译
-monoco i18n scan
-
-# 创建翻译任务
-monoco issue create feature -t "翻译 {filename} 到 {lang}"
-
-# 添加备忘录
-monoco memo add "需要翻译: {filepath}"
-```
-
-## 输出示例
-
-扫描完成后，应生成如下报告：
-
-```
-I18n Scan Report
-================
-Source Language: en
-Target Languages: zh, ja
-
-Missing Translations:
-- docs/guide.md → zh/guide.md [MISSING]
-- docs/api.md → ja/api.md [MISSING]
-
-Coverage: 85%
-```

monoco/features/issue/resources/en/skills/monoco_atom_issue/SKILL.md

@@ -1,165 +0,0 @@
----
-name: monoco_atom_issue
-description: Official skill for Monoco Issue System. Treats Issues as Universal Atoms, managing the lifecycle of Epic/Feature/Chore/Fix.
-type: atom
-version: 1.0.0
----
-
-# Issue Management
-
-Use this skill to create and manage **Issues** (Universal Atoms) in Monoco projects.
-
-## Core Ontology
-
-### 1. Strategy Layer
-
-- **🏆 EPIC**: Grand goals, vision containers. Mindset: Architect.
-
-### 2. Value Layer
-
-- **✨ FEATURE**: Value increments from user perspective. Mindset: Product Owner.
-- **Atomicity Principle**: Feature = Design + Dev + Test + Doc + i18n. They are one.
-
-### 3. Execution Layer
-
-- **🧹 CHORE**: Engineering maintenance, no direct user value. Mindset: Builder.
-- **🐞 FIX**: Correcting deviations. Mindset: Debugger.
-
-## Workflow Policies
-
-### 1. Strict Git Workflow
-
-Monoco enforces a **Feature Branch** model.
-
-- **Start**: Agents **MUST** use `monoco issue start <ID> --branch` to start working.
-  - This creates and switches to a standard `feat/<ID>-<slug>` branch.
-  - **Do NOT** manually create branches using `git checkout -b`.
-- **Protected Main**: **NO** direct modification on `main`, `master`, or `production` branches. Linter will block this.
-- **Submit**: Run `monoco issue submit <ID>` when work is ready for review.
-  - This moves the issue to `Review` stage and generates a Delivery Report.
-  - **Note**: This does **not** merge the code. You (or the user) must handle the Merge/PR process.
-
-## Standardized Workflow
-
-### Workflow Diagram
-
-```mermaid
-stateDiagram-v2
-    [*] --> Plan
-    Plan --> Build: monoco issue start
-    Build --> Submit: monoco issue submit
-    state "Oracle Loop" as Oracle {
-        Submit --> Review: Auto/Manual Review
-        Review --> Fix: Reject
-        Fix --> Submit: Retry
-    }
-    Review --> Merge: Approve
-    Merge --> [*]: monoco issue close
-```
-
-### Action Steps
-
-1.  **Plan Phase**:
-    - Ensure Issue exists and is in `Open` status.
-    - Verify requirements and tasks.
-
-2.  **Build Phase**:
-    - Run `monoco issue start <ID> --branch` (Verification: ensures branch is created).
-    - Implement features/fixes.
-    - Run `monoco issue sync-files` to track changes.
-
-3.  **Submit Phase (Oracle Loop)**:
-    - Run tests to ensure quality.
-    - Run `monoco issue lint`.
-    - Run `monoco issue submit <ID>`.
-    - **IF** errors/feedback received:
-      - Fix issues.
-      - Re-run tests.
-      - Re-submit.
-
-4.  **Merge Phase**:
-    - Once approved:
-    - Run `monoco issue close <ID> --solution completed --prune`.
-
-### 2. File Tracking
-
-Agents must track modified files to maintain Self-Contained Context.
-
-- **Mechanism**: Issue Ticket Front Matter contains a `files: []` field.
-- **Automated (Recommended)**: Run `monoco issue sync-files` inside the Feature Branch. It diffs against the base branch.
-- **Manual (Fallback)**: If working without branches, Agent MUST **actively** append modified paths to the `files` list.
-
-## Guidelines
-
-### Directory Structure & Naming
-
-`Issues/{CapitalizedPluralType}/{lowercase_status}/`
-
-- **Types**: `Epics`, `Features`, `Chores`, `Fixes`
-- **Statuses**: `open`, `backlog`, `closed`
-
-### Structural Integrity
-
-Issues are validated via `monoco issue lint`. key constraints:
-
-1. **Mandatory Heading**: `## {ID}: {Title}` must match front matter.
-2. **Min Checkboxes**: At least 2 checkboxes (AC/Tasks).
-3. **Review Protocol**: `## Review Comments` required for `review` or `done` stages.
-
-### Path Transitions
-
-Use `monoco issue`:
-
-1. **Create**: `monoco issue create <type> --title "..."`
-   - Params: `--parent <id>`, `--dependency <id>`, `--related <id>`, `--sprint <id>`, `--tags <tag>`
-
-2. **Transition**: `monoco issue open/close/backlog <id>`
-
-3. **View**: `monoco issue scope`
-
-4. **Validation**: `monoco issue lint`
-
-5. **Modification**: `monoco issue start/submit/delete <id>`
-
-6. **Sync**: `monoco issue sync-files [id]` (Sync code changes to Issue file)
-
-7. **Validation**: `monoco issue lint` (Enforces compliance)
-
-## Validation Rules (FEAT-0082)
-
-To ensure data integrity, all Issue tickets must follow these strict rules:
-
-### 1. Structural Consistency
-
-- Must contain a Level 2 Heading matching exactly: `## {ID}: {Title}`.
-- Example: `## FEAT-0082: Issue Ticket Validator`
-
-### 2. Content Completeness
-
-- **Checkboxes**: Minimum of 2 checkboxes required (one for AC, one for Tasks).
-- **Review Comments**: If `stage` is `review` or `done`, a `## Review Comments` section is mandatory and must not be empty.
-
-### 3. Checkbox Syntax & Hierarchy
-
-- Use only `- [ ]`, `- [x]`, `- [-]`, or `- [/]`.
-- **Inheritance**: If nested checkboxes exist, the parent state must reflect child states (e.g., if any child is `[/]`, parent must be `[/]`; if all children are `[x]`, parent must be `[x]`).
-
-### 4. State Matrix
-
-The `status` (folder) and `stage` (front matter) must be compatible:
-
-- **open**: Draft, Doing, Review, Done
-- **backlog**: Draft, Doing, Review
-- **closed**: Done
-
-### 5. Environment Policy
-
-Linter includes environment-aware guardrails:
-
-- 🛑 **Dirty Main Protection**: Fails if uncommitted changes are detected on protected branches (`main`/`master`).
-
-### 6. ID Format & Hierarchy
-
-- **ID Specification**: Issue IDs must strictly follow the `TYPE-XXXX` format, where `XXXX` are 4 digits (e.g., `FEAT-0001`, `FIX-9999`).
-- **No Suffixes**: IDs with suffixes like `FEAT-0001-1` are strictly prohibited.
-- **Hierarchy Expression**: Sub-features or sub-tasks must be expressed using the `parent` field in the Front Matter. Do NOT use ID naming conventions (like hierarchical suffixes) to express relationships.

monoco/features/issue/resources/en/skills/monoco_workflow_issue_creation/SKILL.md

@@ -1,167 +0,0 @@
----
-name: monoco_workflow_issue_creation
-description: Extract improvement clues from Memo, classify and create Issue Ticket (Copilot Mode)
-type: workflow
-domain: issue
-version: 1.0.0
----
-
-# Issue Create Workflow
-
-Standardized workflow for extracting improvement clues from Memo, analyzing and creating structured Issue Tickets.
-
-**Applicable Scenario**: Copilot Mode (Human-led, AI-assisted)
-**Target Users**: Developers who need to quickly transform ideas/notes into actionable tasks
-
-## Workflow State Machine
-
-```mermaid
-stateDiagram-v2
-    [*] --> Extract: Read Memo
-    
-    Extract --> Classify: Identify Type
-    Extract --> Archive: No Value
-    
-    Classify --> Design: Architecture Design Required
-    Classify --> Direct: Create Directly
-    
-    Design --> Create: Design Complete
-    Direct --> Create: Create Directly
-    
-    Archive --> [*]: Archive Memo
-    Create --> [*]: Issue Creation Complete
-```
-
-## Execution Steps
-
-### 1. Extract
-
-- **Goal**: Extract key improvement clues from Memo
-- **Input**: Memo file or temporary notes
-- **Output**: Structured improvement clue list
-- **Checkpoints**:
-  - [ ] Run `monoco memo list` to view pending Memos
-  - [ ] Analyze improvement type and impact scope for each Memo
-  - [ ] Identify actionable improvements (not pure reference materials)
-  - [ ] Record improvement motivation and expected effects
-
-**Analysis Dimensions**:
-| Dimension | Question |
-|-----------|----------|
-| Value | What problem does this improvement solve? |
-| Scope | Which modules/features are affected? |
-| Urgency | Do it now or later? |
-| Feasibility | Is there enough information to start? |
-
-### 2. Classify
-
-- **Goal**: Determine Issue type and priority
-- **Checkpoints**:
-  - [ ] Determine if it's an architecture-level improvement (→ Epic)
-  - [ ] Determine if it's user value increment (→ Feature)
-  - [ ] Determine if it's engineering debt (→ Chore)
-  - [ ] Determine if it's a bug fix (→ Fix)
-  - [ ] Assess if pre-architecture design is required
-
-**Decision Branches**:
-
-| Condition | Type | Next Step |
-|-----------|------|-----------|
-| Architecture vision-level improvement, needs decomposition into multiple Features | Epic | → Design |
-| User deliverable value, with clear acceptance criteria | Feature | → Direct |
-| Engineering maintenance task, technical debt cleanup | Chore | → Direct |
-| Bug fix, with clear reproduction steps | Fix | → Direct |
-| Pure reference material, no direct improvement value | - | → Archive |
-| Requires architecture design to estimate effort | - | → Design |
-
-### 3. Design (Optional)
-
-- **Goal**: Preliminary architecture design for complex improvements
-- **Applicable**: Epic or large Feature
-- **Checkpoints**:
-  - [ ] Analyze existing architecture inheritance
-  - [ ] Determine technical solution direction
-  - [ ] Identify dependency relationships and risk points
-  - [ ] Estimate effort and milestones
-
-**Outputs**:
-- Architecture Decision Record (ADR) draft
-- Subtask decomposition suggestions
-- Dependency Issue list
-
-### 4. Create
-
-- **Goal**: Create Issue that meets specifications
-- **Checkpoints**:
-  - [ ] Run `monoco issue create <type> -t "Title"`
-  - [ ] Write clear description and background
-  - [ ] Define verifiable acceptance criteria (at least 2 Checkboxes)
-  - [ ] Set dependency relationships (if needed)
-  - [ ] Associate related Memo (if applicable)
-  - [ ] Run `monoco issue lint` to verify compliance
-
-**Issue Content Template**:
-
-```markdown
-## Objective
-Clearly describe the goal and expected outcome of this Issue.
-
-## Acceptance Criteria
-- [ ] Acceptance criterion 1
-- [ ] Acceptance criterion 2
-
-## Technical Tasks
-- [ ] Technical task 1
-- [ ] Technical task 2
-
-## Related
-- Parent: EPIC-XXXX (if applicable)
-- Related Memo: MEMO-XXXX (if applicable)
-```
-
-### 5. Archive (Optional)
-
-- **Goal**: Archive Memos with no direct improvement value
-- **Checkpoints**:
-  - [ ] Confirm Memo content is pure reference material
-  - [ ] Record archiving reason
-  - [ ] Update Memo status (if system supports)
-
-## Issue Type Guide
-
-| Type | Purpose | Prefix | Mindset | Example |
-|------|---------|--------|---------|---------|
-| Epic | Grand goals, vision container | EPIC- | Architect | Refactor core architecture |
-| Feature | User value increment | FEAT- | Product Owner | Add export functionality |
-| Chore | Engineering tasks | CHORE- | Builder | Upgrade dependency versions |
-| Fix | Bug fixes | FIX- | Debugger | Fix memory leak |
-
-## Related Commands
-
-```bash
-# View pending Memos
-monoco memo list
-
-# Create Issue
-monoco issue create feature -t "Title"
-monoco issue create chore -t "Title"
-monoco issue create fix -t "Title"
-monoco issue create epic -t "Title"
-
-# Verify Issue compliance
-monoco issue lint
-```
-
-## Relationship with flow_engineer
-
-This workflow complements `flow_engineer`:
-- `issue-create-workflow`: Focuses on Issue creation phase, transforming ideas into actionable tasks
-- `flow_engineer`: Focuses on code implementation phase, executing Investigate → Code → Test → Report → Submit
-
-## Copilot Mode Tips
-
-As an AI Copilot, you should:
-1. **Ask proactively**: When Memo content is unclear, ask human developers for intent
-2. **Provide options**: Give multiple classification suggestions with reasoning
-3. **Assist drafting**: Help write Issue descriptions and acceptance criteria
-4. **Remind compliance**: Ensure created Issues meet project specifications