shmakk 1.1.0 → 1.2.0

package/skills/general-ddd-aggregate.md

@@ -0,0 +1,52 @@
+---
+name: ddd-aggregate
+description: Scaffold an aggregate root with entity, value objects, repository interface, domain events, and test stubs
+argument-hint: "<context> <aggregate-name>"
+allowed-tools: Bash(mkdir * find * ls *) Read Write Edit Grep Glob mcp__claude-flow__memory_store mcp__claude-flow__memory_search mcp__claude-flow__agentdb_hierarchical-store mcp__claude-flow__hooks_pre-task mcp__claude-flow__hooks_post-task
+category: general
+---
+Scaffold a complete aggregate root inside a bounded context.
+
+Parse `$ARGUMENTS` as `<context-name> <aggregate-name>` (both kebab-case). The context must already exist under `src/`.
+
+## Steps
+
+1. **Validate**: Confirm `src/<context>/domain/` exists. If not, suggest running `/ddd-context <context>` first.
+
+2. **Pre-task hook**: `npx @claude-flow/cli@latest hooks pre-task --description "DDD aggregate: <aggregate-name> in <context>"`
+
+3. **Create aggregate root entity**:
+   - File: `src/<context>/domain/entities/<aggregate-name>.entity.ts`
+   - Include: unique ID field, constructor with invariant validation, domain methods that enforce business rules, `equals()` based on identity
+   - Export a TypeScript class extending or implementing a base `AggregateRoot` interface
+
+4. **Create value objects**:
+   - File: `src/<context>/domain/value-objects/<aggregate-name>-id.value-object.ts`
+   - Include: immutable ID value object with factory method and validation
+   - Add additional value objects as properties of the aggregate suggest them
+
+5. **Create repository interface**:
+   - File: `src/<context>/domain/repositories/<aggregate-name>.repository.ts`
+   - Include: `findById`, `save`, `delete` methods
+   - Use the aggregate root and its ID value object as types
+   - This is an interface only -- no implementation (infrastructure concern)
+
+6. **Create domain events**:
+   - File: `src/<context>/domain/events/<aggregate-name>-created.event.ts`
+   - File: `src/<context>/domain/events/<aggregate-name>-updated.event.ts`
+   - Include: event name (past tense), timestamp, aggregate ID, payload
+
+7. **Create unit test stubs**:
+   - File: `src/<context>/domain/entities/<aggregate-name>.entity.test.ts`
+   - Include: test cases for construction invariants, domain methods, equality
+   - Use `describe`/`it` with `should [behavior] when [condition]` names
+
+8. **Update barrel exports**: Add new files to the relevant `index.ts` barrel files.
+
+9. **Store in domain model graph**:
+   ```
+   mcp__claude-flow__agentdb_hierarchical-store --parent "context:<context>" --child "aggregate:<aggregate-name>" --relation "contains"
+   mcp__claude-flow__memory_store --key "ddd-aggregate-<context>-<aggregate-name>" --value "AGGREGATE_SUMMARY" --namespace tasks
+   ```
+
+10. **Post-task hook**: `npx @claude-flow/cli@latest hooks post-task --task-id "ddd-aggregate-<aggregate-name>" --success true --train-neural true`

package/skills/general-ddd-context.md

@@ -0,0 +1,46 @@
+---
+name: ddd-context
+description: Create and manage a DDD bounded context with standard directory structure
+argument-hint: "<context-name>"
+allowed-tools: Bash(mkdir * find * ls *) Read Write Edit Grep Glob mcp__claude-flow__memory_store mcp__claude-flow__memory_search mcp__claude-flow__agentdb_hierarchical-store
+category: general
+---
+Create a bounded context directory structure for the given context name.
+
+Parse `$ARGUMENTS` as the context name (kebab-case). If empty, list existing contexts.
+
+## Steps
+
+1. **Validate name**: Ensure the context name is kebab-case and does not already exist under `src/`.
+
+2. **Create directory structure**:
+   ```
+   src/<context-name>/
+     domain/
+       entities/
+       value-objects/
+       events/
+       services/
+       repositories/
+     application/
+     infrastructure/
+   ```
+
+3. **Generate index files**:
+   - `src/<context-name>/domain/entities/index.ts` -- barrel export for entities
+   - `src/<context-name>/domain/value-objects/index.ts` -- barrel export for value objects
+   - `src/<context-name>/domain/events/index.ts` -- barrel export for domain events
+   - `src/<context-name>/domain/services/index.ts` -- barrel export for domain services
+   - `src/<context-name>/domain/repositories/index.ts` -- barrel export for repository interfaces
+   - `src/<context-name>/domain/index.ts` -- re-export all domain submodules
+   - `src/<context-name>/application/index.ts` -- barrel export for application services
+   - `src/<context-name>/infrastructure/index.ts` -- barrel export for infrastructure implementations
+   - `src/<context-name>/index.ts` -- public API of the bounded context (re-exports domain and application only, NOT infrastructure)
+
+4. **Store in domain model graph**:
+   ```
+   mcp__claude-flow__agentdb_hierarchical-store --parent "domain" --child "context:<context-name>" --relation "contains"
+   mcp__claude-flow__memory_store --key "ddd-context-<context-name>" --value "Created bounded context" --namespace tasks
+   ```
+
+5. **Report**: Confirm the context was created and list the generated files.

package/skills/general-ddd-validate.md

@@ -0,0 +1,51 @@
+---
+name: ddd-validate
+description: Validate domain boundaries -- detect cross-context import violations and aggregate invariant issues
+argument-hint: ""
+allowed-tools: Bash(find * grep * npx *) Read Grep Glob mcp__claude-flow__memory_store mcp__claude-flow__memory_search mcp__claude-flow__hooks_pre-task mcp__claude-flow__hooks_post-task
+category: general
+---
+Validate domain boundary integrity across all bounded contexts.
+
+## Steps
+
+1. **Discover contexts**: Scan `src/*/domain/` to find all bounded contexts.
+
+2. **Check cross-boundary violations**:
+   - For each context, scan all `.ts` files for import statements
+   - Flag any import that reaches into another context's `domain/` directory directly
+   - Allowed: importing from another context's public `index.ts` (application layer)
+   - Violation: importing from `src/<other-context>/domain/entities/...` directly
+
+   ```bash
+   # Find cross-boundary imports
+   for ctx in $(find src -maxdepth 2 -name "domain" -type d | sed 's|src/||;s|/domain||'); do
+     grep -rn "from ['\"].*src/" "src/$ctx/" --include="*.ts" | grep -v "src/$ctx/" || true
+   done
+   ```
+
+3. **Check aggregate invariant enforcement**:
+   - Scan aggregate root entities for public setters that bypass validation
+   - Flag mutable public properties without invariant checks
+   - Verify that child entities are not directly accessible (must go through aggregate root)
+
+4. **Check event naming conventions**:
+   - Domain events should be past-tense named (e.g., `OrderCreated`, not `CreateOrder`)
+   - Events should be immutable (no public setters)
+   - Events should carry the aggregate ID
+
+5. **Check repository patterns**:
+   - Repository interfaces should exist in `domain/repositories/`, not `infrastructure/`
+   - Repository implementations should exist in `infrastructure/`, not `domain/`
+   - Each aggregate root should have exactly one repository
+
+6. **Report findings**:
+   - Output a table of violations with file path, line number, violation type, and suggestion
+   - Categorize as: `BOUNDARY`, `INVARIANT`, `EVENT`, `REPOSITORY`
+   - Exit with summary: total violations, by category, severity
+
+7. **Store results**:
+   ```bash
+   npx @claude-flow/cli@latest memory store --key "ddd-validation-TIMESTAMP" --value "RESULTS_SUMMARY" --namespace tasks
+   npx @claude-flow/cli@latest hooks post-task --task-id "ddd-validate" --success true --store-results true
+   ```

package/skills/general-dependency-check.md

@@ -0,0 +1,26 @@
+---
+name: dependency-check
+description: Scan project dependencies for known vulnerabilities and CVEs
+argument-hint: "[--path PATH]"
+allowed-tools: Bash(npx * npm *) mcp__claude-flow__memory_store Read
+category: general
+---
+Check dependencies for CVEs and outdated packages:
+
+```bash
+npx @claude-flow/cli@latest security cve --check
+npx @claude-flow/cli@latest security audit --include-dev
+npm audit --json
+```
+
+| Severity | Action |
+|----------|--------|
+| critical | Block deployment, fix immediately |
+| high | Fix before next release |
+| moderate | Schedule fix within sprint |
+| low | Track in backlog |
+
+Auto-fix: `npx @claude-flow/cli@latest security cve --fix`
+
+For continuous monitoring, dispatch via MCP:
+`mcp__claude-flow__hooks_worker-dispatch({ trigger: "audit" })`

package/skills/general-email-marketing.md

@@ -0,0 +1,86 @@
+---
+name: email-marketing
+description: |
+  A brand product-launch email — masthead with wordmark, hero image block,
+  headline lockup with skewed-italic accent, body copy, primary CTA, and a
+  specifications grid. Pure HTML email layout (centered single column, table
+  fallback). Use when the brief asks for an "email", "newsletter blast",
+  "MJML", "product launch email", or "email template".
+triggers:
+  - "email"
+  - "email template"
+  - "newsletter"
+  - "email blast"
+  - "product launch email"
+  - "mjml"
+  - "邮件营销"
+  - "邮件模板"
+od:
+  mode: prototype
+  platform: desktop
+  scenario: marketing
+  featured: 7
+  preview:
+    type: html
+    entry: index.html
+  design_system:
+    requires: true
+    sections: [color, typography, layout, components]
+  example_prompt: "Design a launch email for a sporty running shoe brand — masthead, hero, big headline lockup, specs grid, CTA."
+category: general
+---
+
+# Email Marketing Skill
+
+Produce a single HTML email — centered, single column, no chrome around the
+email body. Treat it like a marketing artifact: one big idea, one CTA.
+
+## Workflow
+
+1. **Read the active DESIGN.md** (injected above). Email leans on the display
+   font more than any other surface — pick the loudest type token in the DS
+   for the headline lockup.
+2. **Pick the brand + product** from the brief. Generate a real wordmark, a
+   real product name, and one real benefit sentence — no placeholders.
+3. **Layout**, in order, all centered inside a 600–680px column on a tinted
+   page background (so the email body looks like an email, not the page):
+   - **Masthead** — wordmark on the left + 3 short nav links (SHOP, JOURNAL,
+     MEMBERS) on the right. Thin underline.
+   - **Hero block** — a 16:9 product image placeholder. Use a DS-tinted
+     gradient or a stylized SVG silhouette of the product (shoe, bottle,
+     headphones, whatever the brief implies). Add a tiny brand stamp on the
+     top-left and a colorway tag on the bottom-left.
+   - **Eyebrow** — small caps, accent color, separated by `·` characters
+     (e.g. "NEW · MAX-CUSHION TRAINER · EMBER FLARE").
+   - **Headline lockup** — 2–3 line headline using the display font, all caps,
+     extra-tight tracking. Apply a slight skew (`transform: skew(-6deg)`) on
+     one accent word to give it a sporty parallelogram feel.
+   - **Body** — 2–3 sentence paragraph, left-aligned, body font.
+   - **Primary CTA** — solid pill or block button. One only.
+   - **Specs grid** — 2×2 grid of (big number + unit + label) callouts using
+     the display font for the numbers.
+   - **Footer** — wordmark, address line, unsubscribe + view-in-browser links.
+4. **Write** a single HTML document:
+   - `<!doctype html>` through `</html>`, CSS inline.
+   - Center the column with `margin: 0 auto`. Set `body { background: <tint> }`
+     so the email-on-page metaphor reads.
+   - No external images — use inline SVG or DS-tinted gradient blocks for the
+     product photo.
+   - `data-od-id` on the masthead, hero, headline, CTA, specs.
+5. **Self-check**:
+   - Email reads top to bottom in 8–10 seconds.
+   - One CTA. Accent appears at most twice (eyebrow + CTA, or headline word).
+   - Looks legible on a 480px window (column reflows, type drops one step).
+
+## Output contract
+
+Emit between `<artifact>` tags:
+
+```
+<artifact identifier="email-slug" type="text/html" title="Email — Subject Line">
+<!doctype html>
+<html>...</html>
+</artifact>
+```
+
+One sentence before the artifact, nothing after.

package/skills/general-healthcheck.md

@@ -0,0 +1,246 @@
+---
+name: healthcheck
+description: Host security hardening and risk-tolerance configuration for OpenClaw deployments. Use when a user asks for security audits, firewall/SSH/update hardening, risk posture, exposure review, OpenClaw cron scheduling for periodic checks, or version status checks on a machine running OpenClaw (laptop, workstation, Pi, VPS).
+category: general
+---
+
+# OpenClaw Host Hardening
+
+## Overview
+
+Assess and harden the host running OpenClaw, then align it to a user-defined risk tolerance without breaking access. Use OpenClaw security tooling as a first-class signal, but treat OS hardening as a separate, explicit set of steps.
+
+## Core rules
+
+- Recommend running this skill with a state-of-the-art model (e.g., Opus 4.5, GPT 5.2+). The agent should self-check the current model and suggest switching if below that level; do not block execution.
+- Require explicit approval before any state-changing action.
+- Do not modify remote access settings without confirming how the user connects.
+- Prefer reversible, staged changes with a rollback plan.
+- Never claim OpenClaw changes the host firewall, SSH, or OS updates; it does not.
+- If role/identity is unknown, provide recommendations only.
+- Formatting: every set of user choices must be numbered so the user can reply with a single digit.
+- System-level backups are recommended; try to verify status.
+
+## Workflow (follow in order)
+
+### 0) Model self-check (non-blocking)
+
+Before starting, check the current model. If it is below state-of-the-art (e.g., Opus 4.5, GPT 5.2+), recommend switching. Do not block execution.
+
+### 1) Establish context (read-only)
+
+Try to infer 1–5 from the environment before asking. Prefer simple, non-technical questions if you need confirmation.
+
+Determine (in order):
+
+1. OS and version (Linux/macOS/Windows), container vs host.
+2. Privilege level (root/admin vs user).
+3. Access path (local console, SSH, RDP, tailnet).
+4. Network exposure (public IP, reverse proxy, tunnel).
+5. OpenClaw gateway status and bind address.
+6. Backup system and status (e.g., Time Machine, system images, snapshots).
+7. Deployment context (local mac app, headless gateway host, remote gateway, container/CI).
+8. Disk encryption status (FileVault/LUKS/BitLocker).
+9. OS automatic security updates status.
+   Note: these are not blocking items, but are highly recommended, especially if OpenClaw can access sensitive data.
+10. Usage mode for a personal assistant with full access (local workstation vs headless/remote vs other).
+
+First ask once for permission to run read-only checks. If granted, run them by default and only ask questions for items you cannot infer or verify. Do not ask for information already visible in runtime or command output. Keep the permission ask as a single sentence, and list follow-up info needed as an unordered list (not numbered) unless you are presenting selectable choices.
+
+If you must ask, use non-technical prompts:
+
+- “Are you using a Mac, Windows PC, or Linux?”
+- “Are you logged in directly on the machine, or connecting from another computer?”
+- “Is this machine reachable from the public internet, or only on your home/network?”
+- “Do you have backups enabled (e.g., Time Machine), and are they current?”
+- “Is disk encryption turned on (FileVault/BitLocker/LUKS)?”
+- “Are automatic security updates enabled?”
+- “How do you use this machine?”
+  Examples:
+  - Personal machine shared with the assistant
+  - Dedicated local machine for the assistant
+  - Dedicated remote machine/server accessed remotely (always on)
+  - Something else?
+
+Only ask for the risk profile after system context is known.
+
+If the user grants read-only permission, run the OS-appropriate checks by default. If not, offer them (numbered). Examples:
+
+1. OS: `uname -a`, `sw_vers`, `cat /etc/os-release`.
+2. Listening ports:
+   - Linux: `ss -ltnup` (or `ss -ltnp` if `-u` unsupported).
+   - macOS: `lsof -nP -iTCP -sTCP:LISTEN`.
+3. Firewall status:
+   - Linux: `ufw status`, `firewall-cmd --state`, `nft list ruleset` (pick what is installed).
+   - macOS: `/usr/libexec/ApplicationFirewall/socketfilterfw --getglobalstate` and `pfctl -s info`.
+4. Backups (macOS): `tmutil status` (if Time Machine is used).
+
+### 2) Run OpenClaw security audits (read-only)
+
+As part of the default read-only checks, run `openclaw security audit --deep`. Only offer alternatives if the user requests them:
+
+1. `openclaw security audit` (faster, non-probing)
+2. `openclaw security audit --json` (structured output)
+
+Offer to apply OpenClaw safe defaults (numbered):
+
+1. `openclaw security audit --fix`
+
+Be explicit that `--fix` only tightens OpenClaw defaults and file permissions. It does not change host firewall, SSH, or OS update policies.
+
+If browser control is enabled, recommend that 2FA be enabled on all important accounts, with hardware keys preferred and SMS not sufficient.
+
+### 3) Check OpenClaw version/update status (read-only)
+
+As part of the default read-only checks, run `openclaw update status`.
+
+Report the current channel and whether an update is available.
+
+### 4) Determine risk tolerance (after system context)
+
+Ask the user to pick or confirm a risk posture and any required open services/ports (numbered choices below).
+Do not pigeonhole into fixed profiles; if the user prefers, capture requirements instead of choosing a profile.
+Offer suggested profiles as optional defaults (numbered). Note that most users pick Home/Workstation Balanced:
+
+1. Home/Workstation Balanced (most common): firewall on with reasonable defaults, remote access restricted to LAN or tailnet.
+2. VPS Hardened: deny-by-default inbound firewall, minimal open ports, key-only SSH, no root login, automatic security updates.
+3. Developer Convenience: more local services allowed, explicit exposure warnings, still audited.
+4. Custom: user-defined constraints (services, exposure, update cadence, access methods).
+
+### 5) Produce a remediation plan
+
+Provide a plan that includes:
+
+- Target profile
+- Current posture summary
+- Gaps vs target
+- Step-by-step remediation with exact commands
+- Access-preservation strategy and rollback
+- Risks and potential lockout scenarios
+- Least-privilege notes (e.g., avoid admin usage, tighten ownership/permissions where safe)
+- Credential hygiene notes (location of OpenClaw creds, prefer disk encryption)
+
+Always show the plan before any changes.
+
+### 6) Offer execution options
+
+Offer one of these choices (numbered so users can reply with a single digit):
+
+1. Do it for me (guided, step-by-step approvals)
+2. Show plan only
+3. Fix only critical issues
+4. Export commands for later
+
+### 7) Execute with confirmations
+
+For each step:
+
+- Show the exact command
+- Explain impact and rollback
+- Confirm access will remain available
+- Stop on unexpected output and ask for guidance
+
+### 8) Verify and report
+
+Re-check:
+
+- Firewall status
+- Listening ports
+- Remote access still works
+- OpenClaw security audit (re-run)
+
+Deliver a final posture report and note any deferred items.
+
+## Required confirmations (always)
+
+Require explicit approval for:
+
+- Firewall rule changes
+- Opening/closing ports
+- SSH/RDP configuration changes
+- Installing/removing packages
+- Enabling/disabling services
+- User/group modifications
+- Scheduling tasks or startup persistence
+- Update policy changes
+- Access to sensitive files or credentials
+
+If unsure, ask.
+
+## Periodic checks
+
+After OpenClaw install or first hardening pass, run at least one baseline audit and version check:
+
+- `openclaw security audit`
+- `openclaw security audit --deep`
+- `openclaw update status`
+
+Ongoing monitoring is recommended. Use the OpenClaw cron tool/CLI to schedule periodic audits (Gateway scheduler). Do not create scheduled tasks without explicit approval. Store outputs in a user-approved location and avoid secrets in logs.
+When scheduling headless cron runs, include a note in the output that instructs the user to call `healthcheck` so issues can be fixed.
+
+### Required prompt to schedule (always)
+
+After any audit or hardening pass, explicitly offer scheduling and require a direct response. Use a short prompt like (numbered):
+
+1. “Do you want me to schedule periodic audits (e.g., daily/weekly) via `openclaw cron add`?”
+
+If the user says yes, ask for:
+
+- cadence (daily/weekly), preferred time window, and output location
+- whether to also schedule `openclaw update status`
+
+Use a stable cron job name so updates are deterministic. Prefer exact names:
+
+- `healthcheck:security-audit`
+- `healthcheck:update-status`
+
+Before creating, `openclaw cron list` and match on exact `name`. If found, `openclaw cron edit <id> ...`.
+If not found, `openclaw cron add --name <name> ...`.
+
+Also offer a periodic version check so the user can decide when to update (numbered):
+
+1. `openclaw update status` (preferred for source checkouts and channels)
+2. `npm view openclaw version` (published npm version)
+
+## OpenClaw command accuracy
+
+Use only supported commands and flags:
+
+- `openclaw security audit [--deep] [--fix] [--json]`
+- `openclaw status` / `openclaw status --deep`
+- `openclaw health --json`
+- `openclaw update status`
+- `openclaw cron add|list|runs|run`
+
+Do not invent CLI flags or imply OpenClaw enforces host firewall/SSH policies.
+
+## Logging and audit trail
+
+Record:
+
+- Gateway identity and role
+- Plan ID and timestamp
+- Approved steps and exact commands
+- Exit codes and files modified (best effort)
+
+Redact secrets. Never log tokens or full credential contents.
+
+## Memory writes (conditional)
+
+Only write to memory files when the user explicitly opts in and the session is a private/local workspace
+(per `docs/reference/templates/AGENTS.md`). Otherwise provide a redacted, paste-ready summary the user can
+decide to save elsewhere.
+
+Follow the durable-memory prompt format used by OpenClaw compaction:
+
+- Write lasting notes to `memory/YYYY-MM-DD.md`.
+
+After each audit/hardening run, if opted-in, append a short, dated summary to `memory/YYYY-MM-DD.md`
+(what was checked, key findings, actions taken, any scheduled cron jobs, key decisions,
+and all commands executed). Append-only: never overwrite existing entries.
+Redact sensitive host details (usernames, hostnames, IPs, serials, service names, tokens).
+If there are durable preferences or decisions (risk posture, allowed ports, update policy),
+also update `MEMORY.md` (long-term memory is optional and only used in private sessions).
+
+If the session cannot write to the workspace, ask for permission or provide exact entries
+the user can paste into the memory files.