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.

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, keychain, git auth, 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
Elasticsearch	⚪ Untested	Search, count, indices, cluster health
Kibana	⚪ Untested	Dashboards, data views, alerting rules
Figma	⚪ Untested	Design files, comments, history
Split.IO	⚪ Untested	Feature flags, change requests
Alation	⚪ Untested	Catalog metadata, search, documents
Sauce Labs	⚪ Untested	Test jobs, builds, real devices

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.

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.