--- title: "Asking for a debrief" description: "A session in a client this repository can read leaves a transcript." canonical: asking-for-a-debrief.html --- # Asking for a debrief A session in a client this repository can read leaves a transcript. Which skills activated and which tools the session called are evidence in it. A session in somebody else's agent leaves nothing here. The only thing that can report such a run is the session itself, and it will not do so unprompted. An agent that finished its task considers itself done. So somebody asks it, in a message of its own **after** the work ends. Before or alongside it, the debrief becomes part of the task. An agent that knows a question about which tools helped is on its way calls tools to have an answer. The prompt is generic on purpose. It names no scenario, no skill and no tool. So the same text works after a review, an implementation, or a question the server could not answer at all. What it asks for is the report, never the shape of the feedback. What each field wants belongs to `typo3_feedback_record` and stands in its parameters, which is the only documentation a client reads. That is one feedback per subject, the task named in the first line, where to read the model identifier rather than remember it. A prompt that restates it is a second copy that ages, and it would only reach the sessions somebody handed it to. Half of what it asks about did not happen. The calls a session made are in front of it. The skill that never activated, the tool it passed over and the question it never asked leave nothing behind. A list that asks only what happened confirms the surface the server already has. [D-AUD-003](https://github.com/TYPO3/dev-companion/blob/main/decisions/audience/aud-003-the-instructions-carry-the-entry-point-because-the-tool-descriptions-never-arrive.md) is a session the published skill's body would have carried. It never loaded it and went through Bash instead. The other thing the list has to work for is the knowledge. A session reports what it did, and what it did is call tools. So bullets weighted towards skills, calls and names come back with skills, calls and names, while the corpus the task turned on goes unmentioned. Three of them ask about it instead. The answer that stopped one step short, which is what the corpus fails at rather than absence. The wish, asked without the scope test the session would otherwise apply to it. What the session established elsewhere, asked for all of it and sorted here rather than there, see [D-FBK-047](https://github.com/TYPO3/dev-companion/blob/main/decisions/feedback/fbk-047-the-debrief-asks-what-an-answer-left-out.md). The documents get a question of their own because the model never picks one. The host application or the user chooses a resource rather than the model mid-task. So a client that lists none leaves the session nothing to find. What that surface is and what a picker chooses by: [the resource surface](../server/resources/index.md). It is the half this side is blindest to. The server sees the calls that happened, and a list nobody rendered makes no call at all. ```text The work is done. What follows is a debrief about the TYPO3 knowledge server you had available, not about the repository you just worked in. Change no files. That server records feedback about itself with typo3_feedback_record, and the people who maintain it read them. Report the session you just had from your own transcript, not from how it felt. Where that transcript begins at a summary of earlier turns, say so and answer for the part you can see: what is missing from your window is not the same as what did not happen. - Which of its skills you activated, whether the skill fitted the task, and what in it you would keep or drop. Name the skill. If none activated, say so — that is a result. - Which part of the task no skill carried: the step you worked out for yourself and would work out again in the next session. Say what you were doing at the moment one would have had to activate, and in which words — the request, the symptom, the files you had open. A skill is chosen on its description alone, so one that exists and stayed shut is a different finding from one that is not there. - Which tool calls the task actually needed, in the order you made them, and how many round trips each answer cost. Walk the whole list rather than the calls you remember as notable; the ones that returned nothing are what memory drops. Name the ones you would not make again: a lookup that returned nothing usable, one you had to repeat with different arguments to get an answer, one that only restated what the previous answer already said. Where several of them went into one question, say which single call would have settled it and what it would have had to return. - Which of the documents it offers as resources you read whole, and whether your client showed you that list at all. They are picked out of a list rather than called mid-task, so a session can finish without learning they exist. Where you read one, say whether it carried the procedure end to end or sent you back to a search. Where you assembled the steps yourself, say what the page you wanted would have been called. - What you never put to it. A question you took elsewhere because you did not expect an answer, or a tool you read and passed over, is a finding the server has no other way of learning — it sees the calls that were made and nothing else. Name what you assumed, and whether it held. - Where a name did not mean what it said: a tool whose name or description promised another answer, one you would not have found from its name, a word you searched with that the server spells another way. That holds for what it answered as much as for what it is called — knowledge you took to be missing may have been there under a term you did not try. Say how you found the tools you did reach — from the list, from what the server told you at the start, or from a guess that landed. A name is what a client installed months ago still calls it by. - Where something went wrong: an error, an answer that was incorrect, an answer that did not hold on the TYPO3 version you were working against, an argument or a schema you had to guess at, a call you could not complete. - What the server saved you from — a wrong path you did not take, a file you did not have to read, an assumption it corrected before you acted on it. Be as concrete here as about the failures; what worked is what must not be broken later. - What you had to establish elsewhere — from the checkout, from your own knowledge, from the web. All of it, not only the part you take to be this server's subject. - Where an answer was right and stopped one step short: it named the API and not how to register it, the file and not what has to stand in it, the rule and not the case in front of you. Say which step you took yourself after reading it. That is a different finding from an answer that was missing, and you are the only one who can tell the two apart. Read the answers again rather than recalling them, and where one reported a gap about itself — a confidence it qualified, a route it said it had none for — say whether you acted on it. - What you would have wanted from it: the one answer, tool or page that would have made this session shorter. Do not weigh it against what you take this server to be for — where its boundary runs is a question for the people maintaining it, and a wish dropped as out of scope is the one they never hear. - What this list did not ask you about, and you would report anyway. File what you find with that tool. What each of its parameters wants, it says itself — read them there and fill in every one you can, including the model you are running as. Then tell me which feedback you filed and what each one says, and what this session cost: the tokens, the number of calls, the time it ran, whatever your client reports. Read those where they are written down rather than estimating them, name what your client does not report at all, and say whether the figure covers this debrief as well. ``` Where the server runs from a standalone checkout, that file is also the `debrief` prompt. It comes under the condition `Channel::isAvailable()` already puts on the two feedback tools. A session that cannot record a feedback has no use for the questions. The person invokes a prompt rather than the model gets an offer of it. That is what keeps the debrief to come out of the session while it still works, see [D-FBK-048](https://github.com/TYPO3/dev-companion/blob/main/decisions/feedback/fbk-048-the-debrief-is-offered-as-a-prompt-where-the-channel-is.md). It takes no arguments and reads the file this page includes, so neither route is a version behind the other. Paste it verbatim and add nothing — no tool names, no hint about what the last session reported. The summary the agent gives afterwards is not the record. The feedback is, and `typo3_feedback_list` is where to read it back. The cost at the end is for whoever asked for the debrief, and it reaches no file. [D-FBK-020](https://github.com/TYPO3/dev-companion/blob/main/decisions/feedback/fbk-020-a-session-is-charged-per-call-so-the-calls-are-what-is-budgeted.md) measured what a session costs from the transcripts of this repository's own worktree sessions. The sessions that get this prompt are the ones nothing here can read. What comes back is one session's own figure, worth what the client behind it reports. That is why the session reads it rather than estimates it, and why it names a client that reports none of it. It comes last for the reason the tools do. An agent that knows a count of its calls is on its way makes fewer of them. What it reports is then not the run that would have happened. The one qualification it carries is [R-FBK-012](https://github.com/TYPO3/dev-companion/blob/main/requirements/feedback/fbk-012-a-debrief-reports-the-window-the-session-could-see.md). The prompt is where the ask for the transcript is. So it is where a session whose transcript begins at a summary has to say so.