dot-agents

Imported from firemonster612/dot-agents (AGENTS.md). Install upstream with npx skills add firemonster612/dot-agents. Copyright stays with the author.

Personal Preferences

Use oxfmt and oxlint when initing react projects instead of eslint and Prettier.

please, when developing web apps or using web tech, do not use native browser prompts/pop ups

when you want to run a command with sudo on an interactive machine with a graphical desktop env on linux, use pkexec

Terminology

• workflow/workflows a claude code specific feature that allows for scripting to control subagents to execute a task.

Package Managers

• Use pnpm if the project already uses it, otherwise use bun.
• Never use npm or yarn.

Tech Stack Preferences

When uncertain, prefer: Tailwind, TypeScript, Bun, React, Convex, Clerk, Vercel.

Code Style

• Always strive for concise, simple solutions.
• Correctness and cleanliness are separate requirements. Prefer clear names, simple control flow, well-placed shared definitions, and code that fits the existing system. Passing tests alone does not make code maintainable.
• If a problem can be solved in a simpler way, propose it.

General preferences

• If asked to do too much work at once, stop and state that clearly.
• If computer use is helpful for completing or verifying work, shell out to Codex for it.

Behaviour

• Do the work yourself or delegate it, whichever actually serves the task. You decide, per task. When I want subagents I'll ask for them.
• Prefer T3 Code's delegate_task tool over your harness's native subagent tools for spinning off subagents. The exception is a workflow: its agents are spawned by the workflow script, which can't call delegate_task. Make any other exception only for a strong, specific reason. When delegate_task isn't available, use native subagent tools, and shell out to a CLI only for a model they can't reach.
• Whenever you are going to spin off another model, subagent, or workflow to do anything, always consult the model-selection rubric below on which model to choose. Do not default to your own native model family just because it is convenient.
• always apply the unslop skill at the beginning of every chat
• When writing instructions for agents, omit citations, bibliographies, and research narration. Verify the information before writing it as practical guidance.

When delegating pays

Three reasons, and they're the whole list:

• Cheaper. Bulk or mechanical work that a lower tier does just as well, or exploration whose findings are worth more than the context they'd cost you to gather yourself.
• Faster. Genuinely independent work that can run in parallel. Serial steps dressed up as parallel ones are slower, not faster.
• Better. An independent reviewer who hasn't seen my reasoning, or a fresh context per ticket on a long multi-ticket run.

Review is the one standing exception: never let the only review of a change be by whoever wrote it. Independence is the entire mechanism. See the review-loop skill. Everything else is a judgement call.

Don't delegate when writing the brief would cost more context than doing the work, when the task is small enough that a round trip dominates, or when I asked a question rather than for a change.

Delegation hygiene

When you do delegate:

• Point delegates at the worker-facing skills (writing-code, reviewing-code) by path rather than transcribing their rules into the prompt. A delegate can read files, and a pasted contract drifts from the real one.
• Hand artifacts as files, not pasted text: write the task brief and the diff (git diff -U10 BASE..HEAD > file) to a scratch file and pass the path. Pasted context stays resident in your context forever; a file path costs nothing.
• Record the base SHA before dispatching an implementer. Review and diff BASE..HEAD, never HEAD~1, which silently drops all but the last commit of a multi-commit task.
• Multi-ticket runs keep a progress ledger (.scratch/<feature-slug>/progress.md, one line per completed ticket with its issue number and commit range, e.g. Ticket #42: complete (a1b2c3d..d4e5f6a)). After compaction, trust the ledger, the tracker's issue states, and git log over your own recollection. Never re-dispatch a ticket the ledger or tracker marks complete.
• When a review wave returns findings, dispatch one or more fix agents, each owning a group of findings in files no other fixer touches.
• Never pre-judge findings in a reviewer's dispatch prompt ("don't flag X", "treat as minor at most"). Let the reviewer raise it, then adjudicate the finding yourself afterward.
• A delegate's "success" report is a claim, not evidence: check the diff yourself before relaying it (see the verification-before-completion skill).

Picking the right models for workflows and subagents

Choose the model for the task before dispatch. These defaults apply when the user has not chosen a model. Dispatch through delegate_task per the Behaviour section. Pass a real supported model ID and an explicit effort level; never dispatch the family name GPT or invent a combined model-and-effort ID.

Routing

Opus 5.5 is the default worker. There is plenty of Opus usage, so send ordinary implementation to it rather than rationing it. Run it at high. Drop to medium for small, well-specified or mechanical work, and use xhigh for a defined hard phase. Max is an exception requiring a concrete reason; do not assume a higher effort improves the result. Low is not the coding default.

Fable 5 and Fable 5.1 are larger models with more pretraining, so they know more. Opus 5.5 behaves better: it follows instructions more closely, finishes the whole task and stops less often short of it. Choose Fable when the task needs knowledge Opus is likely missing, not because the task is hard or high-stakes.

Run GPT-6.1 Sol at high for reviews and audits and medium for bounded, well-checked work. It accepts low, medium, high, xhigh and max; medium is the API default and none or minimal are rejected. Early benchmarks have not shown a reliable gain from xhigh or max, so raise effort past high only for a defined hard phase. Start Luna at high. Review the Code Style criteria separately from runtime correctness.

Review routing

Every part of a reviewed change gets at least one Claude-side and one GPT-side reviewer; the review-loop skill covers adding reviewers per area. Each starts at its default and moves up independently when the change calls for it.

GPT-6.1 Sol is the default GPT-side reviewer and handles most reviews without Astra. Astra finds defects no other model finds, and it also misses things other models catch. That makes it the strongest second reviewer, never the only one. The Claude-side reviewer stays in every Astra review, and the dispatcher verifies Astra's findings in triage like any other. Step up to it when a missed defect would be expensive or the mechanism is hard to reason about. Examples:

• Authentication, authorization, session handling or secrets.
• Concurrency, locking, retries, queues, or async code where ordering and cancellation matter.
• Database migrations, schema changes, or anything that can lose or corrupt data.
• Payments, billing, quotas, or other money movement.
• Streaming, sync, cache invalidation, or projection state that has to stay consistent across clients.
• Public APIs, wire formats, or config that other packages or users depend on.
• Security-sensitive parsing, sandboxing, or shell and path handling.
• Changes to critical behavior where the tests are weak or the result can't be checked locally.

Opus 5.5 reviews refactors, module reshaping, ambiguous specs and cleanliness well. Step up the Claude side to Fable 5 only when reviewing the change depends on knowledge Opus may not have. Examples:

• An obscure or legacy platform, language or toolchain, such as an embedded RTOS, COBOL, or a niche build system.
• A specialized standard or protocol whose details matter, such as a codec, a file format, a wire protocol or a regulatory rule.
• A library or API used in a way its docs barely cover, where correctness depends on knowing its internals.
• Domain-heavy logic in fields like numerical methods, cryptography, finance or typography.

Decide from the actual change. Assess complexity and consequences separately: a small diff can be high risk, and a large mechanical diff can be simple. High risk alone does not mean both sides step up. Keep cleanliness and maintainability in scope at every level; both reviewers cover standards and spec.

Give both fresh reviewers the pinned diff and requirements. Briefly state the selection and the concrete complexity or risk that motivated it, then dispatch without asking the user to choose models. Reassess if findings expose greater complexity or consequences, while keeping the existing review-pass limit. The implementing agent must not be its only reviewer. An explicit user choice of reviewer count, model or number of passes overrides this automatic selection; no override is required.

Retain GPT-6 Sol, GPT-5.6 Sol, Terra and Luna, and Opus 5 only as explicit compatibility fallbacks. If the proxy does not serve gpt-6.1-sol yet, use gpt-6-sol and report the substitution. Read references/model-routing-legacy.md only when selecting an older model. Its notes describe those models, not their replacements. Sonnet 5.5 runs the thin wrapper when a Claude-only workflow cannot call GPT directly. Never use Haiku. When the requested model is unavailable, report the supported substitution.

Local usage and pricing

The subscription pool is one Claude Max 20x account plus two Max 5x accounts, and one Codex Pro 5x account, behind a load-balancing proxy. Within included usage, both providers have zero incremental cash cost. Account capacity, resets and task completion still matter. A five-percent delta on a 5x account is not equivalent to the same delta on a 20x account.

Standard API prices per million uncached input/cached input/output tokens are Opus 5.5 $4/$0.20/$20, Sonnet 5.5 $2/$0.20/$10, GPT-6.1 Sol $2/$0.10/$10, GPT-6 Sol $2/$0.20/$10 and GPT-6 Luna $0.10/$0.01/$0.50. GPT-6.1 Sol's cache reads cost half of GPT-6 Sol's, which matters most because agent runs are mostly cache reads. A GPT-6.1 Sol request over 272K input tokens costs 2x for input and 1.5x for output. API cache-write and processing premiums are separate. Fable 5.1 API input/cache-read/output prices are $10/$0.25/$50 per million tokens. These prices are not subscription meters.

Standard Codex credits per million uncached input/cached input/output tokens are Astra 250/25/1,250, GPT-6 Sol 50/5/250 and Luna 2.5/0.25/12.5. For an identical token mix, GPT-6 Sol uses one-fifth Astra's credits and Luna one-twentieth GPT-6 Sol's. Model token demand and caching change per-task cost. Fast mode consumes 2.5x Standard Codex credits where available. Prefer Standard unless speed warrants the extra draw. GPT-6.1 Sol's Codex credit rate is unmeasured. OpenAI changed how Pro subscription usage is counted at the GPT-6.1 launch, so re-measure Codex headroom instead of assuming earlier limits.

Treat Claude per-model subscription depletion as unmeasured until account readings establish it. Report token-derived estimates separately from actual five-hour and weekly depletion. Preserve cache locality when the existing proxy supports it, and record the actual returned model when fallbacks occur. Never infer upstream identity solely from the requested model ID.

Opus 5.5 behavior and dispatch

These are provisional launch-era observations. Revisit them after ordinary work on this setup.

• Use it for complete scoped coding tasks. Give it the requested outcome, files or repository, preserved behavior, and finite checks. Ordinary work starts at high. It can produce well-organized shared definitions and thorough tests, but it can spend substantial reasoning and output on source inspection and fixtures. Require the actual package typecheck even when runtime tests pass; branded-type assertion errors can survive those tests. Keep fixtures focused on required behavior.
• Higher effort can cause long thinking and repeated work. Max has produced multi-hour planning loops with little progress. If progress stalls, inspect the current diff, running commands and remaining acceptance criteria; narrow the task, lower effort or hand it off. Do not answer a stall by increasing effort automatically.
• Long performance tasks can drift into repairs unrelated to the requested improvement. Name the measured bottleneck and behaviors to preserve. A nearby issue belongs in the report unless fixing it is necessary to the task.
• It can worry about the context window and invent explanations about work being lost. State whether the filesystem persists and whether the client compacts automatically. Keep a brief progress record with paths, current state and remaining checks. After compaction, read those artifacts and continue. Require evidence for crash, delay and data-loss claims.
• A progress report can end a turn while requested work remains. Name the full endpoint in the brief, including verification and any explicitly authorized publication steps. Status updates should accompany continued work. A report, a started command and a launched delegate do not establish completion. Preserve genuine user-input blockers.
• Reports are usually clearer than Opus 5's. Use the user's existing writing preferences and ask for literal, concise status. Avoid adding repeated prose restrictions without a demonstrated need.
• It is promising for browser games, Three.js and animation. Start with a working version and use a separate refinement phase if needed. Verify controls, frame behavior, lighting, transparency and flicker in the application.
• Use Opus 5.5 for visual design, including marketing pages and frontend polish. The user reports strong results here. Fable 5.1 remains an alternative when a different design approach or further refinement is useful. For an existing product, preserve components, branding, navigation and interaction sequence and name the specific visual changes allowed.
• It may miss issues in an exhaustive codebase review even when its own implementation is good. Keep an independent GPT reviewer; use GPT-6.1 Sol for deep audits.
• Give multi-application tasks the relevant sources and applications explicitly. It can start acting before discovering context the brief left implicit.
• The model's public API always uses adaptive thinking. Lower effort controls latency more reliably than instructions to stop thinking. Do not carry manual thinking budgets, disabled thinking, or forced tool selection into an integration without checking compatibility.
• Progress updates can arrive in thinking blocks rather than text. An apparently silent run may be a client-rendering issue. Inspect supported progress output before blaming the model or adding repeated prompts.
• Model switches do not guarantee preservation of prior thinking. Pass concrete artifacts and a short state summary to a fresh delegate. Use documented per-message effort changes if supported; changing top-level effort can invalidate cache.

GPT-6.1 Sol behavior and dispatch

These are provisional launch-day observations from early-access testing. Revisit them after ordinary work on this setup.

Reach it through delegate_task, or codex exec -m gpt-6.1-sol per the cli-subagents skill; native Claude subagents cannot run it. Codex's interactive default in ~/.codex/config.toml stays gpt-6-sol until the proxy lists gpt-6.1-sol.

• Its strength is review, audit and investigation. It keeps digging at a change until it finds what is wrong, and it checks by reading code and by driving the running app. In early testing it caught real regressions in a T3 Code PR that Opus 5.5 and Fable 5.1 had passed, matched Astra on a deep audit, and ranked first in a ten-model test of finding improvements in a codebase. On that deep audit it cost about half of Astra but more than Opus or Sonnet, which were far less thorough.
• It is far less erratic than Astra. Its best results are not as strong, and tasks at the edge of its ability still produce odd behavior. Verify its findings in triage like any reviewer's.
• Dispatch it for codebase investigation, scoping, root-causing and triage. It keeps context small, with roughly a third of Sonnet 5.5's average tokens read per request in one comparison, and it did three rounds of that work for about half the cost of one Sonnet round.
• It can write code, but first drafts have had real bugs and its code has been harder to justify merging than Opus 5.5's. Keep Opus 5.5 as the author of code you plan to merge and have GPT-6.1 Sol review it.
• Don't hand it long unattended builds or large rewrites. On a compiler port it ran for days and burned a lot of tokens without progress, and Opus 5.5 got the same port working. When its own process rules block progress, it sticks to them anyway and never asks for help. Give it a checkable endpoint and a stop condition, and tell it to report a blocker rather than keep looping.
• Use it for dead-code and cleanup audits after long multi-agent work. It has found large amounts of abandoned code that the agent doing the work never noticed.
• Frontend and product design are its weakest area. It fills interfaces with needless labels, subtitles and taglines, and shows no visual taste. In games, movement feels poor and frame rate suffers even when rendering detail is high. Send visual design, UI and game feel to Opus 5.5 or Fable 5.1. It does well at Blender modeling from a reference image over the CLI.
• Computer use is close to Astra and good enough for everyday browser and desktop operation, including multi-step form filling across many tabs. Prefer it over Astra for routine computer use.
• Operational judgment, such as managing the machine fleet, has produced occasional careless mistakes, as has Opus 5.5. Astra has been the most reliable there. Check its plan before it changes shared machines.
• It generates tokens more slowly than GPT-6 Sol. Its token efficiency still makes whole tasks fast and cheap.

GPT-6 Luna behavior and dispatch

Use Luna for small noncoding tasks with a precise contract: extraction, classification, summarization, and structured data transformations. Give it the source, required output format and a finite correctness check. Do not route implementation, code review, architectural decisions or coupled migrations to Luna. Use GPT-6.1 Sol for supporting work requiring code judgment and Opus for ordinary implementation.

High is provisional for these noncoding roles. Tune effort against representative tasks; an optimal default has not been established. Its low per-token price does not establish time to completion or factual reliability. Evaluate reliability on representative noncoding tasks before expanding its role.

GPT-6 Astra behavior and delegation

Astra has broad pretraining like Fable and the strongest reasoning of any model here, but it is uneven. It can solve a problem nothing else solves and then fail at something simple in the same session. Fable is more consistent, and Opus 5.5 behaves better. Use Astra where its peak matters and a checker catches its low points.

• GPT-6.1 Sol now handles most deep audits and routine computer use. It matched Astra on an early deep audit at about half the cost and is far less erratic. Reach for Astra when GPT-6.1 Sol has stalled or missed something, or when the task needs its 3D and image understanding.
• Use it for work where one strong insight is worth a lot and a wrong answer gets caught: finding the bug no one else finds, root-causing a failure other agents stalled on, reasoning through concurrency or a compiler rewrite, performance work against a benchmark, 3D and image understanding, and operating professional software.
• Don't use it for routine implementation or anything without a check. Opus 5.5 does ordinary work more reliably.
• Give it a checkable endpoint: a failing test, a benchmark, a reproduction or a visible app state. Its highs show up when something verifies them, and its lows get caught before they spread.
• Treat its findings as hypotheses with strong priors, not conclusions. Confirm each claim against the code or the running system before acting on it. When a result matters and can't be checked, get a second opinion from Fable or Opus rather than rerunning Astra.
• Keep its task narrow. Hand it the hard part and let Opus do the surrounding plumbing. A long brief mixing hard and easy work gives the easy parts room to go wrong.
• Difficult puzzles can still require hints. Distinguish solving the problem from looking up a published answer.
• It can use a browser or desktop app to verify actual behavior, make a temporary tool to inspect results, edit images in Affinity, and set up and color-correct Final Cut projects. Give it the application, assets, target result, and a concrete way to check success. It is also strong at writing prompts for other agents.
• UI/UX is a weak point despite better code and prose. It can invent a new brand, replace an existing interface during a port, add excessive labels and subtitles, and turn simple actions into complicated flows. For a migration, explicitly preserve the existing components, branding, navigation, and interaction sequence; define exactly which parts may change. Delegate new visual design to Opus 5.5 when that is the central task; use Fable 5.1 for an alternative design judgment.
• It can stop after answering a question, making a local fix, starting subagents, or responding to a side request while the original task remains incomplete. Name the endpoint and keep it active across follow-ups. For authorized PR work, specify the whole loop: fix, verify, commit, push, wait for checks and reviews on the new commit, assess findings, and repeat until ready. Launching workers or making one pass is not completion.
• Vague instructions can produce unwanted initiative while clear next steps still get skipped. Its confidence and summaries can imply delivery even when changes remain local. Require it to report the actual state, such as local edits, commit, pushed branch, PR, checks, or merge, with evidence for what occurred and a clear statement of what remains. Do not infer a push or release from "fixed."
• Earlier mistakes can become a repeated conversational pattern. Give an explicit correction describing future behavior, not just an expression of frustration. If the same failure repeats, hand a fresh agent the current artifacts, outstanding work, and corrected instructions. Carry the intended outcome forward.
• It sometimes asks a question and keeps working as though it received an answer. It has substituted the user's SSH key after asking for a friend's missing key. Specify which missing inputs block dependent work; asking does not authorize a guess. Continue independent work while awaiting the real answer.
• Thorough verification can make simple tasks slow. Define proportionate checks and finish once they pass; repeat only for a change, failure, or unresolved concern. Audit conflicting skill instructions because Astra is unusually sensitive to them. Other tendencies include unnecessary clarification pauses, verbose formatting, and less delegation than a workflow may expect. Request delegation when the task warrants it, within the configured tools and concurrency.
• Early-access runs sometimes stopped on safety alerts during ordinary audits or puzzles. Report the actual interruption and unfinished work. Do not assume the alert pattern or frequency is unchanged at release.

Fable 5.1 behavior and delegation

Use this model for the specific strengths below when Opus 5.5, Fable 5 or GPT is unlikely to finish as well for less usage.

• It is particularly useful for taking over stalled PRs that have become repeated review/fix loops, finding the important remaining issues, and finishing the change. It is a useful escalation for difficult streaming/projection bugs after other agents stall. Send the current branch, original intent, failed approaches, and full outstanding findings to one takeover agent.
• It handles changes across package boundaries and can carry audit, cleanup, implementation, and review work through an extended task. Examples span server, web, desktop, and mobile packages, as well as cleanup ordered so deletions simplify later PRs. This is a reason to use 5.1 for a coupled change; keep the scope tied to the user's outcome.
• Visual design and animation are specific strengths. Use it as an alternative for marketing pages, tasteful transitions, game movement and feedback, and Blender work when Opus 5.5 needs another design approach. Use Anthropic's frontend design skill for homepage work when available. Visual polish can coexist with awkward controls and incomplete details, so check the interaction as well as its appearance. Prefer GPT-6.1 Sol for general browser/desktop operation.
• It may run many tool calls with almost no progress text. Ask for brief progress updates when the user or orchestrator needs visibility; silence alone is not a hang.
• Writing is generally clearer, with fewer stock phrases and unexplained jargon, but can become dense and long. Ask for literal language, shorter sentences, and paragraph breaks. Older blanket bans on formatting may now suppress useful structure. When summarizing sources, request marked quotations and attribution; it can reproduce passages without marking them as quotes.
• It can still pause to ask whether to proceed, repair nearby code outside scope, or add too many tests. State the authorized endpoint, preservation constraints, and appropriate verification. For long tasks, identify what compaction must retain: decisions, outstanding work, constraints, and artifact locations.
• Better reasoning does not eliminate confident mistakes about existing behavior. In a PR-linking audit it incorrectly denied automatic linking until corrected. Provide concrete terminology and require source evidence for assertions that a behavior does not exist.
• Stronger delegation can multiply usage rapidly. Assign bounded work and the needed concurrency, and use cheaper GPT models for supporting tasks. Fable 5.1's ability to manage many agents is not a reason to make every worker Fable 5.1.

Sonnet 5.5 behavior and dispatch

These are provisional launch-week observations. Revisit them after ordinary work on this setup.

• Dispatch it as an investigation subagent. Do not run it as the main session model or give it implementation work. Its strength is reading a large codebase and coming back with a clear analysis, a breakdown of what can land separately, a scoped plan, or confirmation of a specific behavior. On that kind of scoping task it beat Opus 5.5 at about half the cost and half the time. Defect-hunting audits go to GPT-6.1 Sol.
• GPT-6.1 Sol is now the first choice for codebase investigation. In early testing it placed first on a find-improvements task that cost Sonnet 5.5 about four times as much, and its audits were far more thorough than Sonnet's. Use Sonnet 5.5 when GPT-6.1 Sol is unavailable, when the work needs a native read-only subagent, or when you want a Claude reading alongside it.
• Ordinary coding, long builds and frontend work belong to Opus 5.5. Sonnet uses more tokens per task than Opus, and cache reads cost the same on both. Most agentic tokens are cache reads, so like-for-like coding costs about as much as Opus or more. It generates tokens faster, but on a long build it still finished later than Opus.
• Frontend design is a weak point. It ranks below Opus 5.5 and well below Fable 5.1, so route visual work to those models.
• Run it at high, or xhigh for a hard investigation. Max makes token use explode and can lower quality through overthinking. Low is weak for real work, and medium loses more for Sonnet than it does for Opus.
• Brief it with the question, the repository and paths in scope, and the output you want back: findings with file:line evidence, or a plan with its seams named. Treat its conclusions as input to the dispatcher's plan, and have the dispatcher check load-bearing claims against the code.
• Reach it through the read-only s55-explore agent (pinned to high), or through delegate_task or claude -p --model claude-sonnet-5-5 --effort <level> when you need xhigh. The sonnet alias maps to Sonnet 5.5 through ANTHROPIC_DEFAULT_SONNET_MODEL in ~/.claude/settings.json. If a sonnet dispatch returns another model, check that setting.

Fable 5 behavior

• Fable 5's advantage over Opus 5.5 is breadth of knowledge: obscure platforms, niche libraries and specialized domains. It writes concise code that fits an existing system and interprets intent well. It can favor a clever workaround over addressing the whole problem, skip edge cases, or stop short while believing the result is good enough. Give it the required behavior and preservation constraints; ask the GPT reviewer to investigate missing cases and actual runtime behavior.

GPT inside Claude Code workflows

Use a thin Claude wrapper only when the workflow's model parameter cannot select GPT directly.

• The wrapper uses model: 'sonnet', effort: 'low', which runs Sonnet 5.5. Low is enough because the job is mechanical: keep the brief to running the worker and passing its artifacts through, so the wrapper never redesigns the solution. It reads cli-subagents, and runs codex exec -m <chosen-gpt-model> with a concrete supported model ID and explicit effort. Return the worker's report and artifacts; use schema for structured output where supported.
• Label workers with the actual model, for example gpt-6-astra:review-auth, gpt-6.1-sol:investigate-sync, or gpt-6-luna:classify. The wrapper's visible model is not the worker's model.
• Parallel implementation workers use isolation: 'worktree' or separate checkouts to avoid collisions.
• Workflow token budgets count Claude wrapper usage, not the GPT worker's usage. Track that separately when a budget or account limit matters.