$npx -y skills add pixee/pixee-cli --skill pixee-preferencesRead and write Pixee organization preferences from files or stdin with optimistic concurrency handled by the CLI.
| 1 | # pixee organization preferences |
| 2 | |
| 3 | > **PREREQUISITES:** Read `../pixee-shared/SKILL.md` for global flags, exit codes, and error |
| 4 | > handling, and `../pixee-auth/SKILL.md` if authentication needs to be configured. |
| 5 | |
| 6 | Organization preferences are a freeform markdown blob (≤10,000 characters) that the Pixee |
| 7 | platform applies to every analysis run for the organization. The content shapes both *triage* |
| 8 | (is a given finding a real risk for this org?) and *remediation* (how should the fix look in |
| 9 | this codebase?), and is stored as a single document with audit metadata: `content`, |
| 10 | `updated_at`, `updated_by`, `org_id`. The MVP hardcodes `org_id` to `default-organization`; |
| 11 | an `--org-id` flag is planned once the platform supports multi-org. |
| 12 | |
| 13 | ## pixee organization preferences get |
| 14 | |
| 15 | ``` |
| 16 | pixee organization preferences get [--content-only] |
| 17 | ``` |
| 18 | |
| 19 | - Default text output: a two-line `Org: <id>` / `Updated: <iso> by <actor>` header (colon |
| 20 | separated, no tabs, because the markdown body is multiline and tabs are reserved for list |
| 21 | commands), a blank line, then the `content` body emitted verbatim with no synthetic |
| 22 | trailing newline. |
| 23 | - `--content-only` prints the body alone, byte-for-byte. Designed for piping into a file, |
| 24 | `less`, `bat`, or a diff tool. No header, no trailing newline added. |
| 25 | - `--output json` (or `--json`) emits the full record including the HAL `_links` envelope. |
| 26 | See `../pixee-api/SKILL.md` for HAL conventions; do not restate them in scripts. |
| 27 | - When no preferences have ever been set, the command exits 0 with no stdout and writes a |
| 28 | single line to stderr: `no organization preferences set`. Branch on this for |
| 29 | fresh-organization flows. |
| 30 | |
| 31 | ## pixee organization preferences set |
| 32 | |
| 33 | ``` |
| 34 | pixee organization preferences set (--from-file <path> | --content <string>) |
| 35 | ``` |
| 36 | |
| 37 | - Exactly one of `--from-file` or `--content` is required; passing both, or neither, is a |
| 38 | parse error (exit 1) before any network call. |
| 39 | - `--from-file -` reads `content` from stdin, enabling get-transform-set pipelines. |
| 40 | - Content over 10,000 characters is rejected client-side before the round-trip with the |
| 41 | observed character count in the error. |
| 42 | - Optimistic concurrency is handled internally: the CLI performs a GET, then PUTs with |
| 43 | `If-Match: <etag>` (or `If-None-Match: *` on first creation). Agents and scripts never |
| 44 | touch ETag headers directly. |
| 45 | - On HTTP 412, the CLI exits 1 with a friendly stderr line: |
| 46 | `concurrent modification: another writer updated organization preferences between read and |
| 47 | write; re-run to refresh`. Re-running typically succeeds; if multiple writers race |
| 48 | repeatedly, refresh and re-author against the latest content. |
| 49 | - On success, output mirrors `get` (default header + body in text mode, full record in JSON |
| 50 | mode). |
| 51 | |
| 52 | ## Precedence and scope |
| 53 | |
| 54 | Pixee resolves preferences per-analysis with strict fallback, no merging: |
| 55 | |
| 56 | 1. If the repository has `PIXEE.md` at its root (even if empty), it is used exclusively. |
| 57 | 2. Else if organization preferences exist with non-empty `content`, they are used. |
| 58 | 3. Else the analysis runs without preference guidance. |
| 59 | |
| 60 | An empty `PIXEE.md` is a deliberate opt-out: a repo with one is treated as having |
| 61 | preferences, which silently shadows org preferences for that repo. Agents working in a |
| 62 | specific repo should check for `PIXEE.md` before assuming org preferences will apply. |
| 63 | |
| 64 | Humans can author preferences in the Pixee web app under an organization's |
| 65 | *Settings → Preferences*; the CLI and the web UI write the same resource. |
| 66 | |
| 67 | ## Writing effective preferences |
| 68 | |
| 69 | Preferences come in three flavors: |
| 70 | |
| 71 | - **Remediation guidance.** How the team prefers to fix specific vulnerability classes: |
| 72 | preferred libraries, internal utility classes, code patterns to use or avoid. |
| 73 | - **Triage context.** Why a finding may not be a real risk here: deployment architecture, |
| 74 | compensating controls (WAF, network isolation, MFA), intentional patterns, false-positive |
| 75 | zones. |
| 76 | - **Rule preferences.** Enable or disable specific scanner rules by tool name and rule ID, |
| 77 | including marking rules as remediable when Pixee should attempt an automatic fix. |
| 78 | |
| 79 | For worked examples of each flavor, see [`references/preferences-authoring.md`](references/preferences-authoring.md). |
| 80 | Treat those examples as starting points and adapt them to the org's stack, tone, and |
| 81 | compliance posture. |
| 82 | |
| 83 | ## Examples |
| 84 | |
| 85 | ```bash |
| 86 | # Print the body verbatim, suitable for piping into an editor or less |
| 87 | pixee organization preferences get --content-only |
| 88 | |
| 89 | # Pretty-print the record as JSON, then pull a single field with jq |
| 90 | pixee organization preferences get --json | jq -r '.updated_by' |
| 91 | |
| 92 | # Walk to the canonical resource via HAL (do not hardcode the path) |
| 93 | href=$(pixee organization |