codymaster 4.5.4 → 4.8.0

package/skills/cm-tdd/SKILL.md

@@ -1,7 +1,7 @@
 ---
-name: cm-tdd
+
+## name: cm-tdd
 description: Use when implementing any feature or bugfix, before writing implementation code
----
 
 # Test-Driven Development (TDD)
 
@@ -16,12 +16,14 @@ Write the test first. Watch it fail. Write minimal code to pass.
 ## When to Use
 
 **Always:**
+
 - New features
 - Bug fixes
 - Refactoring
 - Behavior changes
 
 **Exceptions (ask your human partner):**
+
 - Throwaway prototypes
 - Generated code
 - Configuration files
@@ -37,6 +39,7 @@ NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST
 Write code before the test? Delete it. Start over.
 
 **No exceptions:**
+
 - Don't keep it as "reference"
 - Don't "adapt" it while writing tests
 - Don't look at it
@@ -83,21 +86,14 @@ Before writing ANY test, check `.cm/CONTINUITY.md`:
 
 Write one minimal test showing what should happen.
 
-<Good>
-```typescript
-test('retries failed operations 3 times', async () => {
-  let attempts = 0;
-  const operation = () => {
-    attempts++;
-    if (attempts < 3) throw new Error('fail');
-    return 'success';
-  };
+```typescript test('retries failed operations 3 times', async () => { let attempts = 0; const operation = () => { attempts++; if (attempts < 3) throw new Error('fail'); return 'success'; };
 
   const result = await retryOperation(operation);
 
   expect(result).toBe('success');
   expect(attempts).toBe(3);
 });
+
 ```
 Clear name, tests real behavior, one thing
 </Good>
@@ -113,10 +109,12 @@ test('retry works', async () => {
   expect(mock).toHaveBeenCalledTimes(3);
 });
 ```
+
 Vague name, tests mock not code
-</Bad>
+
 
 **Requirements:**
+
 - One behavior
 - Clear name
 - Real code (no mocks unless unavoidable)
@@ -130,6 +128,7 @@ npm test path/to/test.test.ts
 ```
 
 Confirm:
+
 - Test fails (not errors)
 - Failure message is expected
 - Fails because feature missing (not typos)
@@ -142,37 +141,9 @@ Confirm:
 
 Write simplest code to pass the test.
 
-<Good>
-```typescript
-async function retryOperation<T>(fn: () => Promise<T>): Promise<T> {
-  for (let i = 0; i < 3; i++) {
-    try {
-      return await fn();
-    } catch (e) {
-      if (i === 2) throw e;
-    }
-  }
-  throw new Error('unreachable');
-}
-```
-Just enough to pass
-</Good>
+```typescript async function retryOperation(fn: () => Promise): Promise { for (let i = 0; i < 3; i++) { try { return await fn(); } catch (e) { if (i === 2) throw e; } } throw new Error('unreachable'); } ``` Just enough to pass
 
-<Bad>
-```typescript
-async function retryOperation<T>(
-  fn: () => Promise<T>,
-  options?: {
-    maxRetries?: number;
-    backoff?: 'linear' | 'exponential';
-    onRetry?: (attempt: number) => void;
-  }
-): Promise<T> {
-  // YAGNI
-}
-```
-Over-engineered
-</Bad>
+```typescript async function retryOperation( fn: () => Promise, options?: { maxRetries?: number; backoff?: 'linear' | 'exponential'; onRetry?: (attempt: number) => void; } ): Promise { // YAGNI } ``` Over-engineered
 
 Don't add features, refactor other code, or "improve" beyond the test.
 
@@ -185,6 +156,7 @@ npm test path/to/test.test.ts
 ```
 
 Confirm:
+
 - Test passes
 - Other tests still pass
 - Output pristine (no errors, warnings)
@@ -196,6 +168,7 @@ Confirm:
 ### REFACTOR - Clean Up
 
 After green only:
+
 - Remove duplication
 - Improve names
 - Extract helpers
@@ -208,17 +181,20 @@ Next failing test for next feature.
 
 ## Good Tests
 
-| Quality | Good | Bad |
-|---------|------|-----|
-| **Minimal** | One thing. "and" in name? Split it. | `test('validates email and domain and whitespace')` |
-| **Clear** | Name describes behavior | `test('test1')` |
-| **Shows intent** | Demonstrates desired API | Obscures what code should do |
+
+| Quality          | Good                                | Bad                                                 |
+| ---------------- | ----------------------------------- | --------------------------------------------------- |
+| **Minimal**      | One thing. "and" in name? Split it. | `test('validates email and domain and whitespace')` |
+| **Clear**        | Name describes behavior             | `test('test1')`                                     |
+| **Shows intent** | Demonstrates desired API            | Obscures what code should do                        |
+
 
 ## Why Order Matters
 
 **"I'll write tests after to verify it works"**
 
 Tests written after code pass immediately. Passing immediately proves nothing:
+
 - Might test wrong thing
 - Might test implementation, not behavior
 - Might miss edge cases you forgot
@@ -229,6 +205,7 @@ Test-first forces you to see the test fail, proving it actually tests something.
 **"I already manually tested all the edge cases"**
 
 Manual testing is ad-hoc. You think you tested everything but:
+
 - No record of what you tested
 - Can't re-run when code changes
 - Easy to forget cases under pressure
@@ -239,6 +216,7 @@ Automated tests are systematic. They run the same way every time.
 **"Deleting X hours of work is wasteful"**
 
 Sunk cost fallacy. The time is already gone. Your choice now:
+
 - Delete and rewrite with TDD (X more hours, high confidence)
 - Keep it and add tests after (30 min, low confidence, likely bugs)
 
@@ -247,6 +225,7 @@ The "waste" is keeping code you can't trust. Working code without real tests is
 **"TDD is dogmatic, being pragmatic means adapting"**
 
 TDD IS pragmatic:
+
 - Finds bugs before commit (faster than debugging after)
 - Prevents regressions (tests catch breaks immediately)
 - Documents behavior (tests show how to use code)
@@ -266,19 +245,21 @@ Tests-first force edge case discovery before implementing. Tests-after verify yo
 
 ## Common Rationalizations
 
-| Excuse | Reality |
-|--------|---------|
-| "Too simple to test" | Simple code breaks. Test takes 30 seconds. |
-| "I'll test after" | Tests passing immediately prove nothing. |
-| "Tests after achieve same goals" | Tests-after = "what does this do?" Tests-first = "what should this do?" |
-| "Already manually tested" | Ad-hoc ≠ systematic. No record, can't re-run. |
-| "Deleting X hours is wasteful" | Sunk cost fallacy. Keeping unverified code is technical debt. |
-| "Keep as reference, write tests first" | You'll adapt it. That's testing after. Delete means delete. |
-| "Need to explore first" | Fine. Throw away exploration, start with TDD. |
-| "Test hard = design unclear" | Listen to test. Hard to test = hard to use. |
-| "TDD will slow me down" | TDD faster than debugging. Pragmatic = test-first. |
-| "Manual test faster" | Manual doesn't prove edge cases. You'll re-test every change. |
-| "Existing code has no tests" | You're improving it. Add tests for existing code. |
+
+| Excuse                                 | Reality                                                                 |
+| -------------------------------------- | ----------------------------------------------------------------------- |
+| "Too simple to test"                   | Simple code breaks. Test takes 30 seconds.                              |
+| "I'll test after"                      | Tests passing immediately prove nothing.                                |
+| "Tests after achieve same goals"       | Tests-after = "what does this do?" Tests-first = "what should this do?" |
+| "Already manually tested"              | Ad-hoc ≠ systematic. No record, can't re-run.                           |
+| "Deleting X hours is wasteful"         | Sunk cost fallacy. Keeping unverified code is technical debt.           |
+| "Keep as reference, write tests first" | You'll adapt it. That's testing after. Delete means delete.             |
+| "Need to explore first"                | Fine. Throw away exploration, start with TDD.                           |
+| "Test hard = design unclear"           | Listen to test. Hard to test = hard to use.                             |
+| "TDD will slow me down"                | TDD faster than debugging. Pragmatic = test-first.                      |
+| "Manual test faster"                   | Manual doesn't prove edge cases. You'll re-test every change.           |
+| "Existing code has no tests"           | You're improving it. Add tests for existing code.                       |
+
 
 ## Red Flags - STOP and Start Over
 
@@ -303,6 +284,7 @@ Tests-first force edge case discovery before implementing. Tests-after verify yo
 **Bug:** Empty email accepted
 
 **RED**
+
 ```typescript
 test('rejects empty email', async () => {
   const result = await submitForm({ email: '' });
@@ -311,12 +293,14 @@ test('rejects empty email', async () => {
 ```
 
 **Verify RED**
+
 ```bash
 $ npm test
 FAIL: expected 'Email required', got undefined
 ```
 
 **GREEN**
+
 ```typescript
 function submitForm(data: FormData) {
   if (!data.email?.trim()) {
@@ -327,6 +311,7 @@ function submitForm(data: FormData) {
 ```
 
 **Verify GREEN**
+
 ```bash
 $ npm test
 PASS
@@ -339,25 +324,27 @@ Extract validation for multiple fields if needed.
 
 Before marking work complete:
 
-- [ ] Every new function/method has a test
-- [ ] Watched each test fail before implementing
-- [ ] Each test failed for expected reason (feature missing, not typo)
-- [ ] Wrote minimal code to pass each test
-- [ ] All tests pass
-- [ ] Output pristine (no errors, warnings)
-- [ ] Tests use real code (mocks only if unavoidable)
-- [ ] Edge cases and errors covered
+- Every new function/method has a test
+- Watched each test fail before implementing
+- Each test failed for expected reason (feature missing, not typo)
+- Wrote minimal code to pass each test
+- All tests pass
+- Output pristine (no errors, warnings)
+- Tests use real code (mocks only if unavoidable)
+- Edge cases and errors covered
 
 Can't check all boxes? You skipped TDD. Start over.
 
 ## When Stuck
 
-| Problem | Solution |
-|---------|----------|
+
+| Problem                | Solution                                                             |
+| ---------------------- | -------------------------------------------------------------------- |
 | Don't know how to test | Write wished-for API. Write assertion first. Ask your human partner. |
-| Test too complicated | Design too complicated. Simplify interface. |
-| Must mock everything | Code too coupled. Use dependency injection. |
-| Test setup huge | Extract helpers. Still complex? Simplify design. |
+| Test too complicated   | Design too complicated. Simplify interface.                          |
+| Must mock everything   | Code too coupled. Use dependency injection.                          |
+| Test setup huge        | Extract helpers. Still complex? Simplify design.                     |
+
 
 ## Debugging Integration
 
@@ -372,4 +359,4 @@ Production code → test exists and failed first
 Otherwise → not TDD
 ```
 
-No exceptions without your human partner's permission.
+No exceptions without your human partner's permission.

package/skills/profiles/README.md

@@ -0,0 +1,21 @@
+# Skill install profiles (Antigravity / Windsurf / token budget)
+
+Use with `install.sh`:
+
+```bash
+bash install.sh --gemini --profile core
+bash install.sh --antigravity --profile core
+bash install.sh --windsurf --profile core
+```
+
+- **core** — Orchestration, TDD, debugging, quality gates, deploy, secrets, identity, terminal (~21 skills). Recommended for global `~/.gemini/antigravity/skills`.
+- **growth** — Ads tracking, CRO, content factory, forms, dashboard, etc. Add on top of core (re-run install to the same target) or install only into a workspace project folder.
+- **design** — UX Master, design system, UI preview, JTBD, brainstorm.
+- **knowledge** — Dockit, NotebookLM skill, deep search, code intelligence, project bootstrap, reactor.
+- **full** — All skills (default when `--profile` is omitted). Same set as [full.txt](full.txt).
+
+**Global vs workspace:** Keep **core** in user global skills; add **growth** / **design** / **knowledge** under the project (e.g. `.gemini/antigravity/skills` in repo) so every session does not load the full catalog.
+
+**MCP:** Disable unused MCP servers in the IDE to avoid retry loops when a server errors; heavy external tools belong in optional profiles, not core.
+
+**Maintainers:** When adding a new `skills/cm-*` folder, update [full.txt](full.txt) and add the skill to the appropriate optional profile (`growth`, `design`, or `knowledge`) if it is not part of `core`.

package/skills/profiles/core.txt

@@ -0,0 +1,23 @@
+# CodyMaster profile: core — Antigravity/Windsurf token budget (orchestration + quality + safety)
+# Install: bash install.sh --gemini --profile core
+cm-skill-index
+cm-how-it-work
+cm-start
+cm-planning
+cm-execution
+cm-continuity
+cm-status
+cm-tdd
+cm-debugging
+cm-code-review
+cm-clean-code
+cm-quality-gate
+cm-test-gate
+cm-safe-deploy
+cm-secret-shield
+cm-identity-guard
+cm-security-gate
+cm-safe-i18n
+cm-skill-chain
+cm-git-worktrees
+cm-terminal

package/skills/profiles/design.txt

@@ -0,0 +1,6 @@
+# UX/UI and product discovery
+cm-design-system
+cm-ux-master
+cm-ui-preview
+cm-brainstorm-idea
+cm-jtbd

package/skills/profiles/full.txt

@@ -0,0 +1,58 @@
+# Complete CodyMaster skill set (same as default install when --profile full or omitted)
+# Kept in sync with skills/cm-*/ — update when adding skills
+cm-ads-tracker
+cm-auto-publisher
+cm-autopilot
+cm-booking-calendar
+cm-brainstorm-idea
+cm-browse
+cm-clean-code
+cm-code-review
+cm-codeintell
+cm-conductor-worktrees
+cm-content-factory
+cm-continuity
+cm-cro-methodology
+cm-dashboard
+cm-debugging
+cm-deep-search
+cm-design-studio
+cm-design-system
+cm-dockit
+cm-ecosystem-roadmap
+cm-engineering-meta
+cm-example
+cm-execution
+cm-git-worktrees
+cm-google-form
+cm-growth-hacking
+cm-guardian-runtime
+cm-how-it-work
+cm-identity-guard
+cm-jtbd
+cm-mcp-engineering
+cm-notebooklm
+cm-planning
+cm-post-deploy-canary
+cm-project-bootstrap
+cm-qa-visual-cli
+cm-quality-gate
+cm-reactor
+cm-readit
+cm-retro-cli
+cm-safe-deploy
+cm-safe-i18n
+cm-second-opinion-cli
+cm-secret-shield
+cm-security-gate
+cm-skill-chain
+cm-skill-index
+cm-skill-mastery
+cm-sprint-bus
+cm-start
+cm-status
+cm-tdd
+cm-terminal
+cm-test-gate
+cm-ui-preview
+cm-ux-master

package/skills/profiles/growth.txt

@@ -0,0 +1,10 @@
+# Marketing, CRO, ads tracking, content — use with core or standalone
+cm-ads-tracker
+cm-cro-methodology
+cm-growth-hacking
+cm-booking-calendar
+cm-content-factory
+cm-auto-publisher
+cm-google-form
+cm-readit
+cm-dashboard

package/skills/profiles/knowledge.txt

@@ -0,0 +1,7 @@
+# Docs, codebase intelligence, research (often larger skills / MCP-adjacent)
+cm-notebooklm
+cm-deep-search
+cm-codeintell
+cm-dockit
+cm-project-bootstrap
+cm-reactor

package/scripts/test-gemini.js

@@ -1,13 +0,0 @@
-const { exec, spawn } = require('child_process');
-
-// Method 1: exec
-exec('gemini -y -p "Hello!"', (err, stdout, stderr) => {
-    console.log('EXEC Result:', stdout || stderr);
-});
-
-// Method 2: spawn
-const child = spawn('gemini', ['-y', '-p', 'Hello!']);
-let out = '';
-child.stdout.on('data', d => out += d);
-child.stderr.on('data', d => out += d);
-child.on('close', () => console.log('SPAWN Result:', out));

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

@@ -1,134 +0,0 @@
----
-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 -->