Ego Simulate

---
name: ego-simulate
description: >-
  Simulate an EGO review submission — produces a readiness report based on
  published review criteria. Triages the extension in reviewer order, applies
  a 23-reason rejection taxonomy with weighted scoring, and generates a
  structured report with a pass/fail verdict. Use before EGO submission to
  assess review readiness.
---

# EGO Review Simulation

Simulate how an EGO (extensions.gnome.org) reviewer would evaluate this GNOME
Shell extension submission. Unlike ego-review (which is a thorough code review)
or ego-submit (which is a packaging pipeline), this skill focuses on
**assessing the extension against known review criteria and published rejection
patterns**.

## Prerequisites

The extension directory must be provided by the user (or use the current
working directory).

## Process

### Step 1: Run ego-lint

Run the automated linter first to establish a baseline:

```bash
bash skills/ego-lint/scripts/ego-lint.sh --show all EXTENSION_DIR
```

Capture the results: FAIL count, WARN count, and specific findings with
file:line references. These feed directly into the scoring in Step 3.

### Step 2: Reviewer Triage

Read `references/reviewer-persona.md` before starting this step.

Adopt the reviewer persona and triage the extension in the order reviewers
actually follow. Do NOT reorganize by category — follow this exact sequence:

1. **metadata.json** — Check UUID, shell-version, required fields, session-modes.
   A bad UUID or missing shell-version stops the review immediately.
2. **Code volume** — Count files and total lines. Assess whether this is
   reviewable in reasonable time. >5000 lines triggers extra scrutiny.
3. **enable/disable symmetry** — Quick visual check that `disable()` undoes
   everything `enable()` creates. This is the #1 rejection cause.
4. **Signal management** — Search for `.connect(` and `.disconnect(` — counts
   should roughly balance. Check for `connectObject` usage (modern pattern).
5. **Timeout handling** — Search for `timeout_add` and `Source.remove` /
   `GLib.Source.remove`. Verify stored IDs and cleanup in disable.
6. **Import segregation** — Quick scan that `extension.js` doesn't import GTK
   and `prefs.js` doesn't import Shell modules.
7. **Deeper read** — Only if all above pass: check for AI slop signals,
   security issues, API correctness, code quality.

For each step, note what a reviewer would think. Use the reviewer's internal
monologue style: "I see X but Y is missing" or "This looks clean."

### Step 3: Score

Read `references/rejection-taxonomy.md` before scoring.

Apply the 23-reason rejection taxonomy. For each reason:
- Check whether the extension triggers it
- If triggered, record the weight and the specific evidence (file:line)
- Each reason contributes its weight ONCE regardless of occurrence count

Sum the weights to compute the base score, then apply the Scoring Modifiers
from `rejection-taxonomy.md` (provenance discount, unmapped FAIL adjustment,
size normalization) to arrive at the final score.

### Integration with ego-lint results

After computing the taxonomy score, cross-reference with ego-lint results
from Step 1:

- Each ego-lint **FAIL** that doesn't already map to a taxonomy reason adds
  weight 5 to the score (structural issue equivalent)
- ego-lint **WARN** results do not add to the score but should be mentioned
  in the Advisory Notes section of the report
- If ego-lint reports 0 FAIL, no adjustment needed

This ensures the simulation verdict reflects automated check failures that
a real reviewer would catch immediately.

Also read `references/approved-examples.md` to calibrate — note where the
extension follows or deviates from idiomatic patterns.

### Step 4: Report

Generate the simulation report in this exact format:

```markdown
## EGO Review Simulation Report

### Extension: [name] ([uuid])

### Triage Summary
[2-3 sentence overview of first impressions, written as the reviewer's internal
monologue. What did they notice first? What's their gut feeling?]

### Blocking Issues (score: N)
- **[Reason #] [Reason name]** (weight N): [Evidence with file:line reference]

### Reviewer Concerns (score: N)
- **[Reason #] [Reason name]** (weight N): [Evidence with file:line reference]

### Advisory Notes
- [Non-blocking observations that reviewers would mention in comments]

### Verdict
**Score: N** — [verdict text based on threshold]
- 0: Likely to pass without comments
- 1-4: Likely to pass with minor comments
- 5-9: May pass, but expect revision requests
- 10+: Will be rejected — address blocking issues first

> **Note:** ego-simulate uses a fast heuristic based on the 23-reason rejection
> taxonomy with fixed weights. ego-review uses a different scale (risk points
> from finding categories). The two scores are not directly comparable — a
> simulate score of 5 does not equal an ego-review risk score of 5. Use
> ego-simulate for quick triage and ego-review for authoritative assessment.

### Suggested Fixes (priority order)
1. [Most impactful fix — the one that drops the score the most]
2. [Next fix]
...
```

## References

Read these reference documents before generating the report:
- `references/reviewer-persona.md` — How reviewers triage submissions
- `references/rejection-taxonomy.md` — 23 rejection reasons with weights
- `references/approved-examples.md` — Idiomatic patterns reviewers like

## Important

- Be honest and direct, like real reviewers. Do not soften rejection verdicts.
- The score must reflect what would actually happen on EGO.
- Include specific file:line references for every triggered rejection reason.
- AI slop signals are cumulative — 3+ signals at weight 8 push the score well
  past the rejection threshold. This matches real reviewer behavior since the
  Dec 2025 blog post.
- A single weight-10 hard blocker is independently sufficient for rejection,
  regardless of how clean the rest of the code is.
- When the verdict is rejection, lead with that. Don't bury it under praise.