odin-jira

name	odin-jira
description	Analyzes a TEN JIRA issue, implements a fix across EUX repositories, creates PRs, and reports back to JIRA with results and reviewer tags.

Odin JIRA — Automated Fix Skill

Takes a TEN JIRA issue key (e.g. TEN-742), analyzes the problem, implements a fix across the relevant EUX repositories, creates pull requests, and reports back to JIRA.

Safety rules — ALWAYS follow these

1. Project scope: Only operate on project TEN. Never create or modify issues in other projects.
2. NEVER commit to main or master: Always create a feature branch. Never push directly to main or master.
3. NEVER deploy backends: Only deploy eux-web-app (frontend) to odin environments. Never trigger backend deploy workflows.
4. Always use --yes on acli edit, transition, and assign commands to avoid interactive prompts.
5. Be concise in JIRA comments and PR descriptions. No filler text.
6. Verify before PR: Always verify that changes compile/build and are correct before creating pull requests.
7. One branch per repo: Use the same branch naming convention across all affected repos: fix/<ISSUE-KEY>-<short-description>.
8. Write Norwegian: All JIRA comments must be written in concise Norwegian (bokmål). PR titles and descriptions remain in English.

Reviewer tagging rules

When commenting on JIRA after creating PRs, use proper ADF mention nodes so reviewers receive JIRA notifications. Plain text names do NOT trigger notifications.

Reviewer account IDs

Use these Atlassian account IDs to build ADF mention nodes:

Repository	Reviewer	Atlassian Account ID
eux-web-app	Dey Rittik	62f25d6ef15eecaf500fbbe8
eux-rina-api	Arild Spikkeland	557058:db5de1a2-5606-4749-8a0e-03d7f89682a3
eux-fagmodul-journalfoering	Arild Spikkeland	557058:db5de1a2-5606-4749-8a0e-03d7f89682a3
eux-nav-rinasak	Vegard Hillestad	712020:9222ebea-ab05-497c-81f6-38a689b6d0f4
eux-neessi	Vegard Hillestad	712020:9222ebea-ab05-497c-81f6-38a689b6d0f4
eux-person-oppdatering	Knut Bjørnar Wålberg	62b035ab673f2103622cb2a9
eux-barnetrygd	Knut Bjørnar Wålberg	62b035ab673f2103622cb2a9
eux-legacy-rina-events	Torsten Kirschner	557058:941fd5b5-9b73-45a6-b54a-cc95bd6bf555
eux-all-rina-events	Torsten Kirschner	557058:941fd5b5-9b73-45a6-b54a-cc95bd6bf555

Multiple repos may be changed — mention all relevant people.

ADF (Atlassian Document Format)

Always use ADF JSON for JIRA comments. Always use --body-file to pass ADF — never pass ADF inline via --body (shell escaping will mangle the JSON and acli will post it as raw text).

Workflow for ADF comments

1. Build the ADF JSON object in memory.
2. Write it to a temp file (e.g. /tmp/odin-comment.json).
3. Pass the file via --body-file.
4. Delete the temp file.

cat > /tmp/odin-comment.json << 'ENDOFJSON'
{"version":1,"type":"doc","content":[{"type":"paragraph","content":[{"type":"text","text":"Comment text"}]}]}
ENDOFJSON
acli jira workitem comment create --key TEN-123 --body-file /tmp/odin-comment.json
rm -f /tmp/odin-comment.json

ADF structure

{"version":1,"type":"doc","content":[...nodes]}

Common node types

Paragraph:

{"type":"paragraph","content":[{"type":"text","text":"Some text"}]}

Heading (level 1-3):

{"type":"heading","attrs":{"level":3},"content":[{"type":"text","text":"Title"}]}

Bullet list:

{"type":"bulletList","content":[
  {"type":"listItem","content":[{"type":"paragraph","content":[{"type":"text","text":"Item"}]}]}
]}

Bold text:

{"type":"text","text":"bold text","marks":[{"type":"strong"}]}

Link:

{"type":"text","text":"click here","marks":[{"type":"link","attrs":{"href":"https://example.com"}}]}

Mention (triggers JIRA notification):

{"type":"mention","attrs":{"id":"<accountId>","text":"@Display Name","accessLevel":""}}

Example — mention Vegard Hillestad:

{"type":"mention","attrs":{"id":"712020:9222ebea-ab05-497c-81f6-38a689b6d0f4","text":"@Vegard Hillestad","accessLevel":""}}

### ADF guidelines

- **NEVER pass ADF inline via `--body`** — always write to a temp file and use `--body-file`.
- Keep ADF as single-line JSON (no pretty-printing) inside the file.
- Use heredoc with single-quoted delimiter (`<< 'ENDOFJSON'`) to prevent shell variable expansion.

## Command reference (acli)

### View an issue

```bash
acli jira workitem view TEN-123
acli jira workitem view TEN-123 --json
acli jira workitem view TEN-123 --fields "summary,status,comment,assignee,reporter,description"

Add a comment

cat > /tmp/odin-comment.json << 'ENDOFJSON'
{"version":1,"type":"doc","content":[{"type":"paragraph","content":[{"type":"text","text":"Comment text"}]}]}
ENDOFJSON
acli jira workitem comment create --key TEN-123 --body-file /tmp/odin-comment.json
rm -f /tmp/odin-comment.json

Search issues

acli jira workitem search --jql "project = TEN AND key = TEN-123" --limit 1

Steps

When invoked with a JIRA issue key (e.g. /odin-jira TEN-742):

Step 1 — Assign, transition, and comment that work has started

First, determine the current user's identity:

acli jira auth status

Assign the issue to the person who initiated the skill, and transition it to "Under arbeid":

acli jira workitem assign --key TEN-742 --assignee "@me" --yes
acli jira workitem transition --key TEN-742 --status "Under arbeid" --yes

Then add a comment announcing that work is in progress:

cat > /tmp/odin-comment.json << 'ENDOFJSON'
{"version":1,"type":"doc","content":[{"type":"paragraph","content":[{"type":"text","text":"🤖 Odin is analyzing this issue and working on a fix. Stand by for updates."}]}]}
ENDOFJSON
acli jira workitem comment create --key TEN-742 --body-file /tmp/odin-comment.json
rm -f /tmp/odin-comment.json

Step 2 — Analyze the JIRA issue

Fetch the full issue details to understand what needs to be done:

acli jira workitem view TEN-742 --json

Read the summary, description, and comments carefully. Understand:

• What is the problem or request?
• What behavior is expected vs actual?
• Are there stack traces, error messages, or specific SED/BUC types mentioned?
• Are there any comments with additional context?

Step 3 — Evaluate description quality

Check for an existing plan: Look through the comments for one with the heading "Odin's plan" (posted by odin-plan). If a plan comment exists, use it as the primary guide for which repositories to change, which files to modify, and what the changes should be. Still verify the plan against the code, but follow its structure and intent.

Before attempting implementation, evaluate whether the issue description or the plan contains enough information to act on. A description is sufficient if you can answer all of these:

1. What is the problem or desired change?
2. Where in the system does it occur? (which service, screen, flow, SED/BUC type, etc.)
3. How to reproduce or verify it? (steps, example data, error messages, screenshots, or expected vs actual behavior)

If the description is sufficient → proceed to Step 4.

If the description is insufficient → comment on the JIRA issue explaining what is missing, then stop. Do not attempt implementation. Example:

acli jira workitem comment create --key TEN-742 \
  --body '{"version":1,"type":"doc","content":[
    {"type":"heading","attrs":{"level":3},"content":[{"type":"text","text":"🤖 Odin — Trenger mer informasjon"}]},
    {"type":"paragraph","content":[{"type":"text","text":"Kunne ikke starte automatisk fiks fordi beskrivelsen mangler nødvendige detaljer."}]},
    {"type":"heading","attrs":{"level":3},"content":[{"type":"text","text":"Hva mangler"}]},
    {"type":"bulletList","content":[
      {"type":"listItem","content":[{"type":"paragraph","content":[{"type":"text","text":"<konkret detalj som mangler, f.eks. hvilken SED-type, feilmelding, steg for å reprodusere>"}]}]}
    ]},
    {"type":"paragraph","content":[{"type":"text","text":"Oppdater beskrivelsen med de manglende detaljene, og kjør Odin på nytt."}]}
  ]}'

Tailor the "What is missing" bullets to the specific gaps. Be concrete — say exactly what information would unblock implementation.

Step 4 — Determine which repositories need changes

Use the EUX Architecture document (navikt/eux-architecture README.md) to understand the platform and identify which repositories are involved.

To read the architecture overview:

cat eux-architecture/README.md

Or if not locally available:

gh api repos/navikt/eux-architecture/contents/README.md --jq '.content' | base64 -d

Based on the issue analysis:

• Map the problem to specific services (e.g. journaling issues → eux-journalfoering, eux-journal; RINA case issues → eux-nav-rinasak, eux-rina-api; frontend issues → eux-web-app, eux-neessi).
• Clone or navigate to the relevant repositories.
• Search the code to confirm where the fix needs to go.

Step 5 — Create feature branches

For each repository that needs changes, determine the default branch (main or master), ensure it is up to date with GitHub, then create the feature branch from it:

cd <repo-directory>
DEFAULT_BRANCH=$(git remote show origin | grep 'HEAD branch' | awk '{print $NF}')
git checkout "$DEFAULT_BRANCH"
git pull origin "$DEFAULT_BRANCH"
git checkout -b fix/TEN-742-short-description

Use the same branch name pattern across all repos: fix/<ISSUE-KEY>-<short-description>.

CRITICAL:

• NEVER make changes directly on the default branch (main/master).
• ALWAYS git pull before branching to ensure you branch from the latest remote state.

Step 5.5 — Bump package.json version

After creating the feature branch, if the repository contains a package.json with a version field, bump it:

1. Determine bump type based on the scope of the change:

   • Minor bump (e.g. 1.2.3 → 1.3.0) — for feature-level changes, new behavior, or significant fixes.
   • Patch bump (e.g. 1.2.3 → 1.2.4) — for small bugfixes, typo corrections, or trivial changes.

2. Append a prerelease suffix derived from the branch name, converted to UPPERCASE:

   • Pattern: <bumped-version>-FIX-<ISSUE-KEY>-<SHORT-DESCRIPTION>
   • Example: branch fix/TEN-742-missing-sed-type → version 1.3.0-FIX-TEN-742-MISSING-SED-TYPE

3. Apply the change using npm version (or edit package.json directly if npm is not available):

# Read current version
CURRENT=$(node -p "require('./package.json').version")

# Decide bump type (minor or patch) based on your analysis
# For a significant fix:
BUMPED=$(node -p "const [ma,mi,pa] = '${CURRENT}'.replace(/-.*/, '').split('.').map(Number); \`\${ma}.\${mi+1}.0\`")
# For a small bugfix:
# BUMPED=$(node -p "const [ma,mi,pa] = '${CURRENT}'.replace(/-.*/, '').split('.').map(Number); \`\${ma}.\${mi}.\${pa+1}\`")

# Build the suffix from the branch name (strip 'fix/' prefix, uppercase everything)
SUFFIX=$(git branch --show-current | sed 's|^fix/||' | tr '[:lower:]' '[:upper:]' | tr '/' '-')

# Set the new version
NEW_VERSION="${BUMPED}-${SUFFIX}"
npm version "$NEW_VERSION" --no-git-tag-version --allow-same-version

4. Commit the version bump as a separate commit before making functional changes:

git add package.json package-lock.json 2>/dev/null
git commit -m "chore: bump version to ${NEW_VERSION}

Co-authored-by: Copilot <[e-mail]>"

Note: The version bump commit must come before any functional code changes so the version is set from the start of the branch.

Step 6 — Implement the fix

Make the necessary code changes in each repository. Follow the coding patterns and conventions already established in each repo. Use the appropriate developer agent if available:

• For Java repos → use eux-java-dev agent patterns
• For Kotlin repos → use eux-kotlin-dev agent patterns
• For frontend (eux-web-app) → use eux-full-stack-dev agent patterns

Step 7 — Verify changes

For each repository with changes:

1. Review the diff to ensure correctness:

   git --no-pager diff
   

2. Run the build if a build system is available:

   # Maven-based projects
   mvn compile -q
   # or for Node.js projects
   npm run build
   

3. Run tests if available:

   mvn test -q
   # or
   npm test
   

4. Verify no unintended files were changed.

Step 8 — Commit and push

For each repository:

git add -A
git commit -m "fix: <concise description of the fix>

Resolves TEN-742

Co-authored-by: Copilot <[e-mail]>"
git push -u origin fix/TEN-742-short-description

Step 9 — Create pull requests

For each repository, create a PR using the GitHub CLI:

gh pr create \
  --title "fix: <concise description> (TEN-742)" \
  --body "Resolves [TEN-742](https://jira.adeo.no/browse/TEN-742)

## Changes
- <bullet list of what was changed and why>

## Verification
- <how the fix was verified>" \
  --base main

Collect all PR URLs for the JIRA comment.

Step 8.5 — Deploy branch to odin test environments

After pushing (both on initial PR creation and after subsequent updates), deploy the eux-web-app feature branch to the odin test environments so changes can be verified before merge.

Only for eux-web-app changes (never deploy backends from this skill):

gh workflow run build-and-deploy-to-q.yaml \
  --repo navikt/eux-web-app \
  --ref fix/TEN-742-short-description \
  -f environment=q2-odin

gh workflow run build-and-deploy-to-q.yaml \
  --repo navikt/eux-web-app \
  --ref fix/TEN-742-short-description \
  -f environment=q1-odin

After triggering, verify the workflows started:

gh run list --repo navikt/eux-web-app --branch fix/TEN-742-short-description --limit 2

Step 9 — Comment on JIRA with results

Create a detailed comment on the JIRA issue summarizing what was done. The comment MUST include:

1. A summary of the changes made
2. Which repositories were modified
3. Links to all open Pull Requests
4. Tags for reviewers based on the reviewer tagging rules above

Build the ADF comment dynamically. Use mention nodes (not plain text) for reviewer tags. Example structure:

cat > /tmp/odin-result-comment.json << 'ENDOFJSON'
{"version":1,"type":"doc","content":[{"type":"heading","attrs":{"level":3},"content":[{"type":"text","text":"🤖 Odin — Fix implemented"}]},{"type":"paragraph","content":[{"type":"text","text":"Changes have been implemented for TEN-742."}]},{"type":"heading","attrs":{"level":3},"content":[{"type":"text","text":"Summary"}]},{"type":"paragraph","content":[{"type":"text","text":"<description of what was changed>"}]},{"type":"heading","attrs":{"level":3},"content":[{"type":"text","text":"Pull Requests"}]},{"type":"bulletList","content":[{"type":"listItem","content":[{"type":"paragraph","content":[{"type":"text","text":"eux-neessi: ","marks":[{"type":"strong"}]},{"type":"text","text":"PR #123","marks":[{"type":"link","attrs":{"href":"https://github.com/navikt/eux-neessi/pull/123"}}]}]}]}]},{"type":"heading","attrs":{"level":3},"content":[{"type":"text","text":"Reviewers"}]},{"type":"paragraph","content":[{"type":"text","text":"Tagging for review: Vegard Hillestad"}]}]}
ENDOFJSON
acli jira workitem comment create --key TEN-742 --body-file /tmp/odin-result-comment.json
rm -f /tmp/odin-result-comment.json

Important: Always include working links to every PR that was created. Use the actual PR URLs returned by gh pr create.

Step 11 — Final check

• Verify all PRs are open and have the correct base branch (main).
• Verify the JIRA comment was created successfully.
• Verify odin deploy workflows were triggered successfully.
• If any step failed, comment on the JIRA issue explaining what went wrong and what was completed.

---

Re-implementation after feedback

These steps apply every time changes are requested — whether from a GitHub PR review, from the user in the same conversation after the initial implementation, or from a subsequent /odin-jira invocation. Any push of updated code to a PR MUST be followed by a JIRA comment and an odin deploy.

Step R1 — Understand the feedback

If feedback comes from a PR review, read the review comments:

gh pr view <PR-NUMBER> --repo navikt/<repo> --comments
gh api repos/navikt/<repo>/pulls/<PR-NUMBER>/reviews --jq '.[].body'

If feedback comes from the user in the current conversation, use what they said directly.

Step R2 — Implement the requested changes

Check out the existing feature branch, make the changes, and verify:

cd <repo-directory>
git checkout fix/TEN-742-short-description
git pull

Make the code changes, then verify (build/test as in Step 6).

Step R3 — Commit and push

git add -A
git commit -m "fix: <concise summary of what changed>

Co-authored-by: Copilot <[e-mail]>"
git push

Step R4 — Deploy to odin environments

If eux-web-app was changed, trigger builds to the odin test environments (same as Step 8.5).

Step R5 — Comment on JIRA with update

Add a JIRA comment summarizing what was modified. Do this after every push — not just the first one. The comment MUST include:

1. What feedback was addressed
2. A summary of the code modifications made
3. Confirmation that the branch was redeployed to odin environments (if eux-web-app)

Example:

cat > /tmp/odin-update-comment.json << 'ENDOFJSON'
{"version":1,"type":"doc","content":[{"type":"heading","attrs":{"level":3},"content":[{"type":"text","text":"🤖 Odin — Update pushed"}]},{"type":"paragraph","content":[{"type":"text","text":"Updated PR based on feedback:"}]},{"type":"bulletList","content":[{"type":"listItem","content":[{"type":"paragraph","content":[{"type":"text","text":"<summary of each modification made>"}]}]}]},{"type":"paragraph","content":[{"type":"text","text":"Branch redeployed to q2-odin and q1-odin for verification."}]}]}
ENDOFJSON
acli jira workitem comment create --key TEN-742 --body-file /tmp/odin-update-comment.json
rm -f /tmp/odin-update-comment.json

Repeat steps R1–R5 for every round of feedback within the same conversation or across invocations.