Load the common method
This skill requires retro. Find its SKILL.md in the catalog or the declared locations and read it
in the current session. In the source repository, it is at this location ; do not assume
that installations keep this arrangement. Reuse its method and its conditions of application,
with the scope and destinations below. Produce a single report, without starting a second session
that would lose the exchanges. If retro is missing, report the dependency and request its installation or its content ;
do not invent its method or announce the retrospective as complete.
Delineate the work observed
Use the ticket and the folder .task/<KEY>/ already designated. Read the relevant available documents :
ticket.md, brief, specs, plans, QA, journal.md, reprise.md and review reports.
Also read the project instructions and the skills that governed the steps concerned.
A missing document is not a defect if the step was not reached or was not requested.
Do not create the missing steps to conduct the retrospective. If there is no identified work folder, present the analysis in the conversation ; clarify the destination only if its recording is requested. If several sessions contributed to the ticket, distinguish the facts of the session from older traces.
Examine the difficulties specific to Flow
Apply the criteria useful to the work actually observed :
| Part | Points to examine |
|---|---|
| Entry and resumption | Requests or authorizations lost, question already settled raised again, journey restarted without reason |
| Brief and spec | Need added or forgotten, question without context, decision not kept, wrong step for clarifying |
| Plan and build | Breakdown too fine or unverifiable, work redone, tracking out of step with the code |
| Reviews | Target incomplete or stale, loop without new element, cost without useful correction, impossible review announced as successful |
| QA and delivery | Preparation confused with execution, reported result presented as observed, request closed too early |
| Log and conventions | Duplicate tracking, insufficient resumption, resource selected but not found or not consulted |
Attribute a problem to Flow only if the facts and its instructions support it. Distinguish a defective instruction from a correct instruction not followed, from a project setting and from a tool limitation. The retrospective evaluates the conduct of the work ; it replaces neither the code review nor the QA. If it reveals a defect in the product, report it for handling at the step concerned without checking any verification.
Guide the improvements
Find the actual source path for each proposal:
| Improvement | Target |
|---|---|
| Running of a step | skills/flow-<étape>/SKILL.md in the source repository of the skills |
| Reusable code convention | Relevant reference of conventions-code, if available |
| Other reusable convention | Source of existing conventions, without creating a skill by default |
| Project-specific instruction | Project conventions documentation |
| Selection of or access to skills | Project instructions; use flow-setup if available to apply the chosen option |
| Specific fact useful for what follows | Ticket log or resumption |
The retro request does not trigger a project reconfiguration or an installation. If a source is not accessible from the current project, keep the proposed change in the report so it can be taken up in the relevant repository. Indicate the expected source and the currently known passage so that the proposal can be verified before applying it; do not correct only the installed copy.
Keep the report
When the ticket folder is known, save the analysis in .task/<KEY>/retro.md, local by default
according to the project instructions. The retro request authorizes this report, not the application of its proposals.
Read the existing content and add a dated entry with the scope and the context limits. Preserve the user's
notes and any follow-ups already made; supplement an existing finding rather than duplicating it.
Use the content requested by retro : facts, probable causes, precise modifications and verification
scenarios. Keep the proposals pending as long as they are not adopted; then distinguish
their application from their effectiveness actually verified. If no useful problem appears, say so without
inventing a rule. Present the main findings in the conversation and give the path of the report.