denchclaw 2.3.21 → 2.4.0

package/skills/crm/views-filters/SKILL.md

@@ -0,0 +1,303 @@
+---
+name: views-filters
+description: .object.yaml format and template, view type settings (kanban, calendar, timeline, gallery, list), saved views with filter operators, and date format rules.
+metadata: { "openclaw": { "inject": true, "always": true, "emoji": "👁️" } }
+---
+
+# CRM Views & Filters
+
+This skill covers `.object.yaml` format, view types, saved views, and filter operators. For workspace fundamentals, see the parent **crm** skill (`crm/SKILL.md`). For creating objects end-to-end, see **object-builder** (`crm/object-builder/SKILL.md`).
+
+---
+
+## .object.yaml Format
+
+Every object directory MUST contain a `.object.yaml` file. This is a lightweight metadata projection that the sidebar reads. Generate it from DuckDB after creating or modifying any object.
+
+Template:
+
+```yaml
+id: "<object_id from DuckDB>"
+name: "<object_name>"
+description: "<object_description>"
+icon: "<lucide_icon_name>"
+default_view: "<table|kanban|calendar|timeline|gallery|list>"
+entry_count: <number>
+fields:
+  - name: "Full Name"
+    type: text
+    required: true
+  - name: "Email Address"
+    type: email
+    required: true
+  - name: "Website"
+    type: url
+  - name: "Status"
+    type: enum
+    values: ["New", "Contacted", "Qualified", "Converted"]
+  - name: "Company"
+    type: relation
+    related_object: company
+    relationship_type: many_to_one
+  - name: "Assigned To"
+    type: user
+  - name: "Actions"
+    type: action
+    action_config:
+      actions:
+        - id: act_mark_done
+          label: "Mark Done"
+          variant: success
+          scriptPath: ".actions/mark-done.sh"
+```
+
+**Action fields** include `action_config` (not `values` or `required`). The `action_config` mirrors the JSON stored in the field's `default_value` in DuckDB. See the **actions** skill for details.
+
+### View Type Settings
+
+`.object.yaml` supports a `view_settings` block for configuring how each view type renders. These settings serve as defaults; individual saved views can override them.
+
+```yaml
+view_settings:
+  kanbanField: "Status" # enum field to group kanban columns by
+  calendarDateField: "Due Date" # date field for calendar events
+  calendarEndDateField: "End Date" # optional: end date for multi-day events
+  calendarMode: "month" # day | week | month | year
+  timelineStartField: "Start Date" # date field for timeline bar start
+  timelineEndField: "End Date" # date field for timeline bar end
+  timelineGroupField: "Status" # optional: enum field to group timeline rows
+  timelineZoom: "week" # day | week | month | quarter
+  galleryTitleField: "Name" # text field for gallery card title
+  galleryCoverField: "Image" # optional: field for gallery card cover
+  listTitleField: "Name" # text field for list row title
+  listSubtitleField: "Description" # optional: text field for list row subtitle
+  column_widths: # optional: custom column widths in pixels (persisted on drag-resize)
+    Full Name: 250
+    Email Address: 200
+    Status: 150
+```
+
+If an object has no custom date field, you MUST fall back to system timestamps:
+
+- `created_at` (always available on entries)
+- `updated_at` (always available on entries)
+
+These can be used in `calendarDateField`, `timelineStartField`, `timelineEndField`, filters, sorts, and date-based user requests.
+
+**View types:**
+
+| View Type  | Best for                        | Required settings           |
+| ---------- | ------------------------------- | --------------------------- |
+| `table`    | Spreadsheet-like data editing   | None (default)              |
+| `kanban`   | Status-based boards             | `kanbanField` (enum)        |
+| `calendar` | Date-based entries              | `calendarDateField` (date)  |
+| `timeline` | Gantt charts / project planning | `timelineStartField` (date) |
+| `gallery`  | Visual card grid                | None (auto-detects title)   |
+| `list`     | Simple compact list             | None (auto-detects title)   |
+
+When creating objects with specific use cases, set `default_view` and `view_settings` appropriately:
+
+- Task boards: `default_view: "kanban"` + `view_settings.kanbanField: "Status"`
+- Event calendars: `default_view: "calendar"` + `view_settings.calendarDateField: "Date"`
+- Project timelines: `default_view: "timeline"` + `view_settings.timelineStartField: "Start Date"` + `view_settings.timelineEndField: "End Date"`
+
+---
+
+## Saved Views and Filters
+
+`.object.yaml` supports a `views` section for saved filter views. These views appear in the UI filter bar and can be created or modified by the agent to immediately change what the user sees (the UI live-reloads via the file watcher).
+
+Default behavior:
+
+- When the user asks to filter, narrow, segment, show only, or hide entries in the UI, create or update a saved view and set `active_view` even if they did not explicitly ask to "create a view".
+- For table views, `columns` is optional. Omit it by default. If `columns` is absent, the UI shows the default/all columns for that view.
+- `views[].columns` controls visibility only, not display order.
+- Only include `columns` when the user explicitly asks for a specific visible subset of columns.
+- If the user asks to reorder columns, update the object's field `sort_order` in DuckDB and regenerate the top-level `.object.yaml` `fields` list in the same order.
+
+### Filter Operators by Field Type
+
+| Field Type          | Operators                                                                                  |
+| ------------------- | ------------------------------------------------------------------------------------------ |
+| text/richtext/email | contains, not_contains, equals, not_equals, starts_with, ends_with, is_empty, is_not_empty |
+| number              | eq, neq, gt, gte, lt, lte, between, is_empty, is_not_empty                                 |
+| date                | on, before, after, date_between, relative_past, relative_next, is_empty, is_not_empty      |
+| enum                | is, is_not, is_any_of, is_none_of, is_empty, is_not_empty                                  |
+| boolean             | is_true, is_false, is_empty, is_not_empty                                                  |
+| relation/user       | has_any, has_none, has_all, is_empty, is_not_empty                                         |
+| tags                | contains, not_contains, is_empty, is_not_empty                                             |
+
+**System timestamp columns are always available on every object entry**:
+
+- `created_at` (date/time)
+- `updated_at` (date/time)
+
+Treat them as date fields for filtering, sorting, calendar, and timeline operations even when `fields` has no `date` type columns.
+
+### Views Template
+
+Append to `.object.yaml`:
+
+**IMPORTANT: The `field` value in filter rules must match the exact field name (case-sensitive) as it appears in the `fields` list, or use system column names (`created_at`, `updated_at`).**
+
+```yaml
+views:
+  - name: "Active deals"
+    view_type: "table"
+    filters:
+      id: root
+      conjunction: and
+      rules:
+        - id: f1
+          field: "Status"
+          operator: is_any_of
+          value:
+            - "Negotiating"
+            - "Proposal sent"
+        - id: f2
+          field: "Amount"
+          operator: gte
+          value: 10000
+    sort:
+      - field: updated_at
+        direction: desc
+
+  - name: "Board"
+    view_type: "kanban"
+    settings:
+      kanbanField: "Status"
+
+  - name: "Calendar"
+    view_type: "calendar"
+    settings:
+      calendarDateField: "Due Date"
+      calendarMode: "month"
+
+  - name: "Timeline"
+    view_type: "timeline"
+    settings:
+      timelineStartField: "Start Date"
+      timelineEndField: "End Date"
+      timelineGroupField: "Status"
+      timelineZoom: "week"
+
+  - name: "Overdue"
+    view_type: "table"
+    filters:
+      id: root
+      conjunction: and
+      rules:
+        - id: f1
+          field: "Due Date"
+          operator: before
+          value: today
+        - id: f2
+          field: "Status"
+          operator: is_not
+          value: Done
+
+active_view: "Active deals"
+```
+
+Each saved view can specify:
+
+- `view_type`: `table` | `kanban` | `calendar` | `timeline` | `gallery` | `list` (defaults to object's `default_view`)
+- `settings`: per-view-type configuration (overrides object-level `view_settings`)
+- `filters`: standard filter rules
+- `sort`: sort rules
+- `columns`: optional visible column names for table view. Omit by default; if absent, the table shows the default/all columns. This controls visibility only, not order. Only set this when the user explicitly requests specific columns.
+- `column_widths`: optional map of field name to pixel width. Set when the user explicitly asks for specific column sizes. The UI also auto-persists widths when columns are drag-resized.
+
+When a user asks for date-based operations (e.g. move from one date to another) and no custom date fields exist, default to `created_at` unless the user explicitly asks for `updated_at`.
+
+### Date Format
+
+All date filter values MUST use ISO 8601 `YYYY-MM-DD` strings (e.g. `"2026-03-01"`). The special value `today` is also supported for `on`, `before`, and `after` operators.
+
+### Date Range Filter (`date_between`)
+
+```yaml
+- id: f1
+  field: Due Date
+  operator: date_between
+  value:
+    - "2026-03-01"
+    - "2026-03-31"
+```
+
+### Relative Date Filters (e.g. "in the last 7 days")
+
+```yaml
+- id: f1
+  field: created_at
+  operator: relative_past
+  relativeAmount: 7
+  relativeUnit: days
+```
+
+### OR Groups (match any rule)
+
+```yaml
+filters:
+  id: root
+  conjunction: or
+  rules:
+    - id: f1
+      field: "Status"
+      operator: is
+      value: "Active"
+    - id: f2
+      field: "Priority"
+      operator: is
+      value: "High"
+```
+
+---
+
+## Generating .object.yaml from DuckDB
+
+**When the user asks to filter/show/hide entries by natural language**, treat that as a request to create or update a saved view unless they clearly want a one-off analysis only. Write the `.object.yaml` with the appropriate views and set `active_view`. Do not add `columns` unless the user explicitly asks for specific visible columns. If they ask to reorder columns, handle that separately by updating field `sort_order` and regenerating the top-level `fields` projection. The web UI will pick up the change instantly via SSE file watcher. Every rule needs a unique `id` (short alphanumeric string). The root filter group also needs `id: root`.
+
+Generate by querying DuckDB then writing the file:
+
+```bash
+# 1. Query object + fields from DuckDB
+duckdb {{WORKSPACE_PATH}}/workspace.duckdb -json "
+  SELECT o.id, o.name, o.description, o.icon, o.default_view,
+         (SELECT COUNT(*) FROM entries WHERE object_id = o.id) as entry_count
+  FROM objects o WHERE o.name = 'lead'
+"
+duckdb {{WORKSPACE_PATH}}/workspace.duckdb -json "
+  SELECT name, type, required, enum_values, default_value FROM fields
+  WHERE object_id = (SELECT id FROM objects WHERE name = 'lead')
+  ORDER BY sort_order
+"
+
+# 2. Use the query results to write .object.yaml (use actual values, not placeholders)
+OBJ_ID=$(duckdb {{WORKSPACE_PATH}}/workspace.duckdb -noheader -list "SELECT id FROM objects WHERE name = 'lead'")
+ENTRY_COUNT=$(duckdb {{WORKSPACE_PATH}}/workspace.duckdb -noheader -list "SELECT COUNT(*) FROM entries WHERE object_id = '$OBJ_ID'")
+
+mkdir -p {{WORKSPACE_PATH}}/lead
+cat > {{WORKSPACE_PATH}}/lead/.object.yaml << EOF
+id: "$OBJ_ID"
+name: "lead"
+description: "Sales leads tracking"
+icon: "user-plus"
+default_view: "table"
+entry_count: $ENTRY_COUNT
+fields:
+  - name: "Full Name"
+    type: text
+    required: true
+  - name: "Email Address"
+    type: email
+    required: true
+  - name: "Status"
+    type: enum
+    values: ["New", "Contacted", "Qualified", "Converted"]
+  - name: "Score"
+    type: number
+  - name: "Notes"
+    type: richtext
+EOF
+```

package/skills/gstack/SKILL.md

@@ -0,0 +1,101 @@
+---
+name: gstack-workflow
+description: Structured AI-assisted development workflow with specialist roles — Think, Plan, Build, Review, Test, Ship, Reflect. Adapted from garrytan/gstack (MIT).
+metadata: { "openclaw": { "inject": true, "always": true, "emoji": "⚡" } }
+---
+
+# gstack — Structured Development Workflow
+
+A process that turns AI into a virtual engineering team. Eighteen specialist roles, structured as a sprint: **Think → Plan → Build → Review → Test → Ship → Reflect**. Each skill feeds into the next.
+
+Adapted from [garrytan/gstack](https://github.com/garrytan/gstack) (MIT License).
+
+---
+
+## Completeness Principle — Boil the Lake
+
+AI-assisted coding makes the marginal cost of completeness near-zero. When presenting options:
+
+- If Option A is complete (all edge cases, full coverage) and Option B is a shortcut — **always recommend A**.
+- **Lake vs. ocean:** A "lake" is boilable — 100% test coverage for a module, full feature implementation, all edge cases. An "ocean" is not — multi-quarter migrations, rewriting dependencies. Recommend boiling lakes. Flag oceans as out of scope.
+- Don't skip the last 10% to "save time" — with AI, that 10% costs seconds.
+
+## Search Before Building
+
+Before building infrastructure or unfamiliar patterns — **search first**.
+
+**Three layers of knowledge:**
+- **Layer 1** (tried and true): Don't reinvent the wheel.
+- **Layer 2** (new and popular): Search for these, but scrutinize.
+- **Layer 3** (first principles): Original observations from reasoning about the specific problem. The most valuable.
+
+---
+
+## Sprint Workflow
+
+| Phase | Skill | Role | What it does |
+|-------|-------|------|--------------|
+| **Think** | [office-hours](office-hours/SKILL.md) | YC Office Hours | Forcing questions that reframe the product before code. Design doc feeds downstream. |
+| **Plan** | [plan-ceo-review](plan-ceo-review/SKILL.md) | CEO / Founder | Rethink the problem. 10-star product. Four modes: Expansion, Selective, Hold, Reduction. |
+| **Plan** | [plan-eng-review](plan-eng-review/SKILL.md) | Eng Manager | Lock architecture, data flow, diagrams, edge cases, tests. |
+| **Plan** | [plan-design-review](plan-design-review/SKILL.md) | Senior Designer | Rate design dimensions 0-10, explain what a 10 looks like, edit the plan. |
+| **Plan** | [design-consultation](design-consultation/SKILL.md) | Design Partner | Build a complete design system from scratch. |
+| **Review** | [review](review/SKILL.md) | Staff Engineer | Find bugs that pass CI but blow up in production. Auto-fix obvious ones. |
+| **Review** | [design-review](design-review/SKILL.md) | Designer Who Codes | Same audit as plan-design-review, then fixes what it finds. |
+| **Debug** | [investigate](investigate/SKILL.md) | Debugger | Systematic root-cause debugging. No fixes without investigation. |
+| **Test** | [qa](qa/SKILL.md) | QA Lead | Test the app, find bugs, fix with atomic commits, re-verify. |
+| **Test** | [qa-only](qa-only/SKILL.md) | QA Reporter | Same methodology as qa, but report only — no code changes. |
+| **Test** | [benchmark](benchmark/SKILL.md) | Performance Engineer | Page load times, Core Web Vitals, bundle sizes. Before/after on every PR. |
+| **Ship** | [ship](ship/SKILL.md) | Release Engineer | Sync main, run tests, audit coverage, push, open PR. |
+| **Ship** | [land-and-deploy](land-and-deploy/SKILL.md) | Release Engineer | Merge PR, wait for CI, deploy, verify production health. |
+| **Ship** | [canary](canary/SKILL.md) | SRE | Post-deploy monitoring loop. Console errors, perf regressions, page failures. |
+| **Reflect** | [retro](retro/SKILL.md) | Eng Manager | Weekly retro with per-person breakdowns, shipping streaks, test health. |
+| **Reflect** | [document-release](document-release/SKILL.md) | Technical Writer | Update all docs to match what shipped. Catches stale READMEs. |
+
+### Safety Tools
+
+| Skill | What it does |
+|-------|--------------|
+| [careful](careful/SKILL.md) | Warn before destructive commands (rm -rf, DROP TABLE, force-push). |
+| [freeze](freeze/SKILL.md) | Restrict edits to one directory to prevent accidental changes. |
+| [guard](guard/SKILL.md) | Maximum safety: careful + freeze combined. |
+| [unfreeze](unfreeze/SKILL.md) | Remove the freeze boundary. |
+
+---
+
+## Completion Status Protocol
+
+When completing any skill workflow, report status using one of:
+- **DONE** — All steps completed successfully. Evidence provided.
+- **DONE_WITH_CONCERNS** — Completed, but with issues to flag.
+- **BLOCKED** — Cannot proceed. State what's blocking and what was tried.
+- **NEEDS_CONTEXT** — Missing information required to continue.
+
+### Escalation
+
+It is always OK to stop and say "this is too hard" or "I'm not confident in this result."
+
+- If you have attempted a task 3 times without success, STOP and escalate.
+- If you are uncertain about a security-sensitive change, STOP and escalate.
+
+---
+
+## Suggesting Skills
+
+When you notice the user is at a particular stage, suggest the appropriate skill:
+
+- Brainstorming a new idea → suggest office-hours
+- Reviewing a plan (strategy) → suggest plan-ceo-review
+- Reviewing a plan (architecture) → suggest plan-eng-review
+- Reviewing a plan (design) → suggest plan-design-review
+- Creating a design system → suggest design-consultation
+- Debugging errors → suggest investigate
+- Testing the app → suggest qa
+- Code review before merge → suggest review
+- Visual design audit → suggest design-review
+- Ready to deploy / create PR → suggest ship
+- Post-ship doc updates → suggest document-release
+- Weekly retrospective → suggest retro
+- Working with production or live systems → suggest careful
+
+All child skills are seeded into the workspace alongside this parent skill and can be read at `{{WORKSPACE_PATH}}/skills/gstack/<child>/SKILL.md`.

package/skills/gstack/benchmark/SKILL.md

@@ -0,0 +1,86 @@
+---
+name: benchmark
+description: |
+  Performance benchmarking. Baseline page load times, Core Web Vitals, and
+  resource sizes. Compare before/after on every PR. Catch bundle size
+  regressions before they ship.
+---
+
+# Benchmark — Measure Performance
+
+Establish baselines and catch regressions.
+
+**Related skills:** [qa](../qa/SKILL.md) | [review](../review/SKILL.md) | [ship](../ship/SKILL.md)
+
+---
+
+## What to Measure
+
+### Core Web Vitals
+- **LCP** (Largest Contentful Paint) — Target: < 2.5s
+- **FID** (First Input Delay) — Target: < 100ms
+- **CLS** (Cumulative Layout Shift) — Target: < 0.1
+
+### Page Load
+- **TTFB** (Time to First Byte)
+- **DOMContentLoaded**
+- **Load event**
+- **Full page load** (all resources)
+
+### Bundle Size
+- **JavaScript bundle size** (compressed + uncompressed)
+- **CSS bundle size**
+- **Total transfer size**
+- **Number of requests**
+
+### Resource Analysis
+- **Largest assets** by size
+- **Uncompressed assets** that should be compressed
+- **Unused JavaScript** (tree-shakeable)
+- **Image optimization** opportunities
+
+---
+
+## Workflow
+
+### 1. Baseline (before changes)
+
+```bash
+git stash  # or checkout base branch
+# Run measurements
+git stash pop  # or checkout feature branch
+```
+
+### 2. Current (after changes)
+
+Run the same measurements on the current branch.
+
+### 3. Compare
+
+```
+PERFORMANCE REPORT
+═══════════════════════════════════════
+                    Before    After     Delta
+LCP:                2.1s      2.3s     +200ms ⚠️
+CLS:                0.02      0.01     -0.01  ✓
+JS Bundle:          245KB     312KB    +67KB  ⚠️
+CSS Bundle:         42KB      43KB     +1KB   ✓
+Requests:           23        25       +2
+Transfer:           890KB     1.1MB    +210KB ⚠️
+═══════════════════════════════════════
+```
+
+### 4. Flag Regressions
+
+- JS bundle size increase > 10KB → warning
+- LCP increase > 200ms → warning
+- CLS increase > 0.05 → critical
+- New unoptimized images → warning
+
+---
+
+## Important Rules
+
+- Always compare against the base branch, not an absolute value
+- Measure multiple times and take the median to reduce noise
+- Flag regressions but don't block — some features legitimately increase size

package/skills/gstack/canary/SKILL.md

@@ -0,0 +1,65 @@
+---
+name: canary
+description: |
+  Post-deploy monitoring loop. Watches for console errors, performance
+  regressions, and page failures. Periodic screenshots and anomaly detection.
+  Use after deploying to production.
+---
+
+# Canary — Post-Deploy Monitoring
+
+Extended monitoring after deployment. Watch for problems that only appear under real traffic.
+
+**Related skills:** [land-and-deploy](../land-and-deploy/SKILL.md) | [qa](../qa/SKILL.md) | [benchmark](../benchmark/SKILL.md)
+
+---
+
+## Monitoring Loop
+
+Run every 2-5 minutes for the specified duration (default: 30 minutes):
+
+### Each Iteration
+
+1. **Navigate** to the production URL
+2. **Console errors** — any new JS exceptions since last check?
+3. **Network errors** — any failed requests?
+4. **Performance** — page load time within normal range?
+5. **Screenshot** — visual comparison with previous iteration
+6. **Key interactions** — test 2-3 critical flows (login, main feature, etc.)
+
+### Anomaly Detection
+
+Flag if any of these change between iterations:
+
+- New console errors appear
+- Network requests start failing
+- Page load time increases > 50% from baseline
+- Visual layout changes unexpectedly
+- Key text content disappears
+- HTTP status codes change (200 → 500)
+
+---
+
+## Output
+
+```
+CANARY REPORT
+═══════════════════════════════════════
+Duration:         30 minutes
+Checks:           12
+Anomalies:        0
+Console errors:   0 new
+Network errors:   0 new
+Performance:      Stable (avg 1.8s LCP)
+Status:           HEALTHY
+═══════════════════════════════════════
+```
+
+If anomalies detected:
+
+```
+⚠️ ANOMALY DETECTED at [timestamp]
+Type:     [console error / network failure / perf regression / visual change]
+Details:  [specific error or change]
+Action:   [recommend: investigate / revert / monitor]
+```

package/skills/gstack/careful/SKILL.md

@@ -0,0 +1,66 @@
+---
+name: careful
+description: |
+  Safety guardrails — warns before destructive commands. Activate by saying
+  "be careful" or when working with production systems.
+  Warns on: rm -rf, DROP TABLE, force-push, git reset --hard, DELETE without WHERE.
+---
+
+# Careful — Destructive Command Guardrails
+
+When active, warn before any potentially destructive operation. The user must explicitly confirm before proceeding.
+
+**Related skills:** [freeze](../freeze/SKILL.md) | [guard](../guard/SKILL.md) | [unfreeze](../unfreeze/SKILL.md)
+
+---
+
+## Destructive Commands to Guard
+
+### File System
+- `rm -rf` — Recursive force delete
+- `rm -r` on important directories
+- Any operation that removes entire directories
+
+### Database
+- `DROP TABLE` / `DROP DATABASE`
+- `DELETE` without `WHERE` clause
+- `TRUNCATE TABLE`
+- `ALTER TABLE DROP COLUMN`
+
+### Git
+- `git push --force` / `git push -f` (especially to main/master)
+- `git reset --hard`
+- `git clean -fd`
+- `git branch -D` on shared branches
+
+### Infrastructure
+- Destroying cloud resources (terraform destroy, kubectl delete)
+- Modifying production environment variables
+- Stopping production services
+
+---
+
+## Warning Format
+
+When a destructive command is about to execute:
+
+```
+⚠️  DESTRUCTIVE COMMAND DETECTED
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+Command:   [the command]
+Risk:      [what could go wrong]
+Reversible: YES / NO / PARTIAL
+
+Proceed? (The user must explicitly confirm)
+```
+
+---
+
+## Rules
+
+- **Never execute a destructive command without explicit user confirmation**
+- **Always explain what could go wrong** — don't just say "are you sure?"
+- **Suggest safer alternatives** when they exist (e.g., `git push --force-with-lease` instead of `--force`)
+- **The user can always override** — these are guardrails, not handcuffs
+
+Combine with [freeze](../freeze/SKILL.md) for maximum safety, or use [guard](../guard/SKILL.md) for both at once.