# Make release notes easier to review
## A complete fictional workflow pack

This is a constructed teaching scenario. It is not a customer case study, a recorded agent execution or proof of a shipped release. Replace the people, facts, permissions and example results before using this structure for real work.

The public page includes genuine Tellenze interface captures with manually prepared synthetic content:
- “Make release notes easier to review” in Example launch, shown In progress and assigned to Sam.
- “Release notes review guide” in a temporary example workspace.

Those captures show the starting definition and guide only. They do not show the later draft, checks or approval below. The customer-portal release facts and all review records in this pack are fictional.

## 1. Task definition

### Exact request

> Make release notes easier to review. Bring the product changes into a short draft, then ask a teammate to check that it is clear.

### Purpose

Help the team understand what changed without chasing a handful of messages. Keep the draft, source facts and review in one place.

### Outcome

One short release-note draft for a fictional customer portal, reviewed against the supplied facts. The reader understands where to download a receipt and what happens while payment is pending.

### In scope

- Gather the supplied release facts and writing guide.
- Draft the note in plain language.
- Map its claims to the source facts.
- Record a teammate’s feedback and resolve it.
- Keep the final version, decision and lesson with the work.

### Outside this task

- Changing the product or its access permissions.
- Publishing the release note.
- Sending customer emails or other external messages.
- Claiming a new feature, performance benefit or outcome not supported by the source register.

### Acceptance criteria

1. The draft explains the changes in plain language.
2. A teammate has reviewed the notes and the feedback is resolved.

These are the criteria visible in the synthetic starting-task capture. The examples below show a possible way to check them. Real work needs real evidence.

## 2. Declared roles

| Role | Contributor | Responsibility |
| --- | --- | --- |
| Work owner | Sam, human | Collect facts, define the boundary, compare the draft with its sources and keep the artifacts. |
| Draft contributor | Sam’s connected agent, illustrative | Use only the supplied guide and change facts to propose copy and flag unknowns. |
| Reviewer | Alex, human | Check the reader’s next step, resolve feedback and approve the exact final version. |

A connected agent’s real actions depend on the member’s access, enabled tools, Required Context and the authorization for that task. This example brief is not a general permission policy.

## 3. Source register

### C1 — Confirmed payment

In this fictional customer portal, a signed-in account holder can download a PDF receipt from Payment history after a payment is confirmed.

### C2 — Pending payment

A pending payment shows “Receipt available after payment is confirmed” instead of a download button.

### C3 — Release scope

Receipt email delivery is unchanged. The draft must not claim automatic emailing, new access permissions or faster processing.

### G1 — Writing guide

Explain what changed, why it helps and what the reader should do next. Link the work for people who need details.

The real synthetic “Release notes review guide” uses this reader-first approach. C1–C3 are invented portal facts supplied for this scenario.

For real work, add a current, accessible source link or record for each fact. A label alone is not verification.

## 4. Agent brief

### Objective

Propose one short release note using C1–C3 and G1. Name the reader’s next step.

### Context

Use the task definition and source register in this pack. No other workspace material is needed for this contribution.

### Allowed actions for this example

- Read the supplied facts and guide.
- Return draft text.
- Map factual claims to source IDs.
- List open questions or missing evidence.

### Actions that need separate authorization

- Edit the product.
- Change task status or access.
- Publish the draft or a Review edition.
- Email customers or send other external messages.
- Retrieve or use other workspace material.

### Stop and ask when

- A required fact is missing.
- Sources conflict.
- A requested action is outside this brief.
- You cannot show why a factual claim belongs in the draft.

### Deliverables

1. Proposed release-note text.
2. Source references for its claims.
3. Open questions for the human reviewer.

### Verification and handoff

Sam compares every claim with C1–C3. Alex reviews whether the next step is clear. The agent contribution ends at the proposed draft and questions.

## 5. Proposed draft — constructed example

### Download a receipt from Payment history.

After a payment is confirmed, sign in and open Payment history. Choose Download receipt beside the payment to save a PDF.

If a payment is still pending, its receipt becomes available after confirmation.

### Claim map

| Draft claim | Supplied source |
| --- | --- |
| Receipt is available after confirmation | C1 |
| Sign in and open Payment history | C1 |
| Choose Download receipt to save a PDF | C1 |
| A pending payment does not yet have a receipt | C2 |
| Begin with the reader’s action | G1 |

### Open question

Should the note explicitly say that receipt emails are unchanged? C3 confirms the fact, but the reviewer should decide how much context the reader needs.

This wording was constructed for the public example. No agent was run to produce it.

## 6. Acceptance check record — illustrative

No product test or customer review was performed for this story. The results below belong to the fictional scenario. Do not reuse them as evidence for real work.

### Check 1 — Plain-language changes

**Criterion:** The draft explains the changes in plain language.

**Method:** Sam compares each sentence with C1–C3 and asks Alex to follow the described next step.

**Example result:** The draft names Payment history, Download receipt and the pending-payment case. No unsupported benefit remains.

**Retained evidence in this scenario:** The source register, claim map, reviewed wording and decision below.

**For real work:** Record the actual source links and review result. Do not claim that a product behavior was tested merely because its release note reads clearly.

### Check 2 — Review feedback resolved

**Criterion:** A teammate has reviewed the notes and the feedback is resolved.

**Method:** Alex reads the draft; Sam records the requested change and final version beside the task.

**Example result:** Alex asks for the email boundary. Sam adds “Receipt emails are unchanged.” Alex approves that version.

**Retained evidence in this scenario:** Alex’s feedback, Sam’s revision and the approval of draft v2.

**For real work:** Keep the actual reviewer, feedback, revision and decision. Leave missing evidence visible and the task open until its criteria are met.

## 7. Review decision — constructed example

**Reviewer:** Alex, human.
**Version reviewed:** Draft v2.
**Decision:** Approve the revised draft.

**Feedback on v1:**

> The download path is clear. Add that receipt emails are unchanged so readers do not assume a new delivery method.

**Resolution:** Sam adds the sentence from C3. Alex checks the revised text.

**Reason for approval:** The draft gives the action, covers the pending-payment case and states the release boundary.

**Remaining step:** Publishing or sending this draft needs a separate approval. Preparing this pack does not publish a Tellenze Review edition, grant source access or send any message.

## 8. Final release note — fictional draft v2

### Download a receipt from Payment history.

After a payment is confirmed, sign in and open Payment history. Choose Download receipt beside the payment to save a PDF. If a payment is still pending, its receipt becomes available after confirmation. Receipt emails are unchanged.

**Sources:** C1 — download path; C2 — pending payment; C3 — email boundary.
**Review:** Alex’s constructed approval of v2 in section 7.

The reviewed draft is the outcome of this example. It is not a claim that the portal feature or release is shipped.

## 9. Retained lesson — constructed example

**What happened:** The first draft explained the download path but left email behavior implicit.

**Change for next time:** Sam adds “What stays unchanged?” to the next release brief. The reviewer checks whether those boundaries belong in the note.

**Next check:** At the next release-note review, check whether the field helped catch an unsupported assumption. Revise the guide if it did not.

**Where the lesson belongs:** In the release-note writing guide and in the next task’s brief.

This is a proposed improvement to a working method. Its benefit still needs to be checked in real work.

## 10. Adapt this pack

1. Replace this fictional request with your exact request.
2. Name one useful outcome and the boundary of the task.
3. Supply current source facts, links and a guide accessible to the contributors.
4. Declare human and agent roles, allowed actions and where to ask for help.
5. Ask for a bounded contribution with inspectable outputs.
6. Replace every illustrative result with actual verification evidence.
7. Name the exact version and human review decision.
8. Retain one useful lesson and how you will check it next time.

## 11. Related starting points

- Clear work brief: /work-templates/clear-work-brief
- First-focus plan: /work-templates/first-focus-plan
- Pre-mortem risk and action brief: /work-templates/pre-mortem-actions
- Retrospective action plan: /work-templates/retrospective-actions
- Decision record: /work-templates/decision-record
- Stakeholder review: /work-templates/stakeholder-review
- Agent brief builder: /agent-brief-builder
- Tools hub: /tools
- Define clear work: /guides/define-clear-work
- Agent workflows: /guides/agent-workflows

These paths are public resources on the Tellenze website. The templates have their own clearly labelled fictional examples; use their blank versions for your work.