Your first connected AI workflow: turn project issues into a meeting brief
You have a review meeting tomorrow and a project tracker full of updates. The useful preparation is to work out what the group needs to discuss, which facts support that discussion and what remains unanswered.
A connected AI assistant can help retrieve records and prepare a first brief. The workflow needs a visible link between the source issues and the proposed agenda, otherwise an attractive summary can conceal missing work or invented decisions.
This tutorial assumes an approved GitHub connection already exists in a compatible AI application. It focuses on the brief itself. You can also practise the transformation using the sample records below, without connecting an account.
Define the meeting before retrieving records
For example, consider a team reviewing a library’s self-service kiosk. The purpose is to decide what investigation is needed before a wider trial. The team has marked relevant GitHub issues with the label kiosk-review. A label is a tag used to group records.
Choose the repository, filter and meeting purpose before asking for a summary. “Tell me how the project is going” leaves room for the assistant to search the wrong work or imply a level of coverage it never achieved.
- Purpose: agree investigations needed before expanding the kiosk trial.
- Source: one approved repository, issues labelled kiosk-review that are currently open.
- Output: a draft meeting brief in chat, with source references.
- Boundary: no issue edits, comments, assignments or meeting invitations.
Use the publisher’s setup instructions if you need a connection. GitHub documents its MCP server setup. This article does not require enabling every tool the server offers.
The sample issue set
Use these example extracts for the exercise. Their numbers are teaching references, not links to a real repository. In a connected run, retain the actual issue URLs and update times returned by the service.
| Record | Supplied information |
|---|---|
| Issue 17: Receipt preview | Open. Preview cuts off the final line. No browser or printer details supplied. |
| Issue 24: Session timeout | Open. A tester reports being logged out while reviewing a loan. Reproduction steps are incomplete. |
| Issue 31: Audio guidance | Open. A request asks whether spoken instructions can be paused. No tested behaviour is recorded. |
These records contain observations and questions, but no agreed root causes, delivery dates or assigned owners. A useful brief should preserve those gaps.
Build the brief in four stages
1. Retrieve a bounded set
Purpose: Know what the brief covers.
Ask for the exact repository and filter. If the result spans several pages, retrieve the remaining pages where the tools support it. If a limit prevents this, put the incomplete coverage at the top of the output.
Record when the retrieval ran. “Open issues” describes a changing set. For a meeting about work completed during a period, you would need a different query that includes the relevant closed issues.
2. Check the evidence table
Purpose: Inspect the input before transforming it.
Request issue numbers, titles, status, update times and URLs in a table. Open the links and compare them with the returned information. In a small first run, inspect every record used in the brief.
The sample table has three records. A proposed brief that discusses a fourth issue needs another source, or a correction. Use the application’s tool-call details to check the intended connection actually returned the records.
3. Separate observations from discussion themes
Purpose: Make interpretation easy to challenge.
For issue 17, “the receipt preview cuts off the final line” is the supplied observation. “The layout may need investigation across output devices” is a possible discussion theme. “The printer driver is faulty” is an unsupported cause.
For issue 31, a question about pausing audio does not establish that the current kiosk is inaccessible or that every visitor needs audio. Ask what behaviour exists and how users experience it.
4. Produce the agenda and review it
Purpose: Give the meeting a decision to make.
For each theme, name the decision the group needs. Avoid a long narrative that attendees must turn into an agenda themselves. Keep questions separate from decisions already recorded in the source.
Check the brief against the meeting purpose. A review about further investigation should not become an announcement that the wider trial is approved. Ask a person familiar with the work to review the draft before it is circulated.
What a useful brief could contain
Purpose: agree the missing information needed before considering a wider kiosk trial.
- Observed: receipt preview truncation is reported in issue 17; issue 24 lacks complete reproduction steps; issue 31 asks about pausing audio.
- Possible theme: the team needs clearer evidence of behaviour during a complete loan journey. This is an interpretation across the three records.
- Decisions needed: what details should be collected for 17 and 24, and who can demonstrate the current audio behaviour for 31?
- Still unknown: affected environments, frequency, causes and whether the reported behaviour has changed since the extracts.
There are no invented commitments in that brief. During the meeting, the group can agree owners and dates. Record those separately as meeting decisions, rather than quietly adding them to the source summary.
A prompt for a connected run
Supply your authorised repository URL in the chat first. Change the label to one that exists in your project, and use only data your organisation permits the chosen application to process.
Use the approved GitHub connection to read only the repository URL supplied in this chat. Retrieve all issues matching label kiosk-review that are open at the time of the request. Follow pagination if the available tools support it; otherwise state the limit. Give an evidence table with issue number, title, status, update time and source URL. State the retrieval time and exact filter. Do not modify records. Then prepare a meeting brief with: purpose, observed facts with issue references, possible discussion themes labelled as interpretations, decisions needed and unanswered questions. Do not invent causes, owners, deadlines or agreement. If access or results are incomplete, flag that before the brief. Stop after showing the draft here.
Refresh without losing the review trail
Before circulating the brief, check for changes to the records that matter. If an issue closed after retrieval, mark the brief’s snapshot time and decide whether to refresh. A stored summary does not stay current just because its source links still work.
After the meeting, retain the checked brief alongside the actual decisions. For your first attempt, choose a small review where you can inspect the whole input set and explain how each agenda item arose.
Sources checked on 21 October 2026. The worked example and template are original Coded Female teaching material. Product controls vary by application and organisation.
You May Also Like
Creating an Agile Glossary: The Unsung Hero of Clear Communication
How AI is reshaping development teams, from tickets to pull requests
