Skills you can use.

---
name: review-a-workflow
description: Review a real workflow by mapping people, steps, tools and pain points, then propose the smallest reversible improvement with human checkpoints and a measurable baseline.
---

# Review a workflow

Use this skill when someone wants to understand or improve a workflow involving real people, steps and tools. Adapt the review to the user's task; do not impose a large universal process.

## Start with what is known

Ask for, or extract from the supplied material:

- the current steps in their actual order;
- who performs, receives or approves each handoff;
- which tools, documents or systems are involved;
- the point where time, confusion, rework or risk appears;
- what can be observed now as a baseline.

Label missing facts as unknown. Separate a stated fact from an interpretation and from a suggestion. Do not infer savings, adoption, accuracy or a system change from a description alone.

## Make the smallest useful map

Represent each meaningful handoff as `person or role → action → artifact or decision → next handoff`. Mark where information is lost, duplicated, delayed or checked. Keep the map short enough that the owner can correct it.

For each pain point, test the options in this order:

1. **Eliminate:** remove a step, field or handoff that does not protect a real need.
2. **Simplify:** reduce choices, clarify the artifact or move a check closer to the decision.
3. **Automate:** suggest assistance only when the input and output are clear and a person can review the result.

Automation is a proposal, never an implied live change. Preserve a human checkpoint wherever an error could affect a person, deadline, money, access or an external message.

## Recommend a reversible next move

Choose one smallest change that can be tried without committing the whole team or replacing the current process. State:

- the exact step it changes;
- the owner and reviewer;
- the artifact produced;
- the checkpoint that can reject or correct it;
- the rollback path;
- one or two baseline measures to compare before and after.

Use measures the user can actually observe, such as elapsed time for a sample, number of handoffs, correction count or unanswered fields. Do not create a target or claim an improvement before it is measured.

## Return

Return a compact review with:

1. known facts and open questions;
2. current handoff map;
3. eliminate/simplify/automate options with their human checkpoint;
4. one reversible recommendation and rollback;
5. baseline and follow-up measures;
6. assumptions and limits.

Do not send messages, edit a production system, or claim that a workflow has changed. The user decides whether to run the suggested experiment.

See [EXAMPLE.md](EXAMPLE.md) for a fictional event-registration review.

---
name: teach-a-workflow
description: Turn a source-grounded workflow into a short demo lesson with practice, a success check, error recovery and facilitator notes.
---

# Teach a workflow

Use this skill when someone needs to learn or teach a concrete workflow. Build a small lesson from the user's source material and task; do not turn it into a generic course or assume a product's current behavior.

## Establish the source boundary

Identify the source of each instruction: supplied document, observed example, user statement or proposed teaching choice. Flag unknown source facts instead of filling them in. If the workflow depends on a live tool, teach only the behavior the supplied source supports.

## Build the lesson

Create five connected parts:

1. **Short demo:** show the smallest complete path from input to a useful result. Name what the learner should notice at each handoff.
2. **Practice task:** give the learner a similar, bounded fictional or supplied task to try without touching a real system.
3. **Success check:** define observable evidence of completion, including what should be present, correct or reviewable.
4. **Common error and recovery:** show one likely mistake, how to notice it, and how to return to a safe state.
5. **Facilitator notes:** list the setup, questions to ask, places to pause, source facts to verify and what not to assume.

Keep the demo and practice task short enough to finish in one sitting. Show a human review point whenever the workflow can create an external message, change a record, affect access, or make a consequential decision.

## Return

Return a lesson with:

- audience and prerequisite input;
- source notes and unknowns;
- demo script;
- practice task;
- success check;
- error/recovery card;
- facilitator notes and a reduced version if the learner gets stuck.

Do not send messages, change systems, or promise that a tool supports a step unless the supplied source verifies it. Ask the learner to make the final decision.

See [EXAMPLE.md](EXAMPLE.md) for a fictional inbox-handoff lesson.