evaluate

Evaluate

Purpose

Assess a technology, tool, article, or competitive development for relevance to Genesis. Produce a structured evaluation with clear recommendations.

When to Use

• New tool or library surfaces that might replace or augment a Genesis component.
• Competitive product launches or updates (e.g., Cursor Automations, Devin).
• User shares an article or resource for assessment.
• Surplus compute is available and the evaluation queue is non-empty.

Workflow

1. Gather context — Read the target material. If the request supplies URLs, fetch every supplied URL and individually address each source; do not stop because the first source seems sufficient. If a concept, research current state.
2. Search for alternatives and in-flight work — When the target is a tool, product, library or capability (not only an idea in an article), it is one candidate, not the field. Before scoring it, search for what else already does the job, and log each search in the output's **Searched:** line. The routes depend on where you run: a foreground session has Bash and every MCP server; a research background session has recon_github_search / recon_github_read and web_fetch, but no Bash; an inbox evaluation has only the health and memory servers (web_search, web_fetch). A search you have no route for is logged as "not run: no route in this context" and named in next_step, never logged as zero results.
   • Genesis's own queue. Open PRs and issues on the public Genesis repo that touch the same area. Foreground: gh pr list --state open --search "<terms>" --limit 1000, same for gh issue list. Research background: recon_github_search(kind="issues", query="<terms>", state="open", repository="<public repo>") finds issues only; follow its pagination signal. Open PRs have no background route. A draft PR or an issue may already own the capability, or the target may replace one.
   • Existing implementations. Public repositories (gh search repos, recon_github_search) and exact code (searchGitHub / grep.app, foreground only).
   • Claude Code mods and plugins, whenever the capability runs inside a Claude Code session: a hook or guard, status line, prompt or context injection, tool interception, notifications, an in-terminal pane, session awareness. From CC 2.1.287 plugins can carry mods (JS/TS function hooks with UI, tool, agent and model calls); a public catalogue scans over three thousand. Foreground: the mod-finder plugin's search_mods tool if installed (it filters by access, e.g. without: ["network"]), otherwise grep the catalogue it reads, https://raw.githubusercontent.com/karanb192/awesome-claude-code-mods/main/catalogue.md. Any context with web_fetch: Anthropic's directory, https://raw.githubusercontent.com/anthropics/claude-plugins-official/main/.claude-plugin/marketplace.json. The community catalogue has no background route yet (#3321). Check each candidate's validated CC version against the pin in docs/reference/cc-compatibility.md: below 2.1.287 a mod needs the early-access flag. Keep action: ADOPT and record the required pin bump in next_step / scope; do not invent an action enum value. Mods are unsandboxed: record each candidate's access footprint, and never propose a mod as the only enforcement for a guard, because a mod that denies a tool call ran before the classic PreToolUse hooks and suppressed them when measured (#2260). A negative result is "not found in ", never "nothing exists".
3. Map to Genesis — Identify which Genesis components or design decisions the target intersects (routing, memory, perception, surplus, etc.).
4. Assess fit — Score along these axes:
   • Capability gap: Does this solve something Genesis lacks?
   • Replacement risk: Could this obsolete a Genesis component?
   • Integration cost: How much work to adopt or adapt?
   • Lock-in risk: Does adopting this violate the flexibility principle?
   • Rigor gap: Where Genesis has an equivalent, is ours as rigorous? "We have X" is not the same as "our X measures effectiveness, handles edge cases, and improves over time." Compare the QUALITY of our implementation against the reference, not just its existence.
   • Overlap Comparison table: When Genesis has a comparable capability, produce the Overlap Comparison table (see Output Format below) instead of prose claims like "we already have this." Required whenever rigor gap is not "N/A — no Genesis equivalent."
5. Recommend — One of: ADOPT, WATCH, IGNORE, ADAPT (take the idea, not the tool). Disposition posture: Genesis's scope is everything digital — default toward ADOPT/ADAPT and acting now. "No current use case", "out of our wheelhouse", and "not obviously valuable" are NOT valid grounds for WATCH/IGNORE. A weaker existing Genesis version means UPGRADE (do the rigor-gap / Overlap comparison), never dismiss. WATCH requires a named re-activation trigger; a trigger-less WATCH is a disguised IGNORE — write it as an honest IGNORE with a reason. ADAPT (stealing patterns/rigor without adopting the code) is common and valuable, but it is not a polite default for "I don't want to act" — reach for ADOPT when the thing itself fits.
6. Write output — Structured evaluation in the format below.