> For the complete documentation index, see [llms.txt](https://help.swarmia.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.swarmia.com/guides/prompt-library.md). # Prompt library Ready-to-use prompts for Swarmia AI and the Swarmia MCP server, organized by role. These prompts answer questions that engineering leaders, managers, product managers, and engineers ask every week. Use them in [Swarmia AI](/features/swarmia-ai.md) or in any AI assistant connected to the [Swarmia MCP server](/settings/integrations/mcp-server.md), such as Claude or Cursor. ### How to use the prompts 1. Copy a prompt and change the timeframe or team if you need to. 2. Paste it into Swarmia AI or your AI assistant. 3. Read the "How this was calculated" note at the end of the answer before you share the numbers. The prompts end with "Render it as an HTML page with a chart and a short summary." In Claude, this turns the answer into a shareable page. In Swarmia AI, you can leave the sentence out, since answers already include charts and tables. We tested the prompts through the MCP server, so answers in Swarmia AI can look a little different. Each prompt comes with an optional sentence to add for more precise results. Add it when you plan to share the answer or make a decision based on it. {% hint style="info" %} Answers follow your permissions in Swarmia. Prompts about "my team" use the team you belong to. Name a team if you want a different one. {% endhint %} ### Tips for reliable answers * **Ask what's behind the numbers.** A metric that moved is a starting point. Ask for the epics, repositories, or pull requests that drove the change, and for themes in work that isn't linked to an issue. * **Ask what to do about it.** End with "What should we change?" so the answer turns into a decision. * **Name the timeframe and the comparison.** "The last 90 days compared with the 90 days before" gives a better answer than "lately." * **Ask for medians for time metrics.** A few long-running pull requests pull averages up. Medians show the typical case. * **Ask how many items each number is based on.** A change failure rate based on 12 failures isn't a trend yet. * **Compare like with like.** Bigger pull requests take longer to review. When you compare groups, such as work reviewed by an AI agent and work that wasn't, ask to compare pull requests of similar size. * **Check catch-all categories.** Investment categories such as "Everything else" or "Unplanned" often hold work that matched no other rule. They don't always mean unplanned work. * **Keep it about teams.** Swarmia is built for team improvement. Ask about teams and systems, not individual performance. ### Prompts by role {% tabs %} {% tab title="Engineering leaders" %} #### Engineering summary for the board A one-page quarter-over-quarter summary of delivery, where engineering effort went, and progress on the biggest initiatives. ``` Write a one-page engineering summary for our board for the last quarter, compared with the previous quarter: delivery (deployment frequency, change lead time, change failure rate, mean time to recovery and PR cycle time for pull requests owned by our engineering teams, using medians, and showing PR cycle time with draft time excluded too), how engineering effort split across investment categories and what shifted, and our biggest initiatives with effort spent and progress. Add a one-line interpretation for each part. Render it as an HTML page with a chart and a short summary. ``` **Use it to decide** what to tell the board, and which delivery, focus, or initiative issue needs a plan before the next meeting. For more precise results, add: "Say how many failed deployments the recovery time rests on, and check for deployment apps that always deploy together." Needs: production deployments and change failure detection, [investment balance](/features/focus/balance-engineering-investments.md), and [initiatives](/features/focus/deliver-strategic-initiatives.md). #### Is our AI investment paying off, and where? Compares AI tool cost with delivery output, finds the teams that get the most out of it, and shows where AI-assisted work struggles and what to change. ``` Is our AI investment paying off, and where? For the last 6 full months, compare AI coding tool cost (token usage at list price, engineering teams only) with merged PRs per FTE and total cost per merged PR, and show which teams get the most output per AI dollar. For teams where spend grew without output, name the epics it went to. Then, for the last 90 days, show where AI-assisted work struggles by type of work, such as pull requests closed without merging or many changes requested, and suggest what to change. Flag holiday months. Render it as an HTML page with a chart and a short summary. ``` **Use it to decide** whether to keep expanding AI spend, which teams' AI practices to spread, and what to change in how teams use AI. For more precise results, add: "Treat uncategorized work as a sign of abandoned, unlinked drafts rather than a type of work." Needs: an AI coding tool integration with cost data, an issue tracker, investment balance, and cost settings for the cost share. See [AI cost](/features/ai-tools/ai-cost.md). #### Where does engineering time go, and why did it shift? Shows how effort moved between investment categories and names the epics and themes behind each change. ``` How did engineering effort split across our investment categories in the last two quarters, in FTEs and %? For each category that moved more than 2 percentage points, name the 3 to 5 epics or projects that drove the change, and group the titles of pull requests not linked to any issue into themes with counts. End with what to rebalance. Render it as an HTML page with a chart and a short summary. ``` **Use it to decide** whether the shift between categories was planned, and which projects or untracked work to cap next quarter. For more precise results, add: "Compare quarters with date filters that end on each quarter's last day, and check that the categories add up to total effort." Needs: [investment balance](/features/focus/balance-engineering-investments.md) configured and an issue tracker for epics. #### How much effort goes to our initiatives? Shows each team's split between initiatives and other work, and what the biggest other work is. ``` For a VP update, show how much of each team's effort last quarter went to our initiatives versus other work, which initiatives got the most effort, and what the biggest pieces of non-initiative work were. Flag catch-all initiatives and initiatives that got very little effort. Render it as an HTML page with a chart and a short summary. ``` **Use it to decide** which initiatives to split, staff, re-date, or close, and which teams need their other work brought under goals. For more precise results, add: "For any team dominated by one initiative, show the split with and without it." Needs: [initiatives](/features/focus/deliver-strategic-initiatives.md) and pull requests linked to issues. {% endtab %} {% tab title="Directors" %} #### Where is delivery getting stuck in each team? Breaks lead time into stages, looks at how issues flow, and explains what the slowest pull requests or issues have in common. ``` Where is delivery getting stuck in each team? For the last 90 days, break change lead time into stages (coding, waiting for first review, review, waiting to merge, waiting to deploy) and look at issues too: issue cycle time, flow efficiency and issues stuck in progress. For each team's biggest bottleneck, look at the slowest pull requests or issues and tell me what they have in common. Render it as an HTML page with a chart and a short summary. ``` **Use it to decide**, team by team, whether to change the review rota, how you stack and size pull requests, code ownership, or how you keep the issue tracker tidy. For more precise results, add: "Define the slow tail, for example pull requests that waited more than a day, and compare its size and weekday with the team's median." Needs: deployments configured for the deploy stage. #### Are teams delivering more without quality dropping? Compares throughput with bugs, change failure rate, and maintenance work per team, and names the systems behind any drop. ``` For each team, compare the last 3 months with the 3 before: merged PRs per FTE, bugs created in our issue tracker, change failure rate and the share of effort spent on keeping the lights on. Flag any team where throughput went up but bugs, failures or maintenance work grew, name the areas or systems behind it, and say how many failures each rate is based on. Render it as an HTML page with a chart and a short summary. ``` **Use it to decide** which team to check in with before faster delivery turns into quality problems, and where to plan stabilization or maintenance capacity. For more precise results, add: "If every team's change failure rate moves at the same time, treat it as a change in how failures are detected, not a real improvement." Needs: an issue tracker with bug issue types, investment balance with a maintenance or KTLO category, and production deployments with change failure detection. #### Has code review become a bottleneck? Tracks review volume and wait times, then finds the teams and repositories where pull requests wait longest. ``` Has code review become a bottleneck? Over the last 6 months show, per month: PRs merged, reviews given, median time to first human review and the share of PRs reviewed by an AI review agent. Then show which teams and repositories wait longest for a first review and what those pull requests have in common. Render it as an HTML page with a chart and a short summary. ``` **Use it to decide** where to add reviewers or a rota, which repositories need explicit review routing or an AI review agent, and whether to set a batch-size agreement. For more precise results, add: "Leave out repositories where pull requests usually merge without review before ranking the slowest ones." Needs: AI review agents detected on pull requests for the agent share. See [Review agents](/features/ai-tools/review-agents.md). #### Which teams' survey results dropped the most, and why? Compares the last two surveys across teams and looks at each dropping team's comments and system data. ``` Compare the latest completed developer experience survey with the previous one across teams. Which teams' scores dropped the most, on which questions, and what do their comments and system data suggest is behind it? Render it as an HTML page with a chart and a short summary. ``` **Use it to decide** which teams to follow up with and on what, and which issues to handle across the whole organization. For more precise results, add: "Give respondent counts per team, and treat moves under 0.5 points as noise for teams with fewer than 8 people." Needs: at least two completed [surveys](/features/run-developer-experience-surveys.md). An issue tracker helps explain the drops. {% endtab %} {% tab title="Engineering managers" %} #### Prepare our retro Compares the last two weeks with the two before and suggests discussion questions. ``` Prepare my team's retro for the last two weeks: what slowed us down compared with the two weeks before (pull request cycle and review times, working agreement misses, work stuck in progress), and suggest 3 discussion questions. Render it as an HTML page with a chart and a short summary. ``` **Use it to decide** which one or two changes the team commits to in the retro. For more precise results, add: "Use medians for merged PRs, and check whether a change in our issue tracker or PR linking explains any sudden jump." Needs: an issue tracker for stuck work. [Working agreements](/features/working-agreements.md) are optional. #### Is review work spread evenly? Shows each person's share of the team's reviews without names, as a workload view. ``` How is code review work spread across my team over the last 30 days? Show each person's share of the team's reviews without names, and how many pull requests are waiting for review right now. Keep it about workload balance, not performance. Render it as an HTML page with a chart and a short summary. ``` **Use it to decide** whether to change how reviews get assigned, for example round-robin or code owners. For more precise results, add: "Count only reviews of other people's pull requests, and check that the shares add up to the team total." #### How much time goes to keeping the lights on, and on what? Digs into maintenance work: the biggest items, recurring problems, themes in unlinked pull requests, and what to automate. ``` How much engineering time went to keeping the lights on (bugs, incidents, maintenance, upgrades) in the last 3 full months, by month and team? Dig into the work: name the issues and epics that took the most effort, group the rest and any pull requests without an issue into themes with example titles, and flag repeats like the same system fixed again, manual dependency updates or flaky tests. Say what to prevent, automate or invest in. Render it as an HTML page with a chart and a short summary. ``` **Use it to decide** which recurring maintenance work to eliminate, automate, or fund a fix for, and which team needs reliability investment. For more precise results, add: "If we have a second, product-area investment breakdown, split the maintenance work by it." Needs: investment balance with a maintenance or keep-the-lights-on (KTLO) category and an issue tracker. CI and incident data make the patterns sharper. Use "my team" to scope it to one team. #### Which pull requests need attention today? Lists open pull requests that are stuck, grouped by reason. ``` Which of my team's open pull requests need attention today? Group them by reason: waiting for review over a day, approved but not merged, open more than 5 days, or larger than 500 lines, and list old drafts separately. Render it as an HTML table with links and a short summary. ``` **Use it to decide** which pull requests to unblock today, and who to nudge. For more precise results, add: "Find pull requests waiting for review by their current stage, not by time to first human review, which stays empty until a qualifying review." #### Are our sprints realistic? Compares committed and completed story points and finds the work that keeps carrying over. ``` Are my team's sprints realistic? For the last 3 completed sprints, show committed vs completed story points, scope added after the sprint started and carryover, and point out patterns, such as the same issues carried over again and again. Render it as an HTML page with a chart and a short summary. ``` **Use it to decide** how many points the team should commit to next sprint and which stories to split before they carry over again. For more precise results, add: "List the issues behind the carryover with how many sprints each one has been in." Needs: Jira boards mapped to teams and a story point field, or Linear teams with cycles on and estimates. See [Sprints](/features/focus/sprints.md). #### What did my team say in the latest survey? Shows the team's lowest-scoring questions and comment themes, checks them against the team's data, and suggests what to act on. ``` What did my team say in our latest completed developer experience survey? Show our lowest-scoring questions and what changed since the previous survey, summarize the comment themes without quoting anyone, and check each theme against our team's data, such as review times or work in progress. Suggest one or two things to act on. Render it as an HTML page with a chart and a short summary. ``` **Use it to decide** which survey theme the team acts on first, and which metric to track until the next survey. For more precise results, add: "Use the latest survey that is closed or has published results, say how many people responded, and paraphrase comments without quoting or attributing anyone." Needs: at least two completed [surveys](/features/run-developer-experience-surveys.md). #### Are complex or risky changes getting enough review? Finds the most complex merged pull requests that skipped approval or merged very fast. ``` Which merged pull requests from the last 30 days were rated most complex or high risk but were merged without an approving review or within an hour of opening? Group them by repository. Render it as an HTML table with links and a short summary. ``` **Use it to decide** whether to require approvals or branch protection in specific repositories. For more precise results, add: "If you have a pull request complexity enrichment, check how common each level is and use only the top level." Needs: pull request complexity ratings. {% endtab %} {% tab title="Platform & DevEx" %} #### Is CI slowing engineers down? Finds the slowest and least reliable workflows and estimates time spent waiting. ``` Which CI workflows were the slowest and least reliable over the last 30 days? Show median and P90 run time and failure rate per workflow, and estimate how many hours engineers spent waiting on CI. Render it as an HTML page with a chart and a short summary. ``` **Use it to decide** which CI workflow or flaky test suite to fix first. For more precise results, add: "Estimate waiting time only from the workflow that blocks every pull request, counting runs on pull request branches, not by adding up all workflows." Needs: GitHub Actions. See [CI visibility](/features/metrics/get-visibility-into-your-ci-pipeline.md). #### Which parts of our codebase slow us down? Compares repositories on speed, size, and CI health, and explains why the slowest ones are slow. ``` Which parts of our codebase slow us down the most? For repositories with at least 20 merged pull requests in the last 90 days, compare median cycle time, time to first human review, pull request size and CI failure rate. For the two slowest, break cycle time into stages and look at their slowest pull requests to explain what they have in common. Render it as an HTML page with a chart and a short summary. ``` **Use it to decide** where to invest in review rotas, CI fixes, or PR-splitting for specific repositories. For more precise results, add: "In a monorepo, also compare the owning teams inside the busiest repository." Needs: GitHub Actions for CI failure rates. See [CI visibility](/features/metrics/get-visibility-into-your-ci-pipeline.md). #### How are AI cloud agents doing? Compares agent pull requests with ones engineers opened, and shows which tasks agents land and which they don't. ``` How are AI cloud agents doing in our codebase over the last 90 days? For each agent show PRs, merge rate, median size and cycle time, compared with pull requests our engineers opened at similar size, and describe what kinds of tasks get merged versus closed without merging. Render it as an HTML page with a chart and a short summary. ``` **Use it to decide** which kinds of tasks to hand to cloud agents and which to stop sending them. For more precise results, add: "Read the titles of closed agent pull requests, since many are prototypes or duplicates rather than failures." Needs: at least one AI cloud agent detected. See [Cloud agents](/features/ai-tools/cloud-agents.md). #### Do AI-assisted pull requests come with tests? Compares the share of test code across AI tools and finds the repositories where AI changes ship without tests. ``` Do AI-assisted pull requests come with tests? For merged pull requests in the last 60 days, compare the share of changed lines that are tests for each AI tool and for pull requests without AI, counting each pull request once per tool, and list the repositories where AI-assisted pull requests most often change code without any tests. Render it as an HTML page with a chart and a short summary. ``` **Use it to decide** where to add test expectations to AI agent instructions or CI checks. For more precise results, add: "Separate docs, specs and migrations from logic changes before counting untested pull requests." Needs: at least one AI tool connected. See [AI tool detection & filters](/features/ai-tools/ai-tool-detection-and-filters.md). #### Is our AI code review agent helping? Compares review time and quality between pull requests an agent reviewed and those it didn't. ``` Is our AI code review agent helping? For PRs of similar size merged in the last 90 days, compare review time, time to first human review and change failure rate between PRs an AI review agent reviewed and those it didn't. Render it as an HTML page with a chart and a short summary. ``` **Use it to decide** whether to keep, tune, or expand the AI review agent. For more precise results, add: "Check how many failures and non-reviewed PRs there are before drawing conclusions, and say if the unreviewed PRs look like a different kind of work." Needs: an AI review agent that Swarmia detects. See [Review agents](/features/ai-tools/review-agents.md). #### What do engineers say, and does the data agree? Summarizes your latest survey and checks each theme against system data. ``` Summarize our latest completed developer experience survey: the lowest-scoring questions overall and by team, what changed since the previous survey, and the main themes in the comments. Then check each theme against our system data. Render it as an HTML page with a chart and a short summary. ``` **Use it to decide** which survey theme to act on first, backed by data you can track. For more precise results, add: "Paraphrase comment themes instead of quoting people, and check them against monthly PR size, time to first human review and CI failure rate." Needs: at least one closed [survey](/features/run-developer-experience-surveys.md), and two for a comparison. {% endtab %} {% tab title="Operations & finance" %} #### Monthly software capitalization summary Summarizes capitalizable effort and cost, with the top epics and a six-month trend. ``` Prepare last month's software capitalization summary from Swarmia's capitalization data: total effort and cost, how much was capitalizable, and the top 10 epics with their effort, cost and capitalizable share. Show the trend for the last six months. Render it as an HTML page with a chart and a short summary. ``` **Use it to decide** what to book as capitalized cost, and which unlinked work to fix before month-end. For more precise results, add: "Group epics by the highest parent issue title, not its key." Needs: [software capitalization](/features/capitalize-software-development-costs.md) configured and an average developer cost in cost settings. #### Where does our AI spend go? Shows AI cost per team, per merged pull request, and per epic, and what the spend not tied to any issue went into. ``` Where does our engineering teams' AI coding tool spend go? For the last 3 months, count only people in our engineering teams and show AI cost per team and per merged pull request, the 10 epics or projects that used the most AI with their cost per completed issue and the initiative they belong to, and what share of the cost isn't tied to any issue, with the main themes of that untied work. Render it as an HTML page with a chart and a short summary. ``` **Use it to decide** how to set AI budgets and chargeback per team, which epics justify a higher AI allowance, and whether attribution is good enough to charge back. For more precise results, add: "Split the spend not tied to an issue into pull requests without an issue and sessions with no pull request." Needs: AI tool integrations with cost data and an issue tracker with epics. See [AI cost](/features/ai-tools/ai-cost.md). #### How complete is our data? Checks issue linking, uncategorized effort, and pull requests without an owner team. ``` Run a data quality check for the last 30 days: what share of each team's merged PRs is linked to an issue, how much effort is uncategorized in investment balance, and how many PRs have no owner team or are excluded. Tell me what to fix first. Render it as an HTML page with a chart and a short summary. ``` **Use it to decide** what to fix in your setup before you trust or share the numbers. For more precise results, add: "Report catch-all categories like 'Everything else' next to the uncategorized share." Needs: an issue tracker and investment balance. #### Where does this number come from? Explains how a metric is calculated, what feeds it in your setup, and whether it's safe to share. Swap in any metric. ``` Where does our change lead time number come from? Explain how Swarmia calculates it (cite the help center), which integrations and settings feed it, and what our current value is. Show what the number is built from, such as applications, environments or repositories, and what in our setup could make it misleading, and say whether it's safe to share as is. Render it as an HTML page with a chart and a short summary. ``` **Use it to decide** whether to share a number as is, with a caveat, or after fixing your setup. For more precise results, add: "Break the number down by what feeds it, such as deployment application and environment or repository, and flag test or non-engineering sources." {% endtab %} {% tab title="Product managers" %} #### Will our initiatives finish on time? Shows progress and forecasts each initiative against its target date. ``` For our active initiatives, show progress (issues done vs remaining), effort spent so far, and whether the pace of the last four weeks gets each one done by its target date. Flag initiatives where scope is growing faster than work gets done. Render it as an HTML page with a chart and a short summary. ``` **Use it to decide** which initiatives need a scope cut, more people, or a new date. For more precise results, add: "Compare issues completed with issues added in the last 28 days per initiative, and treat initiatives without an end date as ongoing." Needs: [initiatives](/features/focus/deliver-strategic-initiatives.md) with target dates. See also [Forecast](/features/forecast.md). #### How loaded is my team right now? Compares work in progress, started vs finished work, and unplanned effort with the four weeks before, and names what drove any jump. ``` How loaded is my team right now? Compare the last 4 full weeks with the 4 before: average issues in progress per person (use the team's FTE), issues started vs finished, work added after a sprint started (if we run sprints) and the share of effort on unplanned work. Name the epics or projects behind any jump, list the oldest in-progress issues, and group pull requests without an issue into themes. Render it as an HTML page with a chart and a short summary. ``` **Use it to decide** whether to add, delay, or cut work for the team this month, and what to wrap up first. For more precise results, add: "Divide work in progress by the team's FTE, not headcount, and count epics or projects that stay in progress by design separately." Needs: an issue tracker with issue ownership. Sprints and a planned vs unplanned breakdown make it more complete. #### What's taking time away from roadmap work? Splits the team's effort into roadmap work and everything else, and names the biggest non-roadmap work. ``` What's taking time away from roadmap work for my team? For the last 3 full months, split effort into roadmap work and everything else by category, such as bugs, maintenance and improvements, and flag initiatives that hold most of the team's issues. Name the biggest non-roadmap work with its effort, group pull requests without an issue into themes, and say what to push back on or fund. Render it as an HTML page with a chart and a short summary. ``` **Use it to decide** which non-roadmap work to push back on, and which to fund as planned work. For more precise results, add: "Check how many of the team's issues each initiative holds first. If one holds almost all of them, split by investment category instead." Needs: an issue tracker and [investment balance](/features/focus/balance-engineering-investments.md). Initiatives that map to real projects make it sharper. #### What did my team ship last month? A plain-language summary of completed work for stakeholders, grouped by initiative or product area. ``` What did my team ship last month? Summarize completed epics, stories and notable fixes in plain language for stakeholders, grouped by initiative, or by product area if one initiative holds all of the team's work. Skip subtasks, link every item, mention notable pull requests that shipped without an issue, and keep internal clean-up to one line. Render it as an HTML page with a chart and a short summary. ``` **Use it to decide** what to tell stakeholders the team delivered, and which launches to announce. For more precise results, add: "Leave out subtasks and describe changes by what users can now do, not by ticket title." Needs: an issue tracker with completed epics and stories. {% endtab %} {% tab title="Engineers" %} #### Prepare my self-review Summarizes your own work over the last 6 months: projects, pull requests, themes, and reviews you gave. Replace the email with your own. ``` My work email is name@company.com. Help me prepare my self-review: summarize what I worked on in the last 6 months: the main projects and epics, the pull requests I shipped (if they aren't linked to issues, group them into themes by title), and the reviews I gave to others. Keep it about my own work, without comparing me to anyone. Render it as an HTML page with a chart and a short summary. ``` **Use it to decide** what to highlight in your self-review, and what to work on next. For more precise results, add: "Describe only my own work, never compared with anyone else." Needs: an issue tracker adds projects and epics, but isn't required. #### Where do my pull requests get stuck? Breaks your own pull request cycle time into stages and explains what your slowest ones have in common. Replace the email with your own. ``` My work email is name@company.com. Where do my pull requests get stuck? For my pull requests merged in the last 90 days, break cycle time into stages and show which stage takes the longest, and what my slowest pull requests have in common, such as size, repository or reviewer wait. Render it as an HTML page with a chart and a short summary. ``` **Use it to decide** which habit to change to get your work merged faster, such as opening pull requests earlier or splitting long-running branches. For more precise results, add: "Use sums of each stage for the shares and medians for a typical pull request." #### What's waiting on me right now? Lists review requests, your own stuck pull requests, and issues in progress, oldest first. Replace the email with your own. ``` My work email is name@company.com. What's waiting on me right now? List pull requests where my review is requested, my own open pull requests that are waiting on me or stuck, and issues assigned to me that are in progress, oldest first. Render it as an HTML table with links and a short summary. ``` **Use it to decide** what to unblock first today. For more precise results, add: "Include only review requests made to me personally, and flag in-progress issues untouched for over 30 days." Needs: an issue tracker for the issues. {% endtab %} {% endtabs %} ### Take action on an answer Many answers end with a change you want to make. Ask your assistant to set it up in the same conversation: * "Set up a working agreement for my team: pull requests should get a first review within one business day." * "Save change lead time as a key metric under our Delivery goal." * "Add a tab to my pull request inbox for pull requests waiting more than a day for a first review." Your assistant prepares the change, and nothing changes until you confirm it in Swarmia. See [MCP actions](/settings/integrations/mcp-server/mcp-server-actions.md) for everything you can ask for. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://help.swarmia.com/guides/prompt-library.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.