Inspiration

Teams make important decisions in Confluence meeting notes every week: "Postgres for new services", "no PII in logs", "Kafka, not RabbitMQ". A month later, someone opens a Jira work item that quietly goes the other way. Nobody remembers the decision, and nobody looks it up. Now AI coding agents pick up work items too, and they only see the text of the ticket. The decision is in the wiki; the work is in Jira. Precedent connects the two at the moment work starts.

What it does

  • Captures decisions automatically. Confluence already has a native decision element (/decision). When a page is opened, Precedent reads its decision items, gives each one a stable ID such as DEC-4, and tracks edits and removals. The page byline shows "3 decisions".
  • Shows the decisions that apply to a work item. A Jira issue panel lists the most relevant active decisions, explains why each one applies ("same area: datastore", "matches log, email, phone"), and links to the exact section of the source page.
  • Pre-flight check with Rovo. One click opens the Precedent agent. It reports "Conflict found", "Possible conflict" or "No conflicts found", quotes the decision and its ID, and suggests what to do next: change the approach, or ask the decision owner for an exception.
  • Gives the same memory to other agents. Precedent's actions are exposed as MCP tools. A Rovo Studio agent can add them today. Once a site admin enables them, external MCP clients, such as coding agents, can call get-work-item-precedents before writing code. An open-source skill.md, at the end of this page, tells such an agent when to run the check and what to do with the result.
  • Decision register. A Confluence page lists every decision you can see, with charts by status and by page.

How we built it

  • Forge, end to end. One cross-product app: Jira is the required product and Confluence is optional. Modules:
    • confluence:contentBylineItem, with dynamicProperties doing capture on page view;
    • jira:issuePanel;
    • confluence:globalPage;
    • rovo:agent with four actions;
    • rovo:mcp.
    • Storage is Forge KVS. The UI is UI Kit.
  • Deterministic retrieval, AI judgment.
    • Ranking is explainable code: BM25 over the decision text and its section heading, plus a technology-aware vocabulary (so "MongoDB" matches a decision about "databases"), scope and page links.
    • The Rovo agent only explains and classifies what the actions return, and must cite decision IDs. This keeps answers grounded and costs nothing in model fees.
  • Permission-aware by design. All Confluence reads use asUser(). People only see decisions from pages they can view; trashed and archived pages drop out.
  • Measured, not assumed. Two evaluation sets:
    • 15 hand-written cases;
    • 32 cases written independently by a separate AI agent that never saw the code.
    • On the independent set, the expected decision is in the top three for 28 of 32 work items (87.5%). Keyword conflict hints alone reached only 0.64 precision, so we label them as hints and let Rovo make the call.
  • Demo video. Screen captures of a live development site. The narration is synthetic (Kokoro-82M text to speech, Apache-2.0).

Challenges we ran into

  • Cross-product data access: the app identity could not read pages in some spaces, but the user identity could. That pushed us toward capturing on page view, which turned out better for privacy.
  • The Confluence REST API returns trashed pages with status 200. We now treat only current pages as valid sources.
  • Early ranking surfaced decisions that shared one generic word ("customer"). Requiring a shared technology area, or two or more meaningful words, fixed that.

Accomplishments that we're proud of

  • Zero setup: decisions your team already writes with /decision are picked up with no new process.
  • Every answer is traceable to a decision ID and a source link.
  • The same decision memory works for people in Jira, for Rovo agents and for external AI agents through MCP.

What we learned

  • Grounding beats prompting. A small, explainable retrieval layer made the agent's answers reliable.
  • Independent evaluation matters. Our own test set scored our heuristics far higher than the independently written set.

What's next

  • Propose, accept and supersede decisions from the agent, with an approval step for the decision owner.
  • Teamwork Graph integration to find decision owners and related pages.
  • Marketplace listing.

How it meets the technology requirement

Built entirely on Forge. It integrates Jira (issue panel and work item reads), Confluence (byline item, global page and page reads), Rovo (agent and actions) and the Atlassian MCP server (rovo:mcp). It makes no external calls. After the production deployment of version 2.0.0, the Forge CLI reported that this version is eligible for the Runs on Atlassian program.

Privacy and support

  • Precedent runs entirely on Atlassian Forge and makes no external calls.
  • Every read runs as the current user, so people only see decisions from pages they are allowed to view. Trashed and archived pages are excluded.
  • The app stores decision text, section headings, page titles and page links in Forge storage on the customer's site. It does not store account IDs, author names or email addresses.
  • Questions or problems: leave a comment on this Devpost page.

Agent skill for third-party agents (open source)

Save this as precedent-preflight/SKILL.md in your agent's skills folder (for example Claude Code's .claude/skills/). It is licensed under Apache-2.0.

---
name: precedent-preflight
description: Before you start work on a Jira work item, or commit to a plan, check it against the decisions your team already recorded in Confluence, using the Precedent MCP tools. Use it when a task names a Jira key (for example PAY-231), or when you are about to choose a datastore, message broker, API style, logging approach or other technology.
---

# Precedent pre-flight

Precedent is a Forge app for Jira and Confluence. It reads the decisions your team records with Confluence's native `/decision` element and exposes them to agents through the Atlassian MCP server as four tools:

| Tool | Input | Use it to |
|---|---|---|
| `get-work-item-precedents` | `issueKey`, for example `PAY-231` | get the decisions that apply to a Jira work item |
| `check-plan` | `planText`, optional `issueKey` | check your proposed approach before you write code |
| `search-decisions` | `query`, a topic | find what the team decided about a topic |
| `get-decision` | `decisionId`, for example `DEC-4` | show one decision with its status and source page |

Your MCP client may show these names with a prefix.

## When to run it

- At the start of any task that names a Jira work item.
- Before you pick or change a technology, a datastore, a message broker or an API style, or change how personal data is logged or stored.
- Before you open a pull request, if your plan changed while you worked.

## Steps

1. If the task names a work item, call `get-work-item-precedents` with its key.
2. Write your plan in two to five sentences. Call `check-plan` with it, and with the key if you have one.
3. Read `results`. Each item has the decision `id`, its `statement`, the page section `heading`, `why` it matched, and `pageTitle` and `pageUrl`.
4. Treat `signals` as hints only. They are keyword heuristics (about 0.6 precision on an independent test). Check each one against the decision statement yourself.
5. Decide:
   - **Conflict found:** the plan goes against an active decision. Stop. Tell the user which decision applies (ID, quoted statement, link). Propose an approach that follows it, or suggest asking the decision owner for an exception. Never work around a decision silently.
   - **Possible conflict:** it is unclear whether the decision applies. Ask the user before you continue.
   - **No conflicts found:** continue, and list the decisions that apply as constraints to follow.
6. Cite decisions by ID and link. Never invent a decision, an ID or a link. If the tools return nothing relevant, say so.

## Setup

1. Install Precedent on your Atlassian site. Jira is required; Confluence is optional.
2. A site admin enables Precedent's MCP tools for external clients: Atlassian Administration → Apps → Sites → your site → Connected apps → Precedent.
3. Connect your MCP client to `https://mcp.atlassian.com/forge/e0302fc4-cc00-4e4a-be9a-dd9ae36691c7` and sign in with your Atlassian account. In Claude Code, for example: `claude mcp add --transport http precedent https://mcp.atlassian.com/forge/e0302fc4-cc00-4e4a-be9a-dd9ae36691c7`. Forge MCP access for external clients is a Preview feature of the Atlassian platform.

Every call runs as you, so you only see decisions from pages you are allowed to view.

License: Apache-2.0.
Share this project:

Updates

Submission history