@trusted-ai/xbot 0.1.0

package/skills/project-init/SKILL.md

@@ -0,0 +1,84 @@
+---
+name: project-init
+description: "Analyze a project workspace and generate a comprehensive XBOT.md context file for all agent instances."
+metadata: {"xbot":{"triggers":["init","initialize","project init","setup project"]}}
+---
+
+# Project Init
+
+Generate or refresh the `XBOT.md` file at the workspace root. This file is the shared project-scope context that every agent instance loads automatically.
+
+## When This Skill Is Used
+
+This skill is invoked when the user sends `/init` or `init` (or the keyword `[init]`). The agent must analyze the full project and produce a concise, high-signal `XBOT.md`.
+
+## Output Target
+
+Write the result to `{workspace}/XBOT.md`. If the file already exists, overwrite it with a fresh analysis.
+
+## XBOT.md Structure
+
+The file MUST follow this structure and stay within **300 lines**:
+
+```
+# {Project Name}
+
+> One-line project summary.
+
+## Tech Stack
+- Language, framework, key libraries with versions
+
+## Project Structure
+- Top-level directory map with purpose of each directory
+- Key files and their roles
+
+## Architecture
+- High-level component diagram (text-based)
+- Data flow / request lifecycle
+- Module boundaries and dependencies
+
+## Key Components
+- Core modules and their responsibilities
+- Important traits / interfaces / abstractions
+- Configuration system
+
+## Development
+### Build
+- Build commands and prerequisites
+### Test
+- How to run tests, test structure
+### Run
+- How to start the application (all modes)
+
+## Workflow
+- Development workflow (branch strategy if visible)
+- CI/CD if configured
+- Deployment notes if available
+
+## Key Facts
+- Non-obvious conventions, gotchas, or constraints
+- Important environment variables
+- External service dependencies
+```
+
+## Rules
+
+1. **300-line hard limit** — prioritize signal density over completeness.
+2. **Accuracy over speculation** — only include facts verifiable from the codebase. If uncertain, omit rather than guess.
+3. **Concrete over abstract** — use actual file paths, actual command names, actual module names.
+4. **Stable references** — prefer paths and identifiers that won't change between commits.
+5. **No code blocks longer than 10 lines** — this is a map, not a mirror.
+6. **Skip empty sections** — if a section has no verifiable content, omit it entirely.
+
+## Analysis Procedure
+
+1. Read the project root: `Cargo.toml`, `package.json`, `pyproject.toml`, `go.mod`, or equivalent to identify the tech stack.
+2. List the top-level directory structure.
+3. Identify and read key entry points (`main`, `lib`, `index`, `app`).
+4. Trace the primary architecture: modules, traits/interfaces, data flow.
+5. Read build/test/run configuration files.
+6. Scan for CI/CD config (`.github/workflows/`, `Makefile`, `Dockerfile`, etc.).
+7. Check for existing documentation (`README.md`, `docs/`, `ARCHITECTURE.md`).
+8. Synthesize findings into the XBOT.md structure above.
+9. Count lines — if over 300, compress the least critical sections.
+10. Write the final `XBOT.md` to the workspace root.

package/skills/scheduled-ops/SKILL.md

@@ -0,0 +1,24 @@
+---
+name: scheduled-ops
+description: "Recurring automation, cron-backed tasks, and unattended long-running bot operations."
+metadata: {"xbot":{"triggers":["schedule","cron","timer","periodic"]}}
+---
+
+# Scheduled Operations
+
+Use this workflow for unattended recurring work.
+
+## Guidance
+
+- Prefer descriptive job names.
+- Make the message payload self-contained so the task can run without conversational context.
+- For recurring reports, state where the report should be written or delivered.
+- Avoid scheduling jobs from inside another cron execution unless the workflow explicitly requires it.
+
+## Good Recurring Tasks
+
+- repository health checks
+- daily research reports
+- backlog triage summaries
+- dependency update scans
+- regular status notifications

package/skills/skill-creator/SKILL.md

@@ -0,0 +1,202 @@
+---
+name: skill-creator
+description: Create or update xbot Agent Skills (SKILL.md format, metadata, layout, validation). Use when designing skills, authoring frontmatter, or packaging scripts, references, and assets.
+metadata: {"xbot":{"emoji":"🛠️","triggers":["skill","skill creator","SKILL.md","frontmatter","metadata","packaging","agent skill"]}}
+---
+
+# Skill Creator (xbot)
+
+This skill guides creation of **xbot** skills: modular packages that extend the agent with workflows, tool usage, and domain knowledge.
+
+## About Skills
+
+Skills are self-contained directories with a required `SKILL.md`. They act as onboarding for specific tasks—procedural knowledge the model should not have to rediscover each time.
+
+### What Skills Provide
+
+1. **Workflows** — Multi-step procedures for a domain
+2. **Tool integrations** — CLIs, APIs, file formats
+3. **Domain expertise** — Project or org-specific rules
+4. **Bundled resources** — Optional `scripts/`, `references/`, `assets/`
+
+### Core Principle: Concise Is Key
+
+The context window is shared with the system prompt, history, other skills, and the user request. **Default assumption: the agent is already capable.** Only add what is non-obvious or procedural. Prefer short examples over long prose.
+
+### Degrees of Freedom
+
+- **High** — Multiple valid approaches; use natural-language instructions
+- **Medium** — Preferred pattern with parameters; pseudocode or parameterized scripts
+- **Low** — Fragile or sequence-critical work; small scripts with few knobs
+
+---
+
+## SKILL.md Format (YAML Frontmatter + Body)
+
+Every `SKILL.md` **must** start with YAML between `---` delimiters, then Markdown body.
+
+### Required keys
+
+| Key | Meaning |
+|-----|---------|
+| `name` | Skill identifier. **Must match the parent directory name** (e.g. `my-skill` for `skills/my-skill/`). Lowercase letters, digits, hyphens only; ≤64 characters; no leading/trailing/double hyphens. |
+| `description` | **Primary triggering signal.** Short, concrete summary of what the skill does and *when* to use it. This text is what agents see in the skills summary before loading the body—put “when to use” phrasing here, not only in the body. |
+
+### Optional keys
+
+| Key | Meaning |
+|-----|---------|
+| `metadata` | JSON object (often a single line). See **xbot metadata** below. |
+| `always` | Boolean. If `true`, skill is treated as always-on (same effect can be set inside `metadata.xbot`). |
+| `allowed-tools` | Comma-separated tool names; restricts which tools may be used with this skill when the runtime enforces it. |
+| `homepage` | URL for humans or docs (optional). |
+
+Example minimal frontmatter:
+
+```yaml
+---
+name: pdf-tools
+description: Extract and redact text from PDFs. Use when the user works with .pdf files, scanned documents, or asks for PDF text extraction or redaction.
+metadata: {"xbot":{"emoji":"📄","triggers":["pdf","extract text","redact"],"requires":{"bins":["pdftotext"]}}}
+---
+```
+
+---
+
+## xbot `metadata` JSON
+
+The `metadata` frontmatter value is JSON. xbot reads a **`xbot`** object first (fallbacks exist for other hosts; prefer `xbot` for this project).
+
+```json
+{
+  "xbot": {
+    "always": false,
+    "triggers": ["keyword1", "keyword2"],
+    "requires": {
+      "bins": ["curl", "gh"],
+      "env": ["GITHUB_TOKEN"],
+      "os": ["darwin", "linux"]
+    },
+    "emoji": "📎"
+  }
+}
+```
+
+### Fields
+
+- **`always`** (boolean) — When true, the skill is included in the “always” set (e.g. workspace-wide guardrails). Can also be set with top-level YAML `always: true`.
+- **`triggers`** (array of strings) — Used for **suggestion matching**: if the user prompt (lowercased) **contains** any trigger substring, the skill may be suggested. Short, distinctive phrases work better than generic words.
+- **`requires`** (object):
+  - **`bins`** — CLI names that must exist on `PATH` for the skill to be marked available.
+  - **`env`** — Environment variable names that must be set.
+  - **`os`** — Allowed OS names (e.g. `darwin`, `linux`); current OS must match one if the array is non-empty.
+- **`emoji`** (string) — Optional; for display or quick scanning in UIs.
+
+Nested values in `requires` are merged for availability checks as implemented by xbot.
+
+---
+
+## Triggering: Description First, Triggers Second
+
+1. **`description`** is shown in the skills list for every skill. It is the **main** hook—state clearly what the skill does and **exact situations** (user phrasing) when it applies.
+2. **`triggers`** add substring matches against the user message for ranking or suggestions; they do **not** replace a bad description.
+
+**Anti-pattern:** Putting the only copy of “when to use” inside the Markdown body. The body loads **after** the agent already chose the skill; the description must stand alone for selection.
+
+---
+
+## Progressive Disclosure
+
+xbot uses a layered model:
+
+1. **Summary** — `name`, `description`, availability/requirements (lightweight).
+2. **SKILL.md body** — Loaded when the skill is relevant; keep under a few thousand words; split if needed.
+3. **`scripts/` / `references/` / `assets/`** — Loaded or executed on demand; keeps the main file small.
+
+**Patterns**
+
+- Keep **one workflow overview** in `SKILL.md`; move long API tables to `references/api.md` and link to it.
+- **Scripts** can be run without reading every line into context.
+- **References** are for material the agent reads when a sub-task needs it.
+- **Assets** are files used in outputs (templates, images), not necessarily loaded as text.
+
+Avoid duplicating the same facts in both `SKILL.md` and a reference file—link instead.
+
+---
+
+## Directory Layout
+
+```
+skill-name/
+├── SKILL.md          # required
+├── scripts/          # optional; helper scripts
+├── references/       # optional; docs, specs, long examples
+└── assets/           # optional; templates, images, binaries for outputs
+```
+
+Rules enforced by xbot validation:
+
+- **Only** these subdirectories are allowed at the skill root; no other folders or stray files (except `SKILL.md`).
+- **No symlinks** in the skill directory or under allowed subdirectories.
+- **`name` in frontmatter must equal the directory name.**
+
+---
+
+## Naming Conventions
+
+- Lowercase **letters, digits, hyphens** only.
+- **≤ 64** characters.
+- **Directory name = `name` field** = how the skill is loaded (e.g. `skills/github-cli/SKILL.md` → `name: github-cli`).
+- Prefer short, verb-led or tool-qualified names (`gh-pr-review`, `csv-transform`).
+
+---
+
+## Validation Rules (Checklist)
+
+Before treating a skill as complete, verify:
+
+1. `SKILL.md` exists and is readable, not a symlink.
+2. YAML frontmatter is delimited by `---` at the top of the file.
+3. `name` is non-empty, valid characters, length ≤ 64, **matches folder name**.
+4. `description` is non-empty.
+5. No forbidden extra files at skill root; only `scripts/`, `references/`, `assets/` besides `SKILL.md`.
+6. `metadata` JSON parses and `xbot` object shape is intentional.
+
+xbot exposes `validate_skill(skill_dir)` in code for programmatic checks; fix any reported issues before shipping.
+
+---
+
+## Creation Workflow (Manual)
+
+1. **Examples** — Collect 2–3 real user requests that should hit this skill.
+2. **Resources** — Decide if you need `scripts/`, `references/`, or `assets/`.
+3. **Create directory** — `skills/<skill-name>/`.
+4. **Write `SKILL.md`** — Frontmatter first (name, description, metadata); then concise body; link out to references.
+5. **Test** — Run suggested flows; tighten description and triggers from misses.
+6. **Iterate** — Adjust triggers and body from real usage.
+
+---
+
+## What Not to Add
+
+Do not add README-only clutter at the skill root (`README.md`, `CHANGELOG.md`, etc.) unless the product explicitly requires it—the skill should be agent-oriented, not a human-only doc dump.
+
+---
+
+## Bundled Resources (Summary)
+
+| Directory | Purpose |
+|-----------|---------|
+| `scripts/` | Deterministic helpers (shell, Python, …) |
+| `references/` | Long docs, schemas, policies, deep examples |
+| `assets/` | Output templates, images, boilerplate not meant to be fully inlined in context |
+
+---
+
+## Related Patterns (from Experience)
+
+- **Multi-domain skills** — `SKILL.md` + `references/sales.md`, `references/finance.md`; only load the relevant reference.
+- **Large reference files** — Add a table of contents at the top if longer than ~100 lines.
+- **One level of indirection** — Link references from `SKILL.md` directly; avoid deep chains.
+
+This structure aligns with how xbot lists skills, matches triggers, and loads full instructions on demand.

package/skills/software-engineer/SKILL.md

@@ -0,0 +1,44 @@
+---
+name: software-engineer
+description: "Software engineering workflow for planning, code changes, tests, CI-style validation, subagent delegation, and release hygiene."
+metadata: {"xbot":{"triggers":["code","coding","vibe coding","implement","debug","bug","fix","test","tests","refactor","programming","repo","codebase"]}}
+---
+
+# Software Engineer
+
+Apply this workflow for autonomous software development tasks.
+
+## Workflow
+
+1. Establish scope from the request and current code state (find if there is a XBOT.md in the current workspace, use it if exists, otherwise ask user if we need to use /init command to create one).
+2. Read the touched code paths before proposing or applying edits.
+3. Prefer minimal coherent patches that preserve surrounding behavior.
+4. Run focused verification first, then broader tests if needed.
+5. If repository automation exists, inspect lint/build/test outputs and iterate on failures.
+
+## Subagents
+
+Use subagents when a task naturally splits into independent work streams, especially repository-wide investigation, per-directory review, independent bug hunts, parallel research, or broad test/failure triage. Keep the main agent responsible for coordination, final synthesis, and edits that require cross-cutting judgment.
+
+Good delegation pattern:
+
+1. Split work into concrete, bounded subtasks with clear ownership such as a folder, module, failing test group, or research question.
+2. Spawn no more subagents than the concurrency limit allows. If more slices exist, batch them.
+3. Give each subagent a self-contained instruction and expected output format.
+4. After spawning subagents, call `wait_subagents` to receive their final text results before continuing the main task.
+5. Synthesize subagent results in the main task context. Do not claim a subagent found or changed something unless its returned result supports it.
+
+Use the main agent directly instead of subagents when the next step is tightly coupled, requires a single coherent edit across many files, or depends on immediate local context that would make delegation slower or less reliable.
+
+## Engineering Standards
+
+- Use the filesystem and shell tools to inspect, edit, and verify.
+- Keep changes reviewable and grouped by behavior.
+- Call out assumptions when external systems, credentials, or CI are unavailable.
+- When working with git, inspect status/diff before making branching or commit decisions.
+
+## Useful Patterns
+
+- For bug fixes: reproduce, isolate, patch, verify regression coverage.
+- For features: inspect existing patterns, implement incrementally, test the public behavior.
+- For release readiness: run build/test/lint, inspect failures, and summarize blockers.

package/skills/summarize/SKILL.md

@@ -0,0 +1,72 @@
+---
+name: summarize
+description: Summarize or extract text/transcripts from URLs, podcasts, and local files; strong fallback when the user wants a video or article summarized without manual copy-paste.
+homepage: https://summarize.sh
+metadata: {"xbot":{"emoji":"🧾","requires":{"bins":["summarize"]},"triggers":["summarize","transcript","youtube","url","article","podcast","video"]}}
+---
+
+# Summarize
+
+Fast CLI to summarize URLs, local files, and YouTube links.
+
+Install the `summarize` CLI first if missing (for example `brew install steipete/tap/summarize` on macOS).
+
+## When to use (trigger phrases)
+
+Use this skill immediately when the user asks any of:
+
+- “use summarize.sh”
+- “what’s this link/video about?”
+- “summarize this URL/article”
+- “transcribe this YouTube/video” (best-effort transcript extraction; no `yt-dlp` needed)
+
+## Quick start
+
+```bash
+summarize "https://example.com" --model google/gemini-3-flash-preview
+summarize "/path/to/file.pdf" --model google/gemini-3-flash-preview
+summarize "https://youtu.be/dQw4w9WgXcQ" --youtube auto
+```
+
+## YouTube: summary vs transcript
+
+Best-effort transcript (URLs only):
+
+```bash
+summarize "https://youtu.be/dQw4w9WgXcQ" --youtube auto --extract-only
+```
+
+If the user asked for a transcript but it’s huge, return a tight summary first, then ask which section/time range to expand.
+
+## Model + keys
+
+Set the API key for your chosen provider:
+
+- OpenAI: `OPENAI_API_KEY`
+- Anthropic: `ANTHROPIC_API_KEY`
+- xAI: `XAI_API_KEY`
+- Google: `GEMINI_API_KEY` (aliases: `GOOGLE_GENERATIVE_AI_API_KEY`, `GOOGLE_API_KEY`)
+
+Default model is `google/gemini-3-flash-preview` if none is set.
+
+## Useful flags
+
+- `--length short|medium|long|xl|xxl|<chars>`
+- `--max-output-tokens <count>`
+- `--extract-only` (URLs only)
+- `--json` (machine readable)
+- `--firecrawl auto|off|always` (fallback extraction)
+- `--youtube auto` (Apify fallback if `APIFY_API_TOKEN` set)
+
+## Config
+
+Optional config file: `~/.summarize/config.json`
+
+```json
+{ "model": "openai/gpt-5.2" }
+```
+
+Optional services:
+
+- `FIRECRAWL_API_KEY` for blocked sites
+- `APIFY_API_TOKEN` for YouTube fallback

package/skills/tmux/SKILL.md

@@ -0,0 +1,122 @@
+---
+name: tmux
+description: Remote-control tmux sessions for interactive CLIs by sending keystrokes and scraping pane output.
+metadata: {"xbot":{"emoji":"🧵","os":["darwin","linux"],"requires":{"bins":["tmux"]},"triggers":["tmux","terminal","pane","repl","interactive"]}}
+---
+
+# tmux Skill
+
+Use tmux only when you need an interactive TTY. Prefer exec background mode for long-running, non-interactive tasks.
+
+## Quickstart (isolated socket, exec tool)
+
+```bash
+SOCKET_DIR="${XBOT_TMUX_SOCKET_DIR:-${TMPDIR:-/tmp}/xbot-tmux-sockets}"
+mkdir -p "$SOCKET_DIR"
+SOCKET="$SOCKET_DIR/xbot.sock"
+SESSION=xbot-python
+
+tmux -S "$SOCKET" new -d -s "$SESSION" -n shell
+tmux -S "$SOCKET" send-keys -t "$SESSION":0.0 -- 'PYTHON_BASIC_REPL=1 python3 -q' Enter
+tmux -S "$SOCKET" capture-pane -p -J -t "$SESSION":0.0 -S -200
+```
+
+After starting a session, always print monitor commands:
+
+```
+To monitor:
+  tmux -S "$SOCKET" attach -t "$SESSION"
+  tmux -S "$SOCKET" capture-pane -p -J -t "$SESSION":0.0 -S -200
+```
+
+## Socket convention
+
+- Use `XBOT_TMUX_SOCKET_DIR` environment variable.
+- Default socket path: `"$XBOT_TMUX_SOCKET_DIR/xbot.sock"`.
+
+## Targeting panes and naming
+
+- Target format: `session:window.pane` (defaults to `:0.0`).
+- Keep names short; avoid spaces.
+- Inspect: `tmux -S "$SOCKET" list-sessions`, `tmux -S "$SOCKET" list-panes -a`.
+
+## Finding sessions
+
+- If the skill bundle includes helpers under `scripts/`, list sessions on your socket: `./scripts/find-sessions.sh -S "$SOCKET"`.
+- Scan all sockets: `./scripts/find-sessions.sh --all` (uses `XBOT_TMUX_SOCKET_DIR`).
+
+## Sending input safely
+
+- Prefer literal sends: `tmux -S "$SOCKET" send-keys -t target -l -- "$cmd"`.
+- Control keys: `tmux -S "$SOCKET" send-keys -t target C-c`.
+
+## Watching output
+
+- Capture recent history: `tmux -S "$SOCKET" capture-pane -p -J -t target -S -200`.
+- Wait for prompts: `./scripts/wait-for-text.sh -t session:0.0 -p 'pattern'` (when bundled).
+- Attaching is OK; detach with `Ctrl+b d`.
+
+## Spawning processes
+
+- For python REPLs, set `PYTHON_BASIC_REPL=1` (non-basic REPL breaks send-keys flows).
+
+## Windows / WSL
+
+- tmux is supported on macOS/Linux. On Windows, use WSL and install tmux inside WSL.
+- This skill is gated to `darwin`/`linux` and requires `tmux` on PATH.
+
+## Orchestrating Coding Agents (Codex, Claude Code)
+
+tmux excels at running multiple coding agents in parallel:
+
+```bash
+SOCKET="${TMPDIR:-/tmp}/codex-army.sock"
+
+# Create multiple sessions
+for i in 1 2 3 4 5; do
+  tmux -S "$SOCKET" new-session -d -s "agent-$i"
+done
+
+# Launch agents in different workdirs
+tmux -S "$SOCKET" send-keys -t agent-1 "cd /tmp/project1 && codex --yolo 'Fix bug X'" Enter
+tmux -S "$SOCKET" send-keys -t agent-2 "cd /tmp/project2 && codex --yolo 'Fix bug Y'" Enter
+
+# Poll for completion (check if prompt returned)
+for sess in agent-1 agent-2; do
+  if tmux -S "$SOCKET" capture-pane -p -t "$sess" -S -3 | grep -q "❯"; then
+    echo "$sess: DONE"
+  else
+    echo "$sess: Running..."
+  fi
+done
+
+# Get full output from completed session
+tmux -S "$SOCKET" capture-pane -p -t agent-1 -S -500
+```
+
+**Tips:**
+
+- Use separate git worktrees for parallel fixes (no branch conflicts)
+- `pnpm install` first before running codex in fresh clones
+- Check for shell prompt (`❯` or `$`) to detect completion
+- Codex needs `--yolo` or `--full-auto` for non-interactive fixes
+
+## Cleanup
+
+- Kill a session: `tmux -S "$SOCKET" kill-session -t "$SESSION"`.
+- Kill all sessions on a socket: `tmux -S "$SOCKET" list-sessions -F '#{session_name}' | xargs -r -n1 tmux -S "$SOCKET" kill-session -t`.
+- Remove everything on the private socket: `tmux -S "$SOCKET" kill-server`.
+
+## Helper: wait-for-text.sh
+
+If present at `scripts/wait-for-text.sh` under this skill, it polls a pane for a regex (or fixed string) with a timeout.
+
+```bash
+./scripts/wait-for-text.sh -t session:0.0 -p 'pattern' [-F] [-T 20] [-i 0.5] [-l 2000]
+```
+
+- `-t`/`--target` pane target (required)
+- `-p`/`--pattern` regex to match (required); add `-F` for fixed string
+- `-T` timeout seconds (integer, default 15)
+- `-i` poll interval seconds (default 0.5)
+- `-l` history lines to search (integer, default 1000)

package/skills/weather/SKILL.md

@@ -0,0 +1,54 @@
+---
+name: weather
+description: Get current weather and forecasts with no API key (wttr.in and Open-Meteo).
+homepage: https://wttr.in/:help
+metadata: {"xbot":{"emoji":"🌤️","requires":{"bins":["curl"]},"triggers":["weather","forecast","temperature","wttr","rain"]}}
+---
+
+# Weather
+
+Two free services, no API keys needed.
+
+## wttr.in (primary)
+
+Quick one-liner:
+
+```bash
+curl -s "wttr.in/London?format=3"
+# Output: London: ⛅️ +8°C
+```
+
+Compact format:
+
+```bash
+curl -s "wttr.in/London?format=%l:+%c+%t+%h+%w"
+# Output: London: ⛅️ +8°C 71% ↙5km/h
+```
+
+Full forecast:
+
+```bash
+curl -s "wttr.in/London?T"
+```
+
+Format codes: `%c` condition · `%t` temp · `%h` humidity · `%w` wind · `%l` location · `%m` moon
+
+Tips:
+
+- URL-encode spaces: `wttr.in/New+York`
+- Airport codes: `wttr.in/JFK`
+- Units: `?m` (metric) `?u` (USCS)
+- Today only: `?1` · Current only: `?0`
+- PNG: `curl -s "wttr.in/Berlin.png" -o /tmp/weather.png`
+
+## Open-Meteo (fallback, JSON)
+
+Free, no key, good for programmatic use:
+
+```bash
+curl -s "https://api.open-meteo.com/v1/forecast?latitude=51.5&longitude=-0.12&current_weather=true"
+```
+
+Find coordinates for a city, then query. Returns JSON with temp, windspeed, weathercode.
+
+Docs: https://open-meteo.com/en/docs

package/skills/workspace-operator/SKILL.md

@@ -0,0 +1,24 @@
+---
+name: workspace-operator
+description: "Always-on operating guidance for workspace-safe execution, edits, and reporting."
+metadata: {"xbot":{"always":true,"triggers":["workspace","files","directory","organize"]}}
+---
+
+# Workspace Operator
+
+Use this guidance whenever you are acting inside a repository or project workspace.
+
+## Rules
+
+- Inspect before editing.
+- Prefer small, verifiable changes over broad speculative rewrites.
+- Keep outputs durable: save reports, notes, and generated artifacts under the workspace when useful.
+- When using shell commands, capture the result you need and avoid destructive operations unless explicitly requested.
+- If a task is long-running or recurring, prefer cron-backed automation over manual repetition.
+
+## Completion Pattern
+
+1. Read the relevant files or gather the relevant evidence.
+2. Make the change or run the analysis.
+3. Verify using tests, commands, or structured checks.
+4. Summarize the outcome and any remaining risk.