Skip to main content

Tips & Tricks

Use this page as a quick-wins checklist for daily Anyy use. Each tip points back to the page that owns the full behavior, so this guide stays practical instead of becoming another reference table.

Get Better Results​

Start With The Outcome​

Tell Anyy what done looks like. A useful prompt names the goal, constraints, relevant files or systems, and how you want the answer verified.

Review the provider fallback docs against the current config code. Fix inaccurate
claims, keep the wording concise, then build the docs site.

Put Context Where Anyy Can See It​

Project files are not automatically swept into every resident session. If a turn needs a file, folder, or project instruction, reference it directly:

Use @file:AGENTS.md and @folder:docs-site/docs/guides to review these pages.

Role identity lives in SOUL.md under the active Anyy home. Project instructions such as AGENTS.md, CLAUDE.md, and .cursorrules are not resident-runtime identity files in this build. See Context Files and Context References.

Let The Runtime Use Its Tools​

For work that needs inspection, ask for the result and constraints, not every low-level step. Anyy can search files, call tools, run approved commands, and report what it verified. Use detailed step-by-step instructions only when the order itself matters.

Sessions And Busy Turns​

Keep Long Work In One Session​

Sessions carry transcript, tool results, approvals, artifacts, and metadata. Resume the same session when the work is still the same thread:

anyy --resume SESSION_ID
anyy chat --session SESSION_ID "Continue from the last docs review."

Use /new when the topic has changed, /branch when you want to try an alternate direction, and /compress when a long session should continue with a smaller context window. See Sessions.

Choose Busy Behavior Deliberately​

In the TUI:

/busy queue
/busy steer
/busy interrupt

In messaging channels, use /queue to add a message behind the active turn and /btw to steer the running turn. /steer is an alias. Use /stop when the active turn should end before you redirect it. See Slash Commands.

Profiles, Roles, Memory, And Skills​

Use Profiles For Real Isolation​

Use separate profiles when data must not mix: personal vs. work, different channel accounts, different provider credentials, or different memory. A profile owns its own config, state database, sessions, memory, skills, channels, secrets, cron jobs, logs, and backups.

Use roles when you want a different persona or operating style inside the same profile. Roles share the profile's memory, skills, channels, providers, and gateway state. See Profiles and Roles.

Store Facts In Memory, Procedures In Skills​

Memory is for durable facts and preferences:

Remember that this repository keeps user-facing docs under docs-site/.

Skills are for repeatable procedures:

Create a skill for the release checklist we just ran.

Do not put task progress, temporary TODOs, raw links, or full transcripts into memory. Use session history/search for past work and skills for reusable "how to" knowledge. See Persistent Memory and Skills System.

Toolsets And Approvals​

Keep Toolsets Narrow​

Toolsets decide which tools are visible to the model. They do not make a tool trusted. A visible tool can still require approval, audit, confirmation, or a ChangePlan.

For ordinary sessions, edit toolsets.default only when you want the new default to apply to new sessions. Existing sessions keep the toolset metadata they already stored. For MCP, prefer anyy mcp add ... --activate-toolset or anyy mcp configure ... --activate-toolset so the matching mcp-<server> toolset is activated intentionally. See Toolsets.

Review ChangePlans Before Approval​

When Anyy proposes a risky operation, read the requested command or ChangePlan before approving it. Approvals are persisted and audited, and approved execution checks the plan hash before replay. Use "deny" when the plan is too broad or the rollback/validation story is missing. See Approvals & ChangePlans.

Long-Running Work​

Use Background Work For Finite Long Tasks​

For long agentic work, use a background child agent:

/background inspect the failing docs build and summarize the likely cause
/agents

For long shell work, Anyy can run managed background process jobs and then inspect them with /jobs, /job <id>, or the process tool. Managed jobs are session-scoped; they are not a general host process list. See Background Jobs.

Make Cron Prompts Self-Contained​

Scheduled work is not your current foreground chat. Put the instructions, sources, delivery expectation, and quiet-case behavior in the cron prompt itself:

Check the build status. If it is healthy, reply with one short status line. If
it is failing, summarize the failing step and the next action.

Use anyy cron list --include-disabled and automation_history when a job is not behaving as expected. See Automate With Cron.

Messaging And Operations​

Treat Channels As Resident Runtime Features​

Channels work through the resident gateway, not through one-shot CLI calls. After editing channel config, reload the gateway channel manager:

anyy channels reload
anyy channels doctor telegram

Start with allowlists or pairing before inviting a bot into broad group spaces. A channel policy controls who may reach Anyy; it does not bypass approvals, ChangePlans, or audit. See Set Up A Messaging Channel.

Keep A Small Operations Loop​

When something feels wrong, check the same few surfaces first:

anyy status
anyy doctor
anyy config

Create a backup before profile moves, risky config changes, or manual state edits:

anyy backup create
anyy backup list

Backups exclude profile secrets by default. Use --include-secrets only when you intend to handle the archive as sensitive credential material. See Backup And Restore.