---
id: capability.infotech.issue-tracking
name: Universal Issue Tracking Coordination
summary: Unified Python/CLI interface for issue tracking across Gitea, GitHub, and GitLab, preventing
  direct platform API usage and credential sprawl for coordinating agents.
owner: issue-core
status: draft
domain: infotech
tags:
- issue-tracking
- coordination
- multi-platform
maturity:
  discovery:
    current: D4
    target: D5
    confidence: high
    rationale: Repo already carries its own detailed capability manifest (CAPABILITY-issue-tracking.yaml)
      plus AGENT_INTEGRATION.md, ROADMAP.md, and a .capability/ feedback-submission mechanism; usage rules,
      API surface, and credential handling are all explicitly documented. This entry migrates that existing
      description into the standard registry location rather than drafting fresh.
  availability:
    current: A2
    target: A3
    confidence: high
    rationale: Both a Python API (`from issue_core.backends.gitea import GiteaBackend`) and a CLI (`issue
      list/create/show/edit/close/comment`, JSON output) are installable via pip; MCP server is planned
      but not yet available.
external_evidence:
  completeness:
    level: C2
    confidence: low
    basis: scope_vs_intent_and_consumer_expectations
    satisfied_expectations:
    - Gitea backend implemented; GitHub/GitLab described in scope
    - CLI with JSON output and offline/local caching
    - credential handling via env vars per credential-routing conventions (GITEA_API_TOKEN, never in code/logs)
    broken_expectations: []
    out_of_scope_expectations: []
  reliability:
    level: R1
    confidence: low
    basis: consumer_quality_signals
    known_reliability_risks:
    - manual backend configuration required in v1.0 (auto-detect planned for v1.1)
    - no built-in issue locking beyond assignee+comment convention
    - MCP server not yet available
discovery:
  intent: Give coordinating agents a single, credential-safe interface for issue tracking across Gitea/GitHub/GitLab
    instead of direct platform API calls, CLI wrapping, or custom scripts.
  includes:
  - unified Python API and CLI over Gitea/GitHub/GitLab issue operations
  - local caching and offline mode
  - credential handling via environment variables
  excludes:
  - MCP server (planned, not yet shipped)
  - distributed locking and query DSL (roadmapped for v2.0)
  assumptions: []
  use_cases: []
  research_memos: []
availability:
  current_level: A2
  target_level: A3
  current_artifacts:
  - Python package (`issue_core`)
  - '`issue` CLI'
  target_artifacts: []
  consumption_modes:
  - cli
  - library import
relations:
  depends_on: []
  supports: []
  related_to: []
evidence:
  documentation:
  - CAPABILITY-issue-tracking.yaml
  - AGENT_INTEGRATION.md
  - ROADMAP.md
  tests:
  - tests/ (109 tests, 61% coverage per CAPABILITY-issue-tracking.yaml testing section)
  consumer_feedback: []
  bug_reports: []
  incidents: []
consumer_guidance:
  recommended_for:
  - agents coordinating via Gitea/GitHub/GitLab issues who would otherwise call platform APIs directly
  not_recommended_for:
  - needs requiring MCP server integration (not shipped yet)
  known_limitations:
  - manual backend configuration in v1.0; no built-in issue locking beyond assignee convention
promotion_history: []
---

# Universal Issue Tracking Coordination

## Overview

`issue-core` is a universal interface for issue-tracking coordination across Gitea, GitHub, and GitLab, giving agents a unified Python API and CLI instead of direct platform API calls. This registry entry migrates the repo's own pre-existing `CAPABILITY-issue-tracking.yaml` capability manifest (109 tests, 61% coverage, documented usage rules and credential handling) into the standard `registry/capabilities/` location.

## Assessment notes

### Discovery

Repo already carries its own detailed capability manifest (CAPABILITY-issue-tracking.yaml) plus AGENT_INTEGRATION.md, ROADMAP.md, and a .capability/ feedback-submission mechanism; usage rules, API surface, and credential handling are all explicitly documented. This entry migrates that existing description into the standard registry location rather than drafting fresh.

### Availability

Both a Python API (`from issue_core.backends.gitea import GiteaBackend`) and a CLI (`issue list/create/show/edit/close/comment`, JSON output) are installable via pip; MCP server is planned but not yet available.

### Completeness

First-pass honest assessment from the REUSE-WP-0017 coverage campaign
(reuse-surface). No external consumer feedback exists yet; levels reflect
scope-vs-intent documentation quality, not internal code quality.

### Reliability

No production consumer telemetry exists yet; reliability level is
intentionally conservative pending REUSE-WP-0019 reuse-telemetry evidence.

## Promotion checklist

- [x] ID follows `capability.<domain>.<name>` pattern
- [x] Maturity enums match `specs/CapabilityMaturityStandard.md`
- [x] `external_evidence` is populated separately from `maturity`
- [ ] Relations reference valid capability IDs (none yet)
- [x] Index entry added in `registry/indexes/capabilities.yaml`