/traceway-write

name: traceway-write
description: 'Operate a Traceway instance with write access. Use when the user wants an agent to change something in Traceway: archive or unarchive issues, acknowledge or resolve on-call pages, snooze, enable or disable alert rules, run a monitor now, create or edit a post-mortem, or mark an endpoint as expected-slow. Requires the separate traceway-write CLI or the /mcp/write server, a write credential, and an organization admin who turned on agent writes.'

<!-- GENERATED FILE: assembled from cli/pkg/mcpserver/knowledge by cli/tools/skillgen. Edit the chunks there and run just gen-skills in cli/. -->

Traceway with write access

This skill drives the `traceway-write` CLI (or the write MCP server) to make the routine changes an on-call engineer makes: archive issues, acknowledge and resolve pages, snooze or toggle alert rules, run monitors, write post-mortems and mark slow endpoints.

To explain how a part of Traceway works before or after a change (what acknowledging a page does to escalation, how a snooze differs from disabling a rule, how a monitor opens an incident), use the `traceway-learn` skill. It is the full product guide. Over MCP the same guide is the `traceway://knowledge/learn` resources.

For pure investigation (debugging an issue, latency analysis), the read-only `traceway` skill has the deeper playbooks. Its commands work the same way here: every read command of `traceway` also exists in `traceway-write`.

> If a `traceway-write` MCP server is connected (stdio `traceway-write mcp`, or `https://<instance>/mcp/write`), prefer its tools over shelling out. Its resources carry this skill's knowledge, and its tool names are listed in the table below.

Setup

1. Install the write CLI

`traceway-write` is a separate binary with its own login, so a read-only `traceway` install can never be upgraded to write in place.

curl -fsSL https://cli.tracewayapp.com/install.sh | sh -s -- --write
traceway-write version

Prebuilt archives are on the [releases page](https://github.com/tracewayapp/traceway/releases) under `cli/vX.Y.Z` tags as `traceway-write_<version>_<os>_<arch>.tar.gz`. From source: `cd traceway/cli && go build -tags write -o bin/traceway-write ./cmd/traceway`.

2. Log in with write access

Ask the user to run the browser login themselves (in Claude Code: `! traceway-write login --url https://<instance>`). The approval page says the login asks for read and write access.

traceway-write login --url https://<instance>

Headless alternative: the user creates a **Read and write** personal access token (Account > Personal Access Tokens, prefix `tww_`, expires within 90 days) and stores it without echoing it:

printf '%s' "$TRACEWAY_WRITE_TOKEN" | traceway-write login --url https://<instance> --token-stdin

A read token (`twp_`) stored in `traceway-write` still cannot write: the server refuses every write with "This credential is read-only".

3. Organization opt-in

An organization owner or admin must turn on **Settings > Agent Access > Allow agent writes**. Until then writes answer 403 "Agent write access is turned off for this organization". Do not try to work around it: tell the user who can turn it on.

4. Select a project

traceway-write projects list
traceway-write projects use <project-id>

MCP instead of the CLI

• Local stdio: `claude mcp add traceway-write -- traceway-write mcp` (uses the `traceway-write login`).
• Remote: add `https://<instance>/mcp/write` as an HTTP MCP server. The client runs OAuth and the consent page asks for read and write access. The plain `/mcp` server never exposes write tools, even to a write token.

Operating with write access

Write access lets an agent take the routine actions an on-call engineer takes during and after an incident. It is opt-in at three levels, and every level has to agree before a write goes through:

1. **The credential.** Only write credentials can write: a `tww_` personal access token, a `traceway-write login`, or an MCP client connected to the `/mcp/write` server. A `twp_` token, a `traceway login` and the `/mcp` server are read only, whatever the person's role. 2. **The organization.** An admin has to turn on Settings > Agent Access. Until then every agent write is refused with a 403 that says so. 3. **The person.** The write runs with the role of the person who created the credential, under the same rules as the dashboard. A `readonly` member's write token cannot archive issues, change alerts, run monitors or edit post-mortems. Acknowledging and resolving pages needs no write role, so any member's write token can do that.

Every write a write credential makes in the organization, accepted or refused because Agent Access is off, is recorded in the organization's agent activity log with the person, the credential, the project and the result.

What an agent can change

| Action | CLI (`traceway-write`) | MCP tool | Reversible | |---|---|---|---| | Archive or unarchive issues | `exceptions archive <hash>...` / `unarchive` | `archive_exceptions` / `unarchive_exceptions` | Yes | | Acknowledge a page | `pages ack <id>` | `acknowledge_page` | No, but harmless: it only stops escalation | | Resolve a page | `pages resolve <id> [--archive-issue]` | `resolve_page` | No | | Enable or disable an alert rule | `alerts enable <id>` / `alerts disable <id>` | `set_notification_rule_enabled` | Yes | | Snooze an alert rule | `alerts snooze <id> --minutes N` (0 clears) | `snooze_notification_rule` | Yes, it expires on its own | | Run a monitor now | `monitors run <id>` | `run_check` | Nothing to undo | | Write a post-mortem | `post-mortems create` / `update <id>` | `create_post_mortem` / `update_post_mortem` | Edits are kept in the activity log | | Mark an endpoint expected-slow | `endpoints mark-slow <endpoint> --offset-ms N --reason ...` (0 removes) | `set_slow_endpoint` | Yes |

Everything else (creating rules and channels, editing