원클릭으로
pixee-integration
List Pixee integrations to discover the id, type, and capabilities of each scanner integration registered with the org.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
메뉴
List Pixee integrations to discover the id, type, and capabilities of each scanner integration registered with the org.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Describe the global flags, output format, exit codes, error handling, and TLS trust troubleshooting used by every Pixee CLI subcommand.
List, view, and delete Pixee analyses with filters and optional polling until the analysis reaches a terminal state.
List, view, analyze, create, and delete Pixee scans with filters for repository, branch, detector tool, and analysis state.
List, create, update, run, and delete Pixee workflows on a repository with partial-update semantics across event kinds.
List, view, and delete Pixee repositories with shared name-or-UUID resolution used by every targeted subcommand.
Detects and closes drift between the latest released Pixee CLI surface and the published `skills/pixee-*` skills on `origin/main`. Trigger after a new pixee release, on a `/audit-skills` request, or when the contributor asks 'are the skills up to date?', 'is there a missing pixee skill?', 'does the CLI match the skills?', 'check skill drift', or 'do we need to update the skills for vX.Y.Z?'. Always audits against `origin/main` (the source of truth for what users see), never the local working tree. Produces a structured drift report first, then files DevRev issues in CAPL-44 and hands each one to `/dev-workflow:implement-issue`. Accepts `--headless` for unattended post-release runs.
| name | pixee-integration |
| description | List Pixee integrations to discover the id, type, and capabilities of each scanner integration registered with the org. |
| metadata | {"version":"1.0.0","openclaw":{"category":"developer-tools","requires":{"bins":["pixee"]},"cliHelp":"pixee integration --help"}} |
PREREQUISITES: Read
../pixee-shared/SKILL.mdfor global flags, exit codes, and error handling, and../pixee-auth/SKILL.mdif authentication needs to be configured. See../pixee-scan/SKILL.mdfor the--integration-idconsumer this skill'slistverb feeds.
pixee integration enumerates the third-party scanner integrations registered with the Pixee
organization. Each integration is the org-side configuration that lets the platform attribute an
uploaded scan to a known source (GitHub App installation, GitLab CI token, Sonar host token,
etc.) and grants the platform any extra capabilities that integration exposes — pushing triage
verdicts back, polling for scans on a cadence, and so on.
The discovery flow exists primarily so an agent calling pixee scan create --integration-id <id>
has a canonical way to look up the integration id without dropping to pixee api.
pixee integration list
List integrations registered with the org. Pagination is transparent: the CLI walks every page in one call.
Text output is tab-separated with columns id, type, capabilities. The capabilities
column is a JSON-array literal (e.g., [] for an integration with no extras, ["triage-push"]
when the integration can push triage verdicts back to the source). JSON output is a flat array
of integration records with the HAL envelope stripped — each record carries id, type,
capabilities, and a _links object for HAL traversal.
The default integration registered for each scanner type often uses the id pattern
<type>-default (e.g., sonar-default, polaris-default, github-default), but that is a
convention, not a contract. List the integrations and read the id rather than constructing it
by hand.
The type discriminator names the scanner family (e.g., sonar, polaris, gitlab,
appscan). It is not identical to the --tool enum on pixee scan create — the latter
distinguishes scan kinds at a finer grain (e.g., polaris_sast vs polaris_sca,
gitlab_sast vs gitlab_dependency_scanning), while the integration type collapses to the
provider family.
# List every integration registered with the org
pixee integration list
# JSON shape for programmatic consumption
pixee integration list --json | jq '.[] | {id, type, capabilities}'
# Find integrations that can push triage verdicts back to the source
pixee integration list --json | jq '.[] | select(.capabilities | index("triage-push"))'
# Discover the sonar integration id and use it in a scan-create call
integration_id=$(pixee integration list --json \
| jq -r '.[] | select(.type=="sonar") | .id' | head -n1)
pixee scan create pixee/pixee-platform \
--tool sonar --integration-id "$integration_id" \
--branch main --sha "$(git rev-parse HEAD)"
# Walk to an integration's HAL self link rather than re-listing
href=$(pixee integration list --json | jq -r '.[] | select(.id=="polaris-default") | ._links.self.href')
pixee api "$href"
pixee integration list rather than constructing a
<type>-default string by hand, since that pattern is a convention the platform can change.type when looking for a specific scanner family. The org may have multiple
integrations of the same type (different GitHub Apps, multiple GitLab tenants) and type
alone is not unique.capabilities before assuming an integration can do more than receive uploads.
triage-push is the load-bearing one today; treat the array as forward-compatible and check
for membership (jq '.capabilities | index("...")') rather than equality.type with pixee scan create --tool. The mapping is one-to-many
for some providers (one polaris integration backs both polaris_sast and polaris_sca
scans). Pick the --tool value from the scan's true kind, and the --integration-id from
whatever integration attributes the upload.pixee api /api/v1/integrations for discovery. The
subcommand pages transparently and surfaces the same fields without the HAL envelope when
text mode is enough.