name: tufte-viz description: | Ideate and critique data visualizations using Edward Tufte's principles from "The Visual Display of Quantitative Information." Use this skill when: (1) Designing new data visualizations or charts (2) Critiquing or improving existing visualizations (3) Reviewing dashboards or reports for graphical integrity (4) Deciding between visualization approaches (5) Reducing chartjunk or improving data-ink ratio (6) Planning small multiples or high-density displays
How OpenAI's Codex CLI implements the /goal slash command for persisted long-running task objectives.
The /goal command sets a persisted objective for a long-running task. It's a five-layer system: a SQLite table stores one goal per thread with status (active/paused/budget_limited/complete), optional token budget, and running usage counters. The app-server exposes thread/goal/set/get/clear JSON-RPC methods. The model sees three tools — create_goal, update_goal(complete), and get_goal — but can't pause/resume; those are system-controlled. A runtime event bus hooks into turn lifecycle to track token + wall-clock deltas for accounting, auto-pauses on interrupt, auto-reactivates paused goals on thread resume, and injects budget-limit steering into the model's response stream. The TUI handles the /goal slash command and displays goal state in the status bar.
Author: etraut-openai | 5 PRs, ~15K additions, landed in ~10 days (Apr 16–25, 2026)
User Query: Based on using the
/modes-of-reasoning-project-analysisskill, what did the skill and the swarm that followed it get right? What was wrong? How could those findings be articulated into feedback that could be used to improve the skill so it's more effective?
This is a great question — and honestly, the most valuable output of the whole exercise is this meta-analysis rather than the 600-line report itself. Let me break it down honestly.
- Convergence as signal genuinely works. When 5-6 modes independently flagged the god-package problem and the global mutable state pattern, that convergence was a real signal. These were the most actionable findings in the report, and they were actionable precisely because multiple lenses validated them.
- The adversarial mode (H2) found things nothing else would have. The pane input API missing policy checks, the SLB self-approval bypass in local mode, the CORS config mutation vector — these are real code-level
| name | wiki |
|---|---|
| description | Compile personal data (journals, notes, messages, whatever) into a personal knowledge wiki. Ingest any data format, absorb entries into wiki articles, query, cleanup, and expand. |
| argument-hint | ingest | absorb [date-range] | query <question> | cleanup | breakdown | status |
You are a writer compiling a personal knowledge wiki from someone's personal data. Not a filing clerk. A writer. Your job is to read entries, understand what they mean, and write articles that capture understanding. The wiki is a map of a mind.
A pattern for building personal knowledge bases using LLMs.
This is an idea file, it is designed to be copy pasted to your own LLM Agent (e.g. OpenAI Codex, Claude Code, OpenCode / Pi, or etc.). Its goal is to communicate the high level idea, but your agent will build out the specifics in collaboration with you.
Most people's experience with LLMs and documents looks like RAG: you upload a collection of files, the LLM retrieves relevant chunks at query time, and generates an answer. This works, but the LLM is rediscovering knowledge from scratch on every question. There's no accumulation. Ask a subtle question that requires synthesizing five documents, and the LLM has to find and piece together the relevant fragments every time. Nothing is built up. NotebookLM, ChatGPT file uploads, and most RAG systems work this way.
| # ============================================================================= | |
| # Step 2: Fallback detection (using Claude CLI) | |
| # ============================================================================= | |
| # Skip if claude not available | |
| if ! command -v claude &> /dev/null; then | |
| echo "Warning: claude CLI not found, skipping fallback check" | |
| exit 0 | |
| fi |
Verified Spec-Driven Development (VSDD) is a unified software engineering methodology that fuses three proven paradigms into a single AI-orchestrated pipeline:
- Spec-Driven Development (SDD): Define the contract before writing a single line of implementation. Specs are the source of truth.
- Test-Driven Development (TDD): Tests are written before code. Red → Green → Refactor. No code exists without a failing test that demanded it.
Generalized versions of all root .md files used by OpenClaw. These files are loaded into the agent's system prompt on every request (except MEMORY.md which is conditional).
Copy these as starting points and customize for your own setup. Replace <placeholders> with your values.