@kolatts/pncli 1.8.0 → 1.10.0

package/dist/{config-PXL632ZX.js → config-NCI2BTQG.js}

@@ -7,7 +7,7 @@ import {
   setRepoConfigValue,
   writeGlobalConfig,
   writeRepoConfig
-} from "./chunk-S4SJLY4M.js";
+} from "./chunk-O3LWAWSN.js";
 export {
   getGlobalConfigPath,
   loadConfig,
@@ -17,4 +17,4 @@ export {
   writeGlobalConfig,
   writeRepoConfig
 };
-//# sourceMappingURL=config-PXL632ZX.js.map
+//# sourceMappingURL=config-NCI2BTQG.js.map

package/dist/{http-TID3W235.js → http-L2P23H2D.js}

@@ -2,9 +2,9 @@
 import {
   HttpClient,
   createHttpClient
-} from "./chunk-QQ7UKWTU.js";
+} from "./chunk-3XHTRFRX.js";
 export {
   HttpClient,
   createHttpClient
 };
-//# sourceMappingURL=http-TID3W235.js.map
+//# sourceMappingURL=http-L2P23H2D.js.map

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@kolatts/pncli",
-  "version": "1.8.0",
+  "version": "1.10.0",
   "description": "The Paperwork Nightmare CLI — One command does what three meetings couldn't.",
   "type": "module",
   "bin": {
@@ -50,6 +50,7 @@
   "license": "Apache-2.0",
   "files": [
     "dist",
+    "skills",
     "LICENSE",
     "NOTICE",
     "README.md",

package/skills/address-pr-feedback/SKILL.md

@@ -0,0 +1,87 @@
+---
+name: address-pr-feedback
+description: Work through all open review comments and SonarQube issues on the current branch's PR. Auto-fixes linting and SonarQube findings; applies AI judgment to reviewer comments. Shows a summary table, then asks user to commit and push before marking threads resolved. Use when asked to address feedback, resolve PR comments, or respond to change requests.
+compatibility: Designed for Claude Code. Requires pncli configured with Bitbucket or Azure DevOps and optionally SonarQube.
+user-invocable: true
+metadata:
+  category: pr-workflow
+  providers: both
+  services: git, bitbucket, ado, sonar
+---
+
+## Step 1 — Detect provider
+
+Run `git remote -v`. `/_git/` in the URL → Azure DevOps. `/scm/` → Bitbucket.
+
+## Step 2 — RESEARCH: Gather all open feedback (parallel)
+
+Launch three tasks simultaneously:
+
+**Task A — Open PR comments**
+
+Bitbucket: `pncli bitbucket get-pr` to get the PR id, then `pncli bitbucket list-comments --pr <id>` filtered to `resolved: false`.
+ADO: `pncli ado repo list-prs --state active` filtered by current branch to get PR id, then `pncli ado repo list-comments --pr <id>` filtered to threads where `status` is not `fixed`.
+
+**Task B — SonarQube issues**
+
+Get current branch: `git rev-parse --abbrev-ref HEAD`
+Run `pncli sonar issues --statuses OPEN --branch <branch>`
+Report: rule key, severity, file, line, message for each open issue.
+
+**Task C — Source context**
+
+For every comment in Task A that references a file path, read that file in full from the working tree.
+
+Wait for all three tasks.
+
+## Step 3 — PLAN: Classify each item
+
+For every comment and SonarQube issue, assign one action:
+
+- **AUTO-FIX** — SonarQube issues; comments explicitly about linting, formatting, or code style rules
+- **AGREED-FIX** — Reviewer threads where a reply from the PR author (or submitter) contains an agreement signal: "sounds good", "will fix", "done", "agreed", "fixed", "+1", "yep", "sure"
+- **AI-JUDGMENT** — Everything else. Apply best judgment to determine the correct fix. Do not skip.
+
+## Step 4 — IMPLEMENT: Apply all fixes
+
+Process AUTO-FIX and AGREED-FIX items first, then AI-JUDGMENT items.
+
+For each item: edit the referenced file(s) directly to resolve the finding.
+Track as you go: `(comment id or sonar key) → (action taken) → (file:line changed)`.
+
+## Step 5 — Show summary table
+
+Print a Markdown table of everything addressed:
+
+| Comment / Finding | Author | Action | File Changed |
+|---|---|---|---|
+| ... | ... | ... | ... |
+
+## Step 6 — Ask user to commit and push
+
+Do NOT auto-commit or auto-push. Print:
+
+```
+All fixes applied. Review the changes above, then:
+  git add <changed files>
+  git commit -m "fix: address PR review feedback"
+  git push
+```
+
+Wait for the user to confirm they have pushed before proceeding to Step 7.
+
+## Step 7 — Reply to and resolve each thread
+
+After the user confirms the push, for each addressed item:
+
+**Bitbucket:**
+```
+pncli bitbucket reply-comment --pr <id> --comment-id <cid> --body "Fixed — <one-line description>"
+pncli bitbucket resolve-comment --pr <id> --comment-id <cid>
+```
+
+**ADO:**
+```
+pncli ado repo reply-comment --pr <id> --thread-id <tid> --body "Fixed — <one-line description>"
+pncli ado repo resolve-comment --pr <id> --thread-id <tid>
+```

package/skills/code-review/SKILL.md

@@ -0,0 +1,82 @@
+---
+name: code-review
+description: Review the PR for the current branch. Reads the full diff, existing comments, and referenced source files, then posts categorized inline comments (Blocking / Suggestion / Nit) via pncli. Offers to approve or request changes at the end. Works with Bitbucket and Azure DevOps. Use when asked to review a PR, check the diff, or add code review comments.
+compatibility: Designed for Claude Code. Requires pncli configured with Bitbucket or Azure DevOps.
+user-invocable: true
+metadata:
+  category: pr-workflow
+  providers: both
+  services: git, bitbucket, ado
+---
+
+## Step 1 — Detect provider
+
+Run `git remote -v`. `/_git/` → Azure DevOps. `/scm/` → Bitbucket.
+
+## Step 2 — Find the PR for the current branch
+
+Get current branch: `git rev-parse --abbrev-ref HEAD`
+
+**Bitbucket:** `pncli git current-pr` → returns PR id.
+**ADO:** `pncli ado repo list-prs --state active`, filter entries where `sourceRefName` ends with the current branch name.
+
+## Step 3 — RESEARCH: Read diff, comments, and source files (parallel)
+
+Launch three agents simultaneously:
+
+**Agent A — Full diff**
+Bitbucket: `pncli bitbucket diff --pr <id>`
+ADO: `pncli ado repo diff --pr <id>`
+Parse: file paths, change type (add/edit/delete), added and removed line numbers.
+
+**Agent B — Existing comments**
+Bitbucket: `pncli bitbucket list-comments --pr <id>`
+ADO: `pncli ado repo list-comments --pr <id>`
+Note which file+line combinations already have comments — do not duplicate them.
+
+**Agent C — Source context**
+For each file that appears in the diff: read the full file from the working tree.
+Also read `CLAUDE.md` (or any repo conventions file) if present in the repo root.
+
+Wait for all three agents.
+
+## Step 4 — PLAN: Classify each finding
+
+Analyze the diff against the full source context and existing comments.
+For each issue found, assign a category:
+
+- **Blocking** — correctness bug, security vulnerability, broken contract, data loss risk, undefined behavior
+- **Suggestion** — better approach available, missing test coverage, unclear naming, performance concern, missing error handling at a boundary
+- **Nit** — style preference, whitespace, minor naming, cosmetic
+
+Skip any finding already covered by an existing comment on the same line.
+
+## Step 5 — IMPLEMENT: Post inline comments
+
+Post findings in order: Blocking first, then Suggestion, then Nit.
+
+**Bitbucket:**
+```
+pncli bitbucket add-inline-comment --pr <id> --file <path> --line <n> \
+  --body "[Blocking|Suggestion|Nit] <finding>"
+```
+
+**ADO:**
+```
+pncli ado repo add-inline-comment --pr <id> --file <path> --line <n> \
+  --line-type right --body "[Blocking|Suggestion|Nit] <finding>"
+```
+
+(Use `--line-type left` for lines that were removed.)
+
+## Step 6 — Approve or request changes
+
+**If any Blocking findings were posted:**
+Bitbucket: `pncli bitbucket needs-work --pr <id>`
+ADO: `pncli ado repo wait-for-author --pr <id>`
+
+**If no Blocking findings:** Ask the user: "No blocking issues found. Approve this PR? (y/n)"
+On yes — Bitbucket: `pncli bitbucket approve --pr <id>` / ADO: `pncli ado repo approve --pr <id>`
+On no — leave without approving.
+
+Report: N Blocking, N Suggestion, N Nit. Overall decision.

package/skills/local-setup/SKILL.md

@@ -0,0 +1,225 @@
+---
+name: local-setup
+description: Use when asked to set up pncli for the first time, configure services, or initialize a repo. Walks through identity, work item tracking, source control, and optional services using non-interactive pncli config commands.
+compatibility: Designed for Claude Code. Requires pncli installed and accessible in PATH.
+user-invocable: true
+metadata:
+  category: setup
+  providers: both
+  services: config
+---
+
+Walk the user through a complete pncli setup — global config and repo-level defaults — using non-interactive commands. Ask the user questions and use their answers to run `pncli config set` commands.
+
+**Step 1 — Ask about identity.**
+
+Ask the user:
+- "What is your email address? (used across Jira, Bitbucket, etc.)"
+- "What is your username or user ID?"
+
+Then set the values:
+
+```
+pncli config set user.email <their-email>
+pncli config set user.userId <their-username>
+```
+
+**Step 2 — Ask about work item tracking.**
+
+Ask the user: "Does this organization use **Jira** or **Azure DevOps** for work items and tickets?"
+
+If **Jira**:
+- Ask for their Jira base URL (e.g. `https://jira.company.com`)
+- Ask for their Jira personal access token
+
+```
+pncli config set jira.baseUrl <url>
+pncli config set jira.apiToken <token>
+```
+
+If **Azure DevOps**:
+- Ask for their Azure DevOps Server base URL (e.g. `https://tfs.company.com`)
+- Ask for their ADO personal access token
+- Ask for their default collection name (e.g. `DefaultCollection`)
+- Ask for their default project name
+
+```
+pncli config set ado.baseUrl <url>
+pncli config set ado.pat <token>
+pncli config set defaults.ado.collection <collection>
+pncli config set defaults.ado.project <project>
+```
+
+**Step 3 — Ask about source control.**
+
+Ask the user: "Does this organization use **Bitbucket** or **Azure DevOps** for pull requests and code review?"
+
+If **Bitbucket**:
+- Ask for their Bitbucket Server base URL
+- Ask for their Bitbucket personal access token
+
+```
+pncli config set bitbucket.baseUrl <url>
+pncli config set bitbucket.pat <token>
+```
+
+If **Azure DevOps** and not already configured in step 2, ask for the ADO credentials now.
+
+**Step 4 — Ask about optional services.**
+
+Ask the user about each of these. Skip any they don't use:
+
+**Confluence** — "Do you use Confluence for documentation?"
+
+```
+pncli config set confluence.baseUrl <url>
+pncli config set confluence.apiToken <token>
+```
+
+**SonarQube** — "Do you use SonarQube for code quality and security scanning?"
+
+```
+pncli config set sonar.baseUrl <url>
+pncli config set sonar.token <token>
+```
+
+**SDElements** — "Do you use SDElements for threat modeling?" If yes, ask for their connection string (format: `token@hostname`):
+
+```
+pncli config set sde.connection <token@hostname>
+```
+
+**Checkmarx** — "Do you use Checkmarx CxSAST for vulnerability scanning?"
+
+```
+pncli config set checkmarx.baseUrl <url>
+pncli config set checkmarx.username <username>
+pncli config set checkmarx.password <password>
+```
+
+The base URL is your CxSAST server root, e.g. `https://cx.company.com`. pncli handles the OAuth2 token exchange using your username and password — no other tools required.
+
+**IBM UrbanCode Deploy** — "Do you use IBM UrbanCode Deploy for component imports or deployment processes?"
+
+```
+pncli config set udeploy.baseUrl <url>
+```
+
+Ask whether they authenticate with a PAT or username/password:
+
+- If **PAT**: `pncli config set udeploy.pat <token>`
+- If **username/password**:
+  ```
+  pncli config set udeploy.username <username>
+  pncli config set udeploy.password <password>
+  ```
+
+Optionally set defaults to avoid repeating flags on every command:
+
+```
+pncli config set defaults.udeploy.application <app-name>
+pncli config set defaults.udeploy.environment <env-name>
+```
+
+**Jenkins** — "Do you use Jenkins for CI/CD pipelines?"
+
+```
+pncli config set jenkins.baseUrl <url>
+pncli config set jenkins.username <username>
+pncli config set jenkins.apiToken <token>
+```
+
+The base URL is your Jenkins root, e.g. `https://jenkins.company.com`. pncli authenticates using HTTP Basic (username + API token).
+
+**Artifactory** — "Do you use Artifactory for package management?"
+
+```
+pncli config set artifactory.baseUrl <url>
+pncli config set artifactory.token <token>
+```
+
+Then ask which package ecosystems they proxy through Artifactory (npm, NuGet, Maven). Set whichever apply:
+
+```
+pncli config set artifactory.npmRepo <virtual-repo-name>
+pncli config set artifactory.nugetRepo <virtual-repo-name>
+pncli config set artifactory.mavenRepo <virtual-repo-name>
+```
+
+**Jenkins** — "Do you use Jenkins for CI/CD pipelines?"
+
+```
+pncli config set jenkins.baseUrl <url>
+pncli config set jenkins.username <username>
+pncli config set jenkins.apiToken <token>
+```
+
+**ServiceNow** — "Do you use ServiceNow for change management?"
+
+```
+pncli config set servicenow.baseUrl <url>
+pncli config set servicenow.username <username>
+```
+
+Ask whether they authenticate with a password or API token:
+
+- If **password**: `pncli config set servicenow.password <password>`
+- If **API token**: `pncli config set servicenow.apiToken <token>`
+
+The base URL is your ServiceNow instance root, e.g. `https://mycompany.service-now.com`.
+
+**Contrast IAST** — "Do you use Contrast Security for interactive application security testing?"
+
+```
+pncli config set contrast.orgUuid <org-uuid>
+pncli config set contrast.username <username>
+pncli config set contrast.apiKey <api-key>
+pncli config set contrast.serviceKey <service-key>
+```
+
+Optionally set the base URL if using an on-premise instance (defaults to `https://app.contrastsecurity.com`):
+
+```
+pncli config set contrast.baseUrl <url>
+```
+
+All four credentials (org UUID, username, API key, service key) are found in your Contrast account under **User Settings → Your Keys**.
+
+**Sonatype IQ Server** — "Do you use Sonatype IQ Server for dependency security policy enforcement?"
+
+```
+pncli config set sonatypeiq.baseUrl <url>
+pncli config set sonatypeiq.userCode <user-code>
+pncli config set sonatypeiq.passcode <passcode>
+```
+
+The `userCode` and `passcode` are User Token credentials generated in your IQ Server profile under **User Menu → User Token**. The base URL is your IQ Server instance root, e.g. `https://iq.your-company.com`.
+
+Once configured, use `pncli sonatypeiq applications list` to discover application IDs, then run `pncli deps frisk --source sonatypeiq --application-id <id>` to scan dependencies against your IQ Server policies.
+
+**Step 5 — Set repo-level defaults.**
+
+Ask the user for project-specific defaults:
+- "What is the default Jira project key for this repo?" (e.g. `ACME`)
+- "What is the default target branch for PRs?" (e.g. `main`)
+- If SonarQube is configured: "What is the SonarQube project key?"
+- If SDElements is configured: "What is the SDElements project ID?"
+
+```
+pncli config set --repo defaults.jira.project <key>
+pncli config set --repo defaults.bitbucket.targetBranch <branch>
+pncli config set --repo defaults.sonar.project <key>
+pncli config set --repo defaults.sde.project <id>
+```
+
+The `--repo` flag writes to `.pncli.json` in the repo root, keeping project-specific defaults scoped to the repo and shareable via version control.
+
+**Step 6 — Test connectivity.**
+
+```
+pncli config test
+```
+
+Review the results. If any service shows `ok: false`, help the user troubleshoot the URL or credentials.
+
+Run `pncli config show` to confirm the final configuration.

package/skills/plan/SKILL.md

@@ -0,0 +1,120 @@
+---
+name: plan
+description: Turn a feature description, goal, or problem statement into a structured backlog in Jira or ADO. Explores the codebase with parallel subagents before generating the breakdown; shows the plan to the user for confirmation before creating any work items. Use when asked to plan a feature, break down a problem, or create backlog items from a description.
+compatibility: Designed for Claude Code. Requires pncli configured with Jira or Azure DevOps.
+user-invocable: true
+metadata:
+  category: planning
+  providers: both
+  services: git, jira, ado
+---
+
+## Step 1 — Get the feature description
+
+Ask the user: "What are you planning? Describe the feature, goal, or problem in as much detail as you have."
+
+Wait for their response before proceeding.
+
+## Step 2 — Detect ticket provider
+
+Run `pncli config show`.
+- `jira.baseUrl` present → Jira. Note the default project key from `defaults.jira.project`.
+- `ado.baseUrl` present → ADO. Note the default project from `defaults.ado.project`.
+
+## Step 3 — RESEARCH: Explore the codebase (parallel)
+
+Launch three agents based on the feature description:
+
+**Agent A — Relevant files and patterns**
+Search the codebase for files related to the described feature area (grep for key terms, check likely directories).
+Read the most relevant source files in full.
+Note: existing patterns, data models, API contracts, naming conventions used in this area.
+
+**Agent B — Dependencies and integration points**
+Identify external services, APIs, or packages the feature will touch.
+Read any relevant config files and interface/type definitions.
+Check for existing tests that cover adjacent code — note what's already tested.
+
+**Agent C — Scope and constraints**
+Read `CLAUDE.md` (or any architecture decision records present).
+Identify stable contracts or public APIs that should NOT change.
+Note any known tech debt or open issues in the affected area that could affect scope.
+
+Wait for all three agents.
+
+## Step 4 — PLAN: Produce a story breakdown
+
+Using the research output, generate a structured plan:
+
+```
+Epic: "<Feature name>" — one-sentence description
+
+Story 1: <title>
+  Acceptance criteria:
+    - <testable criterion>
+    - <testable criterion>
+  Size: S / M / L
+  Depends on: (none | Story N)
+
+Story 2: ...
+
+Tasks under Story 1:
+  - <specific implementation step> (<file(s) that will change>)
+  - ...
+```
+
+Show the complete breakdown to the user and ask:
+"Does this plan look right? Say 'looks good' to create the work items, or describe any changes."
+
+**Wait for explicit user confirmation before Step 5.** Do not create any tickets until confirmed.
+
+## Step 5 — IMPLEMENT: Create work items
+
+Only create an Epic if there are more than 2 stories.
+
+**Jira:**
+```
+# Epic (if >2 stories)
+pncli jira create-issue --project <key> --type Epic \
+  --summary "<epic title>" --description "<description>"
+
+# Per story
+pncli jira create-issue --project <key> --type Story \
+  --summary "<story title>" \
+  --description "<acceptance criteria>" \
+  --labels <feature-label>
+
+# Per task
+pncli jira create-issue --project <key> --type Task \
+  --summary "<task title>" --description "<details>"
+
+# Link story → epic
+pncli jira link-issue --key <story> --link-type "is child of" --target <epic>
+
+# Link task → story
+pncli jira link-issue --key <task> --link-type "is child of" --target <story>
+```
+
+**ADO:**
+```
+# Epic (if >2 stories)
+pncli ado work create --type Epic --title "<epic title>" --description "<description>"
+
+# Per story
+pncli ado work create --type "User Story" \
+  --title "<story title>" --description "<acceptance criteria>"
+
+# Per task
+pncli ado work create --type Task --title "<task title>" --description "<details>"
+
+# Link story → epic
+pncli ado work link --id <story> --to <epic> --type parent
+
+# Link task → story
+pncli ado work link --id <task> --to <story> --type parent
+```
+
+## Step 6 — Report
+
+Print: Epic key/id (if created), each story with its key/id, total tasks created.
+Ask: "Want me to open the Epic in the browser?"

package/skills/security-review/SKILL.md

@@ -0,0 +1,108 @@
+---
+name: security-review
+description: Scan all security sources (dependency CVEs, SonarQube vulnerabilities, SonarQube hotspots, optionally SDElements threats), triage by severity, then create Jira or ADO tickets — Bug for critical/blocking findings, Task for others, grouped under an Epic when more than 3 tickets are created. Use when asked to do a security review, scan for vulnerabilities, or triage security findings into the backlog.
+compatibility: Designed for Claude Code. Requires pncli configured with deps scanning and optionally SonarQube and SDElements.
+user-invocable: true
+metadata:
+  category: security
+  providers: both
+  services: deps, sonar, sde, jira, ado
+---
+
+## Step 1 — RESEARCH: Gather all findings (parallel)
+
+Get current branch: `git rev-parse --abbrev-ref HEAD`
+
+Launch four agents simultaneously:
+
+**Agent A — Dependency CVEs**
+`pncli deps frisk`
+Report: package name, CVE id, severity (CRITICAL/HIGH/MEDIUM/LOW), fixed-in version if known.
+
+**Agent B — SonarQube vulnerabilities**
+`pncli sonar issues --types VULNERABILITY --statuses OPEN --branch <branch>`
+Report: rule key, severity, file, line, message.
+
+**Agent C — SonarQube hotspots**
+`pncli sonar hotspots --status TO_REVIEW --branch <branch>`
+Report: securityCategory, vulnerabilityProbability (HIGH/MEDIUM/LOW), file, line, message.
+
+**Agent D — SDElements threats (conditional)**
+First check: `pncli config show` — only run this agent if `sde.connection` is present in the output.
+If present: `pncli sde threats`
+Report: threat title, risk rating, phase (requirements/design/development/testing).
+
+Wait for all agents.
+
+## Step 2 — PLAN: Triage and prioritize
+
+Consolidate all findings into a single prioritized list:
+1. Critical CVEs + Blocker SonarQube vulnerabilities
+2. High CVEs + Critical SonarQube vulnerabilities + High hotspots
+3. Medium findings
+4. Drop low/info findings unless the user explicitly requested them
+
+**Deduplicate:** if the same file+line or the same package appears across multiple sources, merge into one finding and note all source references.
+
+**Assign ticket type:**
+- Critical or Blocker severity → **Bug**
+- All others → **Task**
+
+## Step 3 — Detect ticket provider
+
+Run `pncli config show`.
+- `jira.baseUrl` present → Jira
+- `ado.baseUrl` present → ADO
+
+## Step 4 — IMPLEMENT: Create tickets (highest severity first)
+
+**Jira:**
+```
+pncli jira create-issue \
+  --project <default-project-key> \
+  --type <Bug|Task> \
+  --summary "Security: <description>" \
+  --description "<source>: <severity>\nRule/CVE: <id>\nFile: <path>:<line>\nFix: <guidance>" \
+  --priority <Critical|High|Medium> \
+  --labels security,<source-tag>
+```
+Source tags: `cve-remediation`, `sonar-vulnerability`, `sonar-hotspot`, `threat-model`
+
+**ADO:**
+```
+pncli ado work create \
+  --type <Bug|Task> \
+  --title "Security: <description>" \
+  --description "<details>" \
+  --priority <1|2|3>
+```
+
+Link related findings (same component or same CVE chain):
+- Jira: `pncli jira link-issue --key <new> --link-type "relates to" --target <related>`
+- ADO: `pncli ado work link --id <new> --to <related> --type related`
+
+## Step 5 — Group under Epic if more than 3 tickets
+
+**Jira:**
+```
+pncli jira create-issue --project <key> --type Epic \
+  --summary "Security Review <YYYY-MM-DD>" \
+  --description "Critical: <n>, High: <n>, Medium: <n>. Sources: <list>"
+```
+Then for each ticket: `pncli jira link-issue --key <ticket> --link-type "is child of" --target <epic>`
+
+**ADO:**
+```
+pncli ado work create --type Epic \
+  --title "Security Review <YYYY-MM-DD>" \
+  --description "<breakdown>"
+```
+Then: `pncli ado work link --id <ticket> --to <epic> --type parent`
+
+## Step 6 — Report summary
+
+Print:
+- Sources scanned
+- Total raw findings, deduplicated count
+- Tickets created (with keys/ids)
+- Epic key/id if created