@kolatts/pncli 1.10.0 → 1.11.0

package/skills/plan/SKILL.md

@@ -1,120 +0,0 @@
----
-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

@@ -1,108 +0,0 @@
----
-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

package/skills/ship/SKILL.md

@@ -1,170 +0,0 @@
----
-name: ship
-description: Open a PR for the current branch on Bitbucket or Azure DevOps. Runs the full pre-PR gate (build, lint, typecheck, tests, code review, docs) using parallel subagents before opening the PR. For GitHub repos, use the repo-scoped /ship skill instead. Use whenever the user says "open a PR", "create a PR", "ship this", "pull request", or "/ship".
-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
----
-
-Run the full pre-PR gate and open the PR. Parallelize as much as possible.
-
-Make sure there are no outstanding untracked changes before starting.
-
-Detect provider once up front: run `git remote -v`. `/_git/` → Azure DevOps. `/scm/` → Bitbucket. Use this throughout every phase.
-
-## Phase 0 — Issue check + build command setup
-
-**Issue:** Parse the current branch name for an issue key:
-- Jira key pattern: `[A-Z]+-\d+` (e.g., `PROJ-42`)
-- ADO work item id: a plain integer after a hyphen (e.g., `feature/1234-add-widget` → `#1234`)
-
-If a key is found, note it for use in the PR body (`Closes <key>`). If none is found, proceed without one.
-
-**Build commands (one-time setup):** Check if Phase 2 in this file already has real commands filled in (i.e., not the placeholder text `<build-command>`). If it does, skip this step.
-
-If placeholders are still present, ask the user:
-- "What command do you use to build?" (e.g., `npm run build`, `dotnet build`, `gradle build`)
-- "What command do you use to lint or typecheck?" (e.g., `npm run lint`, `dotnet format --verify-no-changes`)
-- "What command do you use to run tests?" (e.g., `npm test`, `dotnet test`, `./gradlew test`)
-
-Once answered, edit this SKILL.md file directly — replace the `<build-command>`, `<lint-command>`, and `<test-command>` placeholders in Phase 2 below with the actual commands. Save the file before proceeding.
-
-## Phase 1 — Gather context (parallel)
-
-Launch two subagents simultaneously:
-
-**Agent A — Diff + branch info**
-- Run `git log origin/<target-branch>..HEAD --oneline`
-- Run `git diff origin/<target-branch>..HEAD --stat`
-- Run `git diff origin/<target-branch>..HEAD --name-only`
-- Bitbucket: `pncli bitbucket list-prs --state OPEN` filtered to current branch
-- ADO: `pncli ado repo list-prs --state active` filtered to sourceRefName matching current branch
-- Report: branch name, commit list, changed files, existing PR URL if any
-
-**Agent B — Docs audit**
-- Run `git diff origin/<target-branch>..HEAD --name-only`
-- Read every file in `docs/` and every `README.md` in the repo
-- Read `CLAUDE.md` sections relevant to the changed files
-- Check for any docs or site pages that reference changed commands or features — flag anything stale
-- Report: stale docs/README sections, new or updated commands with full signatures
-
-Wait for both agents.
-
-## Phase 2 — Pre-PR gate (parallel)
-
-If a PR already exists (Agent A found one), skip straight to Phase 3.
-
-Launch three subagents simultaneously:
-
-**Agent C — Build + lint**
-1. Run `<build-command>` — must succeed.
-2. Run `<lint-command>` — report errors or warnings.
-- Report: build result, lint issues
-
-**Agent D — Code review**
-- Run `git diff origin/<target-branch>..HEAD` to get the full diff
-- Read each changed file in full
-- Review for correctness, quality, and consistency with any `CLAUDE.md` conventions
-- Rate each issue: Major (blocks merge), Minor (should fix), Nit (optional)
-- Report: overall decision (Approve / Request Changes), all issues with file + line + severity
-
-**Agent E — Tests**
-- Run `<test-command>` and report pass/fail/counts
-- If no tests exist, report that and note which changed files could benefit from coverage
-- Report: test result summary
-
-Wait for all three agents.
-
-## Phase 3 — Fix loop
-
-Collect all issues from Phase 2:
-- Build errors → fix them
-- Lint errors → fix them (warnings: fix if trivial)
-- Code review issues rated Major or Minor → fix them; skip Nits unless trivial
-- Failing tests → fix them
-- Stale docs or README sections (from Agent B) → update them
-
-After fixing, re-run Agent C to confirm build + lint pass. Re-run Agent E if any source files changed.
-
-## Phase 4 — Commit fixes (if any)
-
-If Phase 3 produced any changes:
-- `git add` the changed files
-- Show the staged diff and confirm with the user before committing
-- Commit: `fix(pre-pr): address review feedback`
-
-## Phase 5 — PR preview
-
-Construct the PR title and body (do not open the PR yet):
-
-**Title:** strip the `<username>/` prefix and any leading issue number from the branch name, convert to Conventional Commit format:
-- `type(scope): description`
-- Example: branch `alice/PROJ-42-add-widget` → `feat(widget): add widget`
-
-**Body:**
-```
-## Summary
-<bullet points from commit list>
-
-## Issue
-Closes <issue-key>
-(omit this section entirely if no issue was found in Phase 0)
-
-## Pre-PR gate
-- Build: passed
-- Lint: <clean / N warnings>
-- Code review: <Approve / issues fixed>
-- Tests: <N passed / no tests>
-- Docs: <updated / no changes needed>
-```
-
-Show the formatted title and body to the user, then immediately proceed to open the PR without waiting for confirmation.
-
-## Phase 6 — Open PR
-
-**Bitbucket:**
-```
-pncli bitbucket create-pr \
-  --title "<title>" \
-  --body "<body>" \
-  --source <current-branch> \
-  --target <target-branch>
-```
-
-**ADO:**
-```
-pncli ado repo create-pr \
-  --title "<title>" \
-  --body "<body>" \
-  --source <current-branch> \
-  --target <target-branch>
-```
-
-Report the PR URL to the user.
-
-## Phase 7 — Post-open watch loop
-
-After opening the PR, immediately invoke `/loop 10m` with the following recurring task:
-
-> Poll PR status:
->
-> **Bitbucket:** `pncli bitbucket get-pr --id <id>` — check `state` field.
-> **ADO:** `pncli ado repo get-pr --id <id>` — check `status` field.
->
-> **If MERGED / completed:** Report "PR merged" and stop the loop.
->
-> **If CONFLICTING (Bitbucket state=OPEN with conflicts) or ADO merge conflicts indicated:**
-> `git fetch origin <target-branch> && git merge origin/<target-branch>`
-> Fix any conflicts, `git add`, `git commit -m "fix(merge): resolve conflicts"`, push.
-> Report what was resolved.
->
-> **If reviewer voted CHANGES_REQUESTED / needs-work:**
-> Re-run Phases 2–4 (gate, fix all issues, commit). Push.
-> Report what was fixed.
->
-> **If OPEN / active, no issues:** Report "PR open, checks running — nothing to do yet."
->
-> **If DECLINED / abandoned:** Report "PR closed without merging" and stop the loop.