guild-reflect

Classify run inputs into four proposal buckets and write a reflection file.

6|Updated Apr 24, 2026

Search Tags:#memory #handoff #reflection #proposal #post-task #run-analysis

Ready to run

npx skills add https://github.com/lookatitude/guild --skill guild-reflect

💬 Prompt for ChatGPT / Claude Chat▼

Please help me install this Agent Skill.
Skill: guild-reflect
Source: https://github.com/lookatitude/guild/tree/main/skills/meta/reflect
Command: npx skills add https://github.com/lookatitude/guild --skill guild-reflect

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Post-task reflection helps teams capture learning from a Guild run, convert outcomes into concrete improvement proposals, and ensure memory is preserved without mutating wiki content or decisions.

Core Features & Use Cases

Generates four proposal categories from run inputs: skill_improvement, missing_specialist, context_issues, and followup_backlog.
Writes a single proposal file per run to .guild/reflections/<run-id>.md, and surfaces the output for review and potential promotion by wiki-ingest/decisions components.
Triggers after guild:verify-done passes, gating reflections behind meaningful work and providing a persistent retrospective artifact.

Quick Start

Trigger the reflect skill after a successful verify-done to create the reflection file at .guild/reflections/<run-id>.md and begin review.

Frequently Asked Questions about guild-reflect

High-intent search queries and answers about installing and using this skill.

FAQPage Schema

How do I capture post-task run insights and convert them into improvement proposals?▼

Post-task run insights are captured by classifying observations into four proposal buckets: skill_improvement, missing_specialist, context_issues, and followup_backlog. The process extracts verbatim evidence from run inputs and writes a single reflection file at .guild/reflections/<run-id>.md.

When do I need to generate a reflection file for my run analysis?▼

You generate a reflection file only after a successful verify-done phase with at least one relevant action. This gating ensures that retrospective artifacts are created exclusively behind meaningful work, preserving accurate memory without mutating wiki content or decisions.

How do I extract observations from summary.md and handoff files for memory handoff?▼

Observations are extracted by identifying and classifying data from summary.md, handoffs/*.md, and verify.md inputs. The mechanism categorizes these inputs into distinct proposal buckets, producing a concise rationale and including verbatim evidence for each non-empty category.

Does the reflection process write updates directly to the wiki or decisions repository?▼

The reflection process never writes to the wiki or decisions repository. It outputs a single reflection file with frontmatter metadata and emits a handoff to /guild:stats when integrated, leaving content promotion to separate wiki-ingest or decisions components.

Can I use the reflection file for tracking context issues and missing specialist roles?▼

Yes, the reflection file specifically tracks context_issues and missing_specialist roles alongside skill_improvement and followup_backlog proposals. This categorization helps teams identify workflow gaps and role deficiencies directly from the run's verbatim evidence.

What is the best way to document a post-task retrospective without altering existing wiki content?▼

The best way is to generate a standalone reflection file at .guild/reflections/<run-id>.md. This approach captures learning and preserves team memory by surfacing proposals for review without directly mutating any existing wiki or decisions content.