WeXL Forge · Specify · Beta

Forge Spec

Turns notes, transcripts and docs into epics, stories and acceptance criteria

Takes: Meeting transcript (.txt, .md, .vtt)Notes or a requirements doc as text (.txt, .md)
Gives: Epics and user storiesGiven/When/Then acceptance criteriaOpen questions and assumptionsMarkdown or Jira CSV
Runs on: OpenAIAnthropicAmazon Bedrock
Updated: 12 Oct 2026

Beta: in use on our own product work; not yet handed over to a client team.

The problem

Most requirements start life as a conversation. A product manager, a tech lead, a designer and a tester spend twenty minutes on a call and agree a dozen things: what the feature does, what it must never do, the edge cases, what is parked for later. Then someone has to turn that call into stories a team can size and build. That job usually lands on whoever is least busy, a day or two later, from memory and a few scribbled notes.

That is where requirements quietly break. A decision made at minute nine gets lost. An idea someone floated and the group rejected turns up as a story. “No timer on retries” never becomes an acceptance criterion, so nobody tests for it. The stories that reach the sprint are tidy, but they no longer match what was agreed, and nobody can tell which lines came from the call and which the writer filled in.

Good looks like this: every story traces to something that was actually said; every acceptance criterion can be tested as written; what was parked is listed as parked; and the questions nobody answered are at the top, where the tech lead will see them before sizing.

How it works

Forge Spec reads one source per run: a transcript (including .vtt captions from a video call, with timestamps), meeting notes, or a requirements document saved as text. It numbers every line, so each item it writes can point back to a timestamp or a line number.

It writes an epic with a one-line goal, then user stories, each with Given/When/Then acceptance criteria. Every criterion cites where it came from. Alongside the stories it lists the open questions the source left undecided or never discussed, the assumptions it had to make, and what was raised and parked. Assumptions never go into the stories themselves.

Then it is checked. The answer has to fit a typed schema before anything is printed, and a criterion with no source is rejected rather than shown. That is a structural check, not a judgement on whether the stories are right.

A person then reviews it. In practice that is the product owner or business analyst, and the review is quick because the open questions come first and every line has a source to check against. Forge Spec writes Markdown by default, or a CSV that imports into Jira with stories under their epic.

It is a Python command-line tool built on the Strands Agents SDK, and it calls the model you choose: OpenAI, Anthropic or Amazon Bedrock. For the code-level walkthrough, see How it works in the README.

Where it gets it wrong

Forge Spec is good at structure and traceability. It is not a substitute for the people in the room, and it fails in predictable ways.

It can treat an idea as a decision. When someone says “what if we also…” and the call moves on without a clear no, the agent may not know the idea was dropped. It is told to use only what the source says and to list parked ideas as out of scope, so a reviewer can see what it decided was dropped.
It cannot know what was never said. Non-functional needs such as performance, accessibility, audit or data retention are often assumed by the team and never spoken. Forge Spec raises them as open questions, but it cannot invent the right answer, and it should not.
Story size is a judgement call. It sometimes splits a feature finer than your team would, or bundles two things your team keeps apart. The reviewer has the final say.
Transcripts are imperfect. Speaker labels get swapped, product names get misheard, and crosstalk loses words. Because every criterion cites its timestamp, a reviewer can go back to the line and check what was actually said.

We would rather the agent leave a question open than answer it confidently and wrongly. The review step exists because of this section.

Why not just prompt a chatbot

You can paste a transcript into a chatbot and get user stories back in seconds. They will look plausible, and that is the problem: you cannot tell which lines came from the call and which were filled in. What makes Forge Spec useful is not the model. It is the rules that force a source on every criterion and keep assumptions separate, the typed output that rejects a criterion with no source, the tests that run the real agent loop, and the export to your tracker. That is the part we build, and the part you keep.

What you get

In your engagement: Forge Spec runs on your refinement calls from week one, and your product owners review its output instead of writing stories from scratch.
Under your brand: services firms can offer it inside their own delivery platform, with their own story standards built into its rules.
Built to own: we tune it to your template, glossary and tracker, and hand over the source.

See three ways to use an agent.

Worked example

An illustrative refinement call about a FluentEdge feature, written for this page; the people are named by role. The output is a real run of the agent in the repo, with gpt-5, unedited.

InputRefinement call transcript, 21 minutes

Raw

Refinement call: "Retry what I got wrong" for FluentEdge Practice BETs
Attendees: Product manager (PM), Tech lead (TL), Designer (DS), QA lead (QA)
Duration: 21 minutes. Transcript lightly cleaned of filler words.

[00:00:15] PM: Okay, one item today. Learners finish a Practice BET, see their score, and then the only option is to retake the whole thing. Eight questions. Support tickets say people want to redo just the ones they got wrong.
[00:00:41] TL: Is this all four skills or just reading and listening? Speaking and writing are AI-evaluated, there isn't really a "wrong" answer.
[00:00:58] PM: Good point. Let's say for now, reading and listening only. Those are the MCQ ones.
[00:01:20] DS: Where does the button live? On the result screen, I assume. Next to "Retake test".
[00:01:31] PM: Yes. Something like "Retry the 3 you missed". With the count.
[00:01:44] QA: What if they got everything right?
[00:01:49] PM: Then don't show the button. Maybe a "Nice work" line instead.
[00:02:05] TL: Does a retry count towards their score? Because the Summative score is what recruiters see.
[00:02:16] PM: No. Retries are practice only. They should not change the Practice BET score that's already recorded, and definitely nothing on the Summative.
[00:02:40] DS: Should the retry show the same options in the same order? If it's the same order they'll just remember the position.
[00:02:52] TL: We can shuffle the options. The question bank already supports that.
[00:03:05] PM: Shuffle, yes.
[00:03:30] QA: Do we show the correct answer after the retry, or during?
[00:03:41] PM: After. Same as the normal test. Show which ones they now got right, and for anything still wrong, show the correct answer and the explanation.
[00:04:10] TL: The explanations only exist for about 70 percent of the reading questions. Listening has almost none.
[00:04:22] PM: Then show the correct answer, and the explanation where we have it. Content team can backfill. Let's not block on that.
[00:05:02] DS: Can they retry the retry? Like keep going until they get everything?
[00:05:12] PM: I'd say yes, until they've got them all right. Or they can stop any time.
[00:05:25] TL: That's a loop. Do we need a cap? Each attempt writes rows.
[00:05:36] PM: Hmm. I don't know. Let's not cap it for now but I want to know how many attempts people actually do.
[00:05:50] TL: So an event per retry attempt. I'll make sure analytics gets attempt number and how many were still wrong.
[00:06:30] DS: One idea: what if we also let them retry the questions they got right but were slow on? Like over 60 seconds.
[00:06:44] PM: Interesting, but no, not in this one. Keep it to wrong answers. Park it.
[00:07:15] QA: Mobile. The result screen on mobile already has two buttons stacked. A third makes it long.
[00:07:28] DS: I'll make "Retry what you missed" the primary on both. "Retake test" becomes a text link. That's actually the better default anyway.
[00:07:40] PM: Agreed.
[00:08:20] TL: What about timing? The real Practice BET is timed. Is the retry timed?
[00:08:31] PM: No timer on retries. It's for learning, not for measuring.
[00:09:02] QA: Is this for all users or only the paid tier?
[00:09:10] PM: I need to check with the business side. Write it down as open.
[00:09:45] TL: Offline? Some institutions use it on patchy wifi.
[00:09:55] PM: Same behaviour as the normal test. If the normal test needs a connection, so does this.
[00:10:30] QA: And if they close the app in the middle of a retry?
[00:10:39] PM: They lose that retry, no big deal, they can start again from the result screen. Don't build resume.
[00:11:15] TL: One more. Institutions see reports. Do retries show in the teacher dashboard?
[00:11:27] PM: Not in this release. But the data should be there so we can add it later.
[00:12:00] DS: Copy for the button. "Retry the 3 you missed" or "Practise the 3 you missed"?
[00:12:12] PM: "Retry the 3 you missed". Plain.
[00:12:30] QA: Singular. "Retry the 1 you missed" reads odd.
[00:12:38] DS: "Retry the one you missed" when it's one. I'll write both strings.
[00:13:05] PM: Good. Target is the sprint after next. Tech lead, size it once the stories are written.
[00:13:20] TL: Will do. Send me the stories with the open questions on top.
[End of call]

OutputEpic, eight stories, open questions

Raw

# Epic: Enable 'Retry what I got wrong' for Practice BET (reading and listening)

**Goal:** Let learners retry only the questions they missed in reading and listening Practice BETs for targeted practice without affecting official scores.
**Source:** Refinement call, 21 min. References in [brackets] are transcript timestamps.

## Open questions (resolve before sizing)

1. **Which users/tiers get the feature?** PM needs to check whether this is for all users or only the paid tier. Owner: Product manager (PM). [00:09:02, 00:09:10]
2. **Analytics event timing and schema: should the per-retry event fire on start or on completion, and what is the exact payload and event name?** TL will ensure analytics gets attempt number and how many were still wrong, but the trigger and schema were not specified. [00:05:50]
3. **How is the retry attempt number defined and scoped?** Does the attempt number reset per original Practice BET result session, per user per test, or globally? [00:05:50]
4. **Exact copy when there are zero wrong answers** PM suggested a congratulatory line; confirm final text and tone. [00:01:49]
5. **Localization of button copy** Plural/singular strings were discussed in English; confirm localization approach and translations timeline. [00:12:12, 00:12:38]
6. **Accessibility requirements for retry results** Confirm screen-reader announcements, focus order, and how explanations and correctness are conveyed accessibly.
7. **Data retention and privacy for retry attempt records and analytics** Define how long retry rows and events are kept and whether any PII is included.
8. **Should the count in the Retry button on subsequent loops reflect only remaining incorrect items (current default) or the original incorrect count?** The call implies it updates, but this was not explicitly confirmed. [00:01:31, 00:05:12]

## Stories

### 1. Show Retry CTA on the result screen with correct count and copy

As a learner who has just finished a reading or listening Practice BET,
I want a button to retry only the questions I got wrong with the correct count,
so that I can focus my practice on my mistakes.

**Acceptance criteria**

- Given the result screen of a reading or listening Practice BET and more than one question was answered incorrectly in the attempt,
  when the results are shown,
  then a primary action button labeled "Retry the N you missed" is displayed where N is the count of incorrect questions. [00:00:15, 00:00:58, 00:01:31, 00:07:28, 00:07:40]
- Given the result screen of a reading or listening Practice BET and exactly one question was answered incorrectly in the attempt,
  when the results are shown,
  then a primary action button labeled "Retry the one you missed" is displayed. [00:12:38, 00:12:12]
- Given the result screen of a reading or listening Practice BET and no questions were answered incorrectly in the attempt,
  when the results are shown,
  then no Retry button is displayed. [00:01:44, 00:01:49]
- Given the result screen shows the Retry button,
  then "Retake test" is available as a text link rather than a primary button. [00:07:28, 00:07:40]

### 2. Limit feature to reading and listening only

As a learner who has finished a Practice BET in any skill,
I want the retry-wrong-answers option only where right or wrong applies,
so that the UI reflects the nature of each skill.

**Acceptance criteria**

- Given the result screen of a speaking or writing Practice BET,
  when the results are shown,
  then no Retry-what-you-missed option is displayed. [00:00:41, 00:00:58]
- Given the result screen of a reading or listening Practice BET and there are incorrect answers,
  when the results are shown,
  then the Retry-what-you-missed option is displayed per the button rules. [00:00:58, 00:00:15]

### 3. Run a retry session with only missed items, shuffled options, and no timer

As a learner starting a retry from the result screen,
I want to answer only the questions I got wrong, with shuffled options and no timer,
so that I can relearn without memorizing positions or feeling time pressure.

**Acceptance criteria**

- Given a learner starts a retry from a result screen that shows missed items,
  then the retry session contains exactly the questions that were answered incorrectly in the immediately preceding attempt. [00:00:15, 00:05:12]
- Given a multiple-choice question is presented during a retry session,
  then its answer options are presented shuffled. [00:02:40, 00:02:52, 00:03:05]
- Given a retry session is in progress,
  then no countdown timer is shown and the session is not timed. [00:08:20, 00:08:31]

### 4. Show post-retry feedback with correctness and explanations where available

As a learner who has completed a retry attempt,
I want to see which questions I fixed and the correct answers (plus explanations where available) for those still wrong,
so that I can learn from my mistakes.

**Acceptance criteria**

- Given a retry attempt has been submitted,
  then the system shows which questions are now correct. [00:03:30, 00:03:41]
- Given a retry attempt has been submitted,
  then for each question still incorrect, the correct answer is shown. [00:03:41]
- Given a retry attempt has been submitted and an explanation exists for a still-incorrect question,
  then the explanation is displayed; if no explanation exists, only the correct answer is shown. [00:04:10, 00:04:22]
- Given a retry session is in progress,
  then the system does not reveal correct answers before submission. [00:03:30, 00:03:41]

### 5. Allow repeated retries until all correct; no cap; no resume of in-progress

As a learner practicing until all items are correct,
I want to keep retrying remaining incorrect items or stop at any time,
so that I can reach full correctness at my pace.

**Acceptance criteria**

- Given there are still incorrect items after a retry attempt completes,
  when the result screen is shown,
  then the Retry button is available with the updated count of remaining incorrect items. [00:05:12, 00:01:31]
- Given there are no incorrect items remaining after a retry attempt completes,
  when the result screen is shown,
  then the Retry button is not displayed. [00:05:12, 00:01:49]
- There is no cap on the number of retry attempts. [00:05:36, 00:05:50]
- Given a retry is in progress and the learner closes the app or leaves the session,
  when they return to the result screen,
  then the in-progress retry cannot be resumed and they can start a new retry. [00:10:30, 00:10:39]

### 6. Keep Practice BET and Summative scores unchanged by retries

As a learner concerned about my official scores,
I want my practice retries not to alter recorded Practice BET or Summative scores,
so that my results remain accurate.

**Acceptance criteria**

- Given a Practice BET attempt has a recorded score,
  when any number of retries are completed,
  then the recorded Practice BET score is unchanged. [00:02:05, 00:02:16]
- Retry attempts do not alter any Summative score. [00:02:05, 00:02:16]

### 7. Capture analytics and persist retry attempts; do not show in teacher dashboards (this release)

As a product analyst tracking usage,
I want an event per retry attempt with attempt number and remaining-wrong count, and persisted rows per attempt,
so that we can understand engagement and enable future reporting.

**Acceptance criteria**

- Given a retry attempt occurs,
  then an analytics event is captured for that attempt that includes the attempt number and how many questions were still wrong. [00:05:50]
- Each retry attempt is persisted as data (rows) to support future reporting. [00:05:25, 00:11:27]
- Retry attempts do not appear in the teacher dashboard in this release. [00:11:15, 00:11:27]

### 8. Match connectivity behavior to the normal Practice BET

As a learner using the app with patchy connectivity,
I want the retry feature to follow the same online/offline requirements as the normal test,
so that the experience is consistent.

**Acceptance criteria**

- The retry feature requires a network connection if the normal Practice BET does and behaves the same when offline. [00:09:45, 00:09:55]

## Assumptions (not stated in the source; confirm or correct)

- The count N in the Retry button reflects the number of items currently incorrect (from the immediately preceding attempt: initial test or last retry).
- Attempt numbering for analytics and persisted rows restarts from 1 for the first retry launched from a given Practice BET result screen unless decided otherwise.
- Shuffling applies to the order of answer options only; the set of questions and their order are unchanged unless otherwise specified. [00:02:40, 00:02:52, 00:03:05]
- No timer means there is no countdown UI and no server-side time limit specific to retries beyond any general session expiration. [00:08:20, 00:08:31]
- Retry attempt data is stored in a location accessible to future reporting, even though it is not yet surfaced in teacher dashboards. [00:11:27]
- Closing the app or losing connectivity during a retry abandons that attempt without partial saving or resume, consistent with "Don't build resume". [00:10:39]

## Out of scope (raised and parked)

- Applying this feature to Speaking and Writing skills. [00:00:58]
- Letting learners retry questions they got right but were slow to answer (>60 seconds). [00:06:30, 00:06:44]
- Showing retries in the teacher dashboard in this release. [00:11:15, 00:11:27]
- Resuming an in-progress retry after app close or navigation away. [00:10:39]

Run it on your input.

Send us a real meeting transcript or set of notes. We run Forge Spec on it and send the output back within one working day, with a note on what we would change for your setup.