بنقرة واحدة
keeper
Passwords, credentials, vault, 2FA/TOTP via Keeper; store, retrieve, manage.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
القائمة
Passwords, credentials, vault, 2FA/TOTP via Keeper; store, retrieve, manage.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Use for any Microsoft account, personal or work (Outlook.com, Hotmail, Live, Microsoft 365); preferred over email-client for Microsoft accounts. Graph-based mail (read/send/reply/forward, drafts, flag/categorize, move/archive, folders, attachments, block senders), calendar and meetings, Microsoft Teams (chats, channels, presence), and new-mail/Teams notifications. Requires daemon.
Browse, navigate, click, fill forms, screenshot, or scrape web pages with a stealth (Camoufox) browser.
Design judgment and UI copy for building Vesta dashboard widgets that feel considered rather than templated, within the fixed design system.
Use before building or modifying the user's dashboard: widgets, pages, layouts, custom UI. Understand what the user wants, design it, write a spec, then dispatch the dashboard-builder to build it.
Use when someone who doesn't have their own vesta asks what vesta is, how to get one, or hints they want in. Vesta is invite-only: you gatekeep and build desire through scarcity, draw out what they want, then sell vesta as indispensable to their goals and set them up end-to-end in chat. Not for the owner, who already has one.
Talk to vestad, the host daemon that runs this container. Register a background service to get a port, build public URLs, update vestad to the latest release, check its version, and read gateway logs. Use when a skill needs an inbound port or a shareable link, when the user asks to update Vesta, or when debugging gateway/container issues.
| name | keeper |
| description | Passwords, credentials, vault, 2FA/TOTP via Keeper; store, retrieve, manage. |
All commands are run as one-shot calls from bash (not inside the interactive shell):
keeper "command here"
Setup: See SETUP.md
keeper "l" # list all records
keeper "l twitter" # filter by keyword
keeper "search dropbox login" # search by partial words
keeper "search aws --format json" # JSON output
keeper "get <UID>" # display record details
keeper "get <UID> --unmask" # show full record with passwords in plain text
keeper "get <UID> --format json" # JSON output
keeper "get <UID> --format password" # show only the password
keeper "find-password <UID>" # print just the password
Note: unmask is NOT a subcommand. keeper "unmask <UID> password" does not exist and will fail. Unmasking is the --unmask flag on get, or use find-password to get the password on its own.
keeper "clipboard-copy <UID>" # copy password to clipboard
keeper "clipboard-copy <UID> -l" # copy username
keeper "clipboard-copy <UID> -t" # copy TOTP code
keeper "clipboard-copy <UID> --field url"
keeper "record-add --title 'Gmail' --record-type login login=user@gmail.com password='\$GEN:rand,20' url=https://accounts.google.com"
keeper "record-add -t 'Server' -rt serverCredentials host='\$JSON:{\"hostName\":\"10.0.1.50\",\"port\":\"22\"}' login=admin password='\$GEN:rand,24'"
Record types: login, bankAccount, bankCard, serverCredentials, sshKeys, databaseCredentials, encryptedNotes, softwareLicense, membership, contact, address, wifiCredentials
Password generation: $GEN:rand,<length> (random), $GEN:dice,<words> (diceware)
keeper "record-update -r <UID> --title 'New Title'"
keeper "record-update -r <UID> login=new_user password='\$GEN:rand,20'"
keeper "record-update -r <UID> --notes 'Updated notes'"
keeper "rm <UID> -f" # -f skips confirmation
keeper "trash list" # list deleted records
keeper "trash restore <UID>" # restore from trash
keeper "ls" # list current folder
keeper "ls -l" # detailed listing
keeper "tree" # full folder tree
keeper "mkdir finance/personal" # create folder
keeper "mkdir 'Team Secrets' -sf" # create shared folder
keeper "mv <UID> social" # move record to folder
keeper "totp" # show all TOTP codes
keeper "totp <UID>" # TOTP for specific record
keeper "share-record <UID> -e user@example.com"
keeper "share-record <UID> -e user@example.com --action grant -w -s"
keeper "share-record <UID> -e user@example.com --action revoke"
keeper "one-time-share create <UID> -e 1h"
keeper "generate" # default
keeper "generate -c 20" # 20 characters
keeper "generate -c 16 -u 3 -d 3 -s 3" # 16 chars, 3 upper, 3 digits, 3 special
keeper "generate -dr 6" # diceware passphrase (6 words)
--format json on most commands for machine-readable output-f on destructive commands (rm, delete) to skip interactive confirmation[Records the user accesses often]
[How the user organizes folders and records]
Doing a vault cleanup pass, a few CLI edges to know:
record-update on a type=general (legacy) record errors "Legacy record type is not supported." Fix: record-add a fresh login-type copy (login/password/url), get <uid> --unmask to VERIFY the password copied, mv to the folder, then rm <old> -f. Verify BEFORE deleting the original.$ or !) break single-quoting in the record-add command string ("No closing quotation"). Use double-quotes and escape the dollar sign, e.g. password="p@ss\$w!rd". Verify after.-KomRZ...): rm parses the leading - as a flag. Use rm -f -- <uid> (the -- ends flag parsing).find-duplicate misses same-service fragments under identical titles, so also scan by title. "Never delete the copy with a unique password" is only half a rule: obeyed alone it means any duplicate holding unique data is protected FOREVER, so the clutter accrues (seen in the wild: one service sat at 3 records for months, one of which held nothing but a PIN). The rule is move the unique value first, then delete. Procedure: (1) pick the survivor = whichever record holds something IRREPLACEABLE, e.g. a passkey cannot be recreated by editing, so it always wins over a record holding only copyable text; (2) copy every unique field off the others onto the survivor (--custom for values, --notes for context); (3) VERIFY each value reads back on the survivor (see the --format json note below); (4) ONLY THEN delete the drained ones. Never delete before the value is confirmed on the survivor.
bankCard record, don't fold them into a login. The type gives structured card autofill that a login record can't, so "one service = one record" has this deliberate exception.pinCode meaning a 6-digit app passcode on one record and a 4-digit physical card PIN on another. Label them in the merged record. Never assume two same-named fields are the same secret, and if a user asks for "the PIN" when two exist, give both labelled rather than guessing.--format json, NOT grep on the keeper get display: after record-update, the human-readable output can show a STALE or wrong value for a field (masking, formatting, or label collision), reading as a false "update failed" when it actually succeeded. Confirm by reading the field from keeper get <uid> --format json (walk fields[] for the matching type) and check that client_modified_time/revision bumped.record-update "password=<val>" splits on the FIRST = and treats a leading $GEN: specially: values containing = or starting with $ get mangled silently (exit 0, no visible change until re-checked via JSON). For a value you control, prefer alphanumeric-only (keeper generate --symbols 0), and for arbitrary values use a data file.general-type records: set a field with keeper edit -r <uid> --pass <val>, NOT record-update: record-update on a legacy record errors "Legacy record type is not supported." The deprecated edit --pass still works and takes the value as plain argv (so commas, $, |, [] are safe, with no field-string parsing). Verify with keeper get <uid> --unmask. Simpler than the record-add-a-login-copy migration when you only need to set one field.