pass-cli is aimed at automation and agent workflows, but it currently forces agents to make a choice between guessing blind and over-exposing secrets:

1. item view (human format) renders secret fields as Hidden("<full plaintext value>"). The type system clearly knows the field is Hidden — it just doesn't redact it. Default output should be Hidden(<redacted, N chars>), with an explicit --reveal (or the existing --field X) opting into the value. That one change makes bare view a safe discovery command: field names, note, and attachment metadata are exactly what a script needs to learn before requesting a specific value. --output json has the same problem and the same fix.

2. There is no other discovery path. item list returns no field or attachment info, there's no describe-item command, and a wrong --field guess returns only Field does not exist: X — no hint of what fields do exist (field names are metadata, not secrets). An item whose only secret is a file attachment has zero fields, so every --field attempt fails identically with nothing pointing at the attachment. Callers today must pull the full plaintext item and build their own redaction just to learn a field name — the opposite of what a secrets manager should encourage.

3. item attachment download is the one command that refuses friendly selectors. Everything else accepts --vault-name/--item-title; attachment download demands raw --share-id/--item-id/--attachment-id, which are only discoverable via the unredacted JSON view. It should accept the friendly selectors plus --file-name.

4. Onboarding: pass-cli agent instructions emits the session token in plaintext inside the markdown it tells users to paste to an agent. Convenient, but it normalizes putting a live credential into a chat transcript — the exact anti-pattern a password manager should design against. The instructions should reference an env var or keychain path, never the token value itself.