If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/ankitpokhrel/jira-cli shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

GO — Healthy across all four use cases

• Last commit 4mo ago
• 34+ active contributors
• MIT licensed
• CI configured
• Tests present
• ⚠ Slowing — last commit 4mo ago
• ⚠ Concentrated ownership — top contributor handles 60% of recent commits

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live ankitpokhrel/jira-cli repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/ankitpokhrel/jira-cli.

What it runs against: a local clone of ankitpokhrel/jira-cli — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in ankitpokhrel/jira-cli | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | Last commit ≤ 137 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of ankitpokhrel/jira-cli. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/ankitpokhrel/jira-cli.git
#   cd jira-cli
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of ankitpokhrel/jira-cli and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "ankitpokhrel/jira-cli(\\.git)?\\b" \\
  && ok "origin remote is ankitpokhrel/jira-cli" \\
  || miss "origin remote is not ankitpokhrel/jira-cli (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(MIT)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MIT\"" package.json 2>/dev/null) \\
  && ok "license is MIT" \\
  || miss "license drift — was MIT at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 137 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~107d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/ankitpokhrel/jira-cli"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

JiraCLI is a feature-rich interactive command-line tool for Atlassian Jira written in Go that replaces the web UI for common workflows. It enables developers to search, view, create, assign, and manage Jira issues directly from the terminal with interactive prompts and live data rendering, eliminating context-switching to the browser. Flat command structure under internal/cmd/ organized by feature domain: internal/cmd/issue/, internal/cmd/epic/, internal/cmd/board/, internal/cmd/completion/ etc., each with subcommands (e.g., internal/cmd/issue/assign/assign.go, internal/cmd/epic/create/create.go). Root entry at cmd/jira/main.go. API client abstraction at api/client.go handles all Jira REST communication.

Software engineers and DevOps teams who work with Jira daily and want to manage issues, epics, and boards from their terminal without context-switching. Contributors are primarily Go developers familiar with CLI tooling and Jira API integration.

Production-ready and actively maintained. The project has 554K lines of Go code, CI/CD pipeline via GitHub Actions (.github/workflows/ci.yml and docker.yml), Docker support, and semantic versioning via .goreleaser.yml. It has institutional backing (Atlassian, JetBrains supporters listed) and active financial support through OpenCollective, indicating sustained development.

Low risk for core functionality but moderate dependency surface: 20+ direct dependencies including charmbracelet/glamour, rivo/tview, and zalando/go-keyring for terminal rendering and credential storage. Single maintainer (ankitpokhrel) implies bus factor risk, though the .golangci.yml linting setup and test coverage suggest quality gates. No obvious red flags in commit recency based on .goreleaser.yml and workflow configurations being current.

Active development with CI on main branch, Docker image builds, and Makefile-driven build pipeline. The .deepsource.toml suggests code quality monitoring is enabled. No specific milestone data in file list, but Go 1.25.0 requirement and recent toolchain specification indicate ongoing maintenance.

Clone and build:

git clone https://github.com/ankitpokhrel/jira-cli.git
cd jira-cli
make build

Or install directly:

go install github.com/ankitpokhrel/jira-cli/cmd/jira@latest

Run initialization to configure Jira credentials:

jira init

Daily commands: After installation and jira init (one-time setup with Jira URL, username, API token), run commands like:

jira issue list          # List issues
jira issue view PROJ-123 # View issue
jira issue create        # Interactive issue creation
jira board list          # List boards
jira epic list           # List epics

Completion setup: jira completion bash | source (see internal/cmd/completion/completion.go)

• cmd/jira/main.go: Entry point; initializes Cobra root command and loads configuration
• api/client.go: All Jira REST API interaction; authentication, HTTP client, request/response handling
• internal/cmd/issue/issue.go: Root issue command defining subcommands (assign, create, view, list, etc.); reference implementation for command structure
• internal/cmd/init/init.go: One-time setup storing Jira URL, username, API token in config; sets up keyring integration
• internal/cmd/epic/create/create.go: Example of interactive command flow using survey/v2 prompts and create operations
• .golangci.yml: Linting configuration; enforces code quality standards across the project
• Makefile: Build, test, and release orchestration; defines development workflows

Adding a new command: Create internal/cmd/mycommand/mycommand.go following the pattern in internal/cmd/issue/issue.go or internal/cmd/board/board.go. Modifying API calls: Edit api/client.go for new endpoints. Adding interactive flows: Use github.com/AlecAivazis/survey/v2 (see internal/cmd/epic/create/create.go for examples). Updating config: Modify internal/cmd/init/init.go. Terminal UI: Use rivo/tview as seen in list commands.

Jira authentication: Requires Jira API token, not password; set via jira init which stores in system keyring (zalando/go-keyring). On headless systems, keyring access may fail silently. Interactive prompts: survey/v2 requires TTY; piped input or non-interactive shells will hang. API rate limits: No explicit backoff in visible code; high-volume operations may hit Jira Cloud rate limits. Config storage: Jira config stored in $HOME/.config/jira/config.yml (Viper default); missing config silently fails some commands.

• Jira REST API v3 Authentication (Bearer Token) — JiraCLI uses API token-based auth (not password) managed via system keyring in api/client.go; understanding scopes, token rotation, and rate limits is critical for secure credential handling
• Interactive CLI Pattern (Prompts → Validation → Action) — Core UX of jira-cli relies on survey/v2 multi-choice/text prompts feeding into create/assign operations; seen throughout internal/cmd/issue, internal/cmd/epic/create, understanding the prompt→validate→execute flow is essential
• Terminal UI Rendering (TUI) with tview — List commands use rivo/tview to render tables and interactive selections; tview's event loops and widget management differ significantly from web UI frameworks
• Cobra Command Composition & Flag Parsing — Every command in internal/cmd/* is a Cobra Command; understanding persistent flags (stored in config), subcommand composition, and flag inheritance is fundamental to modifying or adding commands
• System Keyring Integration (zalando/go-keyring) — Credentials stored securely in OS keyring (macOS Keychain, Linux Secret Service, Windows Credential Manager) via zalando/go-keyring; failure to understand fallback behavior on headless systems can cause silent auth failures
• Viper Configuration Management (Hierarchical Config) — Jira config loaded from multiple sources (env vars override file) via Viper; internal/cmd/init/init.go sets defaults; understanding precedence (env > file > default) prevents config override bugs
• Markdown-to-HTML/Confluence Rendering Pipeline — charmbracelet/glamour and russross/blackfriday/v2 render issue descriptions for terminal display; this is non-trivial for ANSI color and layout; kentaro-m/blackfriday-confluence enables wiki format export

• go-jira/jira-cli — Alternative Jira CLI tool in Go; different command structure and less interactive, useful comparison for feature design
• atlassian/jira-python — Official Jira Python library; reference for REST API patterns and which endpoints to support
• cli/cli — GitHub's CLI reference implementation; uses Cobra (same as jira-cli), excellent pattern for command structure and interactive prompts
• spf13/cobra — Underlying CLI framework; understanding Cobra's command composition and flags is essential for extending jira-cli
• spf13/viper — Config management library used for storing Jira credentials and settings; required knowledge for config handling

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add unit tests for api/client.go with mocked HTTP responses

The repo has comprehensive Jira API client code in api/client.go but lacks visible unit test coverage. Given the critical nature of API interactions and the variety of endpoints touched across internal/cmd modules (issue, epic, board operations), adding tests with mocked HTTP responses would catch regressions early and serve as documentation for API contract expectations.

• [ ] Create api/client_test.go with table-driven tests for common API methods
• [ ] Use httptest.NewServer to mock Jira API responses for key endpoints (GET /issue, POST /issue, etc.)
• [ ] Test error handling for auth failures, rate limiting, and malformed responses
• [ ] Add tests for query parameter building and request marshaling
• [ ] Ensure tests cover both cloud and server Jira variants if client supports both

Add integration tests workflow in .github/workflows for end-to-end CLI scenarios

The repo has ci.yml and docker.yml workflows but no integration test workflow. Given the interactive nature of this CLI (uses survey, tview for UI) and the complexity of command chains (issue create → assign → link), an integration test workflow using docker-compose.yml (which already exists) could validate real workflows against a test Jira instance.

• [ ] Create .github/workflows/integration.yml that runs on push to main and PRs
• [ ] Use docker-compose.yml to spin up a Jira test instance (already configured)
• [ ] Add shell scripts in a new tests/integration/ directory for scenario-based testing (e.g., create-assign-move workflow)
• [ ] Test with generated credentials and validate CLI output matches expected results
• [ ] Configure workflow to report coverage metrics back to PR

Add comprehensive error handling documentation and validation for internal/cmd subcommands

The cmd structure shows many subcommands (issue/create, issue/edit, epic/create, etc.) but error paths are difficult to trace. Many of these likely share validation logic (required fields, JQL parsing, format validation) that could be extracted. Adding a validation package and documenting error scenarios would reduce bugs in user-facing commands.

• [ ] Create internal/cmd/validation/validators.go with reusable validators (JQL, issue key, priority, status transitions)
• [ ] Add unit tests in internal/cmd/validation/validators_test.go with edge cases (empty strings, invalid characters, type mismatches)
• [ ] Refactor internal/cmd/issue/create/create.go and internal/cmd/epic/create/create.go to use common validation
• [ ] Document validation rules in README.md or docs/ (e.g., valid field names, JQL syntax examples)
• [ ] Add integration tests validating error messages are user-friendly when validation fails

• Add integration tests for api/client.go endpoints; test file missing despite heavy API usage across all commands
• Implement pagination helpers for board/list and epic/list commands to handle >50 items (see survey/v2 pagination examples)
• Add markdown-to-Confluence wiki format conversion for issue descriptions (infrastructure exists: kentaro-m/blackfriday-confluence dependency imported but unused)

• High · Outdated Alpine Base Image in Dockerfile — Dockerfile, line: FROM alpine:3.19. The Dockerfile uses Alpine 3.19 as the final base image, which is outdated. Alpine 3.19 reached end of life and no longer receives security updates. This exposes the container to known vulnerabilities that won't be patched. Fix: Update to a maintained Alpine version (currently 3.20 or later). Change 'FROM alpine:3.19' to 'FROM alpine:3.20' or the latest stable version available.
• High · Outdated PostgreSQL Image in Docker Compose — docker-compose.yml, line: image: postgres:12.9-alpine. The docker-compose.yml uses PostgreSQL 12.9-alpine which is outdated and no longer actively maintained. PostgreSQL 12 reached end of life in October 2024. This exposes the service to unpatched security vulnerabilities. Fix: Upgrade to PostgreSQL 16 or 17 (currently maintained versions). Update to 'postgres:17-alpine' or 'postgres:16-alpine'.
• High · Outdated Atlassian Jira Image — docker-compose.yml, line: image: atlassian/jira-software:9.14.0. The docker-compose.yml uses 'atlassian/jira-software:9.14.0' which is an older version from 2023. This version likely contains multiple known security vulnerabilities that have been patched in newer releases. Fix: Update to the latest stable version of Atlassian Jira Software. Consult Atlassian's security advisories and update to version 9.16+ or the latest available version.
• Medium · Unencrypted Credentials in Docker Compose — docker-compose.yml, environment variables: POSTGRES_PASSWORD, JIRA_DB_PASSWORD. Database credentials (POSTGRES_PASSWORD=atlassian, JIRA_DB_PASSWORD=atlassian) are hardcoded in plain text in docker-compose.yml. While this is common in development, it's a security anti-pattern that could be accidentally committed to version control. Fix: Use Docker secrets, environment files, or external secret management. Never commit credentials to version control. Use '.env' files with git ignore, or better yet, use Docker secrets or HashiCorp Vault for production.
• Medium · Missing Security Headers in Dockerfile — Dockerfile. The Dockerfile doesn't include security hardening practices such as running as a non-root user, removing unnecessary packages, or applying security updates. The final image contains 'ca-certificates' but lacks other hardening measures. Fix: Add non-root user creation, minimal dependencies, and security updates. Example: Add 'RUN addgroup -g 1000 app && adduser -D -u 1000 -G app app' and use 'USER app' before ENTRYPOINT.
• Medium · Jira Service Exposed on HTTP Port 80 — docker-compose.yml, ports: '80:8080'. The docker-compose.yml exposes Jira on port 80 using HTTP without encryption. This allows traffic to be intercepted and compromised, especially problematic when handling authentication credentials and sensitive project data. Fix: Configure HTTPS/TLS with a reverse proxy (nginx, traefik) or use a higher port mapping with proper SSL termination. Set JIRA_PROXY_SCHEME to 'https' and configure proper certificates.
• Medium · Outdated Go Version for Security Patches — go.mod. The go.mod specifies 'go 1.25.0' with toolchain 'go1.25.6'. Go 1.25 is relatively new, but the specific patch version should be kept updated. Security advisories in Go dependencies require timely updates. Fix: Regularly update Go to the latest patch version and monitor golang.org/x/security advisories. Implement automated dependency scanning with 'go list -u -m all' and update critical dependencies.
• Low · Missing Security Policy — Repository. There is no SECURITY.md or security policy documented in the repository, which makes it difficult for security researchers to responsibly disclose vulnerabilities. Fix: undefined

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.