/assess

description: "Assess a local repo against the active wiki's research body and the broader market. Gap analysis, opportunities, competitive landscape."
argument-hint: "<repo-path> [--wiki <name>] [--local] [--retardmax] [--include-archived]"
allowed-tools: Read, Write, Edit, Glob, Grep, Bash(ls:*), Bash(wc:*), Bash(date:*), Bash(find:*), Bash(head:*), WebFetch, WebSearch, Agent

Your task

**Resolve the wiki.** Do NOT search the filesystem or read reference files — follow these steps: 1. Read `$HOME/.config/llm-wiki/config.json`. If it has `hub_path`, expand leading `~` only (not tildes in `com~apple~CloudDocs`) and prefer that path; use `resolved_path` only as a fallback cache when the expanded `hub_path` is unavailable and `resolved_path` is initialized. If config has only `resolved_path`, use it. If the configured path can be statted but reading `wikis.json` or listing `topics/` fails with `Operation not permitted`, stop and ask the user to grant Full Disk Access/iCloud Drive access to the launcher; do not fall back to `~/wiki` or `resolved_path`. Do not write machine-specific `resolved_path` into shared configs. 2. If no config → read `$HOME/wiki/_index.md`. If it exists → HUB = `$HOME/wiki`. If nothing found, ask the user where to create the wiki. 3. **Wiki location** (first match): `--local` → `.wiki/` in CWD; `--wiki <name>` → `HUB/wikis.json` lookup with portable path resolution (`<HUB>`, `~`, absolute, or HUB-relative); if the registry path is stale, fall back to `HUB/topics/<name>`; CWD has `.wiki/` → use it; else → HUB. 4. Read `<wiki>/_index.md` to verify. If missing → stop with "No wiki found. Run `/wiki init <topic>` first."

Compare a local repository against the wiki's knowledge base and the broader market. Produce a comprehensive gap analysis.

Inventory awareness: repo/wiki/market gaps that are durable follow-ups should be offered as inventory candidates, especially feature candidates, source queues, competitor watch items, or blocked research tasks. Show a compact sample before creating a larger backlog. Do not use inventory records as evidence in the competitive analysis; cite wiki articles, raw sources, or fresh research.

Deviation: wiki resolution order

Unlike other commands, `assess` does NOT default to HUB when no wiki is specified — gap analysis against an empty hub is meaningless. The resolution order is:

1. `--wiki <name>` → look up in `HUB/wikis.json` 2. `--local` → `.wiki/` in current directory 3. Otherwise → ask the user which topic wiki to compare against (do not silently pick one)

Parse $ARGUMENTS

• **repo-path**: Path to the local repository to analyze
• **--wiki <name>**: Which topic wiki to compare against
• **--retardmax**: Skip planning, scan everything, cast wide net on web search
• **--local**: Use project-local wiki
• **--include-archived**: Explicitly allow archived wiki context. Label

archived-derived evidence in the report.

Archived topic wikis are excluded by default, including in `--retardmax`. If the selected `--wiki` is archived, stop and ask the user to restore it or rerun with `--include-archived`.

Compare Protocol

Phase 1: Repo Analysis (parallel agents)

Launch 3 agents IN PARALLEL to understand the repo:

| Agent | Focus | What to read | |-------|-------|-------------| | **Structure** | What the repo IS — architecture, tech stack, directory layout | README, package.json/requirements.txt, directory tree, config files, CLAUDE.md | | **Features** | What the repo DOES — capabilities, commands, APIs, skills | Command files, skill files, source code entry points, route handlers, CLI help | | **Docs** | What the repo CLAIMS — documentation, examples, known limitations | README, docs/, examples/, CHANGELOG, issues if accessible |

Each agent returns a structured summary:

• List of features/capabilities with brief descriptions
• Technologies and dependencies used
• Target audience and use cases
• Known limitations or TODOs mentioned in the code

Phase 2: Wiki Knowledge Scan

1. Read the target wiki's `_index.md` and all category indexes 2. Read all wiki articles (or index summaries if many) 3. Build a knowledge map: what concepts, techniques, tools, and practices does the wiki cover? 4. Note confidence levels — high-confidence wiki knowledge is established, low-confidence is frontier

Phase 3: Gap Analysis

Compare repo features against wiki knowledge:

**A. Repo implements, wiki covers** — alignment. Note where the repo's implementation matches or differs from what the research says is best practice.

**B. Repo implements, wiki silent** — blind spots in research. The repo does things the wiki hasn't researched yet. These are candidates for `/wiki:research` to fill the gap.

**C. Wiki covers, repo doesn't implement** — opportunities. The research suggests capabilities the repo hasn't built yet. These are feature candidates.

**D. Neither covers** — discovered in Phase 4.

Phase 4: Market Scan (parallel agents)

Launch agents IN PARALLEL to find what's out there:

| Agent | Focus | |-------|-------| | **Competitors** | Search for similar tools, projects, products in the same space. What features do they have? | | **Best Practices** | Search for industry best practices, standards, and recommendations the repo should follow. | | **Emerging** | Search for cutting-edge developments, new techniques, or upcoming changes in the field. |

In `--retardmax` mode, add:

| Agent | Focus | |-------|-------| | **Adjacent** | Tools from adjacent fields that solve similar problems differently | | **Failures** | What has been tried and failed in this space? What to avoid? |

Phase 5: Report

Generate a comprehensive comparison report saved to the wiki's `output/` directory. Follow core principle #9 (chunked writes): Write frontmatter + executive summary first, then Edit to append each section.

File: `output/assess-{repo-name}-{YYYY-MM-DD}.md`

---
title: "Repo Comparison: {repo-name} vs {wiki-n