Requirement Yogi MCP - Use AI with requirements

Before you start

Make sure the following are in place (full installation guide on our Github page):

• The RY AI Assistant server is installed and connected to your client.

• Your Confluence/Jira instance has the Requirement Yogi app installed.

How to talk to it: there is nothing special to type no commands, no slash syntax. Describe
your goal naturally and the LLM chooses the right tool. The examples below show prompts you can copy and adapt. Be specific on the fact that you are using Requirement Yogi it helps the LLM to pick the right tool.

Use cases

Create a requirements from a document or meeting notes

When to use it: you have requirements in your head (or in a document / meeting note) and want a fresh Confluence page where each requirement is a properly indexed Requirement Yogi macro.

How it works

1. You describe the requirements in plain language.

2. The LLM decomposes them into a hierarchy: sections, requirements, and optional properties.

3. The Atlassian MCP publishes the page (contentFormat: "adf"). If asked, tell it the space and,
   optionally, the parent page.

Example prompt

Here are the notes from our coffee-machine kickoff meeting. Turn the functional requirements into a new Confluence page called "Smart Coffee Machine Functional Requirements" in the "PRODUCT" space.

Meeting notes: Coffee machine kickoff, 12 March

We agreed the machine has to brew a single espresso really fast — the team said under 30 seconds end to end, and that's a hard requirement for the launch. Water temperature came up too: it must stay between 92 and 96 °C while it's extracting, otherwise the taste suffers. Both of those are top priority. On the interface side, the plan is a touchscreen where the user picks their drink — still a draft, we haven't locked the screens yet. We also want a descaling reminder after every 200 cups, but nobody owns that yet.

From this prose the LLM extracts the requirements, groups them (e.g. a Brewing section and a
User interface section), assigns free-form keys itself, and pulls out recurring properties
(Priority, Status). The server then renders them: requirements sharing the same properties are
merged into a table, a requirement with no property becomes a paragraph, and the section groupings
become headings. Review the proposed page in the chat and adjust the wording, keys or properties
before it is published.

Tips

• Keys are free-form — use whatever scheme you like (BREW-F-01, REQ_12, Login-must-be-2FA).
  There is no imposed format.

• Every requirement needs a description. A node with only a key and children is treated as a
  section (heading), not an indexed requirement.

• Properties are free label/value pairs (Priority, Status, Owner, Release…). They only appear
  when the requirement is rendered as a table row.

Add or fix macros on an existing page

When to use it: a Confluence page already describes requirements, possibly buried in prose or
in an excel sheet, and you want those requirements turned into indexed Requirement Yogi macros
without wasting several days rewrite the document.

How it works

1. Point the LLM at the page. It fetches the page content through the Atlassian MCP.

2. The LLM analyzes the page: it finds the requirements (including those hidden in paragraphs),
   extracts each one's description and properties, and spots properties that recur.

3. It proposes a plan made of typed operations. Review and confirm it.

4. edit_page_requirements applies the plan on the page's ADF, preserving everything that is not a
   requirement (layouts, panels, images, unrelated text).

5. The Atlassian MCP publishes the updated page (version + 1).

The four operation types the LLM can use:

Example prompt

Look at this Confluence page: <paste the page link or ID>. It describes our login feature in prose. Find the functional requirements, turn them into Requirement Yogi macros, and keep everything else on the page intact. Reuse any keys the page already uses; invent sensible keys where there are none. Show me the plan before publishing.

Tips

• The LLM should always show you its analysis and plan first, confirm keys, descriptions and properties before it publishes.

• Existing keys are reused verbatim and never renamed. Where the page has no key, the LLM invents a free-form one.

• Targeting is by exact text snippet of the existing content. If a snippet can't be found on the page, that single operation is skipped and reported as a warning, the rest still apply.

• This is a genuine reshape, not a bulk find-and-replace: a requirement wrapped in a layout or panel is re-indexed in place, the wrapper is left alone.

Link requirements to Jira issues

When to use it: you want to connect existing Requirement Yogi requirements to Jira issues with a
qualified relationship (e.g. a requirement is implemented by a Jira story).

Requires configuration: this use case needs RY_DATA_RESIDENCY and
RY_PERSONAL_ACCESS_TOKEN set on the server (see our Github page).

The flow

1. Find the requirements. Describe which requirements you mean; the LLM writes a query in the RY search syntax and runs search_requirements.

2. Find or create the Jira issues. This is done by the Atlassian MCP. The LLM will ask you how to structure the Jira side, one issue per requirement, or grouped under an epic, sub-tasks, which project, which parent/sprint, and get your confirmation before creating anything.

3. Choose the relationship. list_relationships returns the available link types; you pick one (e.g. "implements", "is tested by") unless it's obvious.

4. Create the links. link_requirements_to_jira creates them and reports how many were linked, skipped, or unauthorized, per operation.

Example prompts

Find all my requirements whose key starts with BREW-F- in the "PRODUCT" space.

For each of those requirements, create a Jira story in project CM and link it to the requirement with the "is implemented by" relationship. Show me the list of stories you'll create before creating them.

And then Link requirements BREW-F-01, BREW-F-02 and BREW-F-03 all to the existing epic CM-100 with the "relates to" relationship.

Tips

• Linking needs numeric Jira issue IDs, not the PROJ-123 keys — the Atlassian MCP resolves these for you.

• Always let the LLM confirm the Jira structure and the relationship with you before it creates anything, creating issues and links changes real data in Jira and Confluence.

• If the search results look off, ask the LLM to check the humanReadable echo it shows how the server understood your query.

Find duplicated or overlapping requirements

When to use it: your requirement base has grown over time and you suspect the same need is stated twice, or several requirements partly overlap. You want the LLM to surface those before they cause conflicting implementations or tests.

How it works

1. You describe the scope to review (a space, a key prefix, a property value, or "everything").

2. The LLM writes an RY search query and runs search_requirements to pull the matching requirements paging through all results.

3. It analyzes the requirement texts semantically: it groups requirements that say the same thing (duplicates) or partly cover each other (overlaps), and explains why each cluster is flagged.

4. It reports the clusters back to you with each requirement's key, text and link so you can decide what to merge, split, or keep.

This is a read-only analysis: nothing is modified in Confluence. The value is combining RY's search (to gather the exact set) with the LLM's judgment (to spot semantic overlap that a keyword search can't).

Example prompt

Search all requirements in the "PRODUCT" space and tell me which ones are duplicates or overlap. Group them into clusters, and for each cluster show the keys, the text, and a one-line explanation of why they overlap. Don't change anything, just give me the report.

Tips

• Narrow the scope for better signal. Reviewing one space or one feature area (key ~ 'BREW-F-%') gives sharper clusters than scanning everything at once.

• Overlap is a judgment call treat the clusters as candidates to review, not automatic deletions. Ask the LLM for its reasoning before acting on any of them.

• Turn the findings into action. Once you've decided, you can chain into other capabilities e.g. ask the LLM to reshape a page (edit workflow) to consolidate the duplicates, or to link the survivors to the right Jira issues.

Assess the impact of a requirement change

When to use it: a requirement changes late in the project and you need to know, quickly, which other requirements are affected before you sign off on the change.

How it works

1. You tell the LLM which requirement changed and what the change is.

2. The LLM uses search_requirements to pull the surrounding requirement set typically the same space, feature area, or requirements sharing properties or terminology with the one that changed.

3. It reasons over the texts to find requirements that depend on, contradict, or restate the changed one the ripple effect a keyword search alone would miss.

4. It reports an impact list: each affected requirement with its key, text, link, and why it's impacted.

This is a read-only analysis and nothing is modified. It combines RY's search (to gather the candidate set) with the LLM's judgment (to trace the semantic ripple).

Example prompt

We just changed the requirement BREW-F-01: the espresso brew time goes from "under 30 seconds" to "under 45 seconds". Search in the "PRODUCT" space and tell me which other requirements this impacts anything that assumes the old timing, depends on it, or now conflicts with it. For each one, give the key, the text, and why it's affected. Don't change anything yet.

Tips

• Give the LLM the before and after of the change, not just the new wording, the delta is what drives the impact analysis.

• The server doesn't hand over a dependency graph, the ripple is inferred from the requirement texts, so widen the search scope if you're worried about missing indirect dependencies, and treat the result as candidates to confirm.

• Chain into follow-ups. Once you know the impact, you can ask the LLM to reshape the affected page (edit workflow) or re-check the Jira issues linked to the impacted requirements.

Troubleshooting

Frequently Asked Questions

What is an MCP ?

The RY AI Assistant is an MCP server: a small program that adds new abilities to an MCP-compatible chat client (Claude, ChatGPT, Copilot, etc.). Once connected, you simply talk to your LLM in plain language and it calls the server's tools for you behind the scenes.

Its job is to give your LLM a set of Requirement Yogi (RY) capabilities, what you build with them is open-ended. The examples in this guide are just starting points to spark ideas, the real value is that you can chain these capabilities into whatever workflow fits your work.

Concretely, the server gives the LLM the power to:

• Know the RY indexing rules: exactly where an RY macro may be placed on a Confluence page so that a requirement gets indexed (used to author or reshape pages correctly).

• Search requirements: write queries in the RY search syntax (RQL) and find requirements across your instance.

• Link requirements to Jira issues: connect requirements to Jira tickets through the RY API.

How is the work split ?

You never hand-write ADF (Confluence's document format), search syntax, or IDs. The division of
labour is:

What tools are available ?

You don't call these directly the LLM does. This table is here so you understand what happens
under the hood and can follow along.

See also

• Our Github page → installation, configuration, and per-client setup.

• Requirement Yogi → the Confluence/Jira app this server works with.

• Model Context Protocol → the standard this server implements.