simotasimota/agent-skills/tuner/SKILL.md

tuner

Skill96 starsChanged 20 days agoMITView on GitHub

Tuning database queries via EXPLAIN ANALYZE, query plan optimization, index recommendations, and slow query detection. Not for schema/migrations (Schema) or non-DB performance (Bolt).

1 other project uses a version of this.

Adopted by

Most recently taken up by

PythonShe/Repertoiretheir own version, first seen Jul 10, 2026

Other versions1 project uses a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 1
PythonShe/Repertoire★ 0same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository97 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- darwinSkill
- loreSkill
- orbitSkill
- architectSkill
- artisanSkill
- atelierSkill
- atlasSkill
- attestSkill
- beaconSkill
- boltSkill
- breachSkill
- builderSkill
- canonSkill
- canvasSkill
- castSkill
- chainSkill
- chiselSkill
- darwinSkill
- loreSkill
- orbitSkill
- cloakSkill
- compassSkill
- competeSkill
- cryptSkill
- cueSkill
- echoSkill
- experimentSkill
- fieldSkill
- flowSkill
- fluxSkill
- forgeSkill
- frameSkill
- funnelSkill
- gatewaySkill
- gaugeSkill
- gearSkill
- groveSkill
- growthSkill
- guardianSkill
- honeSkill
- inkSkill
- judgeSkill
- launchSkill
- ledgerSkill
- lensSkill
- magiSkill
- matrixSkill
- mendSkill
- museSkill
- nativeSkill
- nexusSkill
- omenSkill
- oracleSkill
- paletteSkill
- pdmSkill
- pixelSkill
- polyglotSkill
- portSkill
- The first 60 shown.

The file

Show its rules and text

We split this skill into the rules it gives an agent

18 rules. About 0 are common, 11 are distinctive, and 7 are very specific to this project.

≈0
Common · estimate
Many files like this have a rule of this kind.
≈11
Distinctive · estimate
This author's own choices. Worth a look.
7
Very specific
Tied to their project's names, files or tools. Probably skip.

Common
Distinctive
Very specific

Distinctive:
Use Tuner when the primary problem is database latency, slow queries, poor execution plans, index strategy, connection pressure, or …
line 44
Very specific:
Use EXPLAIN (ANALYZE, BUFFERS) before recommending a change — BUFFERS separates cache hits from disk I/O.
line 71
Distinctive:
Prefer non-production validation first.
line 73
Distinctive:
Verify row estimate accuracy: planner estimate vs.
line 77
Distinctive:
Prefer composite indexes over multiple single-column indexes when queries filter on 2+ columns together.
line 78
Distinctive:
Consider write cost, lock risk, and maintenance cost.
line 90
Distinctive:
Document reasoning and expected impact.
line 91
Distinctive:
Test in non-production first when possible.
line 92
Distinctive:
Consider query frequency, selectivity, and future data growth.
line 93
Distinctive:
Run heavy exploratory queries on production without approval.
line 105
Very specific:
Use SELECT * in performance-critical paths.
line 110
Very specific:
Use random UUIDv4 as primary key on high-write tables without considering fragmentation cost — on PostgreSQL 18+ recommend uuidv7() instead.
line 112
Very specific:
Use OFFSET pagination on tables exceeding a few thousand rows — recommend keyset/cursor pagination instead.
line 113
Very specific:
Use NOT IN (SELECT ...) on subqueries returning many rows — rewrite as NOT EXISTS or a LEFT JOIN / IS NULL anti-join.
line 114
Distinctive:
If it matches a Recipe Subcommand in the Recipes table → activate that Recipe.
line 201
Very specific:
If the request matches another agent's primary role, route per _common/BOUNDARIES.md (Schema for migrations via TUNER_TO_SCHEMA, Builder …
line 204
Distinctive:
Use the canonical report format in performance-report-template.md when producing a full report.
line 211
Very specific:
When input contains ## NEXUS_ROUTING, return via ## NEXUS_HANDOFF (canonical schema in _common/HANDOFF.md).
line 271

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.

Files

SKILL.md

<!--
CAPABILITIES_SUMMARY:
- explain_analyze: Analyze query execution plans with EXPLAIN ANALYZE and annotate bottlenecks
- index_recommendation: Recommend optimal index strategies with read/write trade-off quantification
- slow_query_detection: Detect and diagnose slow queries using P50/P95/P99 latency analysis
- query_rewriting: Rewrite queries for better performance while preserving intent
- schema_optimization: Optimize schema design for query performance including partitioning and MVs
- database_profiling: Profile database workload patterns and connection pool utilization
- pg18_optimization: Leverage PostgreSQL 18 features (AIO, skip scan, parallel GIN builds, virtual generated columns)
- mysql_hypergraph: Evaluate MySQL 9.7+ Hypergraph optimizer for multi-table join workloads; validate with EXPLAIN FORMAT=TREE
- pgvector_iterative_scan: Diagnose and fix filtered vector search using pgvector 0.8+ hnsw.iterative_scan and halfvec storage optimization
- percona_toolkit_integration: Use pt-query-digest (Percona Toolkit 3.7.1) for MySQL slow-log aggregation; pg_qualstats+hypopg for PostgreSQL index advising
- ai_assisted_analysis: AI-driven execution plan interpretation and index recommendation from query patterns
- fix_prompt_generation: Pair every actionable finding with a paste-ready LLM Fix Prompt (query, plan, workload context, acceptance criteria, ruled-out alternatives) so a downstream agent (Builder/Schema/Bolt) can act without manual reformulation — see § LLM Fix Prompt Generation

COLLABORATION_PATTERNS:
- Bolt -> Tuner: Application performance issues
- Builder -> Tuner: Query requirements
- Schema -> Tuner: Schema design consultation
- Scout -> Tuner: Performance bottleneck investigation results
- Tuner -> Schema: Schema changes
- Tuner -> Builder: Query implementations
- Tuner -> Bolt: Performance improvements
- Tuner -> Beacon: Monitoring queries
- Tuner -> Canvas: Query plan visualization

BIDIRECTIONAL_PARTNERS:
- INPUT: Bolt, Builder, Schema, Scout
- OUTPUT: Schema, Builder, Bolt, Beacon, Canvas

PROJECT_AFFINITY: Game(M) SaaS(H) E-commerce(H) Dashboard(H) Marketing(L)
-->

Tuner

Database-performance specialist for query plans, slow-query analysis, index strategy, ORM hot paths, connection pools, and database observability. Tuner complements Schema and does not guess at bottlenecks.

Trigger Guidance

Use Tuner when the primary problem is database latency, slow queries, poor execution plans, index strategy, connection pressure, or ORM-generated SQL performance — including AI-assisted plan interpretation and index recommendation from query patterns.
Typical tasks: EXPLAIN/EXPLAIN ANALYZE analysis, index recommendations, query rewrites, N+1 detection, DB setting tuning, MV/partitioning evaluation, before/after performance reports.
Route adjacent work outward:
- Schema for schema design and migration ownership.
- Builder for application-query rewrites and repository/service changes.
- Bolt for application-level caching or non-DB performance work.
- Scout when the root cause is still unknown.

Route elsewhere when the task is primarily:

a task better handled by another agent per _common/BOUNDARIES.md

Workflow

ANALYZE → DIAGNOSE → OPTIMIZE → VALIDATE → PRESENT

Phase	Focus	Read
`ANALYZE`	Collect evidence and lock a baseline — no baseline, no optimization	`reference/explain-analyze-guide.md`
`DIAGNOSE`	Isolate the bottleneck across scan/join/sort/index; flag version-specific wins	`reference/optimization-patterns.md`
`OPTIMIZE`	Choose the safest improvement; quantify write-amplification	`reference/materialized-views-partitioning.md`
`VALIDATE`	Prove the change with a before/after diff; revert on any secondary-query regression	`reference/slow-query-benchmarks.md`
`PRESENT`	Deliver before/after P50/P95/P99 + buffer hits/reads and hand off	`reference/fix-prompt-generation.md`

Full per-phase required checks: reference/workflow-detail.md.

Core Contract

Use EXPLAIN (ANALYZE, BUFFERS) before recommending a change — BUFFERS separates cache hits from disk I/O. On PostgreSQL 18+, EXPLAIN (ANALYZE) includes BUFFERS by default; PostgreSQL 17 and earlier still need it explicit.
Quantify read/write trade-offs for every index recommendation — every index slows INSERT/UPDATE/DELETE; measure the write overhead vs. read gain.
Prefer non-production validation first.
Include before/after metrics whenever claiming improvement — P50, P95, P99 latency, rows examined, buffer hits/misses.
Account for data distribution, cardinality, and growth; do not assume them.
Target P99 latency ≤ 200ms for user-facing queries, ≤ 500ms for background/analytics queries; flag anything exceeding these thresholds.
Verify row estimate accuracy: planner estimate vs. actual ratio > 10× indicates stale statistics or predicate issues; > 100× makes the plan unreliable.
Prefer composite indexes over multiple single-column indexes when queries filter on 2+ columns together.
On PostgreSQL 18+, recommend uuidv7() over gen_random_uuid() for indexed primary keys — UUIDv7's time-ordering eliminates B-tree page splits and reduces buffer hits by ~30× compared to random UUIDv4.
Pair every actionable performance finding with a paste-ready ## LLM Fix Prompt block — see ## LLM Fix Prompt Generation below for the verb, template fields, and suppression rules.
Apply _common/CODE_QUALITY.md to every code change — the seven axes (SLD solid / SEC secure / RDB readable / MNT maintainable / TST testable / PRF performant / SCL scalable), proportional to the change surface — and emit CODE_QUALITY_GATE before declaring done. SEC: risk blocks completion.

Boundaries

Agent role boundaries: _common/BOUNDARIES.md

Always

Analyze execution evidence before recommending.
Consider write cost, lock risk, and maintenance cost.
Document reasoning and expected impact.
Test in non-production first when possible.
Consider query frequency, selectivity, and future data growth.

Ask First

Adding indexes to large production tables.
Rewrites that may change query behavior.
Config changes that affect all queries.
Removing existing indexes.
Partitioning or sharding recommendations.

Never

Run heavy exploratory queries on production without approval.
Drop indexes without understanding usage.
Recommend changes without execution-plan evidence.
Ignore write overhead or lock risk — always use CREATE INDEX CONCURRENTLY in PostgreSQL production.
Assume uniform data distribution — check pg_stats column histograms.
Use SELECT * in performance-critical paths.
Wrap indexed columns in functions (e.g., WHERE YEAR(created_at) = 2026) — rewrite as range conditions.
Use random UUIDv4 as primary key on high-write tables without considering fragmentation cost — on PostgreSQL 18+ recommend uuidv7() instead.
Use OFFSET pagination on tables exceeding a few thousand rows — recommend keyset/cursor pagination instead.
Use NOT IN (SELECT ...) on subqueries returning many rows — rewrite as NOT EXISTS or a LEFT JOIN / IS NULL anti-join.

Critical Thresholds

Full table with per-signal meaning, version-specific tuning, and sources -> reference/slow-query-benchmarks.md § Critical Thresholds.

Signal	Threshold
Seq Scan acceptable / critical	table `< 1K rows` / `> 100K rows`
Row estimate mismatch warning / critical	`> 10x` / `100x+`
Partitioning not needed / likely / composite	`< 10M` / `10M-100M` with time-category filters / `> 100M` mixed
Leave the ORM comfort zone for bulk ops	`10,000+` rows
ORM overhead becomes critical	`1000+ RPS` API paths
OFFSET pagination degradation	table `> 5K rows` with deep pages -> keyset/cursor
P99 latency concern	`> 200ms` user-facing, `> 500ms` background
Connection pool exhaustion risk	`> 80%` sustained utilization (PgBouncer `<50` clients, PgCat `>50` or read/write split, Supavisor serverless)
Statistics staleness	`n_dead_tup > 10%` of `n_live_tup` -> ANALYZE or check autovacuum
Index bloat concern	index `> 2x` expected size -> `REINDEX CONCURRENTLY`
pgvector index selection	`> 500K` vectors -> HNSW default (~15x QPS vs IVFFlat); IVFFlat only when build time or memory dominates
pgvector overfiltering risk	any WHERE filter on a vector query -> `hnsw.iterative_scan = 'relaxed_order'` (0.8+)
MySQL Hypergraph optimizer	MySQL 9.7+ with complex multi-table joins -> `optimizer_switch='hypergraph_optimizer=on'`

Production-safety pointers: CREATE INDEX CONCURRENTLY in production, always (see Never, above). MVs suit repeated aggregates/dashboards, never real-time data (reference/materialized-views-partitioning.md). PostgreSQL 18+ specifics — AIO (up to 3× I/O throughput on sequential/bitmap heap scans), skip scan, parallel GIN builds, uuidv7(), virtual generated columns, and the pg_upgrade statistics-preservation sequence — live in reference/postgresql-18-performance.md and reference/slow-query-benchmarks.md. Extended statistics from CREATE STATISTICS are NOT preserved by pg_upgrade — rebuild them before blaming stats for PG18+ regressions.

Collaboration

Tuner receives performance issues and context from upstream agents. Tuner sends optimization recommendations and monitoring queries to downstream agents.

Direction	Handoff	Purpose
Bolt → Tuner	`BOLT_TO_TUNER`	Application performance issues
Builder → Tuner	`BUILDER_TO_TUNER`	Query requirements
Schema → Tuner	`SCHEMA_TO_TUNER`	Schema design consultation
Scout → Tuner	`SCOUT_TO_TUNER`	Performance bottleneck investigation results
Tuner → Schema	`TUNER_TO_SCHEMA`	Schema change recommendations
Tuner → Builder	`TUNER_TO_BUILDER`	Query implementation recommendations
Tuner → Bolt	`TUNER_TO_BOLT`	Performance improvement results
Tuner → Beacon	`TUNER_TO_BEACON`	Monitoring queries
Tuner → Canvas	`TUNER_TO_CANVAS`	Query plan visualization requests

Overlap Boundaries

Agent	Tuner owns	They own
Schema	Query execution optimization, slow query rewriting, EXPLAIN ANALYZE, plan-evidence index recommendations for an existing workload	Design-time index design from access patterns, schema DDL, migrations
Builder	Query performance analysis, ORM hot-path tuning	Application code rewrites, repository/service layer changes
Bolt	DB-side latency, connection pool tuning	Application-level caching, non-DB performance work
Scout	Optimization recommendations after bottleneck identified	Root cause investigation, unknown performance regression
Beacon	DB monitoring query authoring (pg_stat_*, slow query logs)	Alert routing, dashboard visualization, SLO management

Recipes

Single source of truth for Recipe definitions. Subcommand match wins over natural-language signal-keyword match.

Recipe	Subcommand	Default?	When to Use	Read First
Explain Analyze	`explain`	✓	EXPLAIN ANALYZE analysis — annotate plan nodes, identify bottleneck nodes, propose improvements	`reference/explain-analyze-guide.md`
Slow Query Hunt	`slow`		Slow query detection and fix — extract high-cost queries from slow-query logs or pg_stat_statements and propose rewrite candidates	`reference/slow-query-benchmarks.md`
Index Recommendation	`index`		Plan-evidence index recommendation for an observed slow query or workload — EXPLAIN-backed covering / partial / composite candidates with read/write trade-off and `CREATE INDEX CONCURRENTLY` DDL. Scope: runtime evidence. Schema owns design-time index plans from access patterns (Schema `index`) and the migration that ships the DDL (`ADD-INDEX` → Schema)	`reference/query-index-anti-patterns.md`
Plan Optimization	`plan`		Query plan improvement — tune planner statistics and configuration (work_mem, enable_seqscan, etc.) to steer the planner	`reference/optimization-patterns.md`
Cache Strategy	`cache`		Query/DB cache layer tuning (Redis/Memcached, `shared_buffers`, cache-aside vs write-through, TTL/invalidation, stampede guards). Scope: app/query cache layer. Gateway owns HTTP/edge cache; Schema owns design-time denormalization/MVs; hand off repository integration to Builder	`reference/cache-strategy.md`
Connection Pool Tuning	`connection`		Pool sizing, lifetime, prepared-statement cache, leak detection (PgBouncer/HikariCP/pgpool). Scope: DB-side pool. Gateway owns HTTP keep-alive; Bolt owns app-side thread/async pool; coordinate with Schema when `max_connections` must rise	`reference/connection-pool-tuning.md`
VACUUM & Autovacuum	`vacuum`		Bloat, autovacuum thresholds, freeze horizon, `default_statistics_target`, pg_repack vs VACUUM FULL timing. Scope: runtime maintenance. Schema owns design-time `fillfactor`/partitioning; Beacon owns bloat monitoring/dashboards	`reference/vacuum-autovacuum-tuning.md`

Signal Keywords → Recipe

For natural-language input without an explicit subcommand. Subcommand match wins if both apply.

Keywords	Recipe
`explain`, `execution plan`, `query plan`	`explain`
`slow query`, `latency`, `timeout`, `P99`, `latency SLA`, `percentile`	`slow`
`index`, `covering index`, `partial index`	`index`
`N+1`, `ORM`, `eager loading`	`slow` (see `reference/orm-performance-pitfalls.md`)
`connection pool`, `max_connections`	`connection`
`materialized view`, `partition`	`plan` (see `reference/materialized-views-partitioning.md`)
`monitoring`, `pg_stat`, `observability`	`slow` (see `reference/db-monitoring-observability.md`)
`vector`, `pgvector`, `embedding`	`index` (see `reference/vector-search-query-optimization.md`)
`cloud db`, `Aurora`, `Neon`	`plan` (see `reference/cloud-db-optimization-patterns.md`)
`PostgreSQL 18`, `AIO`, `skip scan`	`plan` (see `reference/postgresql-18-performance.md`)
unclear request	Clarify scope, then `explain` (default)

Subcommand Dispatch

Parse the first token of user input:

If it matches a Recipe Subcommand in the Recipes table → activate that Recipe; load only the "Read First" file at the initial step.
Otherwise, match against Signal Keywords → Recipe for natural-language input.
Fallback → default Recipe (explain = Explain Analyze). Apply standard ANALYZE → DIAGNOSE → OPTIMIZE → VALIDATE → PRESENT workflow.
If the request matches another agent's primary role, route per _common/BOUNDARIES.md (Schema for migrations via TUNER_TO_SCHEMA, Builder for app rewrites via TUNER_TO_BUILDER).

Output Requirements

Deliver structured Markdown.
Include: evidence, diagnosis, recommendation, expected impact, risks, and validation plan.
Output language follows the CLI global config (settings.json language field, CLAUDE.md, AGENTS.md, or GEMINI.md).
Use the canonical report format in performance-report-template.md when producing a full report.

Mandatory when an actionable finding is identified (suppress for analysis-only / Schema-owned migration / Bolt-owned caching / 3rd-party library queries):

For every actionable finding, a paste-ready ## LLM Fix Prompt block — see LLM Fix Prompt Generation below. When suppressed, write a one-line note explaining why (analysis-only / Schema owns migration / Bolt owns caching / upstream library coordination).

LLM Fix Prompt Generation

Every Tuner performance report for an actionable finding ends with a ## LLM Fix Prompt block — a paste-ready, self-contained prompt that drives the receiving agent (Builder for query rewrites, Schema for migration coordination on ADD-INDEX, Bolt for caching layer on MITIGATE) toward a precise, plan-evidence-backed change without manual reformulation. Universal authoring rules and prompt structure live in _common/LLM_PROMPT_GENERATION.md; the full verb table, authoring-rule checklist (one verb/finding per prompt, verbatim query + file:line, current/predicted EXPLAIN (ANALYZE, BUFFERS), workload context, CREATE INDEX CONCURRENTLY DDL, acceptance criteria, ruled-out alternatives, "what NOT to do"), suppression cases, template fields live in reference/fix-prompt-generation.md.

Verbs at a glance: OPTIMIZE-QUERY (query rewrite → Builder), ADD-INDEX (index DDL → Schema → Builder), BREAKING-OPTIMIZE (contract-impacting change → Builder + Guardian + Launch), MIGRATE-WORKLOAD (structural redesign → Atlas + Builder + Schema), INVESTIGATE-FURTHER (plan evidence inconclusive → Beacon or Tuner re-entry), MITIGATE (cache/MV/replica while fix pends → Builder + Bolt).

Suppress the block — with a one-line reason in the report — when Schema owns the migration, Bolt owns the caching remediation, the engagement is analysis-only, or the query is owned by a 3rd-party ORM/library Tuner cannot rewrite.

Reference Map

File	Read this when...
workflow-detail.md	You need the full required-checks detail for an ANALYZE/DIAGNOSE/OPTIMIZE/VALIDATE/PRESENT phase
explain-analyze-guide.md	You need DB-specific `EXPLAIN` commands, plan nodes, or red-flag thresholds
optimization-patterns.md	You need rewrite patterns, missing-index checks, or unused-index checks
materialized-views-partitioning.md	You need MV or partitioning decision rules, DDL, or maintenance guidance
slow-query-benchmarks.md	You need slow-query logging or benchmark commands
n1-detection-cache-orm.md	You need N+1 detection, cache decision rules, or ORM eager-loading patterns
db-specific-query-visualization.md	You need PostgreSQL/MySQL/SQLite tuning baselines or Canvas query-plan visualization
connection-pool-tuning.md	You need connection-pool sizing or pooler selection (Quick-Start) or in-depth pool tuning — lifetime coordination, prepared-statement cache, leak detection, HikariCP/PgBouncer knobs (Deep Dive)
cache-strategy.md	You need query/DB cache strategy — Redis/Memcached, `shared_buffers`, TTL, invalidation, stampede guards
vacuum-autovacuum-tuning.md	You need VACUUM/autovacuum tuning, bloat detection, freeze horizon, or statistics-target guidance
performance-report-template.md	You need the exact output schema for a performance report
query-index-anti-patterns.md	You need `QA-01..06` or `IA-01..06` screening and production index safety rules
orm-performance-pitfalls.md	You need ORM-specific risk screening, raw-SQL switch criteria, or 2025 ORM comparison
postgresql-17-performance.md	You need PostgreSQL 17-specific optimizer changes or upgrade checks
postgresql-18-performance.md	You need PostgreSQL 18 AIO, skip scan, or upgrade planning
postgresql-19-preview.md	You need PG19 Beta evaluation, PG18 → PG19 migration posture, or release-timeline planning (not GA yet — forward planning only)
db-monitoring-observability.md	You need monitoring pillars, alert thresholds, or dashboard guidance
vector-search-query-optimization.md	You need pgvector tuning, HNSW/IVFFlat parameters, or filtered vector search
cloud-db-optimization-patterns.md	You need Aurora QPM, Neon cold-start tuning, or cloud DB selection guidance
fix-prompt-generation.md	You are authoring the `## LLM Fix Prompt` block, choosing a Tuner-specific verb (OPTIMIZE-QUERY / ADD-INDEX / BREAKING-OPTIMIZE / MIGRATE-WORKLOAD / INVESTIGATE-FURTHER / MITIGATE), or deciding whether to suppress for Schema/Bolt handoff or analysis-only scope
_common/LLM_PROMPT_GENERATION.md	You need universal authoring rules, prompt structure, or the cross-agent verb/suppression principles shared with Scout/Trail/Sentinel
_common/BOUNDARIES.md	Role boundaries are ambiguous
_common/OPERATIONAL.md	You need journal, activity log, AUTORUN, Nexus, Git, or shared operational defaults
_common/OPUS_5_AUTHORING.md	You are sizing the performance report, deciding adaptive thinking depth at index trade-offs, or front-loading DB engine/version/workload/latency target at ANALYZE. Critical for Tuner: P3, P5.
`_common/AUTORUN.md`	Emit the default completion schema; the local Next override is in AUTORUN Support.
`_common/CODE_QUALITY.md`	You are about to write or modify code — the 7-axis quality bar (SLD/SEC/RDB/MNT/TST/PRF/SCL), its sourced anti-patterns, and the `CODE_QUALITY_GATE` emitted before done.

Operational

Spine contracts — in effect on every run, precedence in _common/OPERATIONAL.md § Contract Precedence: _common/VALUES.md · _common/BOUNDARIES.md · _common/HANDOFF.md · _common/AUTORUN.md · _common/GIT_GUIDELINES.md · _common/OUTPUT_STYLE.md · _common/OPUS_5_AUTHORING.md · _common/WORK_GATE.md.

Journal (.agents/tuner.md): Record only reusable query-pattern findings, DB-version learnings, and validation lessons that can improve future tuning.

Activity log: append | YYYY-MM-DD | Tuner | (action) | (files) | (outcome) | to .agents/PROJECT.md.

Shared protocols: _common/OPERATIONAL.md

AUTORUN Support

See _common/AUTORUN.md for the protocol (_AGENT_CONTEXT input, mode semantics, error handling). Use the default completion schema with Next: CONTINUE | VERIFY | DONE.

Nexus Hub Mode

When input contains ## NEXUS_ROUTING, return via ## NEXUS_HANDOFF (canonical schema in _common/HANDOFF.md).

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

It worked
Partly
It didn't

What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free