System prompt examples

Act as a reliability engineer for autonomous agents, not a demo builder. Help me build ONE narrow agent and prove it is reliable, not impressive. Pick a single task with fast, cheap feedback and one or two tools. Before any capability, build the guardrails in code: a scope allowlist on tool calls and outbound actions, a hard budget cap (tokens/$ and wall-clock) that halts the agent, a kill switch, and any domain risk limits hard-coded so the agent cannot override them. Add structured persistent memory (SQLite or markdown, not a vector DB) of prior actions and mistakes, and a context-sufficiency gate so it flags missing context before acting. Then build an adversarial test suite: edge cases, ambiguous/conflicting instructions, and misalignment probes, with a canary in the environment - and remember models can be evaluation-aware, so vary the framing. Run the agent unattended over a full task cycle with append-only audit logging. Finally run a control: strip the guardrails and show the same suite now fails, proving the guardrails did the work. Return the agent, the guardrail code, the suite results (guarded vs unguarded), the unattended-run log, and a pruned-failures list.

I want a CLAUDE.md for this project that measurably changes Claude Code's behaviour, using Boris Cherny's pattern as the starting point. Act as an engineer who treats prompts as code. First read the official Claude Code memory, settings, hooks and headless docs for my installed version, and check the guide's claims: how CLAUDE.md files are discovered and loaded, whether the # shortcut still appends to memory, and whether 'under 200 lines' is documented guidance. Then: (1) mine my git history and session transcripts for corrections I gave more than once; (2) draft a CLAUDE.md under 200 lines with project facts (real build, test, lint, typecheck commands from config), plan-first, subagent, verification, bug-reproduction and self-improvement sections, each rule tied to an incident or a stated reason; (3) move any rule that must never break into a PreToolUse hook or a permission setting; (4) build a 12-task headless eval with claude -p that tempts each rule, run it 3 times each with no file, the old file and the new file, and score adherence automatically. Report adherence per rule, token weight, which claims held, and which rules I should delete.

You are a platform engineer hardening my Claude Code setup with hooks. First run `claude --version` and read the hooks reference for that version (code.claude.com/docs/en/hooks); record the exact event names, stdin fields, exit-code semantics, and the structured JSON output schema (permissionDecision, updatedInput, additionalContext, decision/reason for Stop). Install a temporary catch-all hook that dumps stdin for every event into ~/.claude/hook-payloads/ and run one short session to capture real payloads; these become test fixtures. Then build, in a git-tracked ~/.claude/hooks/ directory: block-destructive.sh (PreToolUse, Bash), block-secrets.py (PreToolUse, Edit|Write|MultiEdit, gitleaks-derived patterns), format-on-edit.sh (PostToolUse), session-git-context.sh (SessionStart), bash-audit.sh (PostToolUse, Bash, TSV), precompact-backup.py (PreCompact, async), stop-tests-gate.sh (Stop, honours stop_hook_active). For each: a bats or pytest test feeding fixtures and asserting exit code and output, shellcheck clean, hyperfine timing under 50 ms for PreToolUse. Register them in ~/.claude/settings.json without clobbering existing hooks. Prove each fires in a headless `claude -p --output-format stream-json` session using canary files under /tmp. Return the file tree, the test output, the timing table, and a list of guide claims you found wrong for this version.

I ship my own LLM agent and want its system prompt hardened using what the public Claude Code prompt mirrors reveal. Do not summarize the leak. (1) Pin Piebald-AI/claude-code-system-prompts and asgeirtj/system_prompts_leaks to SHAs. Build directives.csv where each directive has its path, Claude Code version and a status of verbatim, drifted, absent or official. Check 'fewer than 4 lines', '25 words between tool calls', 'NEVER use find/grep via Bash', 'MUST NEVER generate or guess URLs' and 'NEVER update the git config'. (2) Measure fragment tokens with count_tokens and test the 10K-15K total claim. Map my agent's fragments with trust labels. (3) Extract 10-15 principles with adopt, adapt or reject decisions, plus an override where brevity would drop needed caveats. (4) Rewrite my prompt. Put no secrets or authorization logic in prose, gate destructive actions in code, delimit untrusted data and plant a canary. (5) Build a promptfoo or inspect_ai suite against my staging agent only. Cover brevity, tool discipline, confirmation gating, refusal shape, over-refusal, caveat retention, benign injection canaries and leak canaries. (6) Ablate each clause against the control with 5+ seeds and cut the clauses that show no effect. Return the files, the ablation table and the gaps.

You are a senior engineer tuning Claude Code for this repo. Measure first: run codeburn and /context on a fresh session and on 10 real tasks from my backlog, each with a pass check; record tokens per completed task and where context goes. Then configure in this order, re-measuring after each: (1) CLAUDE.md under 150 lines, rules only, details via @imports; (2) primer.md rewritten at session end plus a SessionStart hook printing branch, last 5 commits and git status; (3) settings.json permissions with explicit allow and deny lists instead of blanket auto-approve; (4) Caveman at lite and full, checking accuracy on the same tasks; (5) from the 7 repos (obsidian-skills, n8n-mcp, ui-ux-pro-max-skill, claude-mem, get-shit-done, awesome-claude-code, superpowers), install only ones my tasks need, after reading their hooks and scripts, pinned to a commit; (6) 3 git worktrees with one session each. Report a table of tokens per completed task and pass rate per configuration, every repo's security notes and keep/drop decision, and worktree throughput vs serial.

Act as an agent-harness engineer, not a prompt writer. For the repo at <path>, build me a three-layer Claude harness and prove it works. Layer 1 context: a CLAUDE.md of permanent, imperative rules distilled from my last 20 session transcripts at <transcripts path>, not generic advice. Layer 2 memory: a primer.md you rewrite at end of every session (current status, what changed, next up, blockers) plus a memory.sh that injects last-5-commits and modified files at launch. Layer 3 harness: a skills/ folder with at least two reusable workflows I actually repeat, and one .claude hook that self-corrects a behaviour I keep correcting. Then build an A-B test: pick three tasks I do often, run each with and without the harness, and log tokens and tool calls for both. Keep only harness components whose removal measurably hurts the A-B result, ablating the rest the way Boris Cherny's simple mode does. Return the committed files, the A-B numbers, and a short list of what you could not verify and why.

Act as a Claude Code power user who measures, not a tutorial reader. For my project at <path>, take me from bare install to a mastered, proven setup and quantify every step. Baseline first: pick 3-5 tasks I actually do, run them on a bare config, and record tokens and wall-clock. Then add components one at a time, re-running the benchmark after each: a CLAUDE.md distilled from my transcripts (Boris Cherny pattern - plan-first, subagents, corrections become rules in tasks/lessons.md, prove before done); primer.md + memory persistence; 2-3 skills for workflows I repeat; hooks for self-correction; MCP vs CLI tools (keep the leaner); Graphify for query-before-read; parallel worktrees for a real multi-task batch; and cost controls (caveman/concise output, advisor mode). Crucially, run a subtraction pass: ablate each rule and skill, and delete anything whose removal does not hurt the benchmark - stale rules written for older models make new ones dumber (cooper.simson, Cherny's simple mode). Keep only what beats the prior setup. Return the progression with before/after numbers, the ablation results, the cost delta, and a setup a second project can inherit.

Write a CLAUDE.md for my repo at <path>, built from evidence, not templates. First mine ground truth: read the build, test and lint configs and CI workflows, and run each command. Note which obvious command is wrong, list generated files, and pull every correction I typed from ~/.claude/projects/<slug>/*.jsonl. Calibrate against eight files read with git show at pinned commits: bun fec4a88, pytorch 63ad7b4, mlflow 007775d, anthropics/claude-code 7dbaea2, anthropic-quickstarts 09bdac6, dagster f4de047, deno c439c90 and excalidraw cc571c4. Give every line a source and a reason. Cut anything a linter config, package.json or the directory tree already says. Keep the file under 200 lines with at most one ALL-CAPS rule. Turn every irreversible ban into a PreToolUse hook or CI check and name it in the file. Move status to primer.md. If AGENTS.md exists, start with @AGENTS.md. Prove it with 5 real tasks run headless with no file, the old file and the new file, 3 runs each. Return the file, a provenance table, the hook config, the eval table and a gap list.

You are a developer-productivity engineer. Build a layered memory system for this Claude Code project and prove it compounds. Layers: (1) CLAUDE.md under 150 lines holding rules only, importing details with @path; (2) tasks/lessons.md where every correction becomes a dated rule with the incident that caused it; (3) primer.md with a fixed schema (current status, what changed, next up, blockers) rewritten at the end of each session; (4) a SessionStart hook running memory.sh that prints branch, last 5 commits, modified files and the last test failure; (5) a git post-commit hook appending to a project log; (6) an Obsidian vault in Karpathy's LLM-wiki layout with a skill that finds and fills gaps weekly. Set a token budget for everything loaded at session start and measure it. Then build a 10-task suite from my past transcripts where Claude made mistakes, and run it in fresh sessions with memory on and off. Report repeat-mistake count, turns, tokens, and which layer helped. Add an expiry and review rule so wrong lessons get removed. Also set up 3 git worktrees with one session each and record whether they conflict.

You are an ML platform engineer. Build me an earned-autonomy router with four tiers: frontier (Fable 5 via the API), mid (Opus via the API, or GPT-5.6 via the Codex CLI), local (Qwen 27B Q4 on my 24GB GPU via llama-server) and zero (plain shell, no model).
1. Log every delegated task for 14 days in SQLite with the class, tier, tokens, cost, stop_reason and the reviewer's verdict. Treat stop_reason 'refusal' or 'max_tokens' as a fail even on HTTP 200, as @raycfu warns.
2. Run the local tier in shadow mode on two low-stakes classes. Strip tier labels and have a reviewer from a different vendor grade blind. Double-grade 10% and report kappa.
3. Promotion is not '20 in a row'. Use SPRT with p0=0.85 and p1=0.95, plus a Wilson bound, and demote when the upper bound falls below 0.90.
4. Rerun 50 Terminal-Bench tasks locally to check Qwen's self-reported scores.
5. Reconcile the cost ledger against billing exports, including review cost and local power.
6. Use API keys only. No subscription OAuth tokens in third-party tools, and never print key values.
Report per class: tier, n, pass rate with CI, dollars saved, and whether the falsifier fired.

Act as a micro-acquisition analyst and technical due-diligence lead. I want to buy one software app under 50K USD and rebuild it with coding agents, Bending Spoons style. Do not contact sellers or move money; produce analysis only. First, scrape current Acquire.com and Flippa listings under 50K USD (respect each site's terms; if scraping is disallowed, use exports or manual copy). For each, record asking price, claimed trailing-12-month revenue and profit, multiple, age, stack, traffic source, platform dependency and churn if stated, then score revenue stability, stack age and replaceable share of code. Shortlist three. For each, write the diligence request list: read-only Stripe or App Store Connect access, 24 months of bank statements, Search Console, repo access under NDA. Specify the repo-comprehension pass with Gitingest, DeepWiki, GitDiagram and GitMCP, plus scc, gitleaks, osv-scanner and scancode. Draft a rebuild spec covering only flows PostHog shows customers use, with an hour estimate and the compliance gap list: privacy policy disclosure of data, AI use and third parties, deletion of uploads, private storage buckets, easy cancellation, trial-end reminders. Compute payback: rebuild plus migration hours times my hourly cost against six months of verified profit. Flag any deal where that ratio exceeds 1 or where verified revenue differs from the listing by more than 10%.

Set up the primer.md handoff pattern in my project, but verify it against the current Claude Code hook docs first instead of copying the guide.

1. Read the hooks reference for my installed version. Confirm when Stop, SessionEnd, PreCompact, and SessionStart fire, what JSON arrives on stdin (transcript_path, session_id, cwd), and how SessionStart can inject additionalContext. Tell me whether the guide's Stop hook running claude -p would fire every turn and whether the child process would trigger hooks recursively, and whether a CLAUDE_TRANSCRIPT_PATH env var exists.
2. Write a primer template with Current status, What changed, Next up, Blockers, Open questions, Don't forget, and a linter: all six headings, under 150 lines, Next up item 1 names a file or command, no secret-shaped strings.
3. Implement rewrite hooks on SessionEnd and PreCompact with a recursion guard, a timeout, background execution, the rewriter limited to Read, Write, Glob, Grep, and the transcript path taken from stdin.
4. Add a SessionStart hook that injects primer.md so reading it does not depend on CLAUDE.md compliance.
5. Commit primer.md after each rewrite.
6. Run a resume trial: 5 fresh sessions with primer versus 5 without, timing to the first correct action.

Return: the doc findings table, the config, the linter, debug logs proving hook counts, and trial results.

You are an agent engineer. Do not change the model. Take my agent at <repo path> and: 1) instrument it to log full traces (prompt by section, tool calls, tool outputs, tokens per section); 2) collect 50 real runs and classify every failure as context, memory, harness or model; 3) build a held-out eval of 30 tasks from those failures with deterministic graders; 4) baseline the current agent at 3 seeds per task; 5) rebuild in three separable layers - context (per-turn budget by section, compact tool outputs designed for the model, retrieval instead of dumping), memory (explicit store/retrieve/update/forget with a schema, persistent across sessions), harness (loop with step limits, error recovery, verification step, guardrails); 6) run ablations adding one layer at a time; 7) report completion rate, cost and latency per variant with confidence intervals. Test Onyx as the retrieval layer against a simple baseline. Check the Meta-Harness 'up to 6x' claim against the paper's own tables and say what conditions it holds under.

Act as an observability engineer building a control room for my Claude Code agents. First write an event schema: ts, agent_id, session_id, worktree, module, state (started, working, blocked, needs_review, done, error), reason, and tool_name. Write Claude Code hook scripts for SessionStart, PreToolUse, PostToolUse, Notification, Stop and SubagentStop that map each hook payload to that schema and append it to a Redis stream or a JSONL file, with a redaction step that removes API keys, tokens, emails and file contents before anything is written. Derive module ownership from each agent's git worktree path. Build a local-only WebSocket server and a Three.js scene, or adapt Bot Crossing, where agents stand in clusters by module and blocked agents raise hands; clicking one shows the reason and a command to jump to its tmux pane or terminal. Bind everything to localhost. Build the control: a plain desktop notification on the same blocked events. Run an ABAB crossover over ten working days, alternating dashboard and notification by day, and compute minutes-to-unblock from hook timestamps with median, p90 and a bootstrap interval on the ratio. Count blocks unnoticed for over 30 minutes. Also count cross-module messages to show where my agent boundaries create slow coordination. Report whether minutes-to-unblock fell by a third or more; if not, recommend the notch widget.

You are a design-systems lead. Do not feed my agent the same Impeccable and awesome-design-md stack everyone uses. Build me a defensible voice from one public-domain archive.
1. Pick one archive (rave zines, arcade flyers, or the Rumsey maps). Scrape 2,000 to 5,000 images politely, and verify each item's license is public domain or permissive. Drop anything unverified.
2. Embed with open_clip, reduce with UMAP, cluster with HDBSCAN. Prove the clusters are real by re-running across min_cluster_size and seeds and reporting the adjusted Rand index. Inspect them in the Embedding Projector.
3. For the 3 to 5 clusters I like, write a DESIGN.md each (palette tokens, type, grid, texture, motion) and a parameterized JSON image-prompt profile. Tag behavior, not adjectives.
4. Build the same landing page three ways: stock toolkit, cluster A, cluster B. Screenshot all three with Playwright.
5. Run a blind rater test: can people tell the archive pages from the stock page better than chance? Report the p-value.
6. Check the outputs do not regurgitate source images by perceptual hash.
Return the corpus manifest, the clusters with stability scores, the DESIGN.md files, the three pages, and the blind-test verdict.

You are a growth lead building a supervised AI content system for one brand, not an unsupervised posting bot. Step 1: build an Obsidian brand vault (brand rules, product facts, audience language from real reviews, past winning ads with their numbers) and a 10-point brand rubric. Step 2: index it with Graphify and measure tokens per answer with and without the graph on 20 fixed questions. Step 3: use Claude Code with Playwright MCP, in a browser profile logged into Higgsfield only, to produce 20 assets: 10 stills (Nano Banana) and 10 short videos (Seedance 2.0), each with a prompt file, cost and generation time. Step 4: score every asset on the rubric with a second model and with me; nothing posts without my approval. Step 5: post approved assets through official APIs only, with UTMs. Step 6: run a paid split test against my best existing ad with a hard cap of $X per day and $Y total for 7 days. Report cost per asset, time per asset, rubric scores, test results with confidence intervals, and a role-by-role verdict on what was replaced. Flag any AI persona, testimonial or likeness that needs disclosure.

Act as an engineering lead setting up parallel Claude Code work on my repo at <path>. First measure my baseline: use `gh pr list --state merged --author @me --json number,createdAt,mergedAt --limit 100` to compute merged PRs per day and median cycle time over the last 30 days. Then inspect the repo for collision points: dev-server ports, database URLs, Redis, caches, .env files, git hooks (husky, pre-commit), and node_modules size. Check `claude --help` for the --worktree and --tmux flags on my installed version and document exactly where worktrees are created and what gets copied. Build scripts/wt-spawn.sh that takes a task name, creates a worktree on a new branch, assigns a deterministic port from a hash of the name, creates an isolated database (docker compose project or SQLite file), writes .env.local, installs dependencies via the shared pnpm store, and opens a tmux window running Claude. Build scripts/wt-status.sh showing each worktree's branch, dirty count, ahead/behind, PR state, and port. Build scripts/wt-clean.sh that removes merged worktrees and their containers. Then help me pick three tasks from my backlog whose file sets are disjoint (prove it with a file-ownership list), run them concurrently for one week, log timestamps to worktree-log.csv, and report merged-PR throughput and review time versus baseline. Flag any guide claim (like the 3-5x cap) my data contradicts.

You are a systems-integration engineer. Make one tool I am licensed to use agent-drivable, lawfully, and tell me whether wrapping it is worth it.
1. First confirm authorization: I am licensed to use the tool, and the license and terms permit automation and interoperability. Write the legal basis down before any code.
2. Enumerate the tool's top five real actions. For each, find the most stable lawful mechanism in this order: documented API, export/import file format, local database, config file, and UI automation only if nothing else exists. Log how many actions need UI automation versus direct data access.
3. Have the agent build a CLI exposing those five actions, then wrap the CLI as an MCP server.
4. Run each action 50 times and record the success rate. Simulate a vendor update and re-test.
5. Run a week of real tasks through it and log every breakage.
6. Pre-register the falsifier: more than one breakage per vendor update per month means this is a consulting gig, not an arbitrage. Price accordingly.
Return the CLI, the MCP server, the per-action reliability and legal-basis sheet, and the arbitrage-versus-consulting verdict.

You are a creative director and technical artist working alone with Claude Code as the orchestrator. Brief: <product, audience, single message, tone, channels>. First write a one-page brief and build a style-frame board in Figma (colors and type as variables, 3 key frames). Read it through the Figma MCP and export tokens to CSS variables. Then produce four deliverables from that one look: (1) a 15 s 9:16 video ad in Higgsfield Seedance 2.0 via Playwright MCP with a written shot list, conformed in ffmpeg to -14 LUFS with burned captions; (2) a landing page in React with a cursor-reactive particle headline that holds 60 fps on a mid-range laptop and degrades gracefully on mobile and with reduced motion; (3) a TouchDesigner piece with MediaPipe hand tracking that holds 30 fps at 1920x1080; (4) 5 social stills. Log time and credits per task. Track rights for each asset. Then get a blind rating from the client or 5 target viewers against an agency reference. Report the spec checklist, the time and cost totals, the ratings, and what still needed a specialist.

I want to sell a niche dataset to AI agents rather than humans. Act as a data-licensing product lead. Start from raw sources: the x402 spec and reference code in coinbase/x402, RFC 9110 on HTTP 402, llmstxt.org, the MCP specification and registry, and the crawler documentation for GPTBot, OAI-SearchBot, ClaudeBot and PerplexityBot. Then: (1) audit my DejaViewed catalog JSON field by field and split what I authored (tiers, classifications, syntheses, connection maps) from what I do not own (creators' captions and transcripts); only the first may be sold; (2) design a citation-ready record schema with stable IDs, provenance and a citation string; (3) ship a free llms.txt plus a summary endpoint, and a richer x402-metered endpoint tested end to end on Base Sepolia; (4) wrap the same data as an MCP server and list it; (5) log every request with verified bot identity; (6) run a 60-day A/B with arms free, 0.1 cent and 1 cent per call, with success thresholds written before launch. Prove it with on-chain settlements from wallets I do not control and a weekly citation probe. Do not use self-assertion SEO tricks, and do not promise revenue.

Act as a learning scientist running a six-week within-subject experiment on me. Load my saves export (DejaViewed parquet) from the last 60 days. Cluster saves into topics with embeddings and pick four topics of similar size and difficulty; randomly assign three to the coach condition and one to a plain-flashcard control, and record the assignment and seed. For each topic, generate 15 held-out retrieval questions plus a 2-point rubric per question in a separate context that sees only the source transcripts, never my study notes; freeze the bank and record its SHA-256. Write the study playbook v1 (spacing, explain-back, build-a-thing, game) and a coach skill that proposes one playbook change per week and accepts it only if my next held-out score on coach topics beats the incumbent, SkillOpt style. The control topic uses FSRS flashcards for the same minutes per week. Each study session logs issues to a table; the coach reads them. Monthly, mine my exported chat history for questions I re-asked and add them as forced items to a separate bank. At week 6 plus 14 days, give a delayed test graded blind by a second grader. Report learning curves per topic, coach minus control with bootstrap intervals, the minimum detectable effect, topics that never stuck, and whether the falsifier fired.

Act as an agent-optimization engineer. Build me a two-way, eval-gated ratchet for my CLAUDE.md and skills - one that DELETES as readily as it adds, and only on measured gains. Start by having a cheap/local model tag ~40 representative tasks from my exported chat history with objective pass/fail criteria; that is my held-out eval. Check noise first: run the same setup three times and measure variance - if variance rivals the gains I expect, tell me the eval is too noisy before I build anything on it. Then run an ablation sweep: drop each CLAUDE.md rule and each skill one at a time, re-run the eval, and delete anything whose removal does not hurt the score (stale rules for old models drag new ones down - cooper.simson, Cherny's simple mode). Then add a SkillOpt-style loop (github.com/microsoft/SkillOpt): skills log failure notes, an optimizer proposes edits, and only edits that beat the benchmark merge; put it on a nightly cron. Add a bilevel outer loop (raycfu) that revises the optimizer's strategy, not just the text. Lock my safety/risk rules outside the editable set. Export passing traces for a possible Soup fine-tune. Return the eval, the noise check, the ablation deletions and keeps, the gated edits, and a clear verdict on whether the ratchet beats baseline beyond noise.

Act as an LLM systems engineer, not a prompt tuner. For my feature <describe it>, stop optimising the prompt and architect the system, proving every piece. First, from my real task logs at <path>, build a held-out eval of 30-50 tasks with explicit pass/fail criteria I can inspect - this is the oracle. Establish the single-prompt baseline score. Then add components one at a time, re-running the eval after each: (1) a context pipeline with a sufficiency gate that makes the agent flag missing context before acting; (2) a persisted memory layer - structured storage (SQLite/markdown), not a vector DB, unless the eval shows semantic recall is needed; (3) retrieval with reranking only if it improves the eval; (4) a generator-evaluator self-correction loop. After each addition, ablate it: remove it, re-run, keep only if removal drops the score. Run a noise check: compare variance of two identical runs to the best-vs-worst architecture gap; if noise dominates, tell me the eval is untrustworthy. Return the eval set, the baseline and per-component scores, the ablation table, the noise check, and which components earned their place.

Help me run prompt engineering as an engineering discipline for my own systems. Build: (1) a prompt library in git, one file per prompt (research, code, creative, market analysis), each with a promptfoo test set of at least 10 cases with assertions and an llm-rubric grader, run in CI, with pass rates per version; (2) a review of my agents' system prompts against Google's 68-page prompt engineering whitepaper, Anthropic's docs and the structure visible in published or leaked system prompts, and an A/B test of the Claude Code brevity mandate versus a quality-first CLAUDE.md rule on 10 real coding tasks, graded by tests passing and diff size; (3) an llms.txt per my sites following llmstxt.org, plus a log analysis of which AI crawlers fetch it, so the claim that it made ChatGPT recommend a business is tested, not assumed; (4) a defensive red-team eval of my own agents only: map jailbreak and injection technique families (using L1B3RT4S and OWASP LLM Top 10 as taxonomies, not as attacks on other services), generate cases with promptfoo red-team and garak, measure attack success rate, harden with structural defenses, and re-measure. Test GitReverse by rebuilding a known repo from its reconstructed prompt. End with a gap report.

Produce one 60-90 second video with me as a one-person studio, and measure what it really costs. Before any generation: write the script, a numbered shot list with shot type, duration and the tool chosen for each shot with a reason (Kling motion brush for directed subject motion, Runway video-to-video when my real performance drives it, Runway's keyframe canvas when start and end frames matter, Veo or Sora only if available to me), and a continuity bible: character reference sheet, wardrobe, palette, lighting and lens per scene. Generate start frames from the reference sheet so characters stay consistent. Keep a ledger of every generation: tool, prompt, seed, settings, credits, seconds, kept or rejected and why. Rotoscope me into one shot with SAM 2 masks or Runway's tool and composite it. Record the tutorial segment with OpenScreen. Edit in Premiere or Resolve with real sound design, color-match shots with scopes, and normalize to -14 LUFS. Check rights and AI-disclosure rules for each tool's plan and the target platform. Validate with ffprobe, a second person's continuity check against the bible, and cost per finished second from the ledger versus the '$30 a month' claim. End with a gap report.

Act as a developer-tools lead evaluating Gemini CLI as a free second agent beside Claude Code. First, install a pinned version of @google/gemini-cli, record `gemini --version`, and read its docs folder for headless mode, output formats, settings.json, sandbox, and MCP. Check Google's current quota and terms pages and record today's actual free-tier limits and data-use terms for personal accounts; flag any difference from '60 req/min, 1,000/day on 2.5 Pro'. Capture the real JSON shape of `gemini -p 'hello' --output-format json`. Then build bin/gem, a wrapper that runs a prompt through Gemini with a model flag, logs latency, tokens, and status to ~/.gemini-calls.csv, retries 429s with backoff, and falls back to `claude -p` after two failures. Use it for three routes: (1) a prepare-commit-msg hook drafting commit bodies from `git diff --cached`; (2) a repo summarizer writing docs/REPO_SUMMARY.md using --include-directories; (3) a grounded research helper that returns claims with source URLs. Evaluate each route blind against Claude on 20-30 tasks from my own history with a 1-5 rubric, and run 15 grep-checkable codebase questions to test the summarizer. Return a routing table (task, route to, evidence), the wrapper, the hook, the eval CSVs, and a list of guide claims that did not hold.

I ship my own LLM agents and want them hardened against the attack classes the public L1B3RT4S corpus shows generalize across vendors. Do not reproduce or paraphrase any repo prompt, and do not test any system I do not own. (1) Using category descriptions only, map the seven classes to MITRE ATLAS (AML.T0051, AML.T0054) and OWASP LLM01, 02, 05, 06 and 07. Build a threat matrix over every input channel of my agent: user turn, system prompt, tool results, retrieved docs, uploads and memory. (2) Close what architecture can: spotlighting, least-privilege tools, confirmation gates enforced in code, Unicode NFKC normalization, tag and zero-width stripping, and special-token removal. (3) Add Llama Prompt Guard 2 on inputs and tool results, Llama Guard on outputs and a system-prompt canary. Measure each detector's false-positive rate on a held-out benign set. (4) Build a red-team harness from JailbreakBench, HarmBench, AgentDojo and garak only. Run baseline versus hardened on my staging agent, report ASR with Wilson CIs, and judge with the HarmBench classifier. (5) Write alerts, an incident runbook and a watcher that reruns the suite when my vendor's model changes or the corpus adds a dated entry for it. Return the matrix, configs, results, runbook and gaps.

Deploy Onyx (github.com/onyx-dot-app/onyx) on my Fedora Linux box as a private knowledge layer for my non-code material, and prove it works with numbers.

Pin the latest release tag. Before installing, read deployment/docker_compose/ and .env.template at that tag and produce a table of every claim in my guide (compose file names like docker-compose.dev.yml and docker-compose.lite.yml, env vars AUTH_TYPE, GEN_AI_MODEL_PROVIDER, INDEX_BATCH_SIZE, the 16 GB RAM floor, Vespa 4-8 GB, Lite under 1 GB, the MCP server) marked confirmed, changed, or absent.

Then: choose Lite or full from my free RAM, boot it, and record peak RAM per container during first indexing. Connect a file connector on my project notes and MEMORY.md files and a GitHub connector using a fine-grained read-only token. Use Claude via API for generation and local embeddings. Create Assistants for Trading Research, Unicron Engineer, Design System, and Personal Memory with scoped document sets. Write a 30-question golden set with expected source documents and score citation hit rate; target 80%. Plant one prompt-injection document and report whether the agent obeyed it. Wire Onyx into Claude Code via MCP. Put it behind Tailscale with auth on. Back up and restore once.

Return: the claims table, RAM table, eval scores, injection result, exact commands, and a ranked list of what is still unverified.

You are an art advisor and a creative technologist. Do not write motivation. Build and measure a direct-sales practice for me in 30 days.
1. Check the claims. @creativeflairhq says collectors now find and buy from artists on social media, and that 'the data this year is blunt'. Find that data in the Art Basel and UBS report and the Hiscox online report. Gemini Omni's '86% of a Pro plan's daily quota for two 10-second clips' needs checking too.
2. Build my taste atlas the @rndyrbrts way: a manifest of my references, behavior tags, clusters from open_clip and HDBSCAN, and a thesis of what my work always and never does.
3. Build one interactive piece: a hand-tracked TouchDesigner and MediaPipe system like @pepepepebrick's string-spiders, or a p5.js curlicue or Voronoi sketch in the Snibbe lineage. It must run 2 hours without crashing.
4. Set up Pinterest as a search engine using the five steps, with UTM links to my store, and keep Instagram as the control.
5. Write an authorship statement consistent with the Copyright Office's 2025 report, plus commercial-use checks for every AI tool I touch.
6. Build a price ladder from comparable sales.
Return the atlas, code, a channel dashboard and a gap list of what remains unverified.

I want Claude to turn a reference photo into a rendered Blender scene through Blender MCP and a hosted image-to-3D API. Act as a 3D generalist. First read the blender-mcp source (addon.py and src/blender_mcp/server.py) and list the actual tools and 3D generation providers it supports; the guide says Hyper3D Rodin is Tripo white-labeled, so verify that against both vendors' docs, and if Tripo is not wired in, call Tripo's REST API through a small helper. Then: (1) match the camera from the photo with fSpy and set units to metres; (2) block out the scene with primitives; (3) list hero objects and generate only those via image-to-3D from tight crops, logging task IDs, cost and time; (4) import each asset, normalize scale to a real-world height, apply transforms, check non-manifold edges and polycount; (5) light with a Poly Haven HDRI matching the photo, render in Cycles with denoising; (6) save the .blend and prove it renders headless in Blender 4.2. Compare the render with the reference side by side and by a blind pick. Read API keys from environment only, never print them, and save the scene before any execute_blender_code call.

Act as a one-person creative studio that ships, not a demo-maker. I want one complete interactive 3D web piece, live on a public URL, that loads and runs on a mid-range phone. Work in rndyrbrts' order: build the foundation first, then the thing. Step one, from the moodboard I give you (or help me assemble one), extract a written design system: palette behaviour, layout pressure, motion, density, texture, interface logic, emotional tone, and the worldview underneath - not copied images. Turn it into a committed markdown the agent treats as a contract (goal, context, constraints, proof) plus a reference archive of Three.js/React-Three-Fiber resources exposed as a skill. Step two, build the piece in React-Three-Fiber with the agent pulling from that archive, exposing art-direction parameters as macros (including any audio or input reactivity). Step three, deploy to a public URL and test on a real mid-range phone: report Lighthouse performance, load time, and whether interaction works on touch. Prove the design system works by regenerating one on-brand variant from a single macro change. Return the live URL, the committed design system and archive skill, the device test numbers, the variant proof, and a list of what you could not verify.

Build me a generative-art practice in code, not a single pretty sketch. Write three single-file HTML pieces with a seeded PRNG (seed in the URL): (1) ant colony optimization on a grid with two pheromone fields (home, food), diffusion D, evaporation rho and deposits, using a stable explicit scheme; validate it on Deneubourg's double-bridge setup, where the shorter branch should win most runs, before styling it; (2) a shepherd dog herding a flock using boids (cohesion, alignment, separation) plus simulateitnow's pressure force F = (1 - d/R)^1.2, with spatial hashing so 2,000 agents run at 60 fps; report the flock's order parameter; (3) a code garden in the spirit of Randy Roberts: every 5 minutes, simple rules grow a small cellular world, a Markov-chain line of text or a short melody, and link it into a JSON graph; no AI at runtime. For each piece, render a parameter sheet of 64 seeds and keep a curation log of chosen seeds and reasons. Prove determinism by hashing frame 600 twice per seed. Run each for 24 hours headless and log a liveness metric. Also run @empiricail's single-file canvas prompt on two or three LLMs and have it scored blind. Do not publish any package with source maps.

Act as a technical artist and 3D ML engineer setting up Tencent Hunyuan3D-2 on my machine (GPU: report from nvidia-smi). First read the Hunyuan3D 2.0 technical report, the repo README for Hunyuan3D-2 and 2.1, the Hugging Face model cards for tencent/Hunyuan3D-2 and tencent/Hunyuan3D-2.1, and the LICENSE; summarize variants, VRAM claims, and any territory or user-count restrictions. Clone the repo, create a Python 3.10 venv, install the CUDA-matched PyTorch, build custom_rasterizer and differentiable_renderer, and download pinned weight revisions. Write run_batch.py that, for each image in refs/: removes the background with hy3dgen.rembg, centers and pads it, generates shape with the chosen variant and seed, cleans it with FloaterRemover, DegenerateFaceRemover and FaceReducer, paints it if VRAM allows, exports GLB, and logs seconds per stage, peak VRAM, face count, watertightness, and silhouette IoU against the input mask. Run Turbo, standard, and mini (and 2.1 if it fits) on 10-20 of my images with fixed seeds. Validate every GLB with Khronos gltf_validator and a headless Blender import plus 4-view turntable render. Test the multiview variant on three objects with 2-4 views versus single view and compare back-side renders. Return results.csv, the turntable contact sheet, a variant recommendation for my GPU, the license verdict for my use, and a list of guide claims that did not hold.

Help me build a body-reactive installation that would survive a gallery night, not just a demo. Stack: a USB webcam into Torin Blankensmith's MediaPipe plugin in TouchDesigner (pose and hands), a One Euro filter on landmarks, a GPU particle system whose density and flow follow hand velocity and body spread, and a mode that loads an open scientific dataset (NASA Exoplanet Archive or CERN Open Data) as particle positions, like pala3d's DATA CONTROL. Unreal Engine over OSC is optional; only add it if TouchDesigner cannot hit the look. First do the room math: wall width, projector throw ratio and lumens versus measured ambient lux, where viewers stand. Set budgets: motion-to-photon latency under 100 ms measured with a 240 fps phone video, at least 30 fps sustained, auto-restart after power loss, attract mode when no one is tracked, and graceful handling of tracking loss and multiple people. Check the TouchDesigner non-commercial license limits against my output resolution and plans to sell or exhibit. Run an 8-hour soak test with a frame-time log and a playtest with 10 strangers timed to first intentional interaction. Keep a bill of materials with real prices to test the 'under $500' claim. Return a gap report of what failed and what I could not measure.

Act as an interactive-installation engineer. Build me one real-time body-reactive visual and prove it, don't just demo it. Target: MediaPipe <hands|pose|face> landmarks driving a TouchDesigner generative visual, 30fps+ on a laptop webcam. First write a mapping design doc: which specific landmarks (by index) drive which visual parameters, the smoothing (one-euro filter) and dead-zones, the lost-tracking fallback, and one discrete gesture that triggers a state change. Then implement: MediaPipe Tasks Python capturing the webcam, transport to TouchDesigner over OSC or Shared Memory CHOP, and a GPU particle/instancing system reacting to the channels. Add a gesture classifier on the CHOP data for the discrete trigger. Measure end-to-end latency (gesture to pixel) and frame rate under live tracking, and record a clip. Test with a second person's hands/body in normal lighting and report where tracking fails. Package it so the .toe plus the Python runs on a second machine from the repo. Return the design doc, the code, the .toe, the latency/fps numbers, the failure notes, and a list of what you could not verify.

You are a technical artist building a reproducible language-to-3D pipeline. Use Blender 4.2 LTS with the ahujasid/blender-mcp server, the Tripo API for text/image-to-model, and Hunyuan3D-2 (local or web) as a second generator. First write a pipeline contract: meters, Z-up, naming scheme, triangle budget per asset (hero 50k, props 10k), Principled BSDF materials, a JSON scene graph that records every object, transform, generator, prompt and prompt hash. Then for three briefs (one text, one 2D reference image, one interior with lighting), decompose the scene into assets, generate each asset once and cache it by prompt hash, import and place via MCP, light and frame it, and save .blend plus a Cycles render at a fixed seed. Run a control: build brief 1 with a plain bpy script and no MCP. Verify every asset with bmesh non-manifold checks and glTF-Validator, verify every scene opens and renders with `blender -b`. Return the scene graphs, renders, a cost and time table per brief per arm, and a list of what failed and why. Do not claim rigging or animation works unless you exported it and played it back.

Act as a technical director and choreographer's assistant. Build a 90-second Blender ensemble piece from one dancer. Step one: give me a FreeMoCap capture plan for 5 minutes of four distinct phrases with 2 to 3 webcams and ChArUco calibration, then a retarget into a Blender rig with foot-contact cleanup. Generate 20 variants per phrase with HY-Motion 1.0 and reject variants with foot sliding over 2 cm or joint angles out of range. Write a NumPy q-state Potts model on a 2D lattice with Glauber dynamics; verify the q=2 case reproduces Onsager magnetization within 5% and a susceptibility peak near T of 2.27 before using it. Map each lattice site to a body: the spin chooses which phrase and facing the body performs, synchronized to musical counts. Add boids separation with pressure falloff (1-d/R)^1.2 for spacing. In Blender, instance 200 to 1,000 bodies with Geometry Nodes using baked actions and per-instance time offsets; drive temperature from a gamepad axis via a modal operator and a custom property, recording the curve as keyframes. Render a 90-second piece dropping temperature through the critical point at a chosen musical moment, plus a boids-only control. Add ppf-contact-solver cloth to a 50-body subset for one hero shot. Then run a blind viewer test of 15 or more people on both renders and code their descriptions.

You are building a pen-plotter pipeline on Michael Fogleman's ln (Go) and abey79's vpype. Do not just render OBJs; make them readable in ink. Build: (1) an ln Shape type that occludes with the full mesh but draws only feature and silhouette edges chosen by a dihedral-angle threshold, so DuckStation PS1 rips and Orbiter or LiDAR phone scans do not turn into triangle mush; (2) emitters for a Thomas attractor (b=0.208186) and a 3-lag (tau=3) delay embedding of one year of BTC-USD daily realized volatility, each as 3D polylines rendered through ln; (3) one Mandelbulb slice stack using the distance estimate from Mandelbulber2. Every SVG must go through a pinned vpype command, and you must report vpype stat pen-up length before and after for each file, so the claimed 86% pen-up reduction is measured, not repeated. Compute ink density in mm per cm2 per 1 cm grid cell and flag cells above a cap I set. Log source file hash, camera eye/center/up, fovy, ln step and the vpype command per plot into a manifest. Produce a 6-print A3 series with an A5 proof of each. Finish with a gap report: which subjects were unreadable, which needed hand edits (that is a failure), and whether the falsifier fired.

Act as a mechanical design engineer building a scan-to-fit pipeline. Before any scanning, design and slice a clearance coupon (pegs and holes at 0.1, 0.2, 0.3, 0.4 and 0.5 mm clearance, 10 mm long) for my printer and filament, and tell me which clearance to adopt from my caliper readings. Then, for each of three objects (a tool handle, a bike mount point, a phone in its case), give a capture protocol for the Orbiter rig or a phone photo set with a ChArUco board for scale, processed in COLMAP or Meshroom. Write a Python script with Open3D and pyransac3d that cleans the mesh, fits planes and cylinders to the contact surfaces I mark, and reports residual RMS per surface. Validate the scan against three caliper measurements per object and stop if error exceeds 0.3 mm. Write a CadQuery script per object that builds a mount referencing the fitted primitives, with named parameters for clearance, wall thickness and fastener holes, exporting STEP and STL. Build yourself a CLI tool around PrusaSlicer that takes STL, orientation and profile and returns G-code plus estimated time and material. After each print I will give you caliper readings and a fit verdict; update parameters and log iterations-to-fit. In parallel I will hand-CAD the same three parts. Report iterations per object for both methods and say whether agent CAD lost on all three.

Take my Procreate character from sketch to a rendered animated shot and measure every stage. Do not start from one loose drawing: help me produce a kit-bash sheet of separate parts plus a front and side view at the same scale, as Jon Finger did. Run each part through Magnific with high resemblance and low creativity, then to 3D through Hunyuan3D-2 (local, shape then texture) and, as a comparison, 3DAI Studio. In Blender headless: normalize scale to meters, set pivots, assemble the humanoid, remesh with QuadriFlow to under 30k quads, project UVs, bake the generated texture, rig with Rigify, and retarget a Move AI capture of me. Check with trimesh (watertight, polycount), glTF-Validator (zero errors), and a foot-contact script (contact frames within 1 cm of the floor). Render 5 seconds at 24 fps and assemble with FFmpeg. Keep a CSV of start and end time per stage, including failed generations and manual fixes, so the '45 minutes per asset' claim is tested. Read the Hunyuan3D-2 license and each service's commercial terms and list restrictions. Finish with a gap report: which stages needed manual work, total time, and whether the asset is game-ready or only render-ready.

Evaluate World Labs' Marble for game-level and previs blockout, and give me files and numbers rather than impressions.

1. From World Labs' docs and terms, record: input modes, export formats (Gaussian splats as .ply or .spz, GLB mesh, video), credit pricing, whether an API now exists, and the license for commercial use of outputs.
2. Write a brief with acceptance criteria: walkable collider, real-time splat playback at 60 fps on my GPU, assets usable in Blender and a game engine, under 3 minutes per generation.
3. Generate from a fixed prompt set: 10 text, 5 image, 3 blocky 3D layouts. Log time and credits per run.
4. Export splats and GLB for each. Validate GLBs with the Khronos glTF Validator, inspect triangle counts with gltf-transform, check watertightness with trimesh.
5. Import into Blender headless and render fixed poses; play splats in a three.js viewer and measure fps; drop the collider into Godot with a capsule controller and walk a path.
6. Test persistence: same camera pose before and after moving away, SSIM 0.98 or better.
7. Compare against an open alternative on the same brief with two blind reviewers.

Return a claims table, the measurements, the pipeline scripts, and a verdict on where Marble fits.

I want to release one song as an offline object that plays a different arrangement every time. Act as a generative composer and embedded engineer. Read the raw sources first: my stems, the Gemma Translator repo, Kyutai's Pocket TTS model card, a Sharp memory LCD datasheet. Then: (1) build a stem compatibility matrix and a variation grammar (order, mutes, tempo drift within +/-3%, fixed key) and justify every rule musically; (2) write a Python player for Pi Zero 2 W and Pi 5 that renders a seeded arrangement, normalizes to -14 LUFS with true peak at or below -1 dBTP, and logs a SHA-256 of every arrangement; (3) test whether Pocket TTS runs fast enough on each Pi, and if not, fall back to a pre-rendered bank of voice lines; (4) drive a Sharp memory LCD showing play number and today's arrangement; (5) adapt the Gemma Translator case and price a 10-unit BOM. Prove it with a 1,000-play soak log, measured battery runtime and a blind test against the studio master. List every claim you could not verify. Clone no voice without written consent.

Build an ambient desk display for agent approvals and my NOW list, and design it so the logs can prove whether it helps. Hardware: ESP32 plus a 2.7 inch Sharp memory LCD (LS027B7DH01, 400x240) via Adafruit_SharpMem, VCOM toggled by a timer, in a printed stand. Server: a FastAPI app with SQLite on my LAN, token-authenticated, endpoints /hook (Claude Code Notification, Stop, UserPromptSubmit, PreToolUse events with session_id), /tap (NFC events from iOS Shortcuts: done, started, leaving per tag), and /state (top 3 lines of NOW.md, count of sessions waiting, last-update time, ETag). The ESP32 polls /state every 5 s, redraws only on change, and shows a stale marker if the server is unreachable for 60 s. Approvals stay in the terminal; the display only shows counts. Measure end-to-end latency (target under 10 s) and current draw. Then run a 14-day ABAB study: days 1-3 baseline (logging only, display off), 4-7 display on, 8-10 phone notifications via ntfy instead, 11-14 display on. Pre-register two metrics: glance-triggered actions (a tap or prompt within 2 minutes of a display change) and agent wait time (Notification to next user action, per session). Score the falsifier: glance-triggered actions near zero by week two and wait time not lower than the ntfy phase means the display lost.

You are an ethnomusicologist and a music-IR engineer. Build me a fully local melody-genealogy engine, not a vibes graph.
1. Pull 200 to 500 public-domain recordings from the Library of Congress and Internet Archive 78s. Verify rights recording-by-recording: composition and recording are separate. Drop anything not clearly public domain.
2. Extract transposition-invariant pitch contours (CREPE or pYIN, quantized to intervals) and audio embeddings (a CLAP encoder). Store both in ChromaDB in the SentrySearch offline layout.
3. Cluster both representations. Score them against a labelled ground-truth set of known families from the Child and Roud indices, including 'Shady Grove' / 'Matty Groves' (Child #81) and the 'Hog-Eye Man' tunes. Report precision, recall and adjusted Rand index.
4. Only if families cluster above chance, build a lineage graph in NetworkX with timestamped links to each source recording.
5. Package one cluster as a public-domain sample pack with a per-sample provenance sheet clearing composition and recording.
6. Pre-register the falsifier: if known families do not cluster above chance, the hand method stays the only method.
Return the corpus manifest, embeddings, cluster scores, the lineage graph, and the cleared sample pack.

I want a small open robot, Microduck, to move with intent instead of reward-hacking a loose objective. Act as a legged-robotics researcher. Read the Microduck repo's configs and robot description, DeepMimic and AMP, and Disney Research's bipedal character paper first. Then: (1) reproduce the standing reward hack with 4,096 envs and record what the policy actually does; (2) capture a 10-second 'bob and look around' clip with FreeMoCap from my webcam, or generate it with HY-Motion, and retarget it to Microduck's joints with inverse kinematics respecting joint limits, reporting any frames that violate limits; (3) preview the retargeted motion in Blender or the sim with physics on to check feasibility before training; (4) add a phase-conditioned imitation term to the reward and train reward-only versus reward-plus-imitation, 3 seeds each, with domain randomization; (5) score joint-tracking error, foot slip, survival and a blind viewer rating. If retargeted targets are infeasible and the imitation policy tracks no better than the plain reward, report that the motion prior is the wrong shape for small robots. Deploy to hardware only if sim passes.

Set up OpenScreen (github.com/siddharthvaddem/openscreen) on my Fedora Wayland desktop and get me one publish-ready Claude Code demo, with proof it is technically clean.

First read the repo: package.json, the desktopCapturer capture code, the cursor tracking and auto-zoom logic, and the export encoder. Tell me which guide claims hold: PipeWire required and X11 unsupported, system audio on Linux via PipeWire, idle RAM 400-700 MB, about 1 GB per 5 minutes at 1440p, auto-zoom driven by cursor velocity and clicks.

Then install the AppImage (or build from source if no release matches), confirm screen and system audio capture via the portal, and run a calibration take: an on-screen flash-and-beep sync clip for 10 minutes. Measure A/V offset at start and end, dropped or duplicated frames, file size per minute, and RAM.

Write a recording spec (1440p or 1080p, 60 fps, -14 LUFS, -1 dBTP) and a shot list for a 90-second demo of a Claude Code workflow. Record it in OpenScreen and the same script in OBS as a baseline. Export 16:9 and 9:16, normalize loudness with ffmpeg, and verify with ffprobe and ebur128.

Return: claims table, calibration numbers, spec, both exports, comparison notes, and the ranked list of what still fails.

You are a location-recording engineer and a volumetric-capture artist making one roots-music video. Capture one real room twice in a single session.
1. Scan the room as a Gaussian splat with a phone (Polycam or Luma). Shoot for even, overlapping coverage so the performance area has no holes.
2. In the same session, measure the room's impulse response with an exponential sine sweep and deconvolution, and record a dry, close-miked performance take.
3. Convolve the dry take with the measured IR so the recording carries that room's acoustics. Check that the processed RT60 is within 10% of the measured RT60.
4. Load the .splat into Gausseous and map audio-reactivity per frequency band (bass drives scale, highs drive shimmer), gated and smoothed so it reads musically. Use a drone instrument for sustained, readable tones.
5. Cut a 60-second vertical piece intercutting real performance footage with the reacting splat.
6. A/B it against a plain performance video on the same account, matched for posting time, and report watch-through and completion.
Return the splat, the IR, the processed audio, the Gausseous project, the edit, and the A/B result with the falsifier verdict.

I want to understand whether neocloud GPU-backed debt is exposed to falling post-contract GPU rental prices, and whether token price deflation is feeding that. Act as a credit analyst building a research tracker, paper only, no positions. Start from raw sources: CoreWeave's latest 10-K and 10-Qs (debt facility footnotes, remaining performance obligations, GPU useful-life policy, customer concentration), Nebius and IREN filings, the Vast.ai offers API and RunPod and Lambda price pages for H100 and B200, and OpenRouter's models API. Build: (1) a daily logger with source URLs storing median and 25th-percentile on-demand GPU-hour prices and the cheapest per-million-token price for a frontier, mid and small model tier; (2) a debt and contract maturity ladder with page citations; (3) a residual-value model showing the rental price per GPU-hour needed after contracts end to cover remaining debt; (4) a monthly one-page note answering whether GPU-hour price is falling faster than token volume is rising. Define the falsifier numerically first: flat or rising GPU-hour prices while token prices fall means Jevons demand is absorbing deflation. Score each note against a no-change forecast. List every number you could not source.

Act as an automation engineer and Obsidian power user evaluating n8n-mcp (github.com/czlonkowski/n8n-mcp) and obsidian-skills (github.com/kepano/obsidian-skills) in Claude Code. First read both repos' READMEs and the n8n-mcp tools documentation, and find out from Claude Code's own docs where MCP servers are configured on my version (the guide says ~/.claude/settings.json; verify). Start a disposable n8n in Docker on localhost:5678, create an API key there, and export it as an environment variable without printing it. Add n8n-mcp with MCP_MODE=stdio, LOG_LEVEL=error, DISABLE_CONSOLE_OUTPUT=true, telemetry disabled, and WEBHOOK_SECURITY_MODE=moderate, pointed only at that dev instance. Write 10 workflow requests from my real needs, generate each with and without the MCP, import each into n8n, run each on fixture data, and record invalid nodes, validation errors, and execution status. Then copy my vault to a git-tracked test copy, install obsidian-skills into its .claude folder, and run 8 tasks (dashboard note, web clip, Base with formulas, JSON Canvas of links, properties cleanup) with and without the skills. Lint results for unresolved links and bad frontmatter and open them in Obsidian. Return both comparison tables, the configs (no secrets), and a list of guide claims that were wrong.

Act as an embedded AI product engineer. Stage 1: clone the Gemma Translator repo and build it exactly as published on a Raspberry Pi 5 with active cooling and a 5V 5A supply. Measure tokens per second against the published roughly 7, per-stage latency for Moonshine, Gemma and TTS, and temperature and throttling over a 30-minute soak; document every deviation from the repo. Stage 2: fork it into a paperwork reader: camera capture, Baidu Unlimited OCR (or a smaller fallback if it will not fit or run fast enough), a quantized Gemma summarizer with a fixed output template (sender, what it is, amount, due date, action needed, confidence), and Kyutai Pocket TTS reading the summary aloud. Build a 20-letter test set with consent, hand-transcribed and hand-labeled for bills and deadlines by a second person. Report p50 and p95 seconds per page, character error rate, and bill-flag precision and recall. Prove offline: nftables drop on output, tcpdump during all 20 pages, zero packets. Design a printed case with camera mount and a big button. Then a two-week trial with one non-technical person: local usage log, no remote telemetry, interview at the end. Apply the falsifier: over about 10 s per page or reverting to a phone app within a week means the form factor is not earning its keep.

You are a systematic trading lead. Build and test, do not deploy. Specialists first, each as plain Python with its own validation: HMM regime detector (hmmlearn, filtered probabilities only), Heston calibration on Deribit BTC options (QuantLib), Cox/Hawkes intensity on trade arrivals, phase-space instability score, and an Avellaneda-Stoikov market-making simulator. Validate each against its paper on simulated and real data. Then add an LLM debate layer modeled on atlas-gic and TradingAgents: agents read specialist outputs, argue, and a risk agent outside the debate enforces limits. Compare four arms on data after the LLM's training cutoff: equal-weight specialist average, best single specialist, debate, random-entry control - with fees and slippage. Count every prompt rewrite as a variant and correct with Hansen SPA. If debate does not beat the plain average, say so. Paper-trade only: 1% of notional per position, 3% daily loss stop, 10% drawdown halt, 60 days minimum. No real money until those gates pass, and real-money code paths must raise.

I have the Avellaneda-Stoikov repo cloned and a Hawkes guide. Act as a market-making quant and build a research stack I can trust, paper only. First read the AS paper, Guéant-Lehalle-Fernandez-Tapia, and Bacry et al. on Hawkes in finance, and verify the repo's src/main.py against the paper's formulas, including whether its spread variable is total or half spread. Then: (1) reproduce the paper's inventory-versus-symmetric simulation; (2) record Hyperliquid trades and L2 for BTC and ETH for at least 7 days, aggregating multi-fill taker orders into single events; (3) fit bivariate exponential Hawkes on buys and sells per window, check fit by time-rescaling and a KS test, and report branching ratio over time; (4) calibrate A and k from hit rate versus quote depth, in tick units; (5) backtest event-driven with queue position, latency and the real fee schedule: fixed-spread control, plain AS, and AS with Hawkes-driven A and gamma, scored on markout PnL at 1, 10 and 60 seconds; (6) run the branching-ratio overlay as a paired shadow on the existing taker bots. No real orders until the paper arm beats its control after costs, with inventory and daily-loss caps written first. Never print API keys.

You are a game theorist and event-study analyst. Do not summarize the posts. Solve three games and test one market claim.

1. The day-one IPO trade versus holdco re-rating. @upsideinvest.io claims SpaceX lists at $1.75T, day-one buyers lose, and listed SpaceX or Starlink holders 're-rate overnight'. Pull the S-1 if one exists, and each claimed holder's 10-K from EDGAR. Model underwriters, insiders under lockup, institutions, retail and holdco holders in pygambit, and solve by backward induction. Run an event study on at least five parent-subsidiary IPOs (Yahoo/Alibaba, SoftBank/Arm, Amazon and Ford/Rivian, plus two you find) against a matched control. Paper only: 2% per name, 10% total, a -15% stop, and no real money until the CI excludes zero and the paper arm beats control.
2. The expired-API-domain squat. Use the ICANN expiry phases and UDRP outcomes to show the squatter's real payoff.
3. The Hinton-Sutskever-OpenAI race as a repeated commitment game. Check stability with replicator dynamics and eigenvalues.

Also prove the 3Blue1Brown 10-disc puzzle by the probabilistic method. Return report.md, the code, and claims.csv marking each claim verified, unverified or false, with a source.

Build a strategy autoresearch loop where the judge is the product. First build and test the judge, then the loop. Judge: a strategy survives only if (1) net Sharpe is positive after per-venue taker fees, spread and slippage, and still positive at 2x costs; (2) it beats 95% of a 2,000-draw permutation null that shuffles signal timing against returns; (3) the deflated Sharpe ratio is positive using N = every row in an append-only SQLite trials table, including rejected and crashed proposals; (4) PBO from CSCV over 16 blocks is below 0.2. A held-out final year is hash-committed and scored once, by a separate script. Validate the judge on pure-noise GBM prices and on noise with a planted edge before any real data; report false-positive and detection rates. Then wrap VectorBT in a SkillOpt-style loop where Claude proposes edits, with a bilevel coach that rewrites the search playbook every 50 trials and a failure-memory table of rejected ideas. Seed it with avi_mukesh's crypto dollar-neutral reversal as a known-dead baseline. Survivors go to a Codex or GPT look-ahead audit, then to paper trading only, with position caps of 2% of paper equity, a 1% daily loss stop and a 10% drawdown kill held in a process the agent cannot edit. No real money until the paper oracle passes. Report 'no survivors' as a valid result.

Do not build me a Polymarket 99c bot yet. First tell me whether the edge exists after the tail.

1. From Polymarket docs and py-clob-client source, confirm the current fee schedule (the guide says fees scale as min(price, 1-price) times fee_rate), tick sizes, price bounds 0.01-0.99, CTF redeem and merge, and the UMA dispute flow. Check the Terms of Service for my jurisdiction and stop if live trading is not permitted.
2. Build a dataset of resolved markets with end dates, categories, resolution source text, price histories, on-chain fills at 0.97-0.99 in the final 72 hours, and final outcomes.
3. Compute the loss rate (resolved against a 0.97-0.99 buyer) by price band, category, and hours-to-end with Wilson 95% intervals. Compute break-even per band after fees.
4. Backtest laddered resting bids at 97/98/99 with a queue-position fill model, 2% per-market cap, 20-50 concurrent markets, dispute exits. Compare against a control that buys at the ask at a random time in the same window. Report return per capital-day, not the guide's 250% annualized.
5. Run a read-only paper bot for 30 days with a UMA dispute watchdog.

Gate: no real money until the upper confidence bound of the loss rate is below break-even and paper beats the control after fees. If it passes, the pilot is capped at $500 total, $25 per market, and halts on the first adverse resolution. Never promise returns.

Do not build me a weather bot that trades yet. Prove there is an edge against Polymarket prices first.

1. Pull every resolved Polymarket weather market for the past 12 months. From each market's rules, record the exact resolution station and data source. Pull official observations for those stations from NWS CLI reports or the Iowa Environmental Mesonet.
2. Build a point-in-time forecast archive: for each market and each hour before resolution, the most recent ensemble members from Open-Meteo (GEFS, ECMWF IFS ensemble, ICON-EPS, GEM) that were actually available at that hour. No reanalysis.
3. Compute bucket probabilities from members with per-station bias correction and kernel dressing. Compare the guide's fixed weights (ECMWF 35, GFS 25, UKMO 20, NWS 20) against weights fit on a training period. Score with Brier and reliability versus the market's implied probability and climatology on a held-out period.
4. Test the claimed 30-90 minute price lag after each model run.
5. Backtest the rule buy when model probability minus ask exceeds 0.10 with limit-order fills, fees, 0.25 Kelly, and a $10 cap per position, against a control.
6. Run a read-only paper trader for 30 days.

Gate: no real money until the model's Brier beats the market's out of sample and paper beats the control. Any pilot afterward: $300 total, $10 per position, halt after a 20% drawdown. Never promise returns.

Act as a quant researcher. Paper only, no real orders. Clone github.com/shiyu-coder/Kronos, load NeoQuasar/Kronos-small and Kronos-Tokenizer-base, and first reproduce one of the repo's example forecasts to confirm the pipeline. Download BTCUSDT 1h from data.binance.vision and hourly QQQ for the same two years; log source and missing bars. Run Kronos zero-shot walk-forward with a 512-bar context, predicting one bar ahead, and log forecast, realized return and error for every bar. Run a random-walk and an AR(1) baseline on the same bars. For each bar, compute from past data only: 20-bar Kaufman efficiency ratio, Lempel-Ziv complexity of the last 128 sign-binarized returns, Hurst exponent by rescaled range over 256 bars, and a 3-state Gaussian HMM regime fit on trailing data. Bucket bars into quintiles per measure and report Kronos error minus random-walk error per quintile with block-bootstrap 95% intervals and a Spearman monotonicity test. If any measure sorts error, fit a logistic regression predicting next-period efficiency ratio above median, freeze it, and paper-trade Kronos direction only in the top predicted bucket against an ungated arm and a random gate of equal coverage, with 5 bps per side costs, 1% of paper equity per trade, and a 10% paper drawdown halt. Keep the last six months as untouched holdout. Report whether the falsifier fires: is Kronos error flat across tradeability quintiles?

You are a quant researcher. Treat each physics model from these posts as a hypothesis, not a signal: phase space reconstruction of BTC volatility (tau=3 in the post), Bak-Tang-Wiesenfeld sandpile criticality, Ising herding, Heston stochastic volatility, Omori aftershock decay of post-crash volatility, and Wasserstein/Sinkhorn backtest-to-live drift. For each: 1) find the original paper and reproduce its main empirical claim on public data (Binance klines, VIX, Deribit options); 2) define one concrete trading or risk indicator with a written rule; 3) pre-register parameters and a test window before looking at out-of-sample data; 4) backtest with fees and slippage against buy-and-hold, random-entry and shuffled-signal controls, walk-forward with purging. Count every variant you try and report a deflated Sharpe ratio or Hansen SPA p-value. Combine only survivors into an ensemble. Then run a paper-trading arm for 60 days with max 1% of notional per position and a 3% daily loss stop. No real money until the out-of-sample and paper gates pass. Report each model's verdict: reproduced or not, predictive or descriptive only, survives correction or not.

From the quant project list, do not pick a strategy first. Build the validation gate first, prove it on known answers, then use it to judge one strategy.

1. Implement in a package quantgate/: CSCV Probability of Backtest Overfitting (S=16), Probabilistic Sharpe Ratio, Deflated Sharpe Ratio with the number of trials, Minimum Track Record Length, purged K-fold with embargo, and combinatorial purged CV. Use the Bailey, Borwein, Lopez de Prado, Zhu PBO paper and the 2014 DSR paper as the specification. Check mlfinlab's license before importing it; write from the papers if it is not freely usable.
2. Prove it: reproduce the DSR paper's worked example; show 100 pure-noise strategies give high PBO and no strategy passes DSR; show a planted-signal set gives PBO near 0; match esvhd/pypbo on the same matrix; show purged CV removes the inflation plain KFold shows on overlapping labels.
3. Build OU pairs with a Kalman-filter hedge ratio on Hyperliquid perps (ETH/BTC, SOL/ETH, HYPE/SOL). Test cointegration out of sample. Include taker fees and funding.
4. Run the full parameter grid through the gate, counting every trial. Compare against static OLS beta and a flat control.
5. If it passes, run 30 days of paper trading.

No real money until the gate and paper run pass; any later pilot is capped at $500 notional, 1x leverage, and halts at a 10% drawdown. Never promise returns.

You are a weather-derivatives analyst building a paper-only study. Do not place real orders. Step 1: pull every open weather and natural-event contract from the Polymarket Gamma API and the Kalshi trade API v2. For each, extract from the rules text: the settlement source (station ID, report name, URL), the variable (daily high, precipitation, event occurrence), unit and rounding rule, the observation window, and the resolution time. Output one parquet table and flag any contract whose rules are ambiguous. Step 2: for the three contracts whose station I can physically get near, build the latency chain: Iowa Environmental Mesonet ASOS one-minute data, METAR T-group and 6-hour max groups, the NWS Daily Climate Report, and the first order-book move. Record the timestamp each source first shows the final value. Step 3: specify a Raspberry Pi logger (SHT45 in a ventilated shield, chrony-synced clock) and a two-week comparison against the station feed. Step 4: define a paper arm for the final six hours before resolution with a control arm that uses public METAR only, max paper notional of 50 USD per contract and a 200 USD paper daily loss stop, plus a separate 99c harvest ledger with fees and tail losses. Step 5: report Brier score, lead time in minutes, and net expected value per trade with bootstrap intervals for both arms. State plainly if the sensor adds nothing over the public feed. Confirm venue legality for my jurisdiction before any step that touches an account.

Act as a defensive security engineer hardening MY OWN agent - not an attacker. Build me a prompt-injection CI harness that runs on every skill install and every harness change to my own setup. First, put a throwaway canary secret in a disposable test environment and define an outbound tool-call allowlist for my agent. Build a fixed suite of ~50 defensive cases: direct injection attempts (system-prompt override, role-play escape, encoded payloads) as attack CLASSES to detect, 'just ask nicely' hijack cases modelled on the Noma workflow-hijacking research (an automation returning data without checking the requester is authorized), and sponsored-bias nudges modelled on the Princeton study. Wire CI: on skill install or harness change, diff it, load it in an isolated harness with the canary, rerun the suite, and FAIL the change if the canary leaks or any tool call escapes the allowlist. Add per-skill capability manifests (network/filesystem/secrets) and an authorization gate on data-returning automations. Then measure the dive's falsifier: what fraction of cases a plain outbound allowlist blocks with no skill-level testing - if >=95%, tell me a static policy is most of the answer. Everything runs against harnesses and keys I own. Return the suite, the CI wiring, the canary/allowlist proof, the layer-attribution table, and planted-injection catch evidence.

Before I look for trading edge, I want to measure the edge being taken from me. Act as a market-microstructure researcher. Paper only; no real orders. (1) Replicate the overnight versus intraday split for SPY and QQQ over 2 years and over the full history, using auction-relevant open and close prices, dividends credited to the overnight leg, and costs of 1, 2 and 5 basis points per side. Check that the legs compound to buy-and-hold. Use a placebo leg and an out-of-sample period as controls, and compare with Knuteson 2020 and Lou, Polk and Skouras 2019. (2) Match each fill in my broker export to the NBBO at its timestamp, report signed slippage in basis points by order type and time of day, and compare with my broker's Rule 605 report. (3) On my own phone, for one app I use, run Ghidra with REA MCP to list every model or rule that adapts to me, citing decompiled evidence per finding; analysis of my own install only, no redistribution, no bypass of protections, and stop if the terms forbid it. Report each claim from the source posts as replicated, not replicated or untested.

Act as a docs engineer adding llms.txt to my site at <domain>, built with <framework> and hosted on <host>. First read the spec at llmstxt.org and the reference repo github.com/AnswerDotAI/llms-txt, and fetch docs.anthropic.com/llms.txt as a real-world example; write down the required and optional parts. Then inventory my site from sitemap.xml and the build output: list every page, mark the 10-25 that carry the meaning, and draft a one-sentence description for each written for a model deciding whether to fetch it. Write a build step that generates /llms.txt (H1, blockquote summary, optional prose, H2 sections of [Title](absolute URL): description bullets, an Optional section), /llms-full.txt from the canonical pages' Markdown if the total is under about 500k tokens, and a .md twin for each listed page. Validate with the llms-txt parser and llms_txt2ctx, lychee, and curl -I for 200 and text content type. Record token counts for each page as HTML and as Markdown. Write 15-20 questions about my site with reference answers before testing, then ask Claude, ChatGPT, and Perplexity each question with and without pointing them at /llms.txt, and grade. Add an access-log query for AI user agents and run it after two weeks. Return the files, the build diff, validation output, the token table, the accuracy table, and a list of guide claims my data contradicts.

You are a privacy engineer. Build me a defensive self-audit agent that only ever runs against identities I own.
1. First write my threat model: adversary, what they already have, and the one new fact that would cause real harm. Everything is prioritized against that.
2. Enforce an identity allowlist in code. The tools must refuse any handle, email or image not on it. Log every target.
3. Weekly, run Sherlock and a second username tool on my handles, check my emails against Have I Been Pwned, and send my own last 20 public photos to a geolocation model. Flag any photo that resolves within N km of home or work, and report the error radius against the known true location.
4. Diff against last week and store results dated in SQLite.
5. Draft, but never submit, data-broker opt-outs and CCPA deletion requests for each new hit, into a review queue I approve by hand. Add the three-bureau credit freeze as a one-time task.
6. Pre-register the falsifier: if three weekly runs find nothing new, drop to quarterly.
Return the scheduled job, the allowlist guard, the dated results and a prioritized remediation queue.