Review past performance

Review Past Performance

Overview

Review the previous rolling 24 hours of agent work as an evidence-gathering exercise, not a vibe check. Produce actionable review artifacts that can later update memories, repo instructions, skills, scripts, hooks, tools, and working routines after user review.

Core Principles

• Prefer evidence over impressions. Cite the conversation, log, memory, command output, or file that supports each finding.
• Treat time as part of the contract. Default to a rolling 24-hour window ending at the review run time.
• Separate durable lessons from one-off incidents. Mark uncertain or stale findings clearly.
• Separate review from implementation. Daily review may create review reports and proposed artifacts; it must not apply those artifacts to memories, repo files, automations, config, permissions, scripts, or hooks without explicit user approval.
• Optimize for future action. Every important finding should produce either a review artifact, a changed workflow, a memory candidate, a permission recommendation, a project idea, or an explicit decision to ignore.
• Treat implementation as promotion, not just file creation. An artifact is only implemented when its useful lesson lands in the right reusable surface: memory, installed skill reference, repo instructions, helper script, automation, permission guidance, or a deliberate local-only archive.
• Track opportunities as well as failures. Capture promising project ideas, workflow inventions, and tool proposals that emerged during the day.

Daily Cadence

Default operating model: run once per day near the start of the workday and review the previous 24 hours.

• Use the active environment timezone when known. If timezone is unknown, state the assumed timezone.
• For manual runs, use the same rolling-window logic unless the user provides --since, --until, or another explicit range.
• Resolve clear date phrases such as May 18 to the current year unless context indicates another year. Resolve weekday-only phrases such as Tuesday to the most recent matching weekday when that is clearly what the user means; ask only when the weekday reference is ambiguous.
• Preferred manual launch prompt: Launch review-past-performance now.
• For scheduled runs, keep the report compact and actionable. The review should be useful even if the user reads it hours later.
• When deciding whether activity exists, ignore the current review run and prior review-only activity from this workflow, such as generated reports, artifact bundles, audit notes, or automation bookkeeping.
• Abort cleanly if no agent interactions, logs, memory updates, or repo activity are found inside the window. Do not re-review older material just to produce output.

Two-Phase Loop

1. Daily review mode: inspect the last 24 hours and create a review report plus actionable review artifacts. Do not implement them.
2. Approved implementation mode: after the user reviews the report, consume selected artifacts and make the approved changes.

Daily review mode is allowed to write its own report and artifact files. Those files are review outputs, not implementation changes. Before writing artifact files, load references/review-artifacts.md and use its Artifact Schema exactly, including persistence layer, sync targets, implementation prompt, and verification fields.

Implementation Request Shortcuts

Support both precise and broad implementation requests.

Precise requests:

• Implement RPP-YYYY-MM-DD-001.
• Implement artifacts 001 and 004 from May 18.
• Use approved implementation mode for artifacts/YYYY-MM-DD-artifacts.md.

Broad requests:

• Implement all artifacts from May 18.
• Implement all artifacts from May 18 except 002 which I reject.
• Implement all artifacts from May 18 except 002 to be deferred.
• Implement today's artifacts.
• Implement the latest artifacts.
• Implement all approved artifacts from the last review.

Date handling:

• Month/day without year means current year unless context says otherwise.
• Ambiguous numeric dates should prefer an existing artifact file; if both or neither exist, ask.
• today and yesterday must be resolved using the active environment date/timezone, then stated before acting.
• Weekday-only implementation requests should ask confirmation if ambiguity matters.
• latest artifacts means the most recently modified artifact document with pending Status: proposed or Status: approved, not the latest report and not already implemented items.

Workflow

1. Set the review window and sources.

   • Default to the rolling last 24 hours ending at the current run time.
   • State the exact start and end timestamps, including timezone.
   • If the window contains no non-review activity after filtering this workflow's own activity, abort after reporting the empty window and checked sources.

2. Build an evidence index before judging.

   • List the sessions, repositories, files, tools, and time ranges found.
   • Note blind spots, missing logs, inaccessible folders, or likely stale memory.
   • Keep raw collection commands read-only.

3. Classify observations.

   • User friction: repeated clarifications, wrong assumptions, mismatched tone, missing context.
   • Human-agent interaction bottlenecks: avoidable questions, excessive babysitting, re-explained preferences, or overloaded parallel work.
   • Tool inefficiency: unnecessary searches, broad reads, repeated failed commands, missed parallelism, avoidable escalations.
   • Permission friction: commands that failed under sandboxing, overly broad approval requests, repeated approval prompts.
   • Repository lessons: setup commands, test commands, path conventions, generated artifacts, known hazards.
   • Cross-repository lessons: habits that transfer across projects and habits that must remain repo-specific.
   • Idea and project signals: new project ideas, feature concepts, automation candidates, skill candidates, or recurring "we should build this" moments.

4. Find patterns, not just incidents.

   • Group similar failures together and count frequency when possible.
   • Preserve at least one concrete evidence item per pattern.
   • Distinguish agent mistakes from environmental constraints, flaky tools, outdated docs, and user preference mismatches.

5. Produce an improvement plan.

   • Start with the highest-leverage fixes.
   • Identify the next bottleneck: the one recurring issue most likely to improve throughput, quality, or user attention if removed.
   • Split recommendations into workflow changes, repo-specific instructions, cross-repo guidance, memory updates, permission policy changes, optional automation/tooling, and idea/project follow-ups.

6. Create review artifacts.

   • Create one artifact for each actionable improvement that should survive beyond the report.
   • Use artifact IDs such as RPP-YYYY-MM-DD-001.
   • Include enough detail that a future agent can implement it after approval without re-reading the whole review.
   • See Review Artifact Contract for the artifact schema and implementation routine.

Storage Rules

• If a review workspace is configured, save reports under reports/YYYY-MM-DD-review.md.
• Save artifacts under artifacts/YYYY-MM-DD-artifacts.md.
• Do not overwrite a previous report or artifact bundle from the same day; add a suffix such as -02 if needed.
• If no storage location is configured, return the report in chat and ask before writing files.
• Empty-window reports should only be stored if the user wants an audit trail; unattended runs with configured storage should not finish chat-only when activity exists unless file writes fail.

Unattended Automation Behavior

• Do not ask clarifying questions unless the review cannot proceed at all.
• Make reasonable assumptions and label them.
• Exclude this review run and prior review-only activity before deciding whether the window has activity.
• If activity exists, write the report and artifact bundle to the configured output paths.
• When creating artifacts, load references/review-artifacts.md and use its Artifact Schema exactly, including persistence layer, sync targets, implementation prompt, and verification fields.
• Treat writing report/artifact files as review outputs, not artifact implementation.
• Do not modify memory, repo files, skills, automations, scripts, hooks, permissions, or config beyond the review outputs.
• If writing files fails, return the report in chat and explicitly say which write failed and why.
• Abort if no new activity exists in the review window.
• Include a compact deferred queue if open deferred artifacts exist.
• Keep findings deduplicated.
• Include Needs User Decision only for consent-requiring actions.

Optional Local Indexers

• Use read-only indexers only when large interaction histories need a compact session index.
• Keep helpers optional, portable, agent-agnostic, and free of hardcoded runtime or private log paths.
• See Interaction Indexer Adapter Guidance for the helper contract and synthetic example script.

Review Artifacts

A review artifact is a proposed change that can be implemented later. It is the main output of the skill, not an appendix.

Artifact types: memory-update, repo-instruction-update, skill-update, script-or-hook, permission-policy, workflow-change, project-idea, and ignore-record.

Minimum artifact fields:

• ID, type, title, priority, status.
• Evidence and impact.
• Proposed change.
• Target scope and likely files or systems.
• Persistence layer and reuse target.
• Approval needed before implementation.
• Implementation prompt for a future agent run.
• Verification or success check.

Approved Implementation Mode

When the user asks to implement one or more review artifacts:

1. Read the selected artifact and confirm its scope.
2. Classify the artifact's persistence layer before editing.
3. Re-open only the evidence and target files needed for that artifact.
4. Apply exactly the approved change, keeping unrelated improvements out.
5. Promote reusable guidance to the right surface: memory, skill reference, repo instructions, helper script, automation, permission guidance, or deliberate local-only archive.
6. Run the artifact's verification check when possible.
7. Report the artifact ID, persistence layer, files changed, verification result, and any follow-up artifact created.

Read the full artifact, not only its implementation prompt. Current skill rules and the artifact contract override stale implementation prompts. If the right persistence layer is ambiguous, stop and ask before writing.

Output Format

Use a concise report with these sections:

1. Scope Reviewed: dates, repositories, sources, and blind spots.
2. Next Bottleneck: the single highest-leverage thing to improve next.
3. Top Findings: the most important problems or missed opportunities, ordered by impact.
4. What Worked Well: behaviors worth preserving.
5. Optimization Plan: concrete workflow changes for future sessions.
6. Repo-Specific Lessons: commands, paths, setup notes, hazards, and preferences per repository.
7. Cross-Repo Lessons: generalizable habits or defaults.
8. Idea and Project Signals: promising ideas, future projects, and automation candidates.
9. Review Artifacts: actionable artifacts with IDs, priorities, and approval status.
10. Memory Candidates: short entries suitable for future memory updates, clearly marked as proposed.
11. Deferred Queue: compact list of open deferred artifacts, if any.
12. Permission Notes: approval patterns, recommended prefix rules, and whether current permission mode fit the task.
13. Needs User Decision: actions that require explicit approval.

Common Mistakes

Mistake	Better behavior
Summarizing everything chronologically	Group by recurring pattern and impact.
Reviewing an arbitrary date instead of the rolling window	State exact last-24-hour start and end timestamps.
Turning every observation into a memory	Save only durable, reusable, non-obvious facts.
Producing a thoughtful review with no implementation path	Create review artifacts with IDs, scope, approval, and verification.
Recommending full access because review is easier	Prefer narrow read-only access and explicit approval for risky actions.
Writing repo files during the review	Keep review mode limited to report/artifact outputs unless the user approves implementation.
Ignoring project ideas because they are not mistakes	Capture useful ideas as project-idea artifacts.

Privacy Rules

• Treat conversation logs, memory folders, and cross-repo scans as sensitive.
• Do not publish real reports, artifacts, memory notes, local usernames, private paths, hostnames, tokens, or automation IDs.
• Use synthetic examples in public documentation.