Install the Anectico skills

A skill is a short set of instructions your agent loads when a task matches it. The Anectico skills teach an agent how to do a job with the Anectico CLI and MCP tools: which commands to run, in what order, and what to check before it answers. They are files on your machine, in the open Agent Skills format that Claude Code, Codex, Cursor and Gemini CLI all read. Nothing in a skill runs on Anectico's side.

The skills are part of the CLI. Each CLI version carries one pack of skills, and every command and tool a skill names is checked against that CLI version before it is released.

The skills

The pack has 23 skills: one foundation teaches the conventions that every job relies on, and 22 skills each teach one job. All 23 are ready to install. A skill marked no under "Installed today" is still being written: anectico skill install does not install it, and the table shows what it will need.

Skill	Installed today	The job	Credential	Scopes	Key bundle	Capability groups
anectico-cli	yes	Use the Anectico CLI and MCP tools by their conventions, and find the skill or command for a job.	OAuth connection or key	docs:read, errors:read, mcp:read, projects:read. Optional: activity:read, agents:content:read, agents:read, agents:write, alerts:acknowledge, alerts:read, alerts:resolve, alerts:rules:delete, alerts:rules:read, alerts:rules:write, analytics:query, analytics:read, analytics:sql, anomalies:delete, anomalies:read, anomalies:write, api_key:read, api_key:write, audit:read, channels:read, connections:read, connections:write, dashboard:read, errors:delete, errors:write, evals:write, export:write, findings:read, findings:write, github_config:read, github_config:write, groups:delete, groups:erase, groups:read, groups:write, incidents:delete, incidents:read, incidents:respond, incidents:write, ingest:write, ingestion:pipelines:write, insights:read, insights:write, llm:read, logs:delete, logs:read, mcp:write, members:read, members:write, metrics:delete, metrics:read, persons:correct, persons:erase, persons:profile:read, persons:read, quarantine:request, query:read, releases:read, releases:write, replay:content:read, replay:delete, replay:read, search:read, settings:delete, settings:read, settings:write, silences:delete, silences:read, silences:write, tickets:delete, tickets:read, tickets:write, traces:delete, traces:read, tracking_plans:delete, tracking_plans:read, tracking_plans:write	investigate	accounts, agent_activity, agent_budget, agent_governance, alerts, analytics, anomalies, connections, docs, errors, evaluation, export, findings, groups, incidents, instrumentation_recipe, llm_cost, log_metrics, logs, metric_watch, metrics, persons, quarantine, query, releases, replay, search, settings, tickets, traces, tracking_plan
anectico-setup	yes	Instrument an app, then verify the first trace and the first customer story.	OAuth connection or key	docs:read, errors:read, logs:read, mcp:read, persons:profile:read, persons:read, projects:read, query:read, settings:read, traces:read. Optional: agents:content:read, analytics:write, api_key:write, ingest:write, mcp:write	investigate	docs, errors, instrumentation, persons, projects, settings, traces
anectico-is-my-app-tracked	yes	A report of which telemetry arrives and what was not observed, labelled as observation.	OAuth connection or key	agents:content:read, analytics:read, logs:read, mcp:read, projects:read, query:read, traces:read, tracking_plans:read. Optional: mcp:write, persons:profile:read, persons:read, tracking_plans:delete, tracking_plans:write	investigate	analytics, coverage_declaration, instrumentation, traces
anectico-sources-and-export	yes	Connect and check intake sources, test log pipelines, manage connections and warehouse exports, and download frozen export jobs with approved changes.	API key	ingestion:pipelines:read, mcp:read. Optional: agents:content:read, analytics:read, api_key:read, connections:delete, connections:read, connections:write, errors:read, export:download, export:read, export:write, ingestion:pipelines:write, logs:read, mcp:write, metrics:read, persons:profile:read, persons:read, search:read, traces:read, warehouse:read, warehouse:write	investigate plus ingestion:pipelines:read	analytics, connections, export, ingestion_sources, warehouse_destination, warehouse_export
anectico-investigate-customer	yes	Answer what happened to one person, across every signal, with proof links.	OAuth connection or key	agents:content:read, agents:read, errors:read, logs:read, mcp:read, persons:profile:read, persons:read, replay:read, traces:read. Optional: analytics:query, analytics:read, dashboard:read, findings:read, findings:write, incidents:read, insights:read, mcp:write, metrics:read, projects:read, releases:read, replay:content:read, surveys:read	investigate	agent_runs, errors, findings, logs, persons, replay, traces
anectico-triage-issue	yes	Say who an error broke for, how badly, and the likely cause.	OAuth connection or key	errors:read, mcp:read, releases:read, replay:read, traces:read. Optional: agents:content:read, agents:read, analytics:read, dashboard:read, findings:read, findings:write, incidents:read, mcp:write, persons:read, projects:read, replay:content:read	investigate	errors, findings, replay, traces
anectico-reproduce-this	yes	Read one chosen failure's reproduction evidence, with every part's gaps stated.	OAuth connection or key	errors:read, mcp:read. Optional: agents:content:read, analytics:read, releases:read, replay:content:read, replay:read, traces:read	investigate	errors, replay, traces
anectico-which-change-caused-this	yes	Find the first release of an issue, the likely commits, and which of them touched the failing code.	OAuth connection or key	errors:read, mcp:read, releases:read. Optional: agents:content:read	investigate	errors
anectico-did-my-fix-work	yes	Declare an approved release fix, measure recovery for its affected people, and compare past recorded answers.	API key	agents:content:read, analytics:read, errors:read, errors:write, mcp:read, mcp:write, persons:read	investigate plus errors:write, mcp:write	analytics, errors, persons
anectico-product-question	yes	A measured answer to a product question, saved as an insight when the person asks, with the viewer link.	OAuth connection or key	analytics:query, analytics:read, insights:read, mcp:read, persons:read. Optional: agents:content:read, governance:read, insights:write, mcp:write	investigate	analytics, saved_insight
anectico-experiments-and-flags	yes	Product experiment readiness and outcomes, flag targeting, and cohort, account-segment and survey inputs.	API key	account_segments:read, analytics:read, experiments:read, flags:read, groups:read, mcp:read, surveys:read. Optional: account_segments:delete, account_segments:write, agents:content:read, cohorts:delete, cohorts:write, experiments:launch, experiments:write, flags:delete, flags:write, mcp:write, persons:profile:read, persons:read, surveys:write	investigate plus account_segments:read, surveys:read	accounts, analytics, cohort, cohorts, experiments, flags, surveys
anectico-dashboards-and-reports	yes	Read-only dashboard proof pages, exact saved-insight pins, and approved scheduled-report configuration and delivery.	API key	dashboard:read, insights:read, mcp:read, reports:read. Optional: agents:content:read, analytics:query, analytics:read, api_key:read, dashboard:delete, dashboard:write, groups:read, insights:delete, insights:write, mcp:write, members:read, persons:profile:read, persons:read, reports:write, surveys:read	investigate	analytics, dashboard, report_subscription, saved_insight
anectico-weekly-review	yes	A weekly product and reliability summary in which every claim has its number and its link.	OAuth connection or key	anomalies:read, errors:read, mcp:read, releases:read, services:read. Optional: agents:content:read, analytics:query, analytics:read, incidents:read, insights:read, metrics:read, persons:profile:read, persons:read, surveys:read, traces:read	investigate	analytics, anomalies, errors, incidents, persons, services
anectico-alerts-setup	yes	Alert rules and metric watches proposed from real traffic, validated, and created when the person approves them.	API key	alerts:read, alerts:rules:read, alerts:rules:write, channels:read, errors:read, evals:read, mcp:read, mcp:write, services:read. Optional: analytics:query, analytics:read, api_key:read, docs:read, event_destinations:read, event_destinations:write, incidents:read, insights:read, members:read, persons:read	investigate plus alerts:read, alerts:rules:write, channels:read, mcp:write	agent_destinations, alerts, analytics, channels, docs, errors, metric_watch, services
anectico-incident	yes	The record of one incident, kept at the person's request: opening, linked signals, updates, resolution and the retrospective.	API key	errors:read, incidents:read, incidents:respond, incidents:write, mcp:read, mcp:write. Optional: agents:content:read, alerts:read, channels:read	investigate plus incidents:read, incidents:respond, incidents:write, mcp:write	alerts, errors, incidents
anectico-oncall-and-escalation	yes	Resolve on-call selection, review and approve responder configuration, and trace incoming alerts and recorded notification delivery.	OAuth connection or key	channels:read, mcp:read, members:read, oncall:read, projects:read. Optional: channels:delete, channels:write, connections:delete, connections:read, connections:write, escalation:delete, escalation:read, escalation:write, incidents:delete, incidents:read, incidents:write, mcp:write, oncall:contacts:write, oncall:delete, oncall:write	investigate plus channels:read, members:read, oncall:read	channels, connections, escalation, incidents, notifications, oncall
anectico-uptime-and-status	yes	Read external check evidence and measured availability, configure approved monitors, and publish reviewed public status updates.	API key	mcp:read, monitoring:read, status:read. Optional: alerts:read, alerts:rules:delete, alerts:rules:read, alerts:rules:write, connections:read, incidents:delete, incidents:read, incidents:write, mcp:write, members:read, monitoring:delete, monitoring:write, oncall:read, projects:read, services:read, status:publish, status:write	investigate plus monitoring:read, status:read	alerts, incidents, monitors, services, status
anectico-agent-fleet-review	yes	A review of the customer's own agents: runs, failures, cost, stored quality scores and containment candidates.	OAuth connection or key	agents:read, evals:read, llm:read, mcp:read. Optional: activity:read, audit:read, metrics:read, persons:read, traces:read	investigate	agent_activity, agent_fleet, agent_governance, agent_runs, evaluation, llm_cost, metrics
anectico-evaluate-my-agents	yes	Score recorded agent work and compare exact evaluator, dataset, experiment and replay evidence.	OAuth connection or key	agents:read, evals:read, mcp:read. Optional: agents:content:read, agents:write, api_key:read, evals:write, mcp:write, members:read, scores:read, scores:write	investigate	agent_governance, agent_runs, agent_sessions, agent_telemetry, agents, evaluation
anectico-govern-my-agents	yes	Review agent inventory, authority and receipts, and apply only explicitly approved governance changes.	API key	agents:read, audit:read, mcp:read, quarantine:request. Optional: agents:write, mcp:write, quarantine:approve, usage:read	investigate plus audit:read, quarantine:request	agent_governance, audit_events, quarantine, receipt_chains, usage
anectico-workspace-admin	yes	Review workspace access, projects, plan and usage; propose administration changes for the person's approval.	API key	api_key:read, billing:read, mcp:read, members:read, projects:read, usage:read. Optional: analytics:write, api_key:write, billing:write, experiments:launch, ingest:write, mcp:write, members:write, projects:delete, projects:write, settings:write	investigate plus api_key:read, billing:read, members:read, usage:read	accounts, api_keys, billing, family_policy, invitations, members, projects, usage
anectico-privacy-controls	yes	Read privacy controls and consent limits, approve capture/disclosure/retention changes, bound diagnostic sampling, and erase or export one person's data with explicit reach and exclusions.	API key	governance:read, ingestion:pipelines:read, mcp:read. Optional: agents:content:read, agents:read, analytics:read, errors:read, evals:read, experiments:read, findings:read, governance:write, groups:read, ingestion:pipelines:write, logs:read, mcp:write, persons:erase, persons:export, persons:profile:read, persons:read, replay:read, scores:read, settings:write, surveys:read, traces:read	investigate plus governance:read, ingestion:pipelines:read	capture_settings, governance, instrumentation, persons, receipt_chains, settings
anectico-live-display	yes	Inspect, prepare and publish an approved Live display, pair its viewer and manage its secret viewing links.	OAuth connection or key	live:read, mcp:read, projects:read. Optional: alerts:read, analytics:query, analytics:read, api_key:read, api_key:write, errors:read, insights:read, live:publish, live:write, logs:read, mcp:write, members:read, persons:read, services:read	investigate	live

The same list, with the commands, flags and MCP tools each skill uses, is available from the CLI:

anectico skill list
anectico skill list -o json

anectico-cli

The foundation skill. It teaches what is the same for every job: the kinds of credential, project scope, JSON output and exit codes, pagination, confirmed writes, how to read a tool result and a refusal, when a result carries a proof link, and how to find a command with anectico docs. It ends with an index that says which job skill to load for which request. The job skills assume it. Print it with:

anectico skill show anectico-cli

anectico-setup

Use it to connect an app and check that data arrives. The agent instruments the app, sends one recognizable test, and asks Anectico whether the test was stored as one customer's story: an identified customer, a trace that carries that customer, and an error on that trace. It returns what is confirmed and what is not, check by check, with links to the customer, the trace and the issue. Verification reads only. A person holding api_key:write and the matching intake scope creates the keys. Before it writes the identify call, the skill tells the agent what Anectico replaces when it receives data, so that the app identifies customers by a stable id and not by an email; see What Anectico redacts and withholds.

anectico-is-my-app-tracked

Audits what a project sends. The agent reports which traces and logs were observed in a stated window, which product events arrived and how capture went, and, when the project has a tracking plan, how each declared event compares with what was stored.

Use it for questions such as "is my app tracked properly?" or "what is missing?".

It only reads, so an OAuth connection or a key is enough. The credential needs traces:read and logs:read as well as the analytics and tracking-plan scopes: a signal it may not read is reported as not checked.

The agent returns three lists: what was observed, what the plan declares and was not observed, and what arrived without being declared. "Missing" always means "not observed in this window". Anectico cannot see what an app did not send, and the skill tells the agent never to claim it. The audit has no proof page of its own; the agent can add a link to one trace that arrived.

anectico-sources-and-export

Use it to maintain an intake source, read its collection evidence, test and activate a log pipeline, inspect a saved connection, manage warehouse destinations and scheduled event exports, or download a frozen result. Configuration and queued work do not prove delivery. The agent shows the server's preview before an approved change, reads it back afterwards, and explains which credential or collector evidence is unknown. Files already sent to your bucket stay there. First SDK installation uses anectico-setup; app-wide tracking coverage uses anectico-is-my-app-tracked; a person's access archive is a privacy job.

anectico-investigate-customer

Use it for "what happened to this customer?". The agent finds the person, reads their events, errors, traces, logs, sessions and agent runs in time order, and opens the failures that matter. It returns the story in plain words, with a link to the person and to each failure, and says what it could not see. It reads only.

Use it also for "who is having a bad time?" when you have not named anybody. The agent first finds the people who crossed a threshold in the window (find_struggling_people), tells you why each one is on the list and what it could not measure, and then goes on with the first person or the one you choose. See Find who is having a bad time.

anectico-triage-issue

Use it for "which error matters, and how bad is it?". The agent ranks the issues by people affected, then reads one issue: who it broke for, since when, in which releases, whether it is still happening, and one occurrence end to end. It returns the impact with its numbers and window, the likely cause as a reading of the evidence, and links to the issue, the people and the trace. It reads only; it does not resolve or assign an issue.

anectico-reproduce-this

Use it for "help me reproduce this failure". The agent reads one occurrence's bundle first: the recorded request, trace, release, session steps and flags observed before the failure. It names each part's state and every gap. Typed inputs are placeholders. A captured request body cannot be linked safely to this failure. Flag exposures do not show every flag's state, and a reproduction is not guaranteed. It reads only and saves nothing.

anectico-which-change-caused-this

Use it for "which release or commit introduced this error?". The agent finds the first release the issue was seen in, the release before it, and the commits between the two. It returns the commit range and the deploy it points to, and marks a suspect commit as a lead from file history, not as the cause. When a GitHub repository is connected, it can also list which commits in the range changed the code that fails, from the two commit ids. It does not find the deployed range by itself. It reads only, and it needs releases on your telemetry.

anectico-did-my-fix-work

Use it after a fix is shipped. With your approval and a scoped write key, the agent declares which issue a release fixes. It then reads five outcomes for the original affected people: recovered, failed again, not seen, seen without outcome and not readable. A counted success must be on the fixed release or later; an event without a release uses the declaration time. Silence never counts. The answer states the original/readable/excluded denominator and the release/time split. It reads the past recorded answers too. Plain reads work through OAuth and save nothing; recording history is a separate approved write. Declaring a fix does not close the issue. See Did my fix work?.

anectico-product-question

Answers a product analytics question with a measured result. The agent reads the event names that really exist, reads the properties it needs, checks how the events were captured, and runs the measurement: a trend, a funnel, retention or another kind. Before it runs a wide or long measurement, it previews it: a preview shows what the server would refuse and which limits apply, and runs nothing. A preview reserves nothing and is not a quote, so the agent does not tell you that a measurement "will work". See Preview a measurement before you run it.

Use it for questions such as "how many people finished checkout last week?" or "where do people drop out of signup?".

It reads, so an OAuth connection or a key is enough. Saving the answer as an insight is the one step that writes: it needs an API key with insights:write and mcp:write, and the agent previews the save and applies it only after you confirm. To read your own property names the credential also needs agents:content:read.

The agent returns the numbers with their denominators, the exact window, the coverage and capture limits, and a link to the stored result in the result viewer. A stored result is kept for a limited time, and the result says until when.

anectico-experiments-and-flags

Use it to check a product experiment's readiness or result, test current flag targeting, and prepare cohorts, account segments and surveys as inputs. It separates current decisions from recorded exposures and interim counts from a final decision. Approved changes use the server preview when one exists. For immediate writes that have no server preview, the agent prepares the exact command for you to run and reads back the result. It never rolls out a winner by itself. Ad-hoc funnels, trends and survey measurements use anectico-product-question.

anectico-dashboards-and-reports

Use it for a dashboard a person will open as a read-only proof page, exact saved-insight widget pins, and scheduled reports. It reads configuration before proposing a change, shows the server's preview when available, and checks the result afterward. It keeps measurement windows separate from delivery schedules and distinguishes a destination accepting a report from a person reading it. Immediate writes without a server preview are prepared for you to run. Dashboard ownership and member-only delivery actions are explicit limits; an API key does not impersonate a member.

anectico-weekly-review

Writes a one-screen summary of the last seven days: the error issues and the people they reached, the people who had the worst week, the people who had a failure and have no matching report, service health, the releases first seen in the week, anomaly findings and incidents, and the counts of the main product events.

Use it for requests such as "give me the weekly review", "what broke this week, and for whom?" or "who hit a problem this week and did not tell us?".

It only reads, so an OAuth connection or a key is enough. Incidents need incidents:read and product event counts need analytics:read. The list of people who had the worst week needs persons:read, and it measures slow requests, click friction and slow pages only with traces:read, analytics:read and metrics:read. Without one of these the agent writes the rest and says which part it could not check.

For the people with a failure and no matching report, the agent uses find_silent_people. It says "no matching report in problem reports and survey answers this week" and names the sources it could not check. It does not say that a person stayed silent or is at risk of leaving. See Find who hit a problem and has no report.

Every claim in the summary has its number, and the issues, people and incidents have links to their proof pages. The skill tells the agent not to call a release the cause of an error, not to compare with a week it did not measure, and to report affected people as "at least", because only resolved people are counted, identified or anonymous. It also tells the agent that the worst-week list is a counting rule, not a judgement about how a person feels, and to say "too few people to rank" when the answer says so.

anectico-alerts-setup

Proposes alert rules and metric watches from the traffic a project really has, and creates the ones you approve. The agent reads the rules and notification channels that exist, reads service health and error issues for a baseline, and tells you for each proposed rule whether it would fire on current traffic. It validates a rule before it creates it.

Use it for requests such as "what should we alert on?" or "tell me when signups drop".

Creating or validating a rule needs an API key with alerts:rules:write. An agent connected through OAuth can read the traffic and hand you the proposal, and nothing more. A metric watch also needs the analytics scopes, because it measures a saved insight.

The agent returns each rule it created with its id and stored definition, who it notifies, and what it proposed and did not create. A new metric watch is always paused; starting it is your decision. The skill does not create notification channels: you choose where alerts go in the Console. Rules and alerts have no proof page; the links in the answer open the error issues the thresholds were taken from.

anectico-incident

Keeps the record of one incident: it opens the incident, links the alerts and error issues behind it, posts updates, acknowledges and resolves it, and drafts the retrospective. Each step happens when you ask for it. The agent never opens or resolves an incident by itself.

Use it for requests such as "open an incident for the checkout failures", "post an update" or "write the retro".

Every step except reading is a write, so the MCP job needs an API key with incidents:write and incidents:respond. Incident response is part of the Pro plan: on another plan the agent can read incidents, every write is refused, and the agent tells you the incident was not opened and why.

Opening and resolving an incident queue notifications for every enabled channel, and those messages cannot be recalled. Through MCP the agent shows you a preview first. The agent returns the incident with its status and a link to its proof page, what is linked, what it changed, and the impact it could observe with the source of each number.

anectico-oncall-and-escalation

Use it to resolve who is on call at a given instant, review escalation destinations, change responder configuration with approval, inspect runbooks and incoming alerts, and read notification receipts. It separates schedule selection, sender acceptance and a person's acknowledgement. Creates without a server preview are handed to the person. The incident and alerts-setup skills own response records and alert rules.

anectico-uptime-and-status

Use it for external checks, heartbeat jobs, availability evidence and public status updates. It separates unknown coverage from measured uptime and a private draft from a published page. Changes with a preview need the person's approval of the server's returned values. Draft operations without a write preview are handed to the person. Use the incident skill for the internal response record.

anectico-agent-fleet-review

Reviews your own AI agents, the ones that run inside your product: which agents ran in the last 24 hours, how many runs failed and with what reason, what the model calls cost by agent, which quality scores are stored, and what is open in the review queue.

Use it for requests such as "how are our agents doing?" or "which agent is failing?".

It only reads, so an OAuth connection or a key is enough. The credential needs agents:read, llm:read for cost and evals:read for stored quality scores. The default investigate key bundle includes all of them, plus the person and trace reads for the spend breakdown. Reading a stored score does not run an evaluation.

The agent returns runs and cost per agent, each failed run with a link to its proof page, and the stored scores with the evaluator version that produced them. When no score is stored it says "no score", never "passed". It names the agents that deserve a person's attention and stops there: the skill never contains an agent. A containment needs two different people, as described in Contain an agent.

anectico-evaluate-my-agents

Use it for "was this run scored?", "did our challenger improve quality?" or "does the evidence meet our release bar?". It reads exact evaluator versions, stored scores, frozen cases, comparisons, gate decisions and session evidence. A missing score stays unknown; a completion score measures the rule's assertions, not every aspect of quality. Fleet ranking and spend remain in the fleet review.

Scoring, recording a judgment, changing sampling and starting a real session replay are separate decisions. The agent shows the server's preview, confirms only after you approve, then reads back. A frozen replay is a read. A real replay exports a person's recorded words to the selected agent. Setup writes that offer no server preview are handed to you. The default investigate bundle covers core reads; content and optional changes need the additional scopes listed above.

anectico-govern-my-agents

Use it for "which agents exist and what may they do?", "did containment take effect?" or "what does this action receipt prove?". It reads declared and discovered inventory, authority, review signals, containment, receipts, signatures, configuration declarations and the audit trail. A pending request enforces nothing. An active containment still needs its individual enforcement results checked.

Changing inventory, approving or lifting containment and sending one message need your decision and the server's preview. Approval uses a different person's credential from the requester. A valid receipt chain checks retained consistency; it does not prove a reported external action happened. The default investigate bundle additionally needs audit:read and quarantine:request for this job. Operation budgets stay in the foundation skill. The job reads current family policy and usage; approved retention changes belong to anectico-workspace-admin.

anectico-workspace-admin

Use it to review members and invitations, key scopes, projects, billing and usage. It keeps a page of access records separate from a total, and a monthly usage snapshot separate from a live counter. It shows the server's actual preview before a confirmed administration change.

The person supplies the required authority. The agent never promotes itself, widens its own key or raises its own budget. Where the current operation has no server confirmation preview, the skill explains that limit and hands the immediate call to the person. Billing needs an organization-wide credential; a selected project does not narrow organization usage.

anectico-privacy-controls

Use it to read capture and disclosure controls, explain withholding, approve privacy changes, or request one person's erasure or access archive. It separates application consent from the project's capture ceiling and a stored retention setting from a completed purge. Erasure needs your separate approval of the server's identity preview, permanent fences and stated exclusions. An archive's manifest and freshness say what it includes; neither operation promises that every backup, unlinked mention or exported copy is covered. See Content policy, Erase a person and Export a person.

anectico-live-display

Use it to inspect or prepare a Live wall, phone or tablet display, publish an approved composition, pair the viewer and manage its viewing links. It distinguishes a draft version from a publication revision, a grant from a viewer count, and unknown grant state from zero links.

The person approves the server's disclosure preview before publication or another confirmed change. The viewing link is a secret, handed over privately and never recorded. Read-only access works with the default investigate bundle; editing and publishing need the specific extra permissions and a suitable project key. An immediate call without a server preview is handed to the person. See Put a project on a live screen.

Install

anectico skill install claude
anectico skill install codex
anectico skill install cursor
anectico skill install gemini
anectico skill install muse

The command writes one folder per skill, each holding a SKILL.md, into the directory your agent reads skills from:

Agent	Your home directory (default)	This repository (--project)
Claude Code	~/.claude/skills	.claude/skills
Codex	~/.agents/skills	.agents/skills
Cursor	~/.cursor/skills	.cursor/skills
Gemini CLI	~/.gemini/skills	.gemini/skills
Muse Code	~/.agents/skills	.agents/skills

Muse Code and Codex read the same folder, so one install serves both, and skill remove for one removes the skills for the other. Meta documents this folder for Muse Code, but Muse Code itself has not been tested here.

Use --project to install into the repository you are in, so the skills can be committed and shared with your team. Use --dir <path> if your agent is configured to read skills from another directory.

Running the command again changes nothing. Cursor also reads the Claude Code and Codex directories, so if you install for more than one agent on the same machine, Cursor lists each skill more than once with the same text.

anectico agent bootstrap --host <agent> installs the skills as one of its steps, so you do not need to run both.

Check, upgrade and remove

Beside the skill folders the CLI keeps an install record, .anectico-skills.json. It holds the pack version and a content hash for every file the CLI wrote. That record is how the CLI tells its own files from yours.

anectico skill status claude
anectico skill upgrade claude
anectico skill remove claude --yes

status writes nothing. It reports each skill as one of:

State	Meaning
up_to_date	The files are exactly what this CLI version writes.
outdated	An earlier CLI version wrote the files and they have not changed since.
modified	The files were edited after the CLI wrote them.
missing	The install record names the skill, but its files are gone.
not_installed	The skill is in the pack and was never installed here.
unmanaged	A folder with the skill's name exists and the CLI has no record of writing it.
retired	The install record names a skill that the pack no longer contains.
blocked	A symbolic link, or something that is not a regular file, is in the way.

upgrade replaces outdated skills, adds skills that have been released since you installed, and removes retired ones. Run it after you upgrade the CLI. It does not overwrite a skill you edited. It reports that skill as refused, upgrades the rest, and exits with code 1. Pass --force to overwrite it; your edits are then lost.

remove needs --yes, like every command that deletes. It deletes the files the install record lists, then each skill folder that is left empty, then the record. It never touches a skill folder that the record does not name, and a file you added to one of the Anectico folders stays. A skill you edited is kept, reported as refused, unless you pass --force.

Three safety rules apply to all four commands:

• The CLI writes only inside the skills directory.
• It never reads or writes a skill file through a symbolic link. If your skills directory is itself a link, name the real directory with --dir.
• If the install record is damaged, status says so, install rebuilds it, and remove deletes nothing until it has been rebuilt.

With -o json, each command prints one report object: the agent, the directory, the state of the install record, and for each skill its state and the action taken (installed, updated, unchanged, removed or refused). A refusal exits with code 1 and still prints the report.

Credentials

Every installed skill ends with a "Credential and permissions" section that states what the job needs. There are two kinds:

• An OAuth connection is enough. The job only reads. An agent that you connected by signing in can do it with its MCP tools. To run the skill's anectico commands, the CLI needs its own credential with the same scopes: your anectico login session, or an API key in ANECTICO_API_KEY.
• An API key is required. The MCP job changes something, for example it saves an insight, creates an alert rule or opens an incident, or needs reads outside the OAuth ceiling. A member with api_key:write can create a key carrying only scopes they hold. A human CLI session can make changes within that person's permissions.

Some jobs read, and have one step that writes. Answering a product question reads; saving the answer as an insight writes. For these the Scopes column lists the scopes the job needs, then, after "Optional", the scopes that only such a step needs. Without an optional scope the agent does the rest of the job and says which step it skipped and why.

The "Key bundle" column names the key bundle that covers a skill's required scopes, and any scopes to add by name. For example, the default investigate bundle reads issues, people, logs and traces and model costs, but it cannot save an insight or create an alert rule. To create a key that can also save an insight, a person holding api_key:write and the requested scopes runs:

anectico apikey create --scope-profile investigate --scope insights:write --scope mcp:write --expires-in 30d

When a command exits with code 4, or a tool is missing from the agent's tool list, the credential lacks a scope. The skill tells the agent to stop, name the missing scope and ask for a key that has it, and not to work around the refusal. See Scope recipes for the bundles and Permissions and safety for what each kind of credential can do.

The foundation skill has a subject-indexed reference for supported operations that do not have a dedicated job skill. Read only the subject needed for the request. The reference teaches each operation’s purpose, exact permissions, preview and confirmation, and read-back checks. Its optional scope list is the union of separate jobs, never a recommended key grant. Choose only the row the person asked for. Budget changes need the owner's approval, and an agent must never raise its own budget. Destination changes likewise need the owner's approval before delivery, subscription, state or signing-secret changes.