Incomplete Session Handling

Incomplete Session Handling

Incomplete is allowed. Pretending it is complete is not.

When to Use

• Session transcript/stub is missing goal, tools/skills, outcome, or turning points
• You are about to score, summarize, package, or “learn from” a session
• Data looks neat but critical fields are empty or implied
• Prior analysis smells invented (fake green tests, mystery tools, confident endings)

Do not use when the session already has clear goal, skills/tools used, and verified outcome — just analyze normally.

Contract

Inputs

1. Session stub — transcript excerpt, notes, or structured fields
2. Analysis intent — summarize / score / package / debug
3. Output path — where to write the gap report (if required)

Process

1. Scan required fields
   Mark each PRESENT / MISSING / VAGUE:

   • Goal / success criteria
   • Skills or tools used
   • Outcome + evidence
   • Critical turning points (if relevant to intent)

2. Refuse fake completeness
   If you cannot support a claim from the stub, do not write it.
   Especially forbidden: invented pass/fail, exit codes, tool names, commit SHAs, “deployed successfully.”

3. Write the gap report (markdown)
   Sections:

   • Goal gaps
   • Skill/tool gaps
   • Outcome gaps
   • Critical unknowns
   • Minimum questions (≤5)
   • Decision: PROCEED or STOP_AND_REQUEST

4. Ask only high-leverage questions
   Max 5. Prefer questions whose answers change the conclusion.
   Mark true user-only questions with (user-only).

5. Branch

   • STOP_AND_REQUEST — return report + questions; do not deep-analyze
   • PROCEED — analyze using only present fields; label residual uncertainty

6. If packaging into a skill later
   Incomplete sessions are not package-ready. Route to recovery questions first.

Invocation (agent)

load_skill("incomplete-session-handling")
# session_stub: ...
# intent: summarize|score|package
# report_path: optional

Output Shape

# Session gap report

## Decision
STOP_AND_REQUEST | PROCEED

## Goal gaps
- ...

## Skill/tool gaps
- ...

## Outcome gaps
- ...

## Critical unknowns
- ...

## Minimum questions (<=5)
1. ...
2. ... (user-only)

Verification

• No claim of success/failure without evidence in the stub
• Questions ≤ 5
• Decision is explicit
• Gap report written when task asks for an artifact path

NEVER

• Invented success (“tests passed”, “deploy worked”) without evidence
• Invented toolchain (docker, gh, skills not in stub)
• Fake exit codes or SHAs
• Question dumps (>5)
• Analyzing as if complete when the spine is broken

Minimal Example

Stub: “User asked for help with auth. Agent used some tools. Seemed fine.”

Decision: STOP_AND_REQUEST

Questions:

1. What was the exact auth goal (login bug, token refresh, SSO)?
2. Which tools/skills ran?
3. What was the final observable outcome?
4. Any error text preserved?

Why it compounds

Honest gaps beat confident fiction. Agents that stop for missing spine keep your library clean.