codymaster 4.1.0

package/skills/cm-dockit/skills/changelog-guide.md

@@ -0,0 +1,195 @@
+# Changelog Documentation Guide
+
+Sub-skill for `cm-dockit` — generates structured changelog documentation from git history or existing `CHANGELOG.md`.
+
+## When to Use
+
+- User requests `changelog` doc type in DocKit
+- Part of `all` doc type generation sequence
+- User asks for "release notes", "version history", "changelog page"
+- After `cm-safe-deploy` Gate 8 generates `CHANGELOG.md`
+
+## Changelog Categories (2 Types Only)
+
+| Category | Icon | Keywords |
+|----------|------|----------|
+| **Improvements** | 🚀 | `feat:`, `add:`, `improve:`, `enhance:`, `refactor:`, `perf:`, `style:`, `chore:`, `docs:` |
+| **Bug Fixes** | 🐛 | `fix:`, `bug:`, `patch:`, `hotfix:`, `correct` |
+
+> [!IMPORTANT]
+> Only 2 categories. No "Breaking Changes", no "Deprecations". Keep it simple.
+
+## Data Sources (Priority Order)
+
+1. **`CHANGELOG.md` at project root** — If exists, read and convert to docs format (preferred, generated by `cm-safe-deploy` Gate 8)
+2. **Git tags + commit history** — If no CHANGELOG.md, generate from `git tag` and `git log`
+3. **Manual input** — If no git history available, ask user for release notes
+
+## Output
+
+### File: `docs/changelog.md`
+
+```markdown
+---
+title: Changelog - [Project Name]
+description: Release history and version notes for [Project Name]
+keywords: [changelog, release notes, version history, updates]
+robots: "index, follow"
+---
+
+# Changelog
+
+All notable changes to this project are documented here.
+
+Categories: 🚀 **Improvements** | 🐛 **Bug Fixes**
+
+## [X.Y.Z] - YYYY-MM-DD
+
+### 🚀 Improvements
+- Description of feature or enhancement (commit-hash)
+
+### 🐛 Bug Fixes
+- Description of bug fix (commit-hash)
+
+---
+
+## [X.Y.Z-1] - YYYY-MM-DD
+
+### 🚀 Improvements
+- ...
+
+### 🐛 Bug Fixes
+- ...
+```
+
+## Generation Procedure
+
+### Step 1: Check for CHANGELOG.md
+
+```
+IF CHANGELOG.md exists at project root:
+  → Read and parse it
+  → Convert to docs/changelog.md with VitePress frontmatter
+  → Preserve all version entries
+
+ELSE IF git tags exist:
+  → Generate changelog from git history
+  → For each tag, collect commits between tags
+  → Categorize each commit into Improvements or Bug Fixes
+  → Write docs/changelog.md
+
+ELSE:
+  → Create empty changelog template
+  → Ask user to provide release notes manually
+```
+
+### Step 2: Categorize Commits
+
+For each commit message, auto-categorize:
+
+```javascript
+function categorize(message) {
+  const lower = message.toLowerCase();
+  const fixKeywords = ['fix', 'bug', 'patch', 'hotfix', 'correct'];
+
+  if (fixKeywords.some(k => lower.includes(k))) {
+    return 'fix';  // 🐛 Bug Fixes
+  }
+  return 'improvement';  // 🚀 Improvements (default)
+}
+```
+
+**Rules:**
+- If a commit contains BOTH improvement and fix keywords → classify as 🐛 Bug Fixes (conservative)
+- If commit has no recognizable prefix → default to 🚀 Improvements
+- Merge commits and `chore: bump version` should be excluded from changelog
+
+### Step 3: VitePress Integration
+
+If output format is `vitepress`, add changelog to sidebar:
+
+```javascript
+// In .vitepress/config.mts sidebar configuration
+{
+  text: 'Changelog',
+  link: '/changelog'
+}
+```
+
+Add to navigation if not already present.
+
+### Step 4: Content Guidelines
+
+Apply standard `cm-dockit` content guidelines:
+- YAML frontmatter with `title`, `description`, `keywords`, `robots`
+- Use `:::info` admonition for version highlights
+- Use `<details>` for older versions (progressive disclosure — Hick's Law)
+- Cross-link to related docs (architecture changes → `architecture.md`, API changes → `api/`)
+- Minimum 2 internal links per page
+
+### Step 5: Validate
+
+- ✅ Every version entry has a date in `YYYY-MM-DD` format
+- ✅ Versions are sorted newest-first
+- ✅ Each version has at least one entry in either category
+- ✅ No duplicate version numbers
+- ✅ Frontmatter is present and valid
+
+## Integration with cm-safe-deploy
+
+```
+cm-safe-deploy Gate 8          cm-dockit changelog
+    │                              │
+    ├─ Generates CHANGELOG.md ────►├─ Reads CHANGELOG.md
+    ├─ Creates git tag             ├─ Converts to docs/changelog.md
+    ├─ Commits changelog           ├─ Adds VitePress frontmatter
+    │                              ├─ Categorizes into 🚀/🐛
+    │                              └─ Adds to sidebar
+    │
+    ▼
+  Closed-loop release process
+```
+
+## Example: Full Changelog Page
+
+```markdown
+---
+title: Changelog - CodyMaster
+description: Complete release history for CodyMaster skill kit
+keywords: [changelog, releases, updates, CodyMaster]
+robots: "index, follow"
+---
+
+# Changelog
+
+> All notable changes to CodyMaster are documented here.
+
+Categories: 🚀 **Improvements** | 🐛 **Bug Fixes**
+
+## [3.5.0] - 2026-03-23
+
+### 🚀 Improvements
+- Add version bump gate to deploy pipeline (a1b2c3d)
+- Upgrade changelog generation in cm-dockit (e4f5g6h)
+- Add 9-gate pipeline visualization (i7j8k9l)
+
+### 🐛 Bug Fixes
+- Fix i18n key parity check for Thai language (m0n1o2p)
+- Fix FAQ card spacing on mobile (q3r4s5t)
+
+---
+
+<details>
+<summary>📦 Older Releases</summary>
+
+## [3.4.0] - 2026-03-20
+
+### 🚀 Improvements
+- Multi-country upgrade for VN, TH, PH
+- Smart Import Engine v2
+
+### 🐛 Bug Fixes
+- Fix employee period score calculation
+
+</details>
+```

package/skills/cm-dockit/skills/content-guidelines.md

@@ -0,0 +1,190 @@
+# Content Quality Guidelines — UX Master Edition
+
+Rules for generating documentation content that is readable, scannable, and compatible with VitePress.
+
+## UX Laws for Documentation
+
+### Hick's Law — Reduce Decision Complexity
+
+- **Max 7 items** in any Table of Contents (TOC) top level
+- **Max 2 primary CTAs** per page (e.g., "Get Started" + "View API")
+- Group related items into categories — never flat-list >10 items
+- Use **sidebar categories** instead of one long sidebar
+
+### Miller's Law — Chunk Information
+
+- **Chunk tables** into groups of 5-9 rows with section headers
+- **Break long pages** into sub-pages if >500 lines
+- Use **visual separators**: `---`, headings, or admonition boxes
+- Each section should be independently scannable
+
+### Doherty Threshold — Optimize for Scanning
+
+- **Lead with a summary** — put the most important info first
+- **Use tables** instead of long paragraphs for structured data
+- **Bold key terms** in definitions and descriptions
+- **Code examples** should be runnable as-is (copy-paste friendly)
+
+### Jakob's Law — Follow Familiar Patterns
+
+- Use **standard doc layouts**: sidebar left, content center, TOC right
+- Use **conventional heading hierarchy**: H1 (title) → H2 (sections) → H3 (subsections)
+- Use **standard admonition types**: tip, info, warning, danger
+
+---
+
+## Filenames
+
+| Rule | ✅ Correct | ❌ Wrong |
+|------|-----------| ---------|
+| **kebab-case** | `getting-started.md` | `Getting_Started.md` |
+| **No underscore prefix** | `analysis.md` | `_analysis.md` |
+| **No dots in names** | `deploy-guide.md` | `Deploy.vi.md` |
+| **Lowercase only** | `api-reference.md` | `API_Reference.md` |
+
+## Frontmatter (Required)
+
+Every `.md` file MUST include:
+
+```yaml
+---
+title: "Descriptive Page Title"
+description: "Brief 1-line description for SEO"
+---
+```
+
+> **Note:** VitePress generates sidebar from file structure — no `sidebar_position` needed.
+
+## Links
+
+- Use **relative paths**: `[API](./api-reference.md)` not absolute
+- **Anchor links** must match actual heading slugs
+- **No `<a>` tags** — use Markdown `[text](url)` syntax
+
+---
+
+## Content Structure Rules
+
+### Quick Reference Card (Required for tech docs)
+
+Every technical document MUST start with a summary box:
+
+```markdown
+> **Quick Reference**
+> - **What**: Brief description of this system/feature
+> - **Stack**: Python 3.10+, PyTorch 2.0, CUDA 12
+> - **Key Files**: `src/engine.py`, `src/model.py`
+> - **Status**: Production / Beta / Experimental
+```
+
+### Admonitions (Custom Containers)
+
+VitePress supports these custom containers natively:
+
+```markdown
+:::tip Performance Tip
+Use batch processing for >100 items — 3x faster than sequential.
+:::
+
+:::info
+This feature requires Python 3.10 or later.
+:::
+
+:::warning Breaking Change
+This API changed in v2.0. See migration guide.
+:::
+
+:::danger Security
+Never expose API keys in client-side code.
+:::
+
+:::details Advanced Configuration Options
+| Option | Default | Description |
+|--------|---------|-------------|
+| `batch_size` | 32 | Processing batch size |
+| `num_workers` | 4 | Parallel worker count |
+:::
+```
+
+### Code Groups (Multi-Platform Examples)
+
+Use VitePress code groups instead of HTML tabs:
+
+```markdown
+::: code-group
+
+\```bash [macOS]
+brew install myapp
+\```
+
+\```bash [Linux]
+apt-get install myapp
+\```
+
+\```bash [Windows]
+winget install myapp
+\```
+
+:::
+```
+
+### Progressive Disclosure (For Advanced Content)
+
+Hide advanced/optional content behind expandable sections:
+
+```markdown
+<details>
+<summary>Advanced Configuration Options</summary>
+
+| Option | Default | Description |
+|--------|---------|-------------|
+| `batch_size` | 32 | Processing batch size |
+| `num_workers` | 4 | Parallel worker count |
+
+</details>
+```
+
+---
+
+## Mermaid Diagram Rules
+
+### Theme-Neutral Approach (No Hardcoded Colors)
+
+**CRITICAL:** Do NOT use inline `style` directives in Mermaid diagrams.
+
+Hardcoded colors (e.g., `style A fill:#2d333b,color:#e6edf3`) break on light themes.
+VitePress has built-in Mermaid support that auto-adapts to light/dark mode —
+just enable `markdown: { mermaid: true }` in config.
+
+**❌ DON'T — Hardcoded dark colors:**
+```
+style A fill:#2d333b,stroke:#6d5dfc,color:#e6edf3
+```
+
+**✅ DO — Clean, no-style diagrams:**
+```mermaid
+graph LR
+    A[Client] --> B[API]
+    B --> C[Database]
+```
+
+> **Note:** Mermaid is built-in to VitePress — no plugin installation needed!
+> Just set `markdown: { mermaid: true }` in `.vitepress/config.mts`.
+
+### Minimum Requirements
+
+- **Architecture docs**: ≥ 2 Mermaid diagrams (overview + sequence)
+- **Data flow docs**: ≥ 3 Mermaid diagrams
+- **SOP guides**: ≥ 1 Mermaid flowchart of the process
+
+---
+
+## Writing Style
+
+| Rule | ✅ Do | ❌ Don't |
+|------|------| ---------|
+| **Lead with WHY** | "Use streaming for real-time apps" | "The streaming module provides..." |
+| **Active voice** | "Install the package" | "The package should be installed" |
+| **Concrete examples** | "Set `batch_size=64` for GPUs with ≥8GB VRAM" | "Adjust batch size as needed" |
+| **Cite sources** | `(src/engine.py:42)` | "In the engine file" |
+| **Tables > paragraphs** | Use tables for comparisons | Write long comparison paragraphs |

package/skills/cm-dockit/skills/sop-guide.md

@@ -0,0 +1,184 @@
+# SOP User Guide Generator — UX Master Edition
+
+Generate professional Standard Operating Procedure (SOP) user guides with progressive disclosure, visual hierarchy, and multi-platform support.
+
+## Input Required
+
+- `docs/_analysis.md` (output from analyze-codebase)
+- Access to source code (routes, UI components, views)
+
+## Content Guidelines
+
+**Before generating, read `skills/content-guidelines.md` for:**
+- Progressive disclosure patterns
+- Writing style rules
+
+## Procedure
+
+### 1. Identify User-Facing Features
+
+Scan the codebase for:
+- Frontend routes/pages (Next.js pages, React routes, view templates)
+- UI components that represent features
+- API endpoints that correspond to user actions
+- Role-based access (admin, user, operator)
+
+### 2. Group by Module (Miller's Law: 5-9 items per group)
+
+Organize features into logical modules:
+```
+Module: User Management (4 features)
+├── Login / Register
+├── Account Settings
+├── Role Assignment
+└── Password Reset
+```
+
+### 3. Generate SOP per Feature
+
+Output to `docs/sop/[module-name].md`
+
+## SOP Template
+
+Each SOP file MUST follow this structure:
+
+```markdown
+---
+title: "[Feature Name]"
+description: "User guide for [feature name]"
+---
+
+# [Feature Name]
+
+> **Quick Reference**
+> - **Who**: [Role required — Admin / User / Operator]
+> - **Where**: [Menu > Submenu > Page]
+> - **Time**: ~[estimated minutes] to complete
+> - **Prerequisites**: [Brief list]
+
+## Prerequisites
+
+- [ ] Logged in with role **[role]**
+- [ ] Have [prerequisites]
+
+## Step-by-Step Guide
+
+### Step 1: [Step Name]
+
+1. Navigate to **[Menu] → [Submenu]**
+2. Click the **[Button Name]** button
+3. Fill in the information:
+
+   | Field | Required | Description | Example |
+   |-------|----------|-------------|---------|
+   | Name | ✅ | Full Name | Jane Doe |
+
+4. Click **Save** to complete
+
+<!-- Screenshot: [Description of screenshot to take] -->
+
+:::tip
+[Helpful tip for this step — derived from common user behavior]
+:::
+
+### Step 2: [Step Name]
+[Continue...]
+
+## Expected Results
+
+- ✅ [Result 1]
+- ✅ [Result 2]
+
+## Troubleshooting
+
+<details>
+<summary>🔴 Error: [Error Message 1]</summary>
+
+**Cause:** [Root cause]
+
+**Solution:**
+1. [Step to fix]
+2. [Step to fix]
+
+**Source:** `(file_path:line_number)`
+
+</details>
+
+<details>
+<summary>🔴 Error: [Error Message 2]</summary>
+
+**Cause:** [Root cause]
+
+**Solution:**
+1. [Step to fix]
+
+</details>
+
+## FAQ
+
+<details>
+<summary>Q: [Question 1]?</summary>
+
+**A:** [Answer derived from actual code logic]
+
+</details>
+
+<details>
+<summary>Q: [Question 2]?</summary>
+
+**A:** [Answer]
+
+</details>
+
+## Related
+
+- [Related SOP](./related-module.md)
+- API: `[METHOD] /api/endpoint`
+```
+
+## Index File
+
+Generate `docs/sop/index.md`:
+
+```markdown
+---
+title: "User Guides"
+description: "System user guides overview"
+---
+
+# User Guides
+
+> **Quick Reference**
+> - **Total Features**: [count]
+> - **Roles**: Admin, User, Operator
+> - **Last Updated**: [date]
+
+## Feature Map
+
+```mermaid
+graph TB
+    M1["User Management"] --> F1["Login"]
+    M1 --> F2["Register"]
+    M1 --> F3["Settings"]
+```
+
+## Feature List
+
+| No. | Feature | Description | Role | Difficulty |
+|-----|---------|-------------|------|------------|
+| 1 | [Name] | [Description] | [Role] | 🟢 Easy |
+```
+
+## Rules
+
+- **Quick Reference card** at top of every SOP
+- **Number every step** — users must be able to follow exactly
+- **Include form field tables** with real examples
+- **Use `<details>` for Troubleshooting & FAQ** (Progressive Disclosure — Hick's Law)
+- **Use `:::tip`** for helpful hints within steps
+- **Add `<!-- Screenshot: ... -->` placeholders** where visual guidance helps
+- **Link to related SOPs** and API docs
+- **Keep language simple and direct** — assume non-technical users
+- **Derive FAQ from actual validation rules** and business logic in code
+- **Cite source**: `(file_path:line_number)` for technical accuracy
+- **Estimate time** for each guide in the Quick Reference