codymaster 4.1.3 → 4.3.0

package/skills/cm-debugging/SKILL.md

@@ -13,8 +13,6 @@ Random fixes waste time and create new bugs. Quick patches mask underlying issue
 
 **Violating the letter of this process is violating the spirit of debugging.**
 
-**Thinking principle (TRIZ):** Use structured cognitive tools — not just checklists — to see bugs from multiple dimensions. When linear investigation stalls, 9 Windows and Contradiction Analysis break the deadlock.
-
 ## The Iron Law
 
 ```
@@ -45,25 +43,7 @@ Use for ANY technical issue:
 - You're in a hurry (rushing guarantees rework)
 - Manager wants it fixed NOW (systematic is faster than thrashing)
 
-## Bug Complexity Classifier
-
-Before entering the phases, classify the bug to determine which cognitive tools activate:
-
-```
-BUG enters cm-debugging
-  → Is reproduction straightforward AND error message points to exact cause?
-    → YES → SIMPLE PATH (standard Phase 0.5 → 1 → 2 → 3 → 4 → 5)
-    → NO  → COMPLEX PATH (all phases + TRIZ tools: 9 Windows, Contradiction, Troika)
-
-STALL DETECTOR (auto-triggers during any phase):
-  → Phase 1 investigation doesn't surface root cause after 2 attempts?
-  → Phase 3 hypothesis fails twice in a row?
-  → UPGRADE to Complex Path → activate TRIZ tools immediately
-```
-
-> **Why classify?** Simple bugs don't need heavy thinking tools. Complex bugs NEED them. The stall detector catches bugs that look simple but aren't.
-
-## The Phases
+## The Four Phases
 
 You MUST complete each phase before proceeding to the next.
 
@@ -153,39 +133,6 @@ IF memory did NOT cause the bug:
    - Keep tracing up until you find the source
    - Fix at source, not at symptom
 
-6. **9 Windows Analysis (TRIZ) — Complex Path / Stall Detector**
-
-   **WHEN standard investigation stalls OR bug classified as complex:**
-
-   Map the bug across 3 time periods × 3 system scopes:
-
-   ```
-   ┌──────────────────┬───────────────────────┬───────────────────────┬───────────────────────┐
-   │                  │  BEFORE bug           │  DURING bug           │  AFTER fix (target)   │
-   ├──────────────────┼───────────────────────┼───────────────────────┼───────────────────────┤
-   │  SUPER-SYSTEM    │  What was the system  │  What external        │  What system-level    │
-   │  (environment,   │  environment before?  │  conditions exist     │  changes prevent      │
-   │   CI, infra,     │  Any env/dep/infra    │  during the bug?      │  recurrence?          │
-   │   dependencies)  │  changes?             │  (timing, load, etc.) │                       │
-   ├──────────────────┼───────────────────────┼───────────────────────┼───────────────────────┤
-   │  SYSTEM          │  How did the module   │  What is the exact    │  How should the       │
-   │  (module/feature)│  work before the bug? │  broken behavior?     │  module work after?   │
-   │                  │  Last known good?     │  What's different     │  What invariant       │
-   │                  │  (git log, deploy)    │  from expected?       │  must hold?           │
-   ├──────────────────┼───────────────────────┼───────────────────────┼───────────────────────┤
-   │  SUB-SYSTEM      │  What were the        │  What specific        │  What component       │
-   │  (function, var, │  component values/    │  values/states are    │  changes fix this     │
-   │   config, state) │  states before?       │  wrong now?           │  at the root?         │
-   └──────────────────┴───────────────────────┴───────────────────────┴───────────────────────┘
-   ```
-
-   **Fill ALL 9 windows.** This reveals:
-   - **Temporal blind spots:** What changed between BEFORE and DURING?
-   - **Scope blind spots:** Is the root cause at a DIFFERENT level than the symptom?
-   - **Fix quality:** Does the target AFTER state prevent the class of bug, not just this instance?
-
-   > **WHY 9 WINDOWS?** Most debugging stalls happen because you're looking at the wrong time period OR the wrong system level. 9 Windows forces you to check ALL combinations.
-
 ### Phase 2: Pattern Analysis
 
 **Find the pattern before fixing:**
@@ -209,29 +156,6 @@ IF memory did NOT cause the bug:
    - What settings, config, environment?
    - What assumptions does it make?
 
-5. **Contradiction Analysis (TRIZ) — Complex Path / Stall Detector**
-
-   **WHEN pattern analysis reveals conflicting behaviors or "impossible" states:**
-
-   Fill in this template:
-
-   ```
-   CONTRADICTION TEMPLATE:
-   ┌─────────────────────────────────────────────────────────────┐
-   │ System NEEDS:  [what the feature/module SHOULD do]         │
-   │ System DOES:   [what it ACTUALLY does]                     │
-   │ Conflict:      [WHY it can't do both — the hidden tension] │
-   │ Resolution:    [dissolve the contradiction, don't compromise]│
-   └─────────────────────────────────────────────────────────────┘
-   ```
-
-   **Common debugging contradictions:**
-   - "Function must be fast" vs "Function must be complete" → missing edge case in optimization
-   - "Config must be flexible" vs "Config must have safe defaults" → bad default caused the bug
-   - "Module must be independent" vs "Module needs shared state" → coupling created race condition
-
-   > **WHY CONTRADICTION?** Bugs often hide where two legitimate requirements CONFLICT. Standard pattern analysis compares code structure. Contradiction analysis compares system INTENTIONS.
-
 ### Phase 3: Hypothesis and Testing
 
 **Scientific method:**
@@ -257,33 +181,6 @@ IF memory did NOT cause the bug:
    - Ask for help
    - Research more
 
-5. **Troika Consulting (TRIZ) — Complex Path / When Hypothesis Stalls**
-
-   **WHEN you can't form a strong hypothesis OR 2 hypotheses have failed:**
-
-   Force yourself to generate hypotheses from **3 different lenses**:
-
-   ```
-   LENS 1 — Code Lens:
-     "What code path leads to this state?"
-     Focus: control flow, logic branches, exception handling, return values
-
-   LENS 2 — Data Lens:
-     "What data/input causes this? What data is missing, corrupt, or unexpected?"
-     Focus: input validation, data shape, null/undefined, encoding, type coercion
-
-   LENS 3 — Environment Lens:
-     "What environmental factor triggers this?"
-     Focus: timing, concurrency, config, network, filesystem, memory, OS differences
-   ```
-
-   **Rules:**
-   - You MUST generate at least 1 hypothesis from EACH lens
-   - If a lens seems "irrelevant" — that's exactly where the bug hides
-   - Test the hypothesis from the LEAST obvious lens first
-
-   > **WHY TROIKA?** When debugging stalls, it's because you're stuck in ONE perspective. Troika forces 3 fundamentally different viewpoints. The bug is almost always visible from a lens you haven't tried.
-
 ### Phase 4: Implementation
 
 **Fix the root cause, not the symptom:**
@@ -381,12 +278,12 @@ If you catch yourself thinking:
 
 ## Quick Reference
 
-| Phase | Key Activities | TRIZ Tool (Complex Path) | Success Criteria |
-|-------|---------------|--------------------------|------------------|
-| **1. Root Cause** | Read errors, reproduce, check changes, gather evidence | **9 Windows** — temporal × spatial analysis | Understand WHAT and WHY |
-| **2. Pattern** | Find working examples, compare | **Contradiction Analysis** — conflicting requirements | Identify root differences |
-| **3. Hypothesis** | Form theory, test minimally | **Troika** — Code/Data/Environment lenses | Confirmed or new hypothesis |
-| **4. Implementation** | Create test, fix, verify | — | Bug resolved, tests pass |
+| Phase | Key Activities | Success Criteria |
+|-------|---------------|------------------|
+| **1. Root Cause** | Read errors, reproduce, check changes, gather evidence | Understand WHAT and WHY |
+| **2. Pattern** | Find working examples, compare | Identify differences |
+| **3. Hypothesis** | Form theory, test minimally | Confirmed or new hypothesis |
+| **4. Implementation** | Create test, fix, verify | Bug resolved, tests pass |
 
 ## When Process Reveals "No Root Cause"
 
@@ -404,9 +301,3 @@ If systematic investigation reveals issue is truly environmental, timing-depende
 **Related skills:**
 - **cm-tdd** - For creating failing test case (Phase 4, Step 1)
 - **cm-quality-gate** - Verify fix worked before claiming success
-- **cm-brainstorm-idea** - When 3+ fixes fail and bug reveals architectural problem → redirect to brainstorm
-
-**TRIZ tools used:**
-- **9 Windows** (Phase 1) — See bug across time × system scope
-- **Contradiction Analysis** (Phase 2) — Find hidden conflicts between requirements
-- **Troika Consulting** (Phase 3) — Force 3 different lenses on the same bug

package/skills/cm-deep-search/SKILL.md

@@ -148,9 +148,13 @@ qmd embed
 Tier 1: Sensory Memory     → temporary variables in session (not persisted)
 Tier 2: Working Memory      → CONTINUITY.md (~500 words)
 Tier 3: Long-Term Memory    → learnings.json, decisions.json
-Tier 4: External Semantic   → qmd (optional, used when project is large)
+Tier 4: External Semantic   → qmd (optional, text search for large docs)
+Tier 5: Structural Code     → CodeGraph (optional, AST graph for code — see cm-codeintell)
 ```
 
+> **qmd** finds text across docs/code. **CodeGraph** finds symbols, call graphs, and impact.
+> They complement each other — use both for maximum intelligence on large projects.
+
 ---
 
 ## 🛑 Staleness Prevention

package/skills/cm-dockit/README.md

@@ -28,13 +28,13 @@ Writing documentation is tedious. Keeping it updated is even harder.
 Simply copy the `doc-kit` folder into your Antigravity skills directory:
 
 ```bash
-cp -r cm-dockit ~/.gemini/antigravity/skills/
+cp -r doc-kit ~/.gemini/antigravity/skills/
 ```
 
 Make sure the CLI script is executable:
 
 ```bash
-chmod +x ~/.gemini/antigravity/skills/cm-dockit/scripts/doc-gen.sh
+chmod +x ~/.gemini/antigravity/skills/doc-kit/scripts/doc-gen.sh
 ```
 
 ## 💻 Quick Start
@@ -44,7 +44,7 @@ chmod +x ~/.gemini/antigravity/skills/cm-dockit/scripts/doc-gen.sh
 To get the best results effortlessly, use the built-in CLI menu:
 
 ```bash
-bash ~/.gemini/antigravity/skills/cm-dockit/scripts/doc-gen.sh
+bash ~/.gemini/antigravity/skills/doc-kit/scripts/doc-gen.sh
 ```
 
 The CLI will ask you 4 quick questions:
@@ -68,24 +68,15 @@ The agent will prompt you for the required choices.
 Doc-Kit is built using specialized sub-skills for maximum depth and accuracy:
 
 ```text
-skills/cm-dockit/
+skills/doc-kit/
 ├── SKILL.md                 # Main orchestration agent
 ├── scripts/
-│   ├── doc-gen.sh           # Interactive CLI
-│   ├── dockit-runner.sh     # DAG-based task execution
-│   ├── dockit-dashboard.sh  # Progress dashboard
-│   └── dockit-task.sh       # Individual task runner
+│   └── doc-gen.sh           # Highly interactive CLI
 ├── skills/
 │   ├── analyze-codebase.md  # Semantic analysis
 │   ├── tech-docs.md         # System Architecture
 │   ├── sop-guide.md         # Step-by-step UX flows
-│   ├── api-reference.md     # Auto REST/GraphQL extraction
-│   └── content-guidelines.md # Content formatting rules
-├── templates/               # Output format templates
-│   ├── markdown/
-│   └── vitepress-premium/
-├── tests/
-│   └── runner.test.ts       # Backend test suite
+│   └── api-reference.md     # Auto REST/GraphQL extraction
 └── workflows/               # Rules for output (Markdown or VitePress)
 ```
 

package/skills/cm-dockit/SKILL.md

@@ -12,25 +12,23 @@ A professional knowledge systematization engine powered by codebase analysis and
 - User asks to "create documentation", "generate docs"
 - User mentions "SOP", "user guide", "manual"
 - User wants technical docs from a codebase
-- User mentions "changelog", "release notes", "version history"
 - User runs `/DocKit Master`
 
 ## Document Types
 
 | Type | Skill File | Description |
 |------|-----------|-------------|
-| **knowledge** | *(generated directly by AI agent)* | Personas, JTBD, Process Flows — knowledge foundation |
+| **knowledge** | `skills/persona-builder.md` + `skills/jtbd-analyzer.md` + `skills/flow-mapper.md` *(files pending)* | Personas, JTBD, Process Flows — knowledge foundation |
 | **tech** | `skills/tech-docs.md` | Architecture, database, deployment, data flow |
 | **sop** | `skills/sop-guide.md` | Step-by-step user guides (enriched with knowledge) |
 | **api** | `skills/api-reference.md` | API endpoint reference with examples |
-| **changelog** | `skills/changelog-guide.md` | Release notes & version history (🚀 Improvements / 🐛 Bug Fixes) |
 | **all** | All above | Full knowledge base + documentation suite |
 
-| Support Skill | Purpose |
-|--------------|--------|
-| **SEO Checklist** | Per-page SEO audit (title, meta, headings, robots) — applied inline by AI agent |
-| **Content Writing** | SEO copywriting, keywords, active voice, FAQ — applied inline by AI agent |
-| **LLM Optimization** | AI-readable structure, NotebookLM-friendly — applied inline by AI agent |
+| Support Skill | File | Purpose |
+|--------------|------|---------|
+| **SEO Checklist** | `skills/seo-checklist.md` | Per-page SEO audit (title, meta, headings, robots) |
+| **Content Writing** | `skills/content-writing.md` | SEO copywriting, keywords, active voice, FAQ |
+| **LLM Optimization** | `skills/llm-optimization.md` | AI-readable structure, NotebookLM-friendly |
 
 ## Output Formats
 
@@ -50,7 +48,7 @@ Please answer the following questions so I can automatically create an execution
 
 | # | Question | Options | Default |
 |---|---------|---------|--------|
-| 1 | **📑 Document type?** | `knowledge` · `tech` · `sop` · `api` · `changelog` · `all` | `all` |
+| 1 | **📑 Document type?** | `knowledge` · `tech` · `sop` · `api` · `all` | `all` |
 | 2 | **🎨 Output format?** | `markdown` (plain) · `vitepress` (premium site) | `vitepress` |
 | 3 | **📂 Code scan scope?** | `full` (entire project) · `focused` (specific folder/feature) | `full` |
 | 4 | **🎯 Focus area?** *(only if `focused`)* | Folder name, module, or specific feature | — |
@@ -86,7 +84,7 @@ After receiving answers, **immediately create an execution plan** (do NOT ask mo
 Map the answers to this execution config:
 
 ```
-DOC_TYPE     = [knowledge | tech | sop | api | changelog | all]
+DOC_TYPE     = [knowledge | tech | sop | api | all]
 FORMAT       = [markdown | vitepress]
 SCOPE        = [full | focused]
 FOCUS_TARGET = [directory/module name if focused, else null]
@@ -144,13 +142,13 @@ Key rules to enforce:
 
 ### Step 3b: Apply SEO & LLM Guidelines (If enabled)
 
-**If SEO = yes:** Apply these SEO content writing guidelines directly:
+**If SEO = yes:** Read `skills/content-writing.md` for:
 - Keyword placement (title, H1, first paragraph, H2s, meta)
 - Inverted pyramid structure (answer first, details later)
 - Active voice (≥80%), transition words (≥30%)
 - FAQ in schema-ready format for rich snippets
 
-**If LLM_OPTIMIZE = yes:** Apply these AI-readability guidelines directly:
+**If LLM_OPTIMIZE = yes:** Read `skills/llm-optimization.md` for:
 - Clean heading hierarchy (no skipped levels)
 - Text descriptions alongside all Mermaid diagrams
 - Self-contained sections (≤500 words per H2)
@@ -161,10 +159,10 @@ Key rules to enforce:
 
 Based on the chosen type, read and follow the corresponding skill file:
 
-- **knowledge** → AI agent generates directly:
-  1. `docs/personas/` (Buyer & User Personas)
-  2. `docs/jtbd/` (JTBD Canvases)
-  3. `docs/flows/` (Workflow, Sequence, Lifecycle, Journey)
+- **knowledge** → Run 3 skills sequentially:
+  1. Read `skills/persona-builder.md` → `docs/personas/` (Buyer & User Personas)
+  2. Read `skills/jtbd-analyzer.md` → `docs/jtbd/` (JTBD Canvases)
+  3. Read `skills/flow-mapper.md` → `docs/flows/` (Workflow, Sequence, Lifecycle, Journey)
 
 - **tech** → Read `skills/tech-docs.md`, generate:
   - `docs/architecture.md` — System architecture + ADR
@@ -181,14 +179,7 @@ Based on the chosen type, read and follow the corresponding skill file:
   - `docs/api/` — Organized by resource
   - Each file: Quick Ref → Endpoints table → Multi-language examples
 
-- **changelog** → Read `skills/changelog-guide.md`, generate:
-  - `docs/changelog.md` — Full release history with 2 categories:
-    - 🚀 **Improvements** — features, enhancements, refactors
-    - 🐛 **Bug Fixes** — fixes, patches, corrections
-  - Reads from `CHANGELOG.md` at project root (generated by `cm-safe-deploy` Gate 8)
-  - If `CHANGELOG.md` doesn't exist, generates from git tags/history
-
-- **all** → Run `knowledge` → `tech` → `sop` → `api` → `changelog` sequentially
+- **all** → Run `knowledge` → `tech` → `sop` → `api` sequentially
 
 ### Step 5: Export
 
@@ -214,7 +205,7 @@ Read and follow `workflows/generate-sitemap.md`:
 
 ### Step 5c: Run SEO Audit (If SEO = yes)
 
-Read `skills/content-guidelines.md` SEO checklist section and audit every generated page:
+Read `skills/seo-checklist.md` and audit every generated page:
 - Title (50–60 chars, keyword) ✔️
 - Meta description (150–160 chars) ✔️
 - Single H1, no skipped levels ✔️
@@ -250,23 +241,15 @@ See also: `cm-deep-search` skill.
 
 ## CLI Quick Start
 
-For a fast interactive experience, use the built-in CLI scripts:
+For a fast interactive experience, users can run the doc generation script from the skill root:
 
 ```bash
-# Main documentation generator
+# Run from the cm-dockit skill directory
 bash scripts/doc-gen.sh
-
-# Full runner with DAG-based task execution
-bash scripts/dockit-runner.sh -p /path/to/project -t all
-
-# Dashboard view of progress
-bash scripts/dockit-dashboard.sh
-
-# Individual task runner
-bash scripts/dockit-task.sh
 ```
 
-> Run these scripts from the `cm-dockit` skill directory.
+> **Note:** The `scripts/` directory and `doc-gen.sh` script need to be created.
+> For now, trigger this skill by invoking `cm-dockit` directly via the AI assistant.
 
 ## UX Principles Applied
 

package/skills/cm-execution/SKILL.md

@@ -26,7 +26,12 @@ Before choosing execution mode, scan plan tasks for technology keywords:
 4. If gap found → trigger Discovery Loop (cm-skill-mastery Part C)
    → npx skills find "{keyword}" → review → ask user → install
 5. Log any installations to .cm-skills-log.json
-6. Only proceed to Mode Selection after all gaps resolved
+6. Code Intelligence Context (cm-codeintell):
+   → IF codegraph available: codegraph_context(task) for each task
+   → IF modifying shared code: codegraph_impact(symbol, depth=2)
+   → IF impact > 10 files: WARN "High impact change"
+   → Inject context into agent prompts → agents skip grep/glob
+7. Only proceed to Mode Selection after all gaps resolved
 ```
 
 ---

package/skills/cm-frappe-agent/SKILL.md

@@ -0,0 +1,134 @@
+---
+name: cm-frappe-agent
+description: |
+  Master Frappe Framework and ERPNext full-stack development. Build, upgrade, 
+  and maintain production-ready Frappe custom apps using the 7-Layer Architecture
+  combined with specialized AI agents for the FULL development lifecycle:
+  development, testing, debugging, bug fixing, installation, remote operations,
+  and performance optimization.
+
+  ALWAYS trigger for: frappe app, frappe doctype, bench, erpnext, frappe hooks,
+  frappe scheduler, frappe workflow, frappe report, frappe api, frappe controller,
+  "create frappe app", "write doctype", "frappe custom app", "bench migrate",
+  "upgrade frappe", "frappe engine", "frappe webhook", "frappe client script",
+  "frappe server script", "frappe test", "improve frappe", "frappe backend",
+  "frappe frontend", "frappe remote", "remote api", "frappe cloud", "REST API",
+  "curl frappe", "install bench", "setup frappe", "create site", 
+  "production setup", "fix bug", "fix error", "solve frappe error",
+  "frappe slow", "optimize query", "web form", "portal", "webform client script",
+  "frappe performance", "frappe install", "bench setup", "frappe permission",
+  "frappe fixture", "frappe workspace", "doc_events", "frappe i18n",
+  "frappe report", "frappe translation", "bench new-app"
+---
+
+# Goal
+
+To provide a **comprehensive lifecycle toolkit** for Frappe/ERPNext development — from installation and setup, through development and testing, to debugging, bug fixing, remote operations, and performance optimization. Built on the strict **7-Layer Architecture** (separating business logic from the Frappe ORM) with specialized **AI Agents** for each lifecycle stage.
+
+---
+
+# Lifecycle Overview
+
+```
+┌─────────────────────────────────────────────────────────────────────┐
+│                    FRAPPE DEVELOPMENT LIFECYCLE                      │
+│                                                                     │
+│  1. INSTALL    → Setup bench, sites, apps          [frappe-installer] │
+│  2. PLAN       → Architecture, DocType design       [frappe-planner]  │
+│  3. BUILD      → Backend, frontend, full-stack      [backend/frontend]│
+│  4. TEST       → Unit tests, integration tests      [commands/test]   │
+│  5. DEBUG      → Log analysis, error investigation  [frappe-debugger] │
+│  6. FIX        → Structured bug fix loop            [frappe-fixer]    │
+│  7. OPTIMIZE   → Performance tuning, caching        [frappe-perf]     │
+│  8. DEPLOY     → Migrate, build, production setup   [commands/bench]  │
+│  9. OPERATE    → Remote API, monitoring             [frappe-remote]   │
+│                                                                     │
+└─────────────────────────────────────────────────────────────────────┘
+```
+
+---
+
+# Instructions
+
+You are the orchestrator of the full Frappe development lifecycle. When handling a task, match it to the right lifecycle stage and invoke the appropriate agent.
+
+## 1. Frappe Architecture Laws: The 7-Layer Pattern
+
+Always reference the core architectural guidelines before implementing any feature:
+*See `resources/7-layer-architecture.md` for comprehensive code examples.*
+
+1. **DocType (Layer 1)**: Frappe manages the schema. Controllers handle `validate`, `on_submit`, etc. No heavy business logic here.
+2. **Engines (Layer 2)**: **Crucial.** Pure Python logic. No Frappe DB calls inside pure algorithms — side-effect-free and testable.
+3. **API (Layer 3)**: `@frappe.whitelist` endpoints using idempotent upsert patterns.
+4. **Tasks (Layer 4)**: Scheduler events (daily, weekly) acting as wrappers around Engines.
+5. **Setup (Layer 5)**: Idempotent install and migrate hooks (`after_install`, `after_migrate`).
+6. **Tests (Layer 6)**: Standalone pure logic tests.
+7. **Client JS (Layer 7)**: Shared utility namespaces (`window.myapp`) and list views.
+
+## 2. Agent Orchestration
+
+### Development Agents (Build)
+*   **DocType Architect (`agents/doctype-architect.md`)**: Schema, relations, workflow states.
+*   **Frappe Backend (`agents/frappe-backend.md`)**: Python APIs, controllers, and background jobs.
+*   **Frappe Frontend (`agents/frappe-frontend.md`)**: Client scripts, dialogs, custom formatters.
+*   **Frappe Custom Frontend (`agents/frappe-custom-frontend.md`)**: Custom standalone frontend pages.
+*   **ERPNext Customizer (`agents/erpnext-customizer.md`)**: Extending core ERPNext modules safely.
+
+### Lifecycle Agents (Operate)
+*   **Frappe Installer (`agents/frappe-installer.md`)**: Bench setup, site creation, production deployment.
+*   **Frappe Planner (`agents/frappe-planner.md`)**: Feature planning and technical design.
+*   **Frappe Debugger (`agents/frappe-debugger.md`)**: Error analysis and log investigation.
+*   **Frappe Fixer (`agents/frappe-fixer.md`)**: Structured bug-fix loop (reproduce → diagnose → fix → verify).
+*   **Frappe Performance (`agents/frappe-performance.md`)**: Query optimization, profiling, caching.
+*   **Frappe Environment Doctor (`agents/frappe-doctor.md`)**: Environment health checks, user record repair, and zombie process cleanup.
+*   **Frappe Remote Ops (`agents/frappe-remote-ops.md`)**: REST API operations for remote/cloud sites.
+*   **GitHub Workflow (`agents/github-workflow.md`)**: Git operations and CI/CD.
+
+## 3. Dedicated Sub-Skills
+
+*   `skills/doctype-patterns/SKILL.md` – Best practices for custom fields, naming rules.
+*   `skills/server-scripts/SKILL.md` – Server-side Python patterns.
+*   `skills/client-scripts/SKILL.md` – JavaScript form/list configurations.
+*   `skills/frappe-api/SKILL.md` – Frappe Framework ORM and Python API usage.
+*   `skills/bench-commands/SKILL.md` – Bench CLI reference.
+*   `skills/remote-operations/SKILL.md` – REST API patterns for remote sites.
+*   `skills/web-forms/SKILL.md` – Web Form development patterns.
+
+## 4. Resource References
+
+*   `resources/7-layer-architecture.md` – Core architecture with code examples.
+*   `resources/code-patterns-guide.md` – **Production code patterns** (Layer 1-9 with real code, i18n, CI/CD, strict constraints).
+*   `resources/bench_commands.md` – Managing sites, building, caching.
+*   `resources/common_pitfalls.md` – Things to avoid.
+*   `resources/scaffold_checklist.md` – New app scaffolding.
+*   `resources/upgrade_patterns.md` – Version upgrade patterns.
+*   `resources/rest-api-patterns.md` – REST API curl patterns.
+*   `resources/doctype-registry.md` – DocType discovery and exploration.
+*   `resources/installation-guide.md` – Complete setup guide.
+*   `resources/web-form-patterns.md` – Web Form scripting.
+
+---
+
+# Best Practices
+
+*   **Never Modify Core Files**: Always use `hooks.py`, Client Scripts, or Custom Fields.
+*   **DB Security**: Always use parameterized queries to prevent SQL injection.
+*   **Naming Conventions (CRITICAL)**: **ALWAYS** use English for `fieldname` (must be `snake_case`, e.g., `violation_name`) and DocType `names` (must be `Title Case`, e.g., `Warehouse Violation`). **NEVER** use Vietnamese or other non-ASCII characters in schema (`name` or `fieldname`). Use Frappe's Translation system or Field `Label` for localized display text. Non-ASCII names cause Frappe/MariaDB query builder & Insights SQL errors.
+*   **Testable Logic**: Keep controllers focused on dispatching. Business logic in `engines/`.
+*   **Error Logging**: ALWAYS use `frappe.log_error()`, NEVER `frappe.logger`.
+*   **Bug Fixes**: Follow the structured fix loop (reproduce → diagnose → fix → verify → document).
+*   **Environment Recovery**: When site boots fail with 500 errors, use `redis-cli flushall`, `bench clear-cache`, and verify core system users (`Guest`, `Administrator`) have `enabled=1` and `user_type='System User'`.
+*   **Remote Operations**: Never expose API keys. Always confirm destructive operations.
+
+---
+
+# Constraints
+
+*   Ensure all custom DocTypes have a Custom App module for proper export.
+*   Do not run destructive `bench` commands (like `--force` or `drop`) without explicit user consent.
+*   Avoid raw SQL unless performing complex joins the ORM cannot handle.
+*   Respect Document-level permissions unless explicitly instructed to use `ignore_permissions=True`.
+*   Never fabricate document data or fake API responses for remote operations.
+
+
+<!-- Generated by Skill Creator Ultra v1.0 - Upgraded v2.0 with lifecycle agents, remote ops, bug fixing, installation, and performance -->