Inspiration
Medical device teams live under design controls (FDA 21 CFR 820, ISO 13485, ISO 14971). They must prove that every user need is met by a requirement, every requirement is verified by a passing test, and every hazard is reduced by a risk control that is itself verified. Most teams keep that proof in a spreadsheet trace matrix that is rebuilt by hand before each release and is out of date the day after.
The most dangerous failure is quiet: a requirement changes after its test passed, and nobody re-runs the test. The old pass still looks green.
What it does
Tracewell turns the Jira issues and links a team already has into a live design-control trace, and publishes the evidence to Confluence.
- Issue panel on every traced issue: what it traces to, what traces to it, its gaps, and what must be re-tested if it changes.
- Project page with four tabs: coverage and gaps by type, the full trace matrix (with CSV export), a hazard to risk control to verification table, and a release check for any fix version.
- Suspect-link automation: when the content of a requirement changes (summary, description, acceptance criteria, labels), Tracewell comments on every passed test below it and on the requirement with the re-test list. Status moves and comments do not trigger it.
- Confluence trace report: verdict, coverage, blockers, trace matrix and risk table, with issue keys linked back to Jira. Publishing again adds a page version, so Confluence page history becomes the audit trail.
- Rovo agent and skill: ask "Is 2.1.0 ready to release?" or "What must be re-tested if MED-3 changes?", or use the issue panel's Ask Tracewell button.
- MCP tools: the five read-only actions are exposed as tools through the Atlassian MCP server, with an open SKILL.md that third-party agents can load.
- Per-project settings map your own issue types, labels and link types, so Tracewell fits an existing project instead of forcing a new one.
Tracewell checks traceability. It does not certify compliance, and the report says so.
How we built it
| Feature | How we used it | Why it mattered | One concrete result |
|---|---|---|---|
| Forge UI Kit (Jira issue panel, project page, project settings page) | All screens are UI Kit components fed by Forge resolvers that call Jira REST v3 as the user. | Native Jira look, no hosting, and users only see issues they can already see. | The demo project page shows 69% coverage (9 of 13 required links) and groups the gaps by type. |
Forge trigger (avi:jira:updated:issue, ignoreSelf) |
Reads the changelog, keeps only content fields, finds passed tests downstream and posts ADF comments as the app. | Catches the stale-test problem the moment it happens instead of at the next audit. | Editing requirement MED-3 on the demo site put suspect comments on its passed test MED-8 and on MED-3 within seconds. |
| Confluence REST v2 through Forge | Creates the trace report page, then updates the same page on every publish. | Page history gives reviewers a dated record of every release check. | Report page in the QMS space went to version 2 on republish, with the verdict as the version message. |
| Rovo agent, skill and actions | tracewell-agent has six actions (five reads plus publish report) and the reusable design-control-release-check skill. Actions return short, capped JSON with a clear verdict. |
Release reviews start with a question, not a spreadsheet. A grounded verdict keeps the agent from guessing. | The same action code run against the demo site returns NOT READY for 2.1.0 with two blockers: MED-9 failed and MED-10 not run. |
Atlassian MCP (rovo:mcp) |
Exposes the five read-only actions as MCP tools. Write actions are not exposed. | Teams can run the release check from their own MCP client, with the user's own Jira permissions. | Five tools declared; a test fails the build if any MCP tool is not a read (GET) action. |
| Trace engine in plain TypeScript | No Forge imports in the rules, so every rule runs in Vitest against an in-memory Jira and Confluence. | Rules for gaps, coverage, risk state and suspect tests can be checked offline and fast. | 92 passing tests, plus 2 opt-in smoke tests against a live site. The manifest is checked with the Forge CLI's own validator. |
Challenges we ran into
- Link direction. Jira links can be drawn either way, so Tracewell derives direction from the design-control chain (need, input, output, verification) instead of trusting the link name.
- What counts as a change. Only content edits should make a test suspect, not status moves or comments, so Tracewell reads the changelog field by field.
- Workflows without a resolution. Team-managed workflows can reach Done without setting a resolution date, which left passed tests looking unrun. Tracewell now falls back to the status change date.
Accomplishments that we're proud of
A complete loop from data teams already keep in Jira: model, rules, UI, automation, agent, MCP and a Confluence audit trail, verified on a live site with seeded demo data.
What we learned
Agent actions work best when they return short, structured verdicts an agent can quote, rather than raw issue data.
What's next for Tracewell
Teamwork Graph links to code and builds, signed review records, and a Marketplace listing.
Built With
- atlassian-forge
- confluence
- confluence-rest-api
- forge-ui-kit
- jira
- jira-rest-api
- mcp
- node.js
- react
- rovo
- typescript
- vitest