AI for Everyday Work and Prompting
Module 7 Build a repeatable manual workflow

Aabha AI Academy · Codeless AI

You can now choose a safe task, write a brief, work from evidence, check claims and prepare useful outputs. This module joins those skills into a small process that another person could follow.

Your result will be a one-page working procedure and two honest run records. You will use the procedure on two different fictional workshop packs and check that the second result reflects the second pack.

What you will learn

- Describe a manual workflow with a start, ordered steps, outputs and a human reviewer.
- Save the input checklist, brief, output requirements and review rules needed to repeat it.
- Decide when to correct a draft, continue with a labelled unknown, or stop.
- Test a normal case and a changed-input case without carrying over old facts.
- Record actual observations rather than claiming unmeasured time savings.

Before you start

Use the skills from Modules 1 to 6. You should be able to trace a claim to supplied text, preserve missing owners and dates, check a simple quantity and distinguish a draft from permission to send it.

Use an approved text-chat assistant, a text editor and a calculator if needed. All inputs below are fictional. No account connection, scheduled run, coding or paid feature is needed.

Plan for about 90 minutes: 30 minutes of explanation and demonstration, 50 minutes of practice, and 10 minutes of checks. The estimate excludes breaks and tool waiting and has not been validated by a beginner pilot.

The Willow Team scenario

You prepare an internal weekly update for the fictional team arranging a community workshop. For each run you need a short update, an action list, a draft message and a record of your checks. You will not send the message or change any real system.

The packs in this module are separate practice snapshots. Do not import facts from earlier modules. All sample outputs and completed records shown here are illustrative, not evidence of a live tool run.

Lesson 1 Map the steps and responsibilities

Suggested time: 6 minutes.

A workflow is an ordered process you can repeat. A manual workflow means you move through the steps yourself: inspect the input, copy the brief into chat, save the response, compare it with the evidence and decide whether to accept it.

Repetition is useful when it makes the work easier to review. Reusing a vague prompt and hoping for the same answer is not enough. A workable procedure explains what must stay stable and what must be replaced each time.

For the workshop task, the stable parts are the safety rules, brief structure, output format and checks. The changing parts are the current notes, source labels, facts, deadlines and unresolved details.

A simple map

Illustration: The learner checks the current input and submits a brief; the assistant produces a candidate draft; the learner verifies, corrects and records an accept or stop decision before any use.
Accompanying diagram: module-7-manual-workflow.svg

Text equivalent:

1. Learner: confirm the task is permitted and the current input is complete enough.
2. Learner: insert the current pack into the saved brief.
3. Assistant: produce a candidate update, action list and message draft.
4. Learner: save that response and compare it with the current evidence.
5. Learner: correct or hold unsupported claims and record unresolved items.
6. Learner: record whether the draft is accepted, needs revision or must stop. Any real-world use requires its own authority and review.

The assistant’s drafting step sits inside a human-operated process. It does not decide whether private information may be entered or whether a message may be sent.

Worked contrast

Unusable procedure:

“Ask AI for the update, then share it.”

Usable start:

“Use the current labelled fictional pack. Create a draft in the saved format. Check every date and owner against that pack. Stop before any sharing.”

The second version names the input, a check and a boundary. You will make it more complete in the next lessons.

Lesson 2 Give every step a stop condition

Suggested time: 6 minutes.

A stop condition tells you when continuing would require guessing, permission or missing evidence. Without one, a procedure can produce polished work even when the input is unsafe or incomplete.

Use three review decisions:

- Accept as a checked draft: The requirements are met and known limitations are clearly shown.
- Revise before accepting: A repair can be made from the available evidence, such as restoring a dropped condition.
- Stop and obtain what is missing: Permission, necessary evidence or an authorised decision is unavailable.

These decisions describe the draft. “Accepted” does not grant permission to send it.

Not every blank stops the whole draft

Suppose the notes say an action is needed but do not name an owner. You can write “Owner not provided” in an internal practice draft if the task allows unresolved fields. You cannot assign the action to a convenient person just to fill the row.

If the task is instead “issue a final task assignment to the responsible owner,” the missing owner is essential. Stop until the responsible person is established.

A useful procedure therefore states both the missing-information rule and the output’s purpose. Our practice outputs may contain explicitly labelled unknowns. They must not contain invented commitments.

Worked stop decisions

- A note says “proposed” but the draft says “confirmed”: revise using the note.
- Two equally applicable sources disagree and neither has authority over the other: label the conflict and hold the affected conclusion for review.
- The pack is fictional, but a required page is missing: obtain it or narrow the output to the material actually available and disclose the limit.
- A real confidential file appears in place of the fictional pack: stop before entering it and return to the authorised practice input.

Pause: Why can “owner not provided” be acceptable in a draft but unacceptable as a completed task assignment? Keep your answer for the self-check.

Lesson 3 Save a reusable working method

Suggested time: 6 minutes.

Save a small local document with five parts:

1. Input checklist: what you must have and what you must not share.
2. Brief: the instructions and a clearly marked place for the current pack.
3. Output requirements: the deliverables and their limits.
4. Verification record: the claims, sources, verdicts and corrections.
5. Approval checklist: what lets the reviewer accept the draft, and what makes them stop.

The procedure should be short enough to follow, while the source pack and run evidence can be attached or saved separately. “One page” here means a concise working procedure, not forcing tiny text onto a physical page. Aim for roughly 300 to 500 words for the procedure itself.

Reusable brief for this module

Task: Prepare an internal workshop update bundle for the fictional Willow Team.
Audience and purpose: Help the coordinator see progress, open work and unresolved details.
Sources: Use only the current pack pasted below. Do not use facts from earlier runs.
Constraints: Preserve proposals, pending confirmations and dependencies. Do not invent owners, dates, progress or promises. If an owner is absent, write "not provided". If sources conflict, label the conflict and do not choose a winner without a stated rule.
Output:
1. A progress update of no more than 120 words.
2. Exactly three action rows. Each row must show action, owner, due date, dependency and status, with its source label.
3. An internal message draft of no more than 60 words asking about one unresolved point. Do not claim that it was sent.
4. A short list of unresolved points.
Checks: Keep all factual claims traceable to the current pack. Check the required lengths and fields before returning the candidate draft.

Current pack — fictional practice
[Replace this entire placeholder with the current pack, including its pack name and source labels.]
End of current pack

The placeholder is an instruction to you while preparing the prompt. Replace it before sending. Never append a new pack beneath an old one and leave the assistant to decide which facts apply.

Lesson 4 Record a run so someone can inspect it

Suggested time: 6 minutes.

A run record describes one use of your procedure. It should let a reviewer answer: what input did you use, what happened, what did you check, and what remains unresolved?

Use this compact format:

Run name and current pack:
Procedure used:
Input safety and completeness check:
Start and finish times, if measured:
Initial output saved at:
Checks performed and source labels:
Errors found and corrections:
Unresolved items and why they remain open:
Final decision and reviewer:

You can use a document section name instead of a file path. The key is that another person can locate the evidence.

A check record must contain evidence

Weak record:

“Looks good. AI checked it.”

Useful record:

“The invitation-review deadline in the output is 14 November 2026. R1.1 gives the same deadline. Supported. Venue confirmation remains pending in R1.2 and in the draft. No confirmed booking is claimed.”

Record corrections, too. Keep the initial response and label your final edited output, rather than replacing the initial response so the error disappears from view.

Measure the work you actually did

If you time a run, include reading, drafting, checking and correction in the work time. Record waiting separately if you want to understand the cause of a delay. Do not claim “saved 30 minutes” unless you have a meaningful comparable baseline.

A shorter drafting time can still lead to more review work. In this course, a supported output with a visible review record matters more than an unmeasured speed claim.

Lesson 5 Test a normal case and a changed case

Suggested time: 6 minutes.

A procedure that works once may depend on an unstated assumption. A changed-input test checks whether the process responds to the new evidence rather than copying the first result.

For our second pack, the invitation-review deadline changes and the venue-confirmation owner is missing. Your procedure should keep the new deadline and expose the missing owner. It should not carry over the earlier values.

Worked comparison

First input:

“Invitation review: Leela, due 14 November 2026.”

Changed input:

“Invitation review: Leela, due 18 November 2026.”

Bad second output:

“Leela will review the invitation by 14 November 2026.”

The instruction may have been reused correctly, but the factual output is stale. Check the second result against the second pack, not against your memory of the first run.

Better second output:

“Review invitation — Leela — due 18 November 2026.”

Keep the test understandable

Use a fresh chat for the changed run if possible, and include the complete saved brief with only the new source pack. This reduces reliance on the previous conversational exchange; it does not guarantee correctness. If you reuse a chat, make the current pack boundary and source-only rule explicit, then check carefully for old facts.

When you change the procedure itself, record the change. A test of new input and a test of a new procedure answer different questions. For the required two runs, first keep the procedure stable so you can inspect how it handles the changed evidence.

Guided practice Build and run the procedure

Suggested time: 30 minutes.

Complete source pack for Run 1

Fictional snapshot dated 11 November 2026. These labels apply only to Run 1.

- R1.1: The invitation draft is complete. Leela is assigned to review it by 14 November 2026. The invitation must not be distributed before review approval. Review has not started and approval is pending.
- R1.2: Arun is assigned to obtain venue confirmation by 15 November 2026. The room request has been sent, but no confirmation has been received. The action is in progress.
- R1.3: Mira is assigned to review the handout by 16 November 2026. Review is blocked until the wording is approved. Wording approval is pending. No separate owner for wording approval is provided in this pack.
- R1.4: The workshop date of 21 November 2026 is proposed, not confirmed. The coordinator wants a practice update, three action rows and a draft question. Nothing is to be sent.

Part A Write your procedure

Spend about 10 minutes. Use the five saved parts from Lesson 3. Your concise procedure must state:

- What current input is required.
- What to do before entering it into the assistant.
- What to replace in the brief.
- Which outputs to save.
- Which factual and format checks to perform.
- What to do with missing or conflicting details.
- Who makes the final decision and what that decision permits.

Include at least one stop condition before drafting and one before accepting the output.

Part B Run and inspect Pack 1

Spend about 15 minutes. Use the reusable brief with R1.1 to R1.4. Save the response and check all three action rows against their notes. For the invitation row, “not provided” is acceptable for a dependency because none is stated for carrying out the review itself. The rule against distributing before approval is a later-use restriction, not a prerequisite for reviewing the draft.

Check at least five material claims, including every due date and the proposed workshop status. Preserve the handout dependency. Correct unsupported details before accepting the practice draft.

Part C Write the run record

Spend about 5 minutes. Record what you actually checked, what you changed and what remains unresolved. The wording-approval owner is missing; your procedure must not invent one.

Offline route: inspect the reference Run 1 bundle in the answers after writing your procedure. Record that you reviewed a supplied bundle and did not perform a live model run. Save the brief for a later tool test.

Independent assignment Test the changed pack

Suggested time: 20 minutes.

Complete source pack for Run 2

Fictional snapshot dated 12 November 2026. These labels apply only to Run 2 and replace Run 1 for this run.

- R2.1: The invitation draft is complete. Leela is assigned to review it by 18 November 2026. The invitation must not be distributed before review approval. Review has not started and approval is pending.
- R2.2: Venue confirmation is still needed by 15 November 2026. The room request has been sent, but no confirmation has been received. The action is in progress. This pack does not name its owner.
- R2.3: Mira is assigned to review the handout by 16 November 2026. Review is blocked until the wording is approved. Wording approval is pending. No separate owner for wording approval is provided in this pack.
- R2.4: The workshop date of 21 November 2026 is proposed, not confirmed. The coordinator wants a practice update, three action rows and a draft question. Nothing is to be sent.

Your task

Run the same procedure with only R2.1 to R2.4. Save a second bundle and run record. Explicitly check:

- Did 18 November replace 14 November for invitation review?
- Is the venue-confirmation owner marked “not provided,” with no carry-over of Arun?
- Does the handout review remain blocked on wording approval?
- Does the workshop date remain proposed?

Keep the facts that are unchanged, too. A changed-input test is not an instruction to rewrite every detail.

Hand in your concise procedure, both briefs, both initial responses or clearly marked offline equivalents, both final bundles, both run records and a short comparison note. If the procedure needs improvement after testing, save the change and explain which observed problem it addresses.

Why this assignment matters

The second run shows whether someone can reuse your method without quietly reusing old evidence. Explicit unknowns are acceptable in this practice draft; invented certainty is not.

Formative self-assessment rubric

Mark each criterion “met” or “needs correction.”

- The procedure has an input, ordered steps, a reusable brief, output requirements and a human reviewer.
- Safety and evidence stop conditions are explicit.
- Both source packs are used in separate runs and both records identify the correct current pack.
- Dates, owners, dependencies and proposal status are supported; unresolved items remain visible.
- Run 2 preserves the new invitation deadline and does not import the old venue owner.
- Checks and corrections are inspectable; any timing or live-run claim is honest.
- The final decision accepts only a practice draft, requires revision or stops; no real-world sending is implied.

Correct factual or privacy gaps before considering the work complete. Revisit only the steps responsible for a failure, then recheck the affected output.

Self-check Before reading the answers

Allow 5 minutes for your answers and 5 minutes for review.

1. Which parts of the workflow stay stable, and which must change each run?
2. Why is “ask AI, then share the result” an incomplete procedure?
3. When may an unknown owner remain in a checked draft, and when should work stop?
4. What does a source label add to a verification record?
5. Why must Run 2 be checked against its own pack?
6. What would you include when measuring total work time?
7. Does accepting a practice draft authorise sending its message?
8. If the second output uses 14 November for invitation review, what should you do?

Answers and explanations

Example concise procedure

Purpose: Prepare a reviewable internal workshop bundle from one current fictional pack. The learner is the reviewer. This procedure produces drafts and does not authorise sending, booking or assigning real work.

1. Confirm that the pack is fictional, labelled and intended for this exercise. Stop before entry if it contains real confidential material or permission is unclear. Check that every required note is present and readable.
2. Identify the current pack and save it with the run name. Do not combine it with an earlier pack. If an essential page is absent, obtain it or explicitly narrow the output.
3. Copy the saved brief, replace its entire source placeholder with the current pack, and check that no old facts remain. Use the required update, three-action and draft-message formats.
4. Run the brief in an approved text chat. Save the exact prompt and first response, or clearly mark an offline review. Treat the response as a candidate draft.
5. Compare every action, owner, date, dependency and status with the current notes. Check the update and message for invented promises or lost caveats. Inspect lengths and required fields. Record at least five checks, including all due dates and the workshop’s proposed status.
6. Correct supported errors from the source. If a requested fact is missing, mark it “not provided.” If an unresolved conflict affects a conclusion, hold that conclusion rather than choosing a convenient answer. Stop any task that cannot be safely completed with labelled gaps.
7. Save the corrected bundle separately from the first response. Record unresolved items, corrections and actual timing if measured. Do not claim a time saving without a comparable baseline.
8. Record “accept as checked practice draft,” “revise” or “stop,” with the reason and reviewer. Acceptance requires supported claims and visible uncertainties. Any later operational use requires its own authorisation and appropriate review.

Run 1 Reference bundle

Illustrative update:

“The invitation draft is complete, with Leela’s review due 14 November 2026 and approval pending. Arun is seeking venue confirmation by 15 November. Mira’s handout review is due 16 November but blocked on wording approval. The wording-approval owner is not provided. The proposed workshop date is 21 November 2026; it is not confirmed.”

Reference action rows:

- Review invitation | Leela | 14 November 2026 | Dependency not provided | Not started; approval pending | R1.1
- Obtain venue confirmation | Arun | 15 November 2026 | Dependency not provided | In progress | R1.2
- Review handout | Mira | 16 November 2026 | Wording approval | Blocked | R1.3

Illustrative message draft:

“Could you clarify who is responsible for the wording approval needed before Mira can review the handout? The current notes do not name an owner. This remains an unresolved point in the workshop update.”

Unresolved points: invitation approval, venue confirmation, wording approval and its owner, and final workshop-date confirmation.

Example five-check record:

1. Leela and the invitation deadline match R1.1: supported.
2. Arun and the venue deadline match R1.2: supported.
3. Mira and the handout deadline match R1.3: supported.
4. Handout review is blocked on wording approval in R1.3: supported.
5. The workshop date is proposed, not confirmed, in R1.4: supported.

The label “pending review” reflects that review is assigned and approval is pending; it does not claim the review has started. Missing dependencies must not be invented. Final decision: accept this illustrative bundle as a checked practice draft, with unresolved items visible. No sending is authorised.

Run 2 Reference changes

Illustrative update:

“The invitation draft is complete, with Leela’s review due 18 November 2026 and approval pending. Venue confirmation is needed by 15 November; its owner is not provided. Mira’s handout review is due 16 November but blocked on wording approval, whose owner is also not provided. The workshop date of 21 November 2026 remains proposed.”

Reference action rows:

- Review invitation | Leela | 18 November 2026 | Dependency not provided | Not started; approval pending | R2.1
- Obtain venue confirmation | Owner not provided | 15 November 2026 | Dependency not provided | In progress | R2.2
- Review handout | Mira | 16 November 2026 | Wording approval | Blocked | R2.3

Illustrative message draft:

“Could you clarify who is responsible for obtaining venue confirmation by 15 November 2026? The current pack does not name an owner, so I have marked the owner as not provided.”

The missing owner is a gap in the current source. Do not assert that nobody has been assigned in reality, or that Arun still owns the task.

Example comparison note:

“The second pack changed the invitation deadline from 14 to 18 November and omitted the venue-confirmation owner. My second bundle uses 18 November and ‘owner not provided.’ It keeps the handout dependency and the proposed workshop date. I checked those facts against R2.1 to R2.4.”

A complete Run 2 record also retains the other unresolved points from its own pack. It does not merely say “same as last time.”

Self-check answers

1. Keep the safety rules, instructions, output requirements and checks stable. Replace the source pack, source labels, facts and run record.
2. It omits input safety, evidence boundaries, output requirements, verification, stop conditions and permission to share.
3. A labelled unknown may remain when the permitted purpose is a draft that allows gaps. Stop when the missing owner is necessary for an operational assignment or when a safe result cannot be produced.
4. A label lets someone locate the evidence and inspect the relevant claim. The record should also explain whether the evidence supports it.
5. The second pack may change facts or omit information. The first output is not the evidence for the second run.
6. Include reading, preparing the brief, drafting, checking and correction. Record waiting separately if useful. A savings claim also needs a fair baseline.
7. No. Draft acceptance and authority to send are different decisions.
8. Compare with R2.1, correct the deadline to 18 November, record the stale-date error and inspect other fields for carry-over. Revise the procedure if it failed to replace the old pack clearly.

Recap and next step

A repeatable manual workflow preserves the method while replacing the evidence. Clear stop conditions and run records make the process reviewable, even when some information remains unknown.

In Module 8, Complete and review the capstone, you will use these skills on larger packs, a 12-row task register and an amendment. You will produce two reviewed bundles and assess them against the course rubric.
