User Evaluate

Purpose

Evaluate content through the lens of what Genesis knows about the user. The differentiator vs generic AI summary is the user model — Genesis's accumulated understanding of who this person is, what they care about, and what they're working on. Treat the user's placement of an item as a request for analysis, not as proof that the item is a strong personal fit or should be adopted.

When to Use

• User drops personal content (articles, research, ideas) into the inbox.
• Content is not Genesis-architecture-relevant but matters to the user.
• Inbox monitor classifies an item as user-relevant.
• User invokes /user-evaluate in a foreground session.

Workflow

1. Assemble user context — Read USER.md, query memory_recall MCP for topics related to the content, check user_model_cache and recent observations. USER.md is the floor; the memory system is the ceiling.
2. Fetch content — If the request supplies URLs, fetch every supplied URL and individually address each source; do not stop because the first source seems sufficient. Never evaluate based on URL text alone. Exhaust all access methods before reporting failure.
3. Apply four lenses — Evaluate through all four, do not skip or collapse:
   • What This Is — content-native analysis (argument, evidence, contribution)
   • How This Could Help You — user-model-informed value extraction
   • What We Could Do With It — collaborative actions (Genesis + user)
   • What to Watch — critical assessment (gaps, biases, counterarguments)
4. Tag (report-only) — Suggest Action Timeline (Now/Soon/Someday) and Relevance (Direct/Tangential/Background). These are recommendations, NOT binding metadata.
5. Write output — Structured evaluation in the format below.

Personal-Relevance Evidence Protocol

Find possible value without manufacturing personal fit. For every material claim about relevance, distinguish:

• Explicit — supported by a specific user statement, current goal, active project, known practice, or constraint in USER.md, memory, or observations.
• Inferred — a plausible connection derived from named evidence. Label it as an inference and say what would confirm or falsify it.
• Unknown — no user-specific evidence is available. Give the content-native value and the question it raises; do not backfill a personal story.
• Constraint-conflicted — a stated user boundary (privacy, employer policy, budget, time, platform, or explicit preference) materially limits the value.

The act of saving an item is evidence of attention, not evidence of agreement, priority, relevance strength, or adoption intent. Likewise, absence from the user model is not evidence of irrelevance. Keep these two directions separate.

Use Direct only when at least one specific, current user fact supports the connection. Generic usefulness, popularity, or broad career value does not make an item Direct. Recommendation strength, confidence, timeline, and next step must match the evidence status. When the connection is uncertain, prefer a bounded experiment or a concrete question over a fabricated confident action.

For external tools, separate the valuable mechanism from its packaging. Before suggesting that Genesis or the user build an equivalent, consider direct use, configuration, API/MCP/CLI integration, a sidecar or container, and reuse of a separable upstream component. Treat implementation language as integration cost, not an automatic veto, and compare those options with the full cost of building, testing, battle-hardening, and maintaining another implementation.

Output Format

When invoked from the inbox, follow the output template in INBOX_EVALUATE.md (summary-first, then lens-by-lens). When invoked standalone (e.g., /user-evaluate), use this structure:

{target title or URL}

Timeline: {Now | Soon | Someday} · Relevance: {Direct | Tangential | Background}

Summary

{1-2 paragraphs: what this is, why it matters to the user, and what to do about it. Lead with what matters most. If a lens contributed nothing meaningful, don't pad — this is a TLDR, not a formality. The reader should be able to stop here and know the key takeaway.}

Action items:

• {concrete collaborative next step if any}

Recommendation

action: explore            # adopt | explore | bookmark | potential_skip
next_step: "One concrete sentence — what specifically to do next"
effort: Small              # Trivial | Small | Medium | Large
timeline: Soon             # Now | Soon | Someday
relevance: Direct          # Direct | Tangential | Background
confidence: high           # low | medium | high

Action vocabulary (commitment gradient):

• adopt — high confidence, start using this now
• explore — medium confidence, try it and experiment before committing
• bookmark — relevant but not urgent, save for when timing is right
• potential_skip — probably not relevant, but leaving the door open

Rules:

• REQUIRED on every evaluation. No exceptions.
• The action field must match your recommendation in the Summary.
• next_step must be concrete and collaborative ("we" framing). "Look into this more" is not concrete. "Read the chapter on progressive summarization and prototype a workflow in your Obsidian vault" is concrete.
• timeline and relevance here are the machine-parseable version of the tags. When invoked standalone, the **Timeline:** / **Relevance:** line above serves as the human-readable quick-scan version. When invoked from the inbox (INBOX_EVALUATE.md template), only the YAML block appears.

What This Is

{Content-native analysis — argument, evidence, contribution}

How This Could Help You

{User-model-informed value extraction}

What We Could Do With It

{Collaborative actions — Genesis + user. Go beyond "adopt or ignore." Consider: incremental improvements to something already in play, better measurement of something currently vibes-checked, upgrades to the approach rather than the tool, patterns that make existing work more rigorous.

When the user asks "what can we learn from this?" — the answer includes EVERYTHING: small refinements, architectural upgrades, measurement gaps, better approaches to the same problem. Not just "should we use this tool."

If the user already does something similar (tool, technique, approach), consider producing a brief comparison:

Aspect	This approach	What you currently do	Delta
{aspect}	{specific}	{specific, from user model}	{improvement?}

This is optional (unlike the Genesis eval's required Overlap Comparison), but encouraged when the user model reveals an existing practice in the same space. Keep it to 2-4 rows.}

What to Watch

{Critical assessment — gaps, biases, counterarguments}

Key Rules

• Assume the request matters, not that the conclusion is positive. Find possible value, then calibrate personal-fit claims to user-specific evidence.
• Never dismiss content because the user model doesn't mention this topic.
• Never over-filter based on the user's known profile. They may be exploring new interests.
• "We" framing — actions are collaborative (Genesis + user), not reports.
• Tags are suggestions — Genesis does not dictate priority to the user.

References

• src/genesis/identity/USER.md — Compressed user snapshot
• docs/actions/user/active.md — User action item tracking
• docs/actions/README.md — Action item conventions