op
Skill1 starsChanged 4 months agoApache-2.0View on GitHub
Use when reading, searching, editing, tagging, moving, or bulk-updating 1Password items, vaults, or secret references with the `op` CLI, or when `op` reports "account is not signed in" or "multiple accounts found".
In this repository19 other files it gives its agents.
- AGENTS.mdAGENTS.md
- agent-aeoSkill
- agent-memorySkill
- beanquerySkill
- ci-repairbaySkill
- delegated-developmentSkill
- ghSkill
- issue-blueprintSkill
- issue-workbenchSkill
- minifluxSkill
- og-imageSkill
- pencil-to-figma-migrationSkill
- pr-comment-sweepSkill
- pr-launchpadSkill
- repo-surveyorSkill
- review-checkpointSkill
- review-repairbaySkill
- shipyardSkill
- skill-optimizerSkill
The file
We split this skill into the rules it gives an agent
5 rules. About 0 are common, 2 are distinctive, and 3 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
Distinctive · estimate
This author's own choices. Worth a look.
3
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 12
Run op account list. With more than one account, pass --account <sign-in address> on every command or set OP_ACCOUNT.
- Very specific: line 14
Run op <command> --help before using a flag you have not verified.
- Distinctive: line 27
Use item IDs, not titles. Titles are not unique.
- Distinctive: line 43
After each write, read the item again and compare the changed fields.
- Very specific: line 56
Use / for nested tags, for example home/nas.
≈ “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.
Files
op
op is the 1Password CLI. Items hold secrets, so every command either reads metadata, reads secrets, or rewrites an item. Pick the narrowest one and keep secrets out of arguments, files, and output.
Connect
- Run
op account list. With more than one account, pass--account <sign-in address>on every command or setOP_ACCOUNT. - "account is not signed in" while the desktop app is unlocked means the sandbox blocks the app integration socket. Rerun outside the sandbox; do not run
op signinfor it. - Run
op <command> --helpbefore using a flag you have not verified. Trust live help over memory.
Read
| Need | Command | Secrets in output |
| Inventory: id, title, vault, category, tags, URLs | op item list --format json | No |
| Filter server-side | --vault, --tags, --categories, --include-archive | No |
| One item, all fields | op item get <id> --format json | Concealed unless --reveal |
| One value | op read 'op://<vault>/<item>/<field>' | Yes |
| Secrets into a process or file | op run, op inject | Only to the target |
- Save the
op item listoutput once to a scratch file and filter it withjq. It holds no secrets, and it saves one API call per item. - Use item IDs, not titles. Titles are not unique.
- Match IPs and hosts with boundaries, for example
(^|[^0-9])10\.0\.0\.3([^0-9]|$). A plain substring also matches110.0.0.3.
Write
| Change | Command | Effect |
| Title, primary URL, favorite | op item edit <id> --title/--url/--favorite | --url sets only the primary URL |
| Tags | op item edit <id> --tags a,b | Replaces all tags. Merge with current tags first |
| Built-in or custom field | op item edit <id> 'section.field[type]=value' | Arguments are visible to other processes. No secret values here |
| Secondary URLs, many fields, secrets | op item get <id> --format json | jq '<change>' | op item edit <id> | Replaces the whole item from JSON |
| Vault | op item move <id> --current-vault A --destination-vault B | New item ID. Changes who has access |
| Preview | add --dry-run to op item edit | No change |
- Pipe JSON, do not write it to disk:
op item getJSON contains secret values. - JSON edits overwrite passkeys.
opcannot show if an item has a passkey. Before a JSON edit on a login that can have a passkey, ask the user, or use flag edits. - After each write, read the item again and compare the changed fields. Item history in the app restores a bad edit.
Bulk changes
- Inventory once, filter with
jq, and show the list of item IDs and the planned change. - Get approval before you edit, move, or delete items in bulk. Moves and deletes change IDs and access.
- Apply each change to one item ID at a time, in sequence. Parallel writes to one vault fail with
(409) Conflict. Each edit takes 2-11 s, so run long batches in the background with a log. - Re-run the inventory filter against live
op item listoutput. It must return no remaining matches. Retry only the items that differ.
The CLI cannot edit SSH Key items ("SSH Key item editing in the CLI is not yet supported") or items with a "Sign in with" field ("unsupported field type: ssoLogin"). List these for the user to change in the app.
Tags
- Use
/for nested tags, for examplehome/nas. The app shows them as a tree. - Tags group items across vaults. Vaults control access and sharing. Use vaults for who can see an item, and tags for what it is.
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
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.