Skip to content

Jira

Developer Reference

This page covers internal implementation details. It is not included in the User Guide.

Jira is a routing target in the integrations agent. The handler classifies queries as jira and forwards them to the code-gen agent for Python script generation.


Repo

escher-dbai/v4-integrations-agent-gointernal/integrations/jira/handler.go


Flow

User query (NL)


Integrations Agent classifier (Haiku)
   {"integration": "jira", "confidence": ...}


Jira handler:
   - emits SSE thinking_state
   - builds CodeGenRequest{ Action: "jira", UserQuery, ConversationContext, ... }
   - calls Code-Gen Agent (POST /api/v1/generate-playbook)
   - proxies the SSE stream back to the client

Same shape as the Linear and GitHub handlers. The handler is a router — it does not implement Jira-specific business logic.


What this is not

The integrations-agent codebase does not contain:

  • A field-mapping engine (Finding severity → Jira priority, etc.)
  • A two-way status sync engine (Jira ticket closed → Finding closed)
  • A saved-rule store ("auto-create a ticket whenever Finding severity ≥ X")
  • An OAuth-installed Jira app

Today's behaviour: each query produces a fresh Python script that calls the Jira REST API once. Mapping, attachment, and status reasoning are encoded in the prompt the user gives Escher, not in stored rules.


Adding capability

Extend the code-gen agent's prompt corpus for action: "jira". Improving classification accuracy is done by editing prompts/integration-classifier.txt in this repo.


See also

  • Linear — same pattern
  • GitHub — same pattern
  • Slack — handled in-house, not via code-gen

Escher — Agentic CloudOps by Tessell