novahiz 0.1.0

package/bundled-skills/pi-history-ingest/SKILL.md

@@ -0,0 +1,312 @@
+---
+name: pi-history-ingest
+description: >
+  Ingest Pi coding agent session history into the Obsidian wiki. Use this skill when the user wants to mine
+  their past Pi sessions for knowledge, import their ~/.pi/agent/sessions folder, extract insights from
+  previous coding sessions, or says things like "process my Pi history", "add my Pi sessions to the wiki",
+  "ingest ~/.pi", or "what have I worked on in Pi". Also triggers when the user mentions Pi sessions,
+  Pi agent history, ~/.pi/agent/sessions, or Pi conversation logs.
+---
+
+# Pi History Ingest — Session Mining
+
+You are extracting knowledge from the user's Pi coding agent sessions and distilling it into the Obsidian wiki. Pi sessions are stored as structured JSONL with a tree layout — your job is to follow the active branch, extract durable knowledge, and compile it.
+
+**Session knowledge closure:** Pi session files are the only factual source for this skill. Do not add background knowledge from model training, other tools, package docs, local files, or the current conversation unless that fact appears in the selected session entries. If outside context seems useful, mark it as an open question or skip it — never present it as extracted session knowledge.
+
+This skill can be invoked directly or via the `wiki-history-ingest` router (`/wiki-history-ingest pi`).
+
+## Before You Start
+
+**Writing profile:** Before drafting or rewriting natural-language Markdown, read and apply the `Writing Profile Resolution` section in `llm-wiki/SKILL.md`. Framework schema, provenance, safety, and operation-specific requirements take precedence.
+`WRITING.md` preferences apply only to newly drafted or rewritten natural-language Markdown; preserve source content and structured records.
+
+1. **Resolve config** — follow the Config Resolution Protocol in `llm-wiki/SKILL.md` (inline `@name` override → walk up CWD for `.env` → global config → prompt setup). This gives `OBSIDIAN_VAULT_PATH` and `PI_HISTORY_PATH` (defaults to `~/.pi/agent/sessions`)
+2. Read `.manifest.json` at the vault root to check what has already been ingested
+3. Read `index.md` at the vault root to understand what the wiki already contains
+
+## Ingest Modes
+
+### Append Mode (default)
+
+Check `.manifest.json` for each source file. Only process:
+
+- Files not in the manifest (new sessions)
+- Files whose modification time is newer than `ingested_at` in the manifest
+
+Use this mode for regular syncs.
+
+### Full Mode
+
+Process everything regardless of manifest. Use after `wiki-rebuild` or if the user explicitly asks for a full re-ingest.
+
+## Pi Data Layout
+
+Pi stores sessions under `~/.pi/agent/sessions/` (or the path set by `PI_CODING_AGENT_SESSION_DIR`).
+
+```
+~/.pi/agent/sessions/
+├── --<cwd-path>--/                    # Working directory with / replaced by -
+│   └── <timestamp>_<uuid>.jsonl       # Session JSONL file
+└── ...
+```
+
+The session filename contains an ISO timestamp and UUID. The parent directory encodes the working directory where the session was created.
+
+### Session JSONL Format
+
+Each `.jsonl` file is a sequence of JSON objects. The first line is always a `session` header; subsequent lines are tree entries with `id` and `parentId`.
+
+Key entry types:
+
+| `type` | Purpose | Ingest? |
+|---|---|---|
+| `session` | Header with `cwd`, `version`, `id`, `timestamp` | Metadata only |
+| `message` | Conversation turn (`user`, `assistant`, `toolResult`, `bashExecution`, etc.) | **Primary source** |
+| `session_info` | Display name set via `/name` | For session title |
+| `compaction` | Context compaction summary | **High signal** |
+| `branch_summary` | Summary when switching branches via `/tree` | **High signal** |
+| `model_change` | Model switch event | Skip |
+| `thinking_level_change` | Thinking level change | Skip |
+| `custom` | Extension state (not in LLM context) | Skip |
+| `custom_message` | Extension-injected message | Context only |
+| `label` | User bookmark/label | Skip |
+
+### Message roles inside `message` entries
+
+- `user` — user input; `content` is string or `(TextContent \| ImageContent)[]`
+- `assistant` — assistant response; `content` is `(TextContent \| ThinkingContent \| ToolCall)[]`
+- `toolResult` — tool execution result; `content` is `(TextContent \| ImageContent)[]`
+- `bashExecution` — bash command + output; `command`, `output`, `exitCode`
+- `branchSummary` — branch switch summary; `summary` string
+- `compactionSummary` — compaction summary; `summary` string
+
+### Key data sources ranked by value
+
+1. **`message` entries (`user` + `assistant`)** — full conversation transcripts; rich but noisy
+2. **`compaction` entries** — pre-synthesized summaries of older context; gold
+3. **`branch_summary` entries** — summaries of abandoned branches; good signal
+4. **`bashExecution` entries** — concrete commands run; useful for workflow patterns
+5. **`session_info` entries** — session name for topic inference
+
+Skip `model_change`, `thinking_level_change`, `custom` (extension state), and `label` entries.
+
+## Step 1: Survey and Compute Delta
+
+Scan `PI_HISTORY_PATH` and compare against `.manifest.json`:
+
+```bash
+# List all session files
+find ~/.pi/agent/sessions -name "*.jsonl" -type f
+
+# Or with custom path
+find "$PI_HISTORY_PATH" -name "*.jsonl" -type f
+```
+
+Build an inventory. For each session file, record:
+- `path` — absolute path
+- `cwd` — decoded from parent directory name (`--<path>--` → `/path`)
+- `session_name` — from the latest `session_info` entry (if any)
+- `modified_at` — file mtime
+- `already_ingested` — presence in `.manifest.json`
+
+Classify each file:
+- **New** — not in manifest
+- **Modified** — in manifest but file is newer than `ingested_at`
+- **Unchanged** — already ingested and unchanged
+
+Report a concise delta summary before deep parsing:
+> "Found N Pi sessions across K projects. Delta: X new, Y modified."
+
+## Step 2: Parse Session JSONL
+
+For each selected session file, read it line by line. Because sessions use a tree structure, build the active branch first:
+
+1. Parse all entries into a map by `id`
+2. Find the current leaf (the entry with no children, or the last `message` entry)
+3. Walk `parentId` chain from leaf to root to get the active path
+4. Reverse the path so it's chronological
+
+### Extraction rules
+
+From the active path, extract:
+
+- **`session` header** — `cwd`, `timestamp`, `parentSession` (if forked)
+- **`session_info`** — `name` field for session title/topic inference
+- **`message` entries with `role: "user"`** — extract `content` text (skip images)
+- **`message` entries with `role: "assistant"`** — extract `text` content blocks; skip `thinking` blocks (noise); note `toolCall` blocks (they reveal what the agent actually did)
+- **`message` entries with `role: "toolResult"`** — summarize outcomes, not full output
+- **`message` entries with `role: "bashExecution"`** — extract command + exit code; recurring commands reveal build/test/deploy workflows
+- **`compaction` entries** — read `summary` verbatim; it's already distilled
+- **`branch_summary` entries** — read `summary` verbatim; captures abandoned approaches
+
+### Evidence ledger
+
+As you parse, build a private evidence ledger before writing any wiki page. Each durable fact or decision you may write must carry at least one source reference:
+
+```
+pi:<session-file-basename>#<entry-id>
+```
+
+If an entry lacks an `id`, use `pi:<session-file-basename>:line<N>` from the JSONL line number. Keep the cited text snippet or summarized observation next to the reference while drafting so you can verify claims before writing.
+
+### Skip / noise filters
+
+- `thinking` content blocks — internal reasoning, not durable knowledge
+- Image content blocks — skip unless the user explicitly asks for image transcription
+- Raw tool outputs longer than 500 chars — summarize the outcome
+- Token accounting (`usage` fields) — metadata only
+- Repeated plan echoes or status updates
+
+### Critical privacy filter
+
+Session logs can include injected instructions, tool payloads, and sensitive text. Do not ingest verbatim.
+
+- Remove API keys, tokens, passwords, credentials
+- Redact private identifiers unless relevant and user-approved
+- Summarize bash outputs that contain paths, environment variables, or secrets
+- Do not quote raw `toolCall` arguments verbatim if they contain sensitive data
+
+## Step 3: Cluster by Topic
+
+Do not create one wiki page per session.
+
+- Group knowledge by stable topic across many sessions
+- Split mixed sessions into separate themes
+- Merge recurring patterns across dates and projects **only when each pattern member has evidence ledger references**
+- Use the `cwd` from the session header to infer project scope
+- Use `session_info.name` as a topic hint when available
+- Drop any cluster whose key claims cannot be traced back to the selected session files
+
+## Step 4: Distill into Wiki Pages
+
+Route extracted knowledge using existing wiki conventions:
+
+- Project-specific architecture/process → `projects/<name>/...`
+- General concepts → `concepts/`
+- Recurring techniques/debug playbooks → `skills/`
+- Tools/services/frameworks → `entities/`
+- Cross-session patterns → `synthesis/`
+
+For each impacted project, create/update `projects/<name>/<name>.md`.
+
+### Writing rules
+
+- Distill knowledge, not chronology
+- Avoid "on date X we discussed..." unless date context is essential
+- Preserve session-specific decision context when it explains why an approach was chosen; do not flatten it into generic tool advice.
+- Add `summary:` frontmatter on each new/updated page (1–2 sentences, ≤ 200 chars)
+- Add confidence and lifecycle fields to every new page:
+  ```yaml
+  base_confidence: 0.42
+  lifecycle: draft
+  lifecycle_changed: <ISO date today>
+  ```
+  Leave `lifecycle` unchanged on update.
+- Add provenance markers using the convention in `llm-wiki`:
+  - Extracted claims use no inline marker by default, but must have a nearby source reference comment.
+  - `^[inferred]` when synthesizing patterns across multiple sessions or inferring from tool calls.
+  - `^[ambiguous]` when sessions conflict or a compaction summary contradicts later turns.
+- Add a source reference comment near every extracted paragraph or bullet:
+  ```markdown
+  - Durable fact from the session. <!-- source: pi:2026-06-01T120000_abcd.jsonl#entry-123 -->
+  ```
+  Multiple sources are comma-separated. These comments are the audit trail; do not omit them for extracted claims.
+- Add/update `provenance:` frontmatter mix for each changed page.
+
+**Mark provenance** per the convention in `llm-wiki`:
+- `compaction` and `branch_summary` entries are pre-distilled — treat as mostly extracted, with source reference comments.
+- Conversation distillation is mostly `^[inferred]` — you're synthesizing from dialogue, and it still needs source references to the turns that support the synthesis.
+- Use `^[ambiguous]` when the user changed their mind across sessions or when compaction summaries disagree with later conversation turns.
+
+### Source verification gate
+
+Before writing any page, verify the draft against the evidence ledger:
+
+1. Every claim (extracted / ^[inferred] / ^[ambiguous]) has at least one `pi:...` source reference; extracted claims must use a nearby `<!-- source: pi:... -->` comment.
+2. Every source reference points to a selected session file and an entry on the active branch (or a cited `compaction` / `branch_summary`).
+3. Proper nouns, tool names, command names, filenames, URLs, package names, and error strings in claims appear in the cited entry text or command fields. Use literal search (`grep`/`rg`) on the session file for distinctive strings when in doubt.
+4. If a claim cannot be verified, either delete it or mark it `^[inferred]` / `^[ambiguous]` with the supporting source refs; never leave unverifiable content without one of these markers (unmarked implies extracted).
+5. Do not write facts learned from the model's training data or the current agent session unless they are explicitly present in the Pi session evidence.
+
+## Step 5: Update Manifest, Log, and Index
+
+### Update `.manifest.json`
+
+For each processed source file:
+
+- `ingested_at`, `size_bytes`, `modified_at`
+- `source_type`: `pi_session`
+- `project`: inferred project name from decoded `cwd`
+- `pages_created`, `pages_updated`
+
+Add/update a top-level summary block:
+
+```json
+{
+  "pi": {
+    "source_path": "~/.pi/agent/sessions/",
+    "last_ingested": "TIMESTAMP",
+    "sessions_ingested": 12,
+    "sessions_total": 40,
+    "pages_created": 5,
+    "pages_updated": 12
+  }
+}
+```
+
+### Update special files
+
+Update `index.md` and `log.md`:
+
+```
+- [TIMESTAMP] PI_HISTORY_INGEST sessions=N pages_updated=X pages_created=Y mode=append|full
+```
+
+**`hot.md`** — Read `$OBSIDIAN_VAULT_PATH/hot.md` (create from the template in `wiki-ingest` if missing). Update **Recent Activity** with a one-line summary — e.g. "Ingested 12 Pi sessions across 3 projects; surfaced patterns in CLI tooling and API design." Keep the last 3 operations. Update `updated` timestamp.
+
+## Privacy and Compliance
+
+- Distill and synthesize; avoid raw transcript dumps
+- Default to redaction for anything that looks sensitive
+- Ask the user before storing personal or sensitive details
+- Keep references to other people minimal and purpose-bound
+
+## Reference
+
+See `references/pi-data-format.md` for field-level parsing notes and extraction guidance.
+
+## QMD Refresh After Vault Writes
+
+QMD is a search index, not the source of truth. If `$QMD_WIKI_COLLECTION` is empty or unset, skip this step. Run it only after this skill has written or rewritten vault markdown. If QMD refresh fails, do not roll back the vault changes; report the QMD status separately.
+
+Use `$QMD_CLI` if set; otherwise use `qmd`.
+
+```bash
+${QMD_CLI:-qmd} update
+```
+
+If the output says vectors are needed or embeddings may be stale, run:
+
+```bash
+${QMD_CLI:-qmd} embed
+```
+
+Verify the collection with either:
+
+```bash
+${QMD_CLI:-qmd} ls "$QMD_WIKI_COLLECTION"
+```
+
+or, when a specific page path is known:
+
+```bash
+${QMD_CLI:-qmd} get "qmd://$QMD_WIKI_COLLECTION/<page>.md" -l 5
+```
+
+Record one of:
+- `QMD refreshed: update + embed + verified`
+- `QMD refreshed: update only + verified`
+- `QMD skipped: QMD_WIKI_COLLECTION unset`
+- `QMD skipped: qmd CLI unavailable`
+- `QMD failed: <short error summary>`

package/bundled-skills/playwright-agent/SKILL.md

@@ -0,0 +1,142 @@
+---
+name: playwright-agent
+description: |
+  Skill global pour l'utilisation de Playwright dans OpenCode. Force le démarrage du serveur
+  de développement dans un terminal externe avant toute interaction navigateur. Fournit les
+  bonnes pratiques, le protocole de connexion, et les commandes courantes.
+  Use when using Playwright, navigating to localhost, taking screenshots, or interacting with a web app.
+  Triggers on: "playwright", "navigateur", "localhost", "serveur", "dev server", "screenshot", "page web".
+license: MIT
+compatibility: opencode
+---
+
+# playwright-agent : Protocole Playwright OpenCode
+
+## Règle absolue — Serveur externe obligatoire
+
+**Toute tâche Playwright nécessitant un serveur local DOIT d'abord démarrer ce serveur dans un terminal externe.**
+
+Pourquoi : le navigateur Playwright (MCP) tourne dans un contexte réseau isolé. Un serveur lancé en arrière-plan PowerShell (`Start-Job`) meurt avec la session. Seul un terminal PowerShell externe (`Start-Process`) maintient le serveur en vie.
+
+## Protocole de démarrage
+
+### Étape 1 — Détecter le type de projet
+
+```bash
+# Vérifier la présence de fichiers de config
+Test-Path package.json      # Node.js (Vite, Next.js, CRA...)
+Test-Path Cargo.toml        # Rust
+Test-Path pyproject.toml    # Python
+Test-Path go.mod            # Go
+```
+
+### Étape 2 — Lancer le serveur dans un terminal externe
+
+**Node.js / Vite / Next.js / React :**
+```powershell
+Start-Process powershell -ArgumentList "-NoExit", "-Command", "cd '<CHEMIN_PROJET>'; npm run dev"
+```
+
+**Avec port personnalisé :**
+```powershell
+Start-Process powershell -ArgumentList "-NoExit", "-Command", "cd '<CHEMIN_PROJET>'; npx vite --port 3000"
+```
+
+**Avec host explicite (si nécessaire) :**
+```powershell
+Start-Process powershell -ArgumentList "-NoExit", "-Command", "cd '<CHEMIN_PROJET>'; npx vite --host 0.0.0.0"
+```
+
+**Python (Flask, FastAPI, Django) :**
+```powershell
+Start-Process powershell -ArgumentList "-NoExit", "-Command", "cd '<CHEMIN_PROJET>'; python -m flask run"
+# ou
+Start-Process powershell -ArgumentList "-NoExit", "-Command", "cd '<CHEMIN_PROJET>'; uvicorn main:app --reload"
+```
+
+**Rust (Actix, Axum) :**
+```powershell
+Start-Process powershell -ArgumentList "-NoExit", "-Command", "cd '<CHEMIN_PROJET>'; cargo run"
+```
+
+### Étape 3 — Attendre et vérifier la disponibilité
+
+```powershell
+Start-Sleep -Seconds 5
+Test-NetConnection -ComputerName localhost -Port <PORT> -WarningAction SilentlyContinue | Select-Object TcpTestSucceeded
+```
+
+Ne passer à l'étape suivante que si `TcpTestSucceeded` est `True`.
+
+### Étape 4 — Naviguer avec Playwright
+
+```
+playwright_browser_navigate(url="http://localhost:<PORT>/")
+```
+
+## Erreurs courantes et solutions
+
+| Erreur | Cause | Solution |
+|---|---|---|
+| `ERR_CONNECTION_REFUSED` | Serveur pas lancé ou port faux | relancer le serveur, vérifier le port |
+| `ERR_CONNECTION_REFUSED` (localhost mais `Test-NetConnection` OK) | IPv6 vs IPv4 | ajouter `--host 0.0.0.0` au serveur |
+| `net::ERR_SOCKET_NOT_CONNECTED` | Serveur en cours de démarrage | attendre plus longtemps |
+| Session PowerShell fermée | Serveur arrêté | relancer le terminal externe |
+
+## Commandes Playwright utiles
+
+### Navigation
+```
+playwright_browser_navigate(url="http://localhost:5173/")
+playwright_browser_navigate_back()
+playwright_browser_tabs(action="list")
+playwright_browser_tabs(action="new", url="http://localhost:5173/page2")
+```
+
+### Interactions
+```
+playwright_browser_click(target="<ref>", element="<description>")
+playwright_browser_type(target="<ref>", text="hello")
+playwright_browser_fill_form(fields=[...])
+playwright_browser_select_option(target="<ref>", values=["option1"])
+playwright_browser_hover(target="<ref>")
+```
+
+### Capture
+```
+playwright_browser_take_screenshot(scale="css")
+playwright_browser_take_screenshot(scale="device", fullPage=true)
+playwright_browser_snapshot()
+```
+
+### Inspection
+```
+playwright_browser_find(text="bouton")
+playwright_browser_console_messages(level="error")
+playwright_browser_network_requests(static=false)
+```
+
+### Attente
+```
+playwright_browser_wait_for(text="Chargé")
+playwright_browser_wait_for(textGone="Loading")
+playwright_browser_wait_for(time=3)
+```
+
+## Bonnes pratiques
+
+1. **Toujours vérifier le port** — ne jamais supposer que le serveur tourne sur 5173. Lire `package.json` ou la sortie du serveur.
+2. **Capturer avant d'agir** — faire un screenshot ou snapshot avant une interaction pour vérifier l'état de la page.
+3. **Nommer les éléments** — toujours passer `element` (description lisible) en plus de `target` (ref technique) pour les clics.
+4. **Vérifier les erreurs console** — après navigation, vérifier `playwright_browser_console_messages(level="error")`.
+5. **Gérer les popups** — `playwright_browser_handle_dialog(accept=true)` pour les confirmations.
+6. **Screenshot = preuve** — chaque étape importante se termine par un screenshot qui sert de preuve de vérification.
+
+## Intégration Novahiz
+
+Ce skill est invoqué automatiquement quand la catégorie `browser` est détectée. Il complète :
+- `novahiz-plan` (étape 1 : cadrer l'objectif)
+- `novahiz-task` (étape 2 : découper les étapes)
+- `novahiz-converge` (vérification finale)
+
+Le serveur externe est un prérequis technique, pas une étape du pipeline. Il ne remplace pas la planification.

package/bundled-skills/postgresql-optimization/SKILL.md

@@ -0,0 +1,179 @@
+---
+name: postgresql-optimization
+description: "PostgreSQL database optimization workflow for query tuning, indexing strategies, performance analysis, and production database management."
+category: granular-workflow-bundle
+risk: safe
+source: personal
+date_added: "2026-02-27"
+---
+
+# PostgreSQL Optimization Workflow
+
+## Overview
+
+Specialized workflow for PostgreSQL database optimization including query tuning, indexing strategies, performance analysis, vacuum management, and production database administration.
+
+## When to Use This Workflow
+
+Use this workflow when:
+- Optimizing slow PostgreSQL queries
+- Designing indexing strategies
+- Analyzing database performance
+- Tuning PostgreSQL configuration
+- Managing production databases
+
+## Workflow Phases
+
+### Phase 1: Performance Assessment
+
+#### Skills to Invoke
+- `database-optimizer` - Database optimization
+- `postgres-best-practices` - PostgreSQL best practices
+
+#### Actions
+1. Check database version
+2. Review configuration
+3. Analyze slow queries
+4. Check resource usage
+5. Identify bottlenecks
+
+#### Copy-Paste Prompts
+```
+Use @database-optimizer to assess PostgreSQL performance
+```
+
+### Phase 2: Query Analysis
+
+#### Skills to Invoke
+- `sql-optimization-patterns` - SQL optimization
+- `postgres-best-practices` - PostgreSQL patterns
+
+#### Actions
+1. Run EXPLAIN ANALYZE
+2. Identify scan types
+3. Check join strategies
+4. Analyze execution time
+5. Find optimization opportunities
+
+#### Copy-Paste Prompts
+```
+Use @sql-optimization-patterns to analyze and optimize queries
+```
+
+### Phase 3: Indexing Strategy
+
+#### Skills to Invoke
+- `database-design` - Index design
+- `postgresql` - PostgreSQL indexing
+
+#### Actions
+1. Identify missing indexes
+2. Create B-tree indexes
+3. Add composite indexes
+4. Consider partial indexes
+5. Review index usage
+
+#### Copy-Paste Prompts
+```
+Use @database-design to design PostgreSQL indexing strategy
+```
+
+### Phase 4: Query Optimization
+
+#### Skills to Invoke
+- `sql-optimization-patterns` - Query tuning
+- `sql-pro` - SQL expertise
+
+#### Actions
+1. Rewrite inefficient queries
+2. Optimize joins
+3. Add CTEs where helpful
+4. Implement pagination
+5. Test improvements
+
+#### Copy-Paste Prompts
+```
+Use @sql-optimization-patterns to optimize SQL queries
+```
+
+### Phase 5: Configuration Tuning
+
+#### Skills to Invoke
+- `postgres-best-practices` - Configuration
+- `database-admin` - Database administration
+
+#### Actions
+1. Tune shared_buffers
+2. Configure work_mem
+3. Set effective_cache_size
+4. Adjust checkpoint settings
+5. Configure autovacuum
+
+#### Copy-Paste Prompts
+```
+Use @postgres-best-practices to tune PostgreSQL configuration
+```
+
+### Phase 6: Maintenance
+
+#### Skills to Invoke
+- `database-admin` - Database maintenance
+- `postgresql` - PostgreSQL maintenance
+
+#### Actions
+1. Schedule VACUUM
+2. Run ANALYZE
+3. Check table bloat
+4. Monitor autovacuum
+5. Review statistics
+
+#### Copy-Paste Prompts
+```
+Use @database-admin to schedule PostgreSQL maintenance
+```
+
+### Phase 7: Monitoring
+
+#### Skills to Invoke
+- `grafana-dashboards` - Monitoring dashboards
+- `prometheus-configuration` - Metrics collection
+
+#### Actions
+1. Set up monitoring
+2. Create dashboards
+3. Configure alerts
+4. Track key metrics
+5. Review trends
+
+#### Copy-Paste Prompts
+```
+Use @grafana-dashboards to create PostgreSQL monitoring
+```
+
+## Optimization Checklist
+
+- [ ] Slow queries identified
+- [ ] Indexes optimized
+- [ ] Configuration tuned
+- [ ] Maintenance scheduled
+- [ ] Monitoring active
+- [ ] Performance improved
+
+## Quality Gates
+
+- [ ] Query performance improved
+- [ ] Indexes effective
+- [ ] Configuration optimized
+- [ ] Maintenance automated
+- [ ] Monitoring in place
+
+## Related Workflow Bundles
+
+- `database` - Database operations
+- `cloud-devops` - Infrastructure
+- `performance-optimization` - Performance
+
+## Limitations
+- Use this skill only when the task clearly matches the scope described above.
+- Do not treat the output as a substitute for environment-specific validation, testing, or expert review.
+- Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.