task-retrospective

---
name: task-retrospective
description: Extracts reusable GRC learning patterns from work the learner already completed. USE WHEN learner describes finished work, points at local output, wants to learn from friction, or asks what to do better next time after acting. NOT FOR live advice, vendor decisions, audit positions, control assessment, or programme operation.
---

# task-retrospective

## What

Turn work the learner already did into structured learning. The work can be real local material in a local adapter, but the output is reflection and reusable learning, not operational judgement.

## When

- The learner describes a completed GRC task.
- The learner points at local output from a completed task.
- The learner wants to learn from a painful or slow workflow.
- The learner asks what to do better next time after they already acted.

## Not For

- Live vendor review, audit prep, control testing, policy authoring, or programme decisions.
- Fictional case practice before the learner has acted. Use `practice-scenario`.
- General stuckness without a completed task. Use `socratic-coach`.

## Inputs

- Learner's description of completed work.
- Real local artefacts only when intentionally provided in a local adapter.
- `brain/task-extraction.md`.
- Optional GRC primitives or corpus files for citation grounding.

## Steps

1. Confirm that this is a retrospective, not operational advice.
2. Use real local output as learning material when intentionally provided.
3. Ask the six extraction questions from `brain/task-extraction.md`, one or two at a time.
4. Surface two or three patterns in the learner's process.
5. Connect the pattern to GRC Engineering primitives or corpus ideas where relevant.
6. Produce a small reusable learning artefact or proposed local profile/progress update.
7. End with: "Where else would this pattern apply?"

## Validation

- The output assesses the learner's process, not the actual outcome.
- Sensitive details are absent or kept local and abstracted.
- The learner leaves with a reusable note, checklist, pattern map, or progress/profile proposal.

## Gotchas

- A real local artefact is learning material, not permission to operate the programme.
- If the learner asks "was this vendor acceptable?", refuse that decision and reflect on the reasoning process.
- Do not ask for all six extraction answers at once unless the learner requests a worksheet.

## Failure Modes

- Operational judgement: remove approval, rejection, audit, policy, or control conclusions.
- Over-extraction: ask the next question only after the prior answer creates signal.
- Toy replacement: do not replace intentionally provided local work with fiction unless sensitivity requires abstraction.

## Examples

- User says "I finished my first vendor review and it took four hours" -> Ask intent and action, identify friction, then produce a learning note.
- User points at local notes from a completed walkthrough -> Use them to extract patterns without judging the control or audit result.
- User asks "Should I have rejected them?" -> Refuse the live judgement and turn it into a retrospective on signals, assumptions, and tradeoffs.