Scribe: add Jira issue creation support

Summary

Scribe should support creating Jira issues in addition to GitHub issues, converging with the work being done in konflux-ci/scribe4jira.

Context

Split from fullsend-ai/fullsend#5869. Scribe now has its own app identity via the scribe mint role added in fullsend-ai/fullsend#5895. Jira integration expands Scribe's capabilities to teams that track work in Jira rather than (or in addition to) GitHub Issues.

Requirements

Scribe should be able to create issues in Jira projects.
The implementation should converge with the existing work in konflux-ci/scribe4jira rather than building from scratch.
Use the existing operator-provided Jira email/API-token authentication contract. Define Jira authentication strategy: interim service account credentials fullsend#4885 and JIRA identity and credential management fullsend#2269 remain related authentication follow-ups, rather than prerequisites for this MVP.
Delegate Jira issue creation to the shared Fullsend CLI primitive so Scribe and other agents can reuse the same implementation.

Open questions

What is the scope of convergence with konflux-ci/scribe4jira — adopt it as-is, fork, or reimplement?
Which Jira field mappings are needed for meeting-note-derived issues?

Implementation dependency

Blocked for integration/merge on fullsend PR #8182 — fullsend issues create, implementing fullsend issue #7083.

The two-repository split is:

Fullsend: provide the shared issue-creation CLI/tracker operation and backend API handling.
Agents: update Scribe PR #1678 to call that operation, retaining Scribe-specific interpretation, matching, content gates, project configuration, and dry-run behavior.

Unblock when the upstream operation is merged and available in the CLI version used by the deployment, and #1678 has adopted and tested it. Verify that the integration preserves the required issue fields, including labels, and creation-field validation; merging #8182 alone does not migrate Scribe.

This is a concrete shared-implementation dependency, distinct from the earlier authentication/provider blockers. Operator-provided credentials and host-side writes remain the agreed MVP approach. Retro adoption is separate follow-up work and is not required to complete this issue.

/fs-triage lots of things have changed between when this was originally filed and now across both the https://github.com/fullsend-ai/fullsend and https://github.com/fullsend-ai/agents repos. Is this still relevant? This is a stale-issue review, not an implementation request: even if the issue is still a valid bug and has sufficient information, do not recommend or trigger ready-to-code yet. Leave it for human prioritization after confirming whether it remains relevant. Do not close a still-relevant bug merely to avoid coding it.

🤖 Finished Triage · ❌ Failure (agent timed out after 10m0s without completing (timeout: 10m0s)) · Started 6:00 PM UTC · Completed 6:12 PM UTC

Commit: 86f9e98 · View workflow run →

Runtime: claude · Model: sonnet → claude-sonnet-5 · Effort: high

@Shiri-sh

/fs-triage we are ready to work on this issue, @Shiri-sh has created a custom fullsend scribe4jira agent that proved the capabilities of this functionality I mirrored her work here so that you can observe it https://github.com/ascerra/scribe4jira unless maybe you can read the actual repo she created here https://github.com/konflux-ci/scribe4jira but I'm not sure if you can access this.

Our goal is to learn from this and add jira write support to the core agents repo here. Outline the architecture and any potential problems you see.

🤖 Finished Triage · ✅ Success · Started 4:39 PM UTC · Completed 4:41 PM UTC

Commit: a159f38 · View workflow run →

Runtime: claude · Model: sonnet → claude-sonnet-5-5 · Effort: high · Cost: $0.31

This issue is still relevant, and it is blocked on upstream work. Here is an architecture outline based on the current repo and the scribe4jira mirror you shared.

What exists today

Scribe (agents/scribe.md, harness/scribe.yaml, scripts/pre-scribe.src.sh, scripts/post-scribe.src.sh) is forge-pluggable through scripts/lib/scribe-ops.lib.sh, which sources a GitHub or GitLab ops library. The contract is small: forge_fetch_* for backlog, closed issues and PRs, plus forge_list_issue_comments, forge_post_issue_comment, forge_create_issue and forge_issue_url_base.
The agent never writes. The post-script validates the JSON result and does all the writes (confidence, public_safe, code-fence and idempotency checks).
Jira support exists for triage and code (scripts/lib/jira-triage-ops.lib.sh, providers/jira-ro.yaml), but only read-only for the agent.
scribe4jira is a self-contained Python package with its own harness and policy. It has a Jira REST client with ADF conversion, deterministic gates (PII, suspicious Unicode, length caps), a project-scope check, an idempotency check on the notes URL, and a dry-run flag. Jira credentials stay on the host; only inference credentials enter the sandbox.

Suggested architecture

Add jira-scribe-ops.lib.sh with the same forge_* functions and a jira case in scribe-ops.lib.sh. Reuse the existing Jira helpers where possible; for ADF/markdown conversion, reuse the fullsend issues post-comment --tracker jira path rather than porting the Python ADF code.
Keep the agent prompt and scribe-result.schema.json tracker-neutral. Jira-specific values (project key, issue type, priority, labels) should be set host-side from config, not chosen by the model.
Keep all Jira writes in the post-script. Add a write-capable provider (see the prerequisite below) and a Jira overlay in harness/scribe.yaml, following the when: overlay pattern in harness/triage.yaml.
Port scribe4jira's gates and idempotency check into the shell post-script (or share them). Reconcile them with the gates that already exist here.
On convergence: scribe4jira's gates and Jira client are worth adopting. Its harness, Python runtime and Drive-source fetcher duplicate what this repo already provides. Reimplementing against the forge-ops contract is likely cleaner than adopting it as-is, but that is a maintainer decision.

Potential problems

Blocked on auth strategy. The Jira authentication strategy (fullsend#4885) is open, and the Jira project-enrollment ADR PR is also open.
No write provider. Only a read-only Jira provider and profile exist here. A write-capable provider must come from the fullsend CLI/mint side, which is outside this repo. A tracking issue is proposed for that.
Data leakage. Meeting-derived content going into Jira from a public repo's configuration is a known risk area. The scribe4jira docs explicitly say to run it in a private deployment, and CI artifacts can contain meeting text even on a dry run.
Mixed backlog. Duplicate and backlog matching needs JQL pagination (nextPageToken), and existing_issue is an integer in the schema while Jira keys are strings. The schema, pre-scribe backlog format and the post-script's numeric checks all need a string-key path.
Per-instance field mapping. Issue types, priorities and required custom fields vary by Jira project and fail at create time, so validate the project up front, as scribe4jira does.
Upstream not reviewed. The konflux-ci/scribe4jira repo was not accessible here; only the mirror was reviewed.
Identity. FULLSEND_FORGE selects one forge per run, so GitHub context plus Jira writes needs an explicit decision.

Once the auth strategy and write provider are settled, this can be re-triaged for implementation. As requested earlier, no implementation hand-off is recommended yet.

Blocked by:

Could not create automatically (file manually or update create_issues.allow_targets in config.yaml):

Prerequisite: fullsend-ai/fullsend — Add a Jira write-capable provider/profile (fullsend-jira-rw) for agents that create issues and comments

The agents repo ships only a read-only Jira provider and profile (type fullsend-jira-ro, endpoint access read-only, curl binary). The Scribe agent needs to create Jira issues and add comments (POST/PUT against /rest/api/3/issue and /rest/api/3/issue/{key}/comment), but the agent must never see the real Jira token.

Requested:

A write-capable provider type/profile (e.g. fullsend-jira-rw) whose placeholder token is substituted by the egress proxy, scoped to *.atlassian.net, usable from a host-side post-script (preferred, matching how GitHub/GitLab writes are done after the agent exits) and, if needed, from the sandbox.
Confirmation of how the scribe mint role (added with the opt-in scribe agent role) should obtain/hold Jira credentials, consistent with the outcome of the Jira authentication strategy decision (interim long-lived service account credentials).
Guidance on Jira data-leakage constraints for public repositories when Scribe writes meeting-derived content into Jira.

If this is already covered by existing work on Jira identity and credential management, please link it and close this as a duplicate.

/fs-triage I agree with keeping Jira writes in the host-side post-script and preserving Scribe’s validation boundary. However, I don’t think this issue needs to remain blocked on authentication strategy, enrollment tooling, or a new write-capable provider.
Authentication already has an accepted initial path. The official Jira setup documents operator-provided JIRA_TOKEN, JIRA_USER_EMAIL, and JIRA_BASE_URL. fullsend#2269 explicitly says that teams bring their own service account for the MVP and that the mint is not a prerequisite. The latest assessment on #4885 also says interim authentication is implemented and documented; rotation guidance and future authentication remain follow-up work. We can initially support that existing email/API-token contract without promising every Atlassian service-account or OAuth credential model.
Host-side writes do not require a new sandbox write provider. The agents repo already has a Jira issue-creation implementation using the runner’s credentials. Scribe can similarly pass prepared context into the sandbox, receive structured proposals, validate them, and perform writes afterward. Core Fullsend also already ships a read-write Atlassian profile, although sandbox write access is unnecessary for this approach.
The remaining points should become implementation requirements within this issue:

Separate hosting from the destination tracker. GitHub/GitLab hosting and optional repository context should remain distinct from Jira backlog matching and writes. There is already an applicable pattern: triage selects FULLSEND_TRACKER, falling back to FULLSEND_FORGE. Scribe needs to adopt that separation rather than treating Jira as a replacement for every repository operation.
Support scheduled and manual execution. Scribe should run through scheduled or manually triggered workflows on GitHub Actions or GitLab CI, collecting meeting notes and creating Jira issues. Scheduling Scribe is separate from polling Jira for events: Jira event polling and automated project enrollment are outside this MVP. Operators can configure the target Jira project and credentials directly.
Make the data contract Jira-aware while preserving existing behavior. The current schema and post-script validation assume numeric issue identifiers. Jira keys, normalized backlog records, URLs, pagination, and matching need explicit support and regression tests. Comment writes should remain disabled until their string-key path is implemented.
Configure fields host-side and fail clearly on unsupported projects. Start with one configured project and issue type, with validated defaults and any required field configuration. The reference client’s validate_project checks project accessibility; it does not establish that all required creation fields are satisfied. Jira exposes creation metadata for that distinction.
Reuse the reference implementation selectively. The public source and tests provide pagination, ADF conversion, gates, and project-scope checks to evaluate and reuse. A wholesale rewrite into shell is not inherently required. Also, its notes-URL duplicate check checks returned comments without paginating them; it should not be treated as complete rerun protection for comments or new issues.
I suggest an initial delivery of new Jira issues from meeting notes through scheduled or manually triggered workflows, using operator-provided credentials in a private deployment, with dry-run enabled by default. Acceptance should include project scoping, preserved content gates, accurate pagination/truncation handling, duplicate prevention on reruns, and tests proving rejected output and dry-runs perform no writes. Logs and artifacts must remain private even during dry-runs. Any installed schedule should remain disabled until the operator explicitly enables it.
Could we remove #4885 and #2269 as blanket blockers, retain them as related follow-ups, and re-triage against this bounded scope? That would clarify implementation readiness while leaving prioritization and any implementation hand-off to maintainers.

🤖 Finished Triage · ✅ Success · Started 5:08 PM UTC · Completed 5:10 PM UTC

Commit: a159f38 · View workflow run →

Runtime: claude · Model: sonnet → claude-sonnet-5-5 · Effort: high · Cost: $0.29

/fs-code

🤖 Finished Code · ✅ Success · Started 5:38 PM UTC · Completed 5:46 PM UTC

Commit: a159f38 · View workflow run →

Runtime: claude · Model: opus → claude-opus-5-5 · Effort: high · Cost: $2.56

Related Jira work: retro and prioritize

Related issues:

Add JIRA support to the retro agent fullsend#2267 — Add JIRA support to the retro agent
Add JIRA support to the prioritize agent fullsend#2266 — Add JIRA support to the prioritize agent

Implementation under review: #1678

The Scribe implementation offers reusable building blocks for these issues: Jira Cloud backlog reads with pagination, ADF conversion, host-side issue creation, creation-field validation, and exact-summary duplicate checks in scripts/lib/jira-scribe-ops.lib.sh. It also separates the issue tracker from the repository forge through FULLSEND_TRACKER.

The strongest overlap is with retro's Jira follow-up issue creation requirements. Prioritize can reuse issue-reading/conversion patterns, but still needs its own Jira input integration and score write-back. Neither agent automatically inherits this support: the implementation is currently Scribe-specific and uses SCRIBE_JIRA_* configuration.

The bounded host-side write approach uses operator-provided credentials and does not require a new sandbox write provider, as clarified in #1676 (comment). Jira comments, event polling, and automated project enrollment remain outside this MVP.

Suggested relationship: related/reusable implementation work, rather than treating this issue as completion of either feature or a mandatory prerequisite for starting them. Shared configuration should follow the harness-composition boundary in ADR 0080.

AI-generated. Review for accuracy.

🤖 Finished Triage · ✅ Success · Started 7:17 PM UTC · Completed 7:19 PM UTC

Commit: a159f38 · View workflow run →

Runtime: claude · Model: sonnet → claude-sonnet-5-5 · Effort: high · Cost: $0.14

This issue is already being addressed: an open, ready-for-review PR implements the bounded MVP (new Jira issues only, one operator-configured project and issue type, host-side writes with operator-provided credentials, dry-run support, and FULLSEND_TRACKER kept separate from the hosting forge).

Remaining gate before merge: the PR states it is blocked for merge on the upstream fullsend issues create CLI work (fullsend PR #8182, tracking issue #7083), which is still open. Once that lands, the PR should switch from its current direct Jira creation path to the shared CLI command, pin and document the CLI version, and confirm that labels and creation-field validation are preserved. This is a merge dependency for the existing PR, not a reason to start separate work.

Carried-forward points from earlier triage that the PR review should confirm:

The result schema and post-script validate existing_issue as an integer. Jira keys such as PROJ-123 need a string path, with regression tests showing GitHub/GitLab still reject non-numeric values.
Check required create fields via createmeta before any write, not only project access.
Backlog matching and rerun protection must paginate fully (nextPageToken).
Meeting content is a leakage risk in Jira, so logs and artifacts should stay private, including during dry-run.
fullsend#4885 and #2269 (authentication follow-ups) remain related, not blockers, for the operator-credential MVP.

The upstream scribe4jira repository could not be reviewed; only the public mirror was. The Jira helpers in this PR may also be reusable for the retro and prioritize Jira issues, but those are related follow-ups, not prerequisites or completed by this work.

Addressed by:

feat(#1676): add Jira issue creation support to scribe #1678

refactor(fullsend-ai#1676): delegate Jira issue creation to fullsend …

@ascerra

@ascerra I opened this PR to continue the work you started #1739. I've also left a comment on your PR at #1678. Since my PR is now updated with the new CLI command, I think it would probably replace the original one you opened. Just wanted to call this out here in this issue.

refactor(fullsend-ai#1676): delegate Jira issue creation to fullsend …

fix(fullsend-ai#1676): address Qodo review findings for Jira scribe i…

Navigation Menu

Repository navigation

Scribe: add Jira issue creation support #1676

Summary

Context

Requirements

Open questions

Implementation dependency

11 remaining items

Related Jira work: retro and prioritize

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Scribe: add Jira issue creation support #1676

Description

Summary

Context

Requirements

Open questions

Implementation dependency

Activity

ralphbean commented on Sep 24, 2026

fullsend-ai-triage commented on Sep 24, 2026

ascerra commented on Oct 14, 2026

fullsend-ai-triage commented on Oct 14, 2026

fullsend-ai-triage commented on Oct 14, 2026

ascerra commented on Oct 14, 2026

fullsend-ai-triage commented on Oct 14, 2026

11 remaining items

ascerra commented on Oct 14, 2026

fullsend-ai-coder commented on Oct 14, 2026

redhat-chai-bot commented on Oct 14, 2026

Related Jira work: retro and prioritize

fullsend-ai-triage commented on Oct 14, 2026

fullsend-ai-triage commented on Oct 14, 2026

andrewevansrh commented on Oct 21, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions