record-after-task

name	record-after-task
description	After completing meaningful work, write a structured trace to Trellis with steps + outcome, then record success/failure feedback. This is what makes future runs of retrieve-before-task useful — without it, the institutional memory is empty.
version	1.0.0
status	preview

Record After Task

Status: preview. Tool signatures are in flux while parallel work lands. Expect revisions before the next minor release.

The retrieve-before-task skill is only useful if there's something to retrieve. This skill closes the loop: once you finish meaningful work, save a structured trace so future agents (and future-you) inherit the result.

When to invoke

Trigger at the end of any task that:

• Successfully fixed a bug, shipped a feature, or completed a refactor.
• Failed in an instructive way (a wrong path that's worth not repeating).
• Discovered a non-obvious gotcha or pattern worth preserving.

Do not invoke for: trivial edits, exploratory reads, conversational turns.

How to invoke

Call save_experience with a JSON trace, then record_feedback with the returned id.

save_experience(trace_json='{
  "source": "claude-code",
  "intent": "<one sentence describing what you set out to do>",
  "steps": [
    {"step_type": "tool_call", "name": "edit_file",
     "result": {"path": "src/...", "summary": "..."}},
    {"step_type": "tool_call", "name": "run_tests",
     "result": {"passed": 12, "failed": 0}}
  ],
  "outcome": {
    "status": "success",
    "summary": "<2-3 sentences: what changed and why it works>"
  },
  "context": {"domain": "<backend/frontend/data-platform/infra/...>"}
}')

record_feedback(trace_id="<id from save_experience>", success=true, notes="<optional>")

What goes in steps

A condensed sequence of meaningful actions, not a verbatim tool log. 3-8 entries is typical. Each step is one action with its result. Skip noise like "read file to understand" — keep the load-bearing actions.

What goes in outcome.summary

The single most important field. Future retrieval will surface this to other agents. Write it for the reader who has no context — name the change, say what it accomplishes, mention any constraint that drove the design.

Bad: "Fixed it." Good: "Added exponential-backoff retry with jitter to PaymentsClient.charge(). Three attempts max, 100-1600ms backoff. Required because Stripe's idempotency layer drops requests during their nightly maintenance window."

When the task failed

Record it anyway. Use outcome.status: "failure" and put the lesson in outcome.summary:

"Tried adding rate limiting via Redis token bucket — abandoned because the orders API runs in a serverless worker pool with no shared cache. Need to revisit once we've decided on a shared state strategy."

Then record_feedback(success=false). This is just as valuable to retrieve-before-task as a success.

Example end-to-end

After finishing the rate-limiting task from the retrieve-before-task example:

save_experience(trace_json='{
  "source": "claude-code",
  "intent": "Add rate limiting to the orders API",
  "steps": [
    {"step_type": "tool_call", "name": "edit_file",
     "result": {"path": "src/orders/middleware.py"}},
    {"step_type": "tool_call", "name": "edit_file",
     "result": {"path": "src/orders/config.py"}},
    {"step_type": "tool_call", "name": "run_tests",
     "result": {"passed": 24, "failed": 0}}
  ],
  "outcome": {
    "status": "success",
    "summary": "Added FastAPI middleware enforcing 100 req/min/user via slowapi. Per-user keying matches the auth-service convention used by the payments service."
  },
  "context": {"domain": "backend"}
}')

record_feedback(trace_id="01JRK...", success=true,
                notes="Pattern lifted from payments-service rate-limiter")

Failure modes to avoid

• Don't skip recording when you're tired at the end of the task. That's exactly when the memory is freshest and most valuable.
• Don't dump raw tool output into steps. Summarize each step to one line.
• Don't omit the domain. Untagged traces are nearly invisible to retrieval.
• Don't conflate success with "no error". Use success=false if the task didn't actually achieve the user's intent.