pncli — The Paperwork Nightmare CLI

Connectivity without MCP.

pncli gives AI coding agents (and humans) structured CLI access to the enterprise tools your org actually runs — Jira, Bitbucket, Confluence, SonarQube, SDElements, Azure DevOps Server, Jenkins, JFrog Artifactory, Checkmarx, and more. No MCP servers required. No meetings to schedule. No forms to fill out.

The service list grows. Any enterprise tool that authenticates with a long-lived credential you generate once (a personal access token, or a refresh token pncli can exchange over plain HTTP) is a candidate — issue trackers and CI/CD, but equally design, docs, observability, and collaboration tools your agents need context from. Request one.

Why?

Your org blocked MCP. Your agents still need to review PRs, create issues, and manage code reviews. pncli is the shim layer that makes it work — one npm install and you're cutting through red tape.

Install

npm install -g @kolatts/pncli

Give it to your agent

pncli ships a skill — setup, conventions, and a reference file per service — that teaches any coding agent how to use it. Install it into your repo:

# Codex & GitHub Copilot via the cross-tool .agents/skills convention (default)
pncli skills install

# GitHub Copilot's own directories (.github/skills)
pncli skills install --agent github-copilot

# Claude Code (.claude/skills)
pncli skills install --agent claude-code

# All three agent hosts at once
pncli skills install --all-agents

Add --scope user to install for every repo on the machine instead. Installed skills are a copy — after upgrading pncli, re-run pncli skills install; skills list, skills status, and pncli doctor warn when the installed copy is stale.

Org plugins from a marketplace

Org-internal plugins distribute the same way from a private git-hosted marketplace, and the marketplace can ship an AGENTS.md / CLAUDE.md that lands in each agent's user-level instructions file as a managed block (your own content is never touched):

# Register, clone, install every plugin, and apply shipped instructions — all three agent hosts
pncli skills marketplace add <git-clone-url> --all-agents

# Later: pull and refresh everything installed from every marketplace
pncli skills marketplace sync --marketplace all --all-agents

# Interactive hub: toggle plugins on/off, add or remove marketplaces
pncli skills marketplace manage

pncli skills marketplace --help lists the whole workflow, pncli skills marketplace instructions list shows which instructions are installed where, and pncli skills status traces every installed skill back to its marketplace.

Quick Start

# Configure your global auth (Jira, Bitbucket, Confluence)
pncli config init

# Add repo-level defaults (check this into git)
pncli config init --repo

# When something isn't working: config, credentials, skills, and marketplaces in one report
pncli doctor

For setup, conventions, and agent integration, see the Getting Started page and the full command reference. The same guidance ships to your agent via pncli skills install.

Configuration

pncli uses a three-layer config system (highest priority wins):

| Layer | File | Contains | In Git? | |-------|------|----------|---------| | Env vars | PNCLI_* | Auth overrides, CI secrets | No | | Repo config | .pncli.json | Team defaults (project, issue type, priority, target branch) | Yes | | Global config | ~/.pncli/config.json | Auth, server URLs, personal defaults | No |

Environment Variables

Every config value can be supplied as a PNCLI_<SERVICE>_<KEY> environment variable, and env vars always win over config files. The cross-service ones:

| Variable | Description | |----------|-------------| | PNCLI_EMAIL | Your email address (used across Jira, Bitbucket, etc.) | | PNCLI_USERID | Your user ID or username | | PNCLI_CONFIG_PATH | Override global config file path |

Per-service variables (base URLs, tokens) are documented in each service's file under skills/pncli/ — the same files pncli skills install hands to your agent — and on the command reference.

For AI Agents

pncli is designed agent-first:

• Every command returns structured JSON to stdout
• Errors are JSON too — always check "ok"
• --dry-run lets agents preview before executing
• Run pncli skills install to give your agent the skills/pncli/ reference — setup, conventions, and a file per service

Global Flags

--pretty                Human-readable formatted output (default: compact JSON)
--verbose               Include full API response metadata
--dry-run               Print the API request without executing
--config <path>         Override global config file location
--output-file <path>    Write JSON output to file instead of stdout

Commit Convention

This project uses Conventional Commits for automatic versioning:

• fix: ... → patch
• feat: ... → minor
• feat!: ... → major

Services

| Service | Status | Description | |---------|--------|-------------| | Git | 🟢 Live | Local repository operations | | Jira | 🔵 Beta | Issues, sprints, projects | | Confluence | 🔵 Beta | Pages, spaces, content | | Azure DevOps | 🔵 Beta | Work items, pipelines | | Bitbucket | 🟡 Basic | Pull requests, repositories | | GitHub | 🟡 Basic | Pull requests, reviews, issues | | SonarQube | 🟡 Basic | Code quality & security | | SDElements | 🟡 Basic | Security requirements | | Artifactory | 🟡 Basic | Artifact repository | | Jenkins | 🟡 Basic | CI/CD pipelines | | Dynatrace | 🟡 Basic | Problems, entities, traces | | Dependencies | 🟡 Basic | CVE detection, license audit | | Checkmarx | ⚪ Untested | Vulnerability scanning (SAST) | | Contrast IAST | ⚪ Untested | Runtime application security | | Sonatype IQ | ⚪ Untested | Dependency policy enforcement | | OpenShift | ⚪ Untested | Pods, events, logs, metrics | | LogScale | ⚪ Untested | Log queries, repositories | | Figma | ⚪ Untested | Design files, comments, history | | Split.IO | ⚪ Untested | Feature flags, change requests | | Alation | ⚪ Untested | Catalog metadata, search, documents |

Status reflects validation against a real instance, not code maturity: Live — used routinely day-to-day · Beta — exercised across several commands and instances · Basic — smoke-tested against one instance · Untested — shipped, not yet run against a live server. The homepage shows the same grid.

Removed integrations: ServiceNow (v5.0.0), IBM UrbanCode Deploy (v2.0.0) — see the changelog for why.

Auth specifics and supported server versions for each service live in its skills/pncli/<service>.md file.

Adding a service

Requests for new integrations are welcome for any enterprise tool, not just the SDLC categories above — design, documentation, observability, ITSM, and collaboration tools all count.

The one hard requirement is authentication: the tool must support a long-lived credential you generate once in its own UI and paste into an env var or config file, with no interactive step between that credential and an authenticated request. For almost every service that is a personal access token that goes straight into a header; vendor naming doesn't matter (API token, user token, PAT). A long-lived token that must first be exchanged for a short-lived one over a plain HTTP call also qualifies — Alation's refresh token is the example, and pncli performs that exchange itself. Tools whose only auth is interactive OAuth, SSO/SAML, username+password, a registered OAuth app, a cloud IAM credential chain, or mTLS can't be supported. Checkmarx's OAuth2 client-credentials path predates this rule and is grandfathered. Two integrations have been removed for exactly this reason. ServiceNow went in v5.0.0: its personal access tokens are an opt-in instance feature many enterprises never enable, so in practice the integration authenticated with a username + password. IBM UrbanCode Deploy went in v2.0.0: UCD tokens are not usable as a standalone credential the way pncli requires, so its only workable auth was username + password.

License

Apache 2.0 — see LICENSE and NOTICE.