Session Report

Session Report Skill

[!IMPORTANT] Capture delivery evidence, commands, changed files, blockers, and standards feedback after a work session.

Optional args: slug=, ticket=<id/url>, mode=interactive|autonomous|channel, channel=, auto_continue=true|false, profile=business|hybrid|technical.

Instructions

When the user asks to perform this workflow, execute the following steps:

Session Report Workflow

Goal: Preserve a concise artifact of what changed, how it was verified, and what should improve.

Steps

1. Collect session facts:
   • User goal, ticket/PR/spec links, changed files, commands run, test results, screenshots/logs, environments.
   • Task-record core (same contract for SDD and non-SDD delivery): stable item/action ID, canonical source reference plus revision, owner, priority, dependencies, criterion references (formal IDs when governed, the approved record's observable criteria otherwise), verification lane, approval reference, and any unresolved blocker with owner and required input. Keep requirement text in its existing authority — the ticket, docs/prd/prd-<slug>.md, docs/srs/srs-<slug>.md, or docs/srs/srs-task-list-<slug>.md — and link it instead of copying or re-minting it.
   • Distinguish checkout absence from absent capability; search authorized refs/worktrees before concluding absence.
   • MCP/tool calls used when available; otherwise local command summaries and artifact paths.
   • Load common-operator-profile; carry the inherited operator_profile, delivery_mode, and work-item identity from the Handoff Payload without re-inferring them.
2. Capture evidence:
   • Implementation summary tied to ACs or tasks.
   • Verification commands and PASS/FAIL/BLOCKED/NOT RUN status; record warnings, skips, and NOT RUN separately from PASS. Original RED without prior observed run stays NOT RUN.
   • Remaining risks, assumptions, and follow-up owners.
3. Record requirements drift and authority state:
   • BRD-lite, PRD, and SRS/FRS updates completed or missing; traceability gaps found during implementation or verification.
   • Keep technical verification, business acceptance, and release as separate referenced decisions; an absent reference is not assessed, never success, and no lifecycle state is inferred from timestamps or filenames.
   • SDD delivery links sdd_progress.py status --state <PATH> --revision <REV> --dirty-identity <ID> --format json|markdown as the generated current-state view; checkpoint completion is not verification, acceptance, or release. Non-SDD delivery records the same work-item and decision references here instead of requiring SDD state.
4. Offer local preparation:
   • Substantive main-session checkpoint with verified readiness (no associated work still active): offer local retrospective preparation once when the host supports it; otherwise state the manual instructions from common/common-session-retrospective references/local-preparation.md. Trivial session: no prompt.
   • Later keeps passive access; Skip suppresses that checkpoint; only meaningful new work plus a new checkpoint permits another offer. Unreliable readiness stays manual-only.
   • Treat this report, a completion signal and any prepared proposal as claims and candidates, never acceptance or approval.
   • No skill, memory, registry or AGENTS_LEARNING.md edit follows; do not read full reports back into model context.
5. Persist and route:
   • Review private paths/links and one-way manifests; keep publication separate from activation.
   • Write the run record to artifacts/runs/[slug]/[compactISO]-session-report.json when file writes are allowed.
   • Remaining code work -> implement-feature or dev-fix.
   • Missing evidence -> verify-work or traceability-audit.
   • Standards update -> retro-learn.
   • Release communication -> publish-notes.

Runtime Contract

• Use at the end of a work session to preserve evidence and follow-ups before context is lost.
• Required inputs: session goal plus changed files or commands run during the session.
• Return BLOCKED only when no session evidence (changes, commands, or verification) exists to report.

Handoff Payload

• slug, operator_profile, delivery_mode, work-item reference plus revision, approval reference, goal, changes, verification results, evidence-lane refs, requirement-drift status, risks, follow-ups, next workflow.

Blocking Questions

• Ask max 3 at a time with a recommended default and 2-3 options.

Output Template

# Session Report

## Goal

## Changes

## Verification

| Command/Check | Result | Evidence |
| --- | --- | --- |
| [check] | [result] | [evidence] |

## Work Item And Evidence
- Mode: brief | standard | extended; work item + revision: [ref @ rev]; owner/approval: [owner / ref]
- Criteria: [refs]; verification lane: [lane]; unresolved blocker: [blocker — owner — input]
- Lanes: technical [ref], acceptance [not assessed], release [not assessed]; SDD status view: [projection ref or n/a]

## BRD/PRD/SRS Update Status

## Risks And Follow-Ups

## Skill Feedback Candidates

## Outcome Report
{schema_version: 1, run_id: "[run-id]", slug: "[slug]", workflow: session-report, feature_status: implemented, started_at: "[timestamp]", completed_at: "[timestamp]", requirement_trace: {brd_objectives: [], requirements: [], acceptance_criteria: [], srs: []}, completed_evidence: [], missing_evidence: [], decision_needed: [], recommended_next_workflow: retro-learn, cost: {source: unavailable}, agent: {identity: "[agent-identity]", model: "[model]"}}

## Next Workflow

## Cost Report
Call `get_session_cost(workflow="session-report")` before final handoff.