shmakk 1.1.0 → 1.2.0

package/skills/database-sql-optimization.md

@@ -0,0 +1,297 @@
+---
+name: sql-optimization
+description: 'Universal SQL performance optimization assistant for comprehensive query tuning, indexing strategies, and database performance analysis across all SQL databases (MySQL, PostgreSQL, SQL Server, Oracle). Provides execution plan analysis, pagination optimization, batch operations, and performance monitoring guidance.'
+category: database
+---
+
+# SQL Performance Optimization Assistant
+
+Expert SQL performance optimization for ${selection} (or entire project if no selection). Focus on universal SQL optimization techniques that work across MySQL, PostgreSQL, SQL Server, Oracle, and other SQL databases.
+
+## 🎯 Core Optimization Areas
+
+### Query Performance Analysis
+```sql
+-- ❌ BAD: Inefficient query patterns
+SELECT * FROM orders o
+WHERE YEAR(o.created_at) = 2024
+  AND o.customer_id IN (
+      SELECT c.id FROM customers c WHERE c.status = 'active'
+  );
+
+-- ✅ GOOD: Optimized query with proper indexing hints
+SELECT o.id, o.customer_id, o.total_amount, o.created_at
+FROM orders o
+INNER JOIN customers c ON o.customer_id = c.id
+WHERE o.created_at >= '2024-01-01' 
+  AND o.created_at < '2025-01-01'
+  AND c.status = 'active';
+
+-- Required indexes:
+-- CREATE INDEX idx_orders_created_at ON orders(created_at);
+-- CREATE INDEX idx_customers_status ON customers(status);
+-- CREATE INDEX idx_orders_customer_id ON orders(customer_id);
+```
+
+### Index Strategy Optimization
+```sql
+-- ❌ BAD: Poor indexing strategy
+CREATE INDEX idx_user_data ON users(email, first_name, last_name, created_at);
+
+-- ✅ GOOD: Optimized composite indexing
+-- For queries filtering by email first, then sorting by created_at
+CREATE INDEX idx_users_email_created ON users(email, created_at);
+
+-- For full-text name searches
+CREATE INDEX idx_users_name ON users(last_name, first_name);
+
+-- For user status queries
+CREATE INDEX idx_users_status_created ON users(status, created_at)
+WHERE status IS NOT NULL;
+```
+
+### Subquery Optimization
+```sql
+-- ❌ BAD: Correlated subquery
+SELECT p.product_name, p.price
+FROM products p
+WHERE p.price > (
+    SELECT AVG(price) 
+    FROM products p2 
+    WHERE p2.category_id = p.category_id
+);
+
+-- ✅ GOOD: Window function approach
+SELECT product_name, price
+FROM (
+    SELECT product_name, price,
+           AVG(price) OVER (PARTITION BY category_id) as avg_category_price
+    FROM products
+) ranked
+WHERE price > avg_category_price;
+```
+
+## 📊 Performance Tuning Techniques
+
+### JOIN Optimization
+```sql
+-- ❌ BAD: Inefficient JOIN order and conditions
+SELECT o.*, c.name, p.product_name
+FROM orders o
+LEFT JOIN customers c ON o.customer_id = c.id
+LEFT JOIN order_items oi ON o.id = oi.order_id
+LEFT JOIN products p ON oi.product_id = p.id
+WHERE o.created_at > '2024-01-01'
+  AND c.status = 'active';
+
+-- ✅ GOOD: Optimized JOIN with filtering
+SELECT o.id, o.total_amount, c.name, p.product_name
+FROM orders o
+INNER JOIN customers c ON o.customer_id = c.id AND c.status = 'active'
+INNER JOIN order_items oi ON o.id = oi.order_id
+INNER JOIN products p ON oi.product_id = p.id
+WHERE o.created_at > '2024-01-01';
+```
+
+### Pagination Optimization
+```sql
+-- ❌ BAD: OFFSET-based pagination (slow for large offsets)
+SELECT * FROM products 
+ORDER BY created_at DESC 
+LIMIT 20 OFFSET 10000;
+
+-- ✅ GOOD: Cursor-based pagination
+SELECT * FROM products 
+WHERE created_at < '2024-06-15 10:30:00'
+ORDER BY created_at DESC 
+LIMIT 20;
+
+-- Or using ID-based cursor
+SELECT * FROM products 
+WHERE id > 1000
+ORDER BY id 
+LIMIT 20;
+```
+
+### Aggregation Optimization
+```sql
+-- ❌ BAD: Multiple separate aggregation queries
+SELECT COUNT(*) FROM orders WHERE status = 'pending';
+SELECT COUNT(*) FROM orders WHERE status = 'shipped';
+SELECT COUNT(*) FROM orders WHERE status = 'delivered';
+
+-- ✅ GOOD: Single query with conditional aggregation
+SELECT 
+    COUNT(CASE WHEN status = 'pending' THEN 1 END) as pending_count,
+    COUNT(CASE WHEN status = 'shipped' THEN 1 END) as shipped_count,
+    COUNT(CASE WHEN status = 'delivered' THEN 1 END) as delivered_count
+FROM orders;
+```
+
+## 🔍 Query Anti-Patterns
+
+### SELECT Performance Issues
+```sql
+-- ❌ BAD: SELECT * anti-pattern
+SELECT * FROM large_table lt
+JOIN another_table at ON lt.id = at.ref_id;
+
+-- ✅ GOOD: Explicit column selection
+SELECT lt.id, lt.name, at.value
+FROM large_table lt
+JOIN another_table at ON lt.id = at.ref_id;
+```
+
+### WHERE Clause Optimization
+```sql
+-- ❌ BAD: Function calls in WHERE clause
+SELECT * FROM orders 
+WHERE UPPER(customer_email) = 'JOHN@EXAMPLE.COM';
+
+-- ✅ GOOD: Index-friendly WHERE clause
+SELECT * FROM orders 
+WHERE customer_email = 'john@example.com';
+-- Consider: CREATE INDEX idx_orders_email ON orders(LOWER(customer_email));
+```
+
+### OR vs UNION Optimization
+```sql
+-- ❌ BAD: Complex OR conditions
+SELECT * FROM products 
+WHERE (category = 'electronics' AND price < 1000)
+   OR (category = 'books' AND price < 50);
+
+-- ✅ GOOD: UNION approach for better optimization
+SELECT * FROM products WHERE category = 'electronics' AND price < 1000
+UNION ALL
+SELECT * FROM products WHERE category = 'books' AND price < 50;
+```
+
+## 📈 Database-Agnostic Optimization
+
+### Batch Operations
+```sql
+-- ❌ BAD: Row-by-row operations
+INSERT INTO products (name, price) VALUES ('Product 1', 10.00);
+INSERT INTO products (name, price) VALUES ('Product 2', 15.00);
+INSERT INTO products (name, price) VALUES ('Product 3', 20.00);
+
+-- ✅ GOOD: Batch insert
+INSERT INTO products (name, price) VALUES 
+('Product 1', 10.00),
+('Product 2', 15.00),
+('Product 3', 20.00);
+```
+
+### Temporary Table Usage
+```sql
+-- ✅ GOOD: Using temporary tables for complex operations
+CREATE TEMPORARY TABLE temp_calculations AS
+SELECT customer_id, 
+       SUM(total_amount) as total_spent,
+       COUNT(*) as order_count
+FROM orders 
+WHERE created_at >= '2024-01-01'
+GROUP BY customer_id;
+
+-- Use the temp table for further calculations
+SELECT c.name, tc.total_spent, tc.order_count
+FROM temp_calculations tc
+JOIN customers c ON tc.customer_id = c.id
+WHERE tc.total_spent > 1000;
+```
+
+## 🛠️ Index Management
+
+### Index Design Principles
+```sql
+-- ✅ GOOD: Covering index design
+CREATE INDEX idx_orders_covering 
+ON orders(customer_id, created_at) 
+INCLUDE (total_amount, status);  -- SQL Server syntax
+-- Or: CREATE INDEX idx_orders_covering ON orders(customer_id, created_at, total_amount, status); -- Other databases
+```
+
+### Partial Index Strategy
+```sql
+-- ✅ GOOD: Partial indexes for specific conditions
+CREATE INDEX idx_orders_active 
+ON orders(created_at) 
+WHERE status IN ('pending', 'processing');
+```
+
+## 📊 Performance Monitoring Queries
+
+### Query Performance Analysis
+```sql
+-- Generic approach to identify slow queries
+-- (Specific syntax varies by database)
+
+-- For MySQL:
+SELECT query_time, lock_time, rows_sent, rows_examined, sql_text
+FROM mysql.slow_log
+ORDER BY query_time DESC;
+
+-- For PostgreSQL:
+SELECT query, calls, total_time, mean_time
+FROM pg_stat_statements
+ORDER BY total_time DESC;
+
+-- For SQL Server:
+SELECT 
+    qs.total_elapsed_time/qs.execution_count as avg_elapsed_time,
+    qs.execution_count,
+    SUBSTRING(qt.text, (qs.statement_start_offset/2)+1,
+        ((CASE qs.statement_end_offset WHEN -1 THEN DATALENGTH(qt.text)
+        ELSE qs.statement_end_offset END - qs.statement_start_offset)/2)+1) as query_text
+FROM sys.dm_exec_query_stats qs
+CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) qt
+ORDER BY avg_elapsed_time DESC;
+```
+
+## 🎯 Universal Optimization Checklist
+
+### Query Structure
+- [ ] Avoiding SELECT * in production queries
+- [ ] Using appropriate JOIN types (INNER vs LEFT/RIGHT)
+- [ ] Filtering early in WHERE clauses
+- [ ] Using EXISTS instead of IN for subqueries when appropriate
+- [ ] Avoiding functions in WHERE clauses that prevent index usage
+
+### Index Strategy
+- [ ] Creating indexes on frequently queried columns
+- [ ] Using composite indexes in the right column order
+- [ ] Avoiding over-indexing (impacts INSERT/UPDATE performance)
+- [ ] Using covering indexes where beneficial
+- [ ] Creating partial indexes for specific query patterns
+
+### Data Types and Schema
+- [ ] Using appropriate data types for storage efficiency
+- [ ] Normalizing appropriately (3NF for OLTP, denormalized for OLAP)
+- [ ] Using constraints to help query optimizer
+- [ ] Partitioning large tables when appropriate
+
+### Query Patterns
+- [ ] Using LIMIT/TOP for result set control
+- [ ] Implementing efficient pagination strategies
+- [ ] Using batch operations for bulk data changes
+- [ ] Avoiding N+1 query problems
+- [ ] Using prepared statements for repeated queries
+
+### Performance Testing
+- [ ] Testing queries with realistic data volumes
+- [ ] Analyzing query execution plans
+- [ ] Monitoring query performance over time
+- [ ] Setting up alerts for slow queries
+- [ ] Regular index usage analysis
+
+## 📝 Optimization Methodology
+
+1. **Identify**: Use database-specific tools to find slow queries
+2. **Analyze**: Examine execution plans and identify bottlenecks
+3. **Optimize**: Apply appropriate optimization techniques
+4. **Test**: Verify performance improvements
+5. **Monitor**: Continuously track performance metrics
+6. **Iterate**: Regular performance review and optimization
+
+Focus on measurable performance improvements and always test optimizations with realistic data volumes and query patterns.

package/skills/dependency-audit.md

@@ -0,0 +1,165 @@
+---
+name: dependency-audit
+version: 1
+category: security
+---
+
+# Dependency Audit
+
+Check dependencies for security vulnerabilities, outdated packages, license issues, and bloat.
+
+## When to use this skill
+
+- User wants to audit, update, or clean up dependencies
+- User asks "are my dependencies secure", "what needs updating", "what licenses do I have"
+- User is preparing for a release or security review
+- User mentions "dependencies", "packages", "npm", "pip", "vulnerabilities", "outdated"
+
+## Procedure
+
+### Step 1: Identify the package manager
+
+```
+ls package.json package-lock.json yarn.lock pnpm-lock.yaml 2>/dev/null  # Node
+ls requirements.txt pyproject.toml Pipfile setup.py 2>/dev/null           # Python
+ls Cargo.toml 2>/dev/null                                                  # Rust
+ls go.mod 2>/dev/null                                                      # Go
+ls Gemfile 2>/dev/null                                                     # Ruby
+```
+
+### Step 2: Security audit
+
+**npm / Node.js:**
+```
+npm audit
+npm audit --json | python3 -c "
+import json,sys
+data = json.load(sys.stdin)
+vulns = data.get('vulnerabilities', {})
+for name, v in vulns.items():
+    print(f\"{v['severity'].upper()}: {name} — {v.get('title', '')}\")
+"
+```
+
+**Python (pip):**
+```
+pip install pip-audit 2>/dev/null
+pip-audit
+```
+
+Or check with safety:
+```
+pip install safety 2>/dev/null
+safety check
+```
+
+**Go:**
+```
+govulncheck ./...
+```
+
+**Rust:**
+```
+cargo audit
+```
+
+### Step 3: Check for outdated packages
+
+**npm:**
+```
+npm outdated
+```
+
+**Python:**
+```
+pip list --outdated
+```
+
+**Go:**
+```
+go list -m -u all 2>/dev/null | grep '\['
+```
+
+### Step 4: License analysis
+
+**npm:**
+```
+npx license-checker --summary
+npx license-checker --failOn "GPL-2.0;GPL-3.0;AGPL-3.0" 2>/dev/null
+```
+
+**Python:**
+```
+pip install pip-licenses 2>/dev/null
+pip-licenses --format=table
+```
+
+Flag licenses that may conflict with your project's license:
+- GPL/AGPL: "copyleft" — may require open-sourcing your code
+- LGPL: generally OK for linking, but check specifics
+- MIT, Apache-2.0, BSD: permissive, generally safe for commercial use
+- Unknown/proprietary: investigate before shipping
+
+### Step 5: Identify unused dependencies (Node.js)
+
+```
+npx depcheck
+```
+
+This identifies packages in `package.json` not actually imported in code.
+
+### Step 6: Check for notably large packages
+
+```
+du -sh node_modules/* 2>/dev/null | sort -rh | head -20
+```
+
+Or for detailed bundle impact: `npx bundlephobia <package-name>` (check web)
+
+## Output format
+
+```
+DEPENDENCY AUDIT: my-project (npm)
+
+SECURITY — 3 vulnerabilities
+  CRITICAL  lodash@4.17.11 — Prototype Pollution (CVE-2021-23337)
+            Fix: npm update lodash → 4.17.21
+  HIGH      axios@0.21.0  — SSRF vulnerability (CVE-2020-28168)
+            Fix: npm install axios@1.6.0
+
+OUTDATED — 12 packages behind
+  Major updates (breaking changes possible):
+    react       17.0.2  →  18.2.0
+    webpack     4.46.0  →  5.88.0
+
+  Minor/patch (generally safe):
+    eslint      8.0.0   →  8.53.0
+    typescript  4.9.5   →  5.3.2
+    [+ 8 more]
+
+LICENSES
+  MIT: 45 packages ✓
+  Apache-2.0: 12 packages ✓
+  ISC: 8 packages ✓
+  ⚠️  GPL-3.0: 1 package (some-lib) — verify this is acceptable for your use case
+
+UNUSED (via depcheck)
+  colors, moment — appear unused. Review before removing.
+
+RECOMMENDED ACTIONS
+1. Fix CRITICAL and HIGH vulnerabilities immediately (run: npm update lodash axios)
+2. Evaluate React 18 upgrade — significant but well-documented migration path
+3. Investigate GPL-3.0 dependency before commercial distribution
+```
+
+## Pitfalls
+
+- Major version updates can be breaking — don't blindly `npm update` everything; review changelogs
+- `npm audit` sometimes flags vulnerabilities in dev-only packages that don't affect production
+- Some "unused" dependencies flagged by depcheck are loaded dynamically or via config — verify before removing
+- License analysis may miss packages with non-standard license declarations — review any `Unknown` entries manually
+
+## Verification
+
+After fixing vulnerabilities: re-run `npm audit` and confirm the specific CVEs no longer appear.
+After updating packages: run your test suite to catch any regressions from version bumps.

package/skills/design-kami-landing.md

@@ -0,0 +1,234 @@
+---
+name: kami-landing
+description: >
+  Produce a print-grade single-page kami (紙 / 纸) document — warm
+  parchment canvas, ink-blue accent, serif at one weight, no italic,
+  no cool grays. The output reads like a professional white paper or
+  studio one-pager, not an app UI. Multilingual by design (EN ·
+  zh-CN · ja). One self-contained HTML file, zero dependencies.
+triggers:
+  - kami
+  - 紙
+  - 纸
+  - paper one-pager
+  - 白皮书
+  - white paper
+  - parchment landing
+  - editorial document
+  - print-grade page
+  - kami landing
+od:
+  category: brand-page
+  surface: web
+  mode: prototype
+  platform: desktop
+  scenario: marketing
+  featured: 3
+  audience: founders, design studios, OSS maintainers, researchers
+  tone: editorial, restrained, print-first
+  scale: viewport-anchored long-form single page
+  preview:
+    type: html
+    entry: index.html
+    reload: debounce-100
+  design_system:
+    requires: false
+  craft:
+    requires:
+      - typographic-rhythm
+      - pixel-discipline
+inputs:
+  - id: brand
+    label: Brand identity
+    description: Name, tagline, location, edition / version, primary URL.
+  - id: hero
+    label: Hero / cover block
+    description: Eyebrow + headline (one line, ≤ 6 words at display size) + tagline + 3 hero meta tokens.
+  - id: manifesto
+    label: Manifesto paragraph + signature
+  - id: metrics
+    label: 3-6 metric tiles (value · label · sub)
+  - id: chapters
+    label: 3-5 numbered chapters (title + lede + body)
+  - id: footer
+    label: License · year · contact + 3-column site index
+parameters:
+  output_format:
+    type: enum
+    values: [standalone-html]
+    default: standalone-html
+  language:
+    type: enum
+    values: [en, zh-CN, ja]
+    default: en
+    description: >
+      Sets the primary serif stack on `:root`. EN uses Charter,
+      zh-CN uses TsangerJinKai02 / Source Han Serif, ja uses
+      YuMincho. Mixed-script content is allowed inline; the browser
+      resolves per-glyph fallback automatically.
+outputs:
+  - path: <out>/index.html
+    description: Self-contained HTML, kami CSS inlined, zero JS, zero external dependencies beyond Google Fonts.
+capabilities_required:
+  - file-write
+example_prompt: |
+  Build me a kami-style one-pager for "Lumen Field", an indie studio
+  shipping a soundscape app for focus. Hero headline "Soundscapes for
+  focused work.", manifesto paragraph + signature "by Lumen Field,
+  Berlin", 3 metric tiles (12 soundscapes / 4 presets / 1 daily ritual),
+  three numbered chapters covering the studio, the app, and the roadmap.
+  English-language stack.
+---
+
+# kami-landing
+
+Produce a single-page document in the **kami (紙 / 纸)** design system.
+The aesthetic borrows from editorial print, technical white papers,
+and old typewritten correspondence — the goal is *good content on
+good paper*, not *modern app UI*.
+
+> **Design system source of truth:** [`design-systems/kami/DESIGN.md`](../../design-systems/kami/DESIGN.md).
+> Read it before shipping. Tokens, type rules, the "ten invariants",
+> and forbidden colors all live there.
+
+## What you get
+
+A single self-contained HTML file with:
+
+- **Warm parchment canvas** (`#f5f4ed`) — never `#ffffff`.
+- **Single chromatic accent** — ink-blue (`#1B365D`), used on the
+  section number, the headline accent word, the left rule of the
+  manifesto, and the metric values. Anywhere else, ink-blue must
+  cover ≤ 5% of the document surface area.
+- **Serif at one weight (500) for hierarchy** — Charter (EN),
+  TsangerJinKai02 / Source Han Serif (CN), or YuMincho (JA),
+  selected by the `language` parameter. **No italic anywhere.**
+- **Tight print rhythm** — line-heights 1.10–1.55, letter-spacing
+  per language (0 for EN, 0.35px for CN, 0.02em for JA).
+- **Numeric stacks set in `font-variant-numeric: tabular-nums`** so
+  metric columns and pagination digits sit cleanly aligned.
+- **Depth via 1px rings + whisper shadows** (`0 4px 24px rgba(0,0,0,0.05)`).
+  No hard drop shadows, no neumorphism, no backdrop-filter blurs.
+- **Tag fills as solid hex** (e.g. `#E4ECF5`), never `rgba()` —
+  print renderers double-paint alpha tags.
+- **Responsive** at 1280 / 980 / 768 / 560.
+
+## Page structure
+
+```text
+1. Eyebrow row     — locale switcher · edition · version (12px sans uppercase)
+2. Hero            — display headline (96–106px serif 500), tagline (21px),
+                     three hero-token chips (paper-tinted)
+3. Manifesto       — pull paragraph in serif 400, 20px, 1.65 LH, with
+                     ink-blue left-rule and signature footer
+4. Metrics row     — 3-6 cells: value (24px serif 500 ink-blue, tabular-nums),
+                     label (12px serif 500 olive)
+5. Chapters        — numbered (`01`, `02`, …) ink-blue serif 500 14px,
+                     section title 28-32px, body 14-15px
+6. Footer          — kicker word (mega serif 500), license · year · contact,
+                     three-column site index in 12px serif 500
+```
+
+## Workflow contract
+
+### 1. Gather brand brief
+
+Use `AskQuestion` (or equivalent) to collect the brand brief in
+chunks. Don't dump the whole input list on the user; ask in two
+rounds:
+
+1. Identity round — name, tagline, location, edition / version,
+   primary URL, dominant language.
+2. Content round — manifesto paragraph + signature, 3-6 metric
+   tiles, 3-5 chapter (title + lede + body) entries.
+
+### 2. Pick the language stack
+
+The `language` parameter controls which `--serif` stack is set on
+`:root`. Pick based on the dominant language of the manifesto and
+chapter body copy:
+
+| `language` | `--serif`                                                 | Notes                                  |
+| :--------- | :-------------------------------------------------------- | :------------------------------------- |
+| `en`       | Charter, Georgia, Palatino, Times New Roman, serif         | default                                |
+| `zh-CN`    | TsangerJinKai02, Source Han Serif SC, Songti SC, Georgia   | letter-spacing 0.35px on body          |
+| `ja`       | YuMincho, Hiragino Mincho ProN, Source Han Serif JP        | also override `--olive` to `#4d4c48` (YuMincho strokes are thinner) |
+
+Inline mixed-script content is fine — the browser per-glyph fallback
+chain handles it. Do **not** chain all three families inside one
+`font-family` declaration; that dilutes character.
+
+### 3. Write `index.html`
+
+Output a single file with all CSS inline. Mirror the structure of
+[`example.html`](./example.html) and use only the tokens from
+`design-systems/kami/DESIGN.md`. Do **not** invent new colors,
+weights, or font families.
+
+Component primitives the agent can drop in (all defined in the
+example's `<style>` block):
+
+- `.eyebrow`, `.label` — sans-serif overlines
+- `.metric` — value + label vertical pair
+- `.section-num` + `.section-title` + `.section-lede`
+- `.tag.standard`, `.tag.brush` — solid-hex tags (one brush max per page)
+- `.quote` — left-rule serif 500 quote
+- `ul.dash` — en-dash bullets in ink-blue
+- `.code` — ivory-bg, 1px-border code block
+- `.footer-kicker` — mega serif 500 word
+
+Tag every editable element with `data-od-id="<unique-slug>"` so the
+host app's comment mode can target it.
+
+### 4. Self-check before delivering
+
+- [ ] Page background is parchment (`#f5f4ed`), never `#ffffff`.
+- [ ] Ink-blue (`#1B365D`) covers ≤ 5% of visible surface — count
+      section numbers, the manifesto rule, the metric values, the
+      headline accent. Total ≤ 5%.
+- [ ] All grays are warm (R ≈ G > B). No `slate-*`, no `#f3f4f6`.
+- [ ] Serif weight stays at 500 — no `font-weight: 700` or `900`
+      anywhere on serif text.
+- [ ] No `font-style: italic` anywhere. Emphasis swaps to ink-blue
+      color or a `.tag` instead.
+- [ ] All numeric stacks (metric values, pagination, dates, financial
+      figures) carry `font-variant-numeric: tabular-nums`.
+- [ ] All tag fills are solid hex (e.g. `#E4ECF5`), never `rgba()`.
+- [ ] Shadows: at most a `1px` ring or a `0 4px 24px rgba(0,0,0,0.05)`
+      whisper. No hard drop shadows.
+- [ ] Headline ≤ 6 words at display size; CJK ≤ 8 characters.
+- [ ] At 768px and 560px the layout collapses to one column without
+      horizontal scroll.
+
+## Files in this skill
+
+```text
+skills/kami-landing/
+├── SKILL.md                 # this contract
+├── README.md                # human quick-start
+└── example.html             # canonical Open Design rendering
+```
+
+## Boundaries
+
+- **Do not** invent new colors or typefaces. The kami palette is
+  fixed; if a brief demands a brand color, push back or render the
+  brand color as a single `.tag.brush` accent.
+- **Do not** introduce a second accent color. Pick ink-blue or pick
+  nothing.
+- **Do not** mix all three font stacks in one declaration; pick the
+  dominant language, override `--serif` on `:root`, and let the
+  browser per-glyph fallback resolve mixed-script inline content.
+- **Do not** use `rgba()` for tag fills — print renderers
+  double-paint alpha tags. Use the pre-blended solid hex from the
+  table in `design-systems/kami/DESIGN.md` §2.
+- **Do not** add JavaScript for animation. The page is paper, not
+  an app — motion belongs to the reader scrolling.
+
+## See also
+
+- [`design-systems/kami/DESIGN.md`](../../design-systems/kami/DESIGN.md) — the full token spec.
+- [`skills/kami-deck/`](../kami-deck/) — sister skill that produces a
+  slide deck in the same kami language.
+- Upstream: [`tw93/kami`](https://github.com/tw93/kami) — original
+  Claude skill (MIT) that the design system adapts.