eiirp

What this skill does

# EIIRP — Everything In Its Right Place

> *"Everything in its right place"* — Radiohead, Kid A

## Contract

After any significant work, EIIRP organizes ALL outputs across two domains:

**Knowledge domain (brain):**
1. Every piece of knowledge lands in the correct brain location.
2. All sources are cited and linked.
3. The active schema pack is updated if a new content type emerged.
4. Entity pages created/updated with cross-links.

**Capability domain (skills):**
5. Every reusable pattern becomes a composable skill.
6. Existing skills are audited for DRY violations.
7. Skill graph is MECE — no gaps, no overlaps, no ambiguous routing.

**The meta-guarantee:** Nothing produced during significant work lives only in chat.
Knowledge → brain. Patterns → skills. Everything in its right place.

## When to Use

- After completing a deep research thread.
- After building something new (code, pipeline, workflow).
- After a multi-source analysis that produced significant findings.
- When the user says "EIIRP", "organize this", "DRY this up", "make this re-doable".
- When a work session produced both knowledge AND new capabilities.
- When you notice skill overlap, duplication, or gaps.

## Phase 1: INVENTORY — What did we produce?

Scan the current session/thread and identify ALL outputs across both domains.

### Knowledge outputs
```
□ Primary findings (the synthesis)
□ Source documents (URLs, PDFs, articles, tweets)
□ Entity mentions (people, companies, organizations, places)
□ Concepts/frameworks (reusable mental models)
□ Data artifacts (structured data, timelines, statistics)
```

### Capability outputs
```
□ New skills created or modified
□ Scripts/code written (should they be in lib/ or scripts/?)
□ Methodology used (search patterns, source chains, verification steps)
□ Workflows that could be automated (cron, pipeline, webhook)
□ Patterns that will recur (→ candidate for skillification)
```

Produce a manifest:

```markdown
## EIIRP Manifest
- Topic: [topic]
- Date: [date]
- Knowledge outputs: [count] (sources, entities, concepts)
- Capability outputs: [count] (skills, scripts, patterns)
- Reusable methodology: [yes/no — describe if yes]
```

## Phase 2: TAXONOMY — Where does each piece go?

**Read the active schema pack first** (the single source of truth for
filing decisions in v0.39+):

```bash
gbrain schema show --json
```

The pack's `page_types[]` lists every directory the brain accepts plus
the primitive each maps to. Walk it for each output and pick the directory
whose `path_prefixes` matches the content's primary subject.

If `brain-taxonomist` is installed, INVOKE IT for ambiguous cases. It runs
the same decision protocol against the active pack and gives you a single
recommended filing path with reasoning.

Output: a filing plan table:

```
| Content | Brain path | Action |
|---------|-----------|--------|
| Primary research | reference/.../page.md | CREATE |
| Person X | people/x-slug.md | CREATE |
| Person Y | people/y-slug.md | UPDATE (already exists) |
| ... | ... | ... |
```

## Phase 3: SCHEMA CHECK — Does the active pack cover this content?

This is where EIIRP closes the schema-derivation loop. If the work
produced content that doesn't fit any existing `page_types`, propose
adding a new type via the v0.39 cathedral:

```bash
# What's emerging in the brain that the active pack doesn't cover?
gbrain schema detect --json

# LLM-refined suggestions (heuristic when no API key set).
gbrain schema suggest --json

# Review what's pending; promote or ignore each candidate.
gbrain schema review-candidates --json
gbrain schema review-candidates --apply <prefix-or-type-name>
```

**Confidence floor (codex finding #9):** when `gbrain schema suggest`
returns confidence < 0.6 on a proposed type, DO NOT auto-apply. Surface
the suggestion to the user and let them choose. The schema-cathedral
ships the primitives; EIIRP enforces the human-in-the-loop gate.

If schema needs change:
- Propose the addition to the user before running `review-candidates --apply`.
- Document the change in the commit message of the next sync.
- The schema-pack engine writes the delta to
  `~/.gbrain/schema-pack-deltas/` — review and merge into the active
  pack via `gbrain schema edit` (or hand-edit the YAML).

## Phase 4: FILE — Create enriched brain pages

For each item in the filing plan:

### 4a. Primary research page
Use the brain page template. MUST include:
- Proper frontmatter (`type`, `title`, `date`, `tags`, sources)
- **State** section — current status/key findings
- **Sources** section — every source with URL, author, date, language
- **Timeline** section — chronological development
- **Entity links** — backlinks to all related brain pages
- **See Also** — related concepts, reference pages

### 4b. Entity pages (people, companies)
For each entity mentioned:
- Check if a brain page exists (`gbrain search "<name>"` or `gbrain get_page people/<slug>`).
- If exists: update State, append Timeline entry citing this research.
- If not: create with enrichment.

### 4c. Commit and verify
After ALL pages are written, run `gbrain sync` (or commit + push in the
brain repo). Verify every link resolves.

## Phase 5: SKILL GRAPH AUDIT — DRY + MECE on capabilities

This phase operates on the SKILL graph, not just the research.

### 5a. New pattern identification

Ask: did this work reveal REPEATABLE patterns that will recur?

**Indicators of a reusable pattern:**
- You used a specific sequence of searches across multiple sources.
- You followed a specific verification/cross-referencing methodology.
- You wrote code that could be parameterized for different inputs.
- The output format is generalizable.
- The user is likely to ask for similar work on a different topic.

**For each identified pattern:**
1. Identify the composable pieces (DRY, MECE):
   - Shared logic → `lib/` (not copy-pasted into skills)
   - Search methodology → skill or lib function
   - Output template → brain template or skill phase
   - Filing logic → already covered by brain-taxonomist + active pack
2. DRY check via the v0.19 resolver:
   ```bash
   gbrain check-resolvable
   ```
   Look for overlapping triggers or unreachable skills.

### 5b. Existing skill audit
For ALL skills used or touched during this work, check:
1. Were any skills BYPASSED? (did you do something manually that a skill should handle?)
2. Are there skills that OVERLAP with what you just did? (merge candidates)
3. Is shared code copy-pasted between skills? (extract to `lib/`)

**The MECE question:** If someone asked for this exact work again tomorrow on a different topic, which skills would they invoke? Is the path clear and unambiguous? If not, fix the routing.

### 5c. Present the plan
```
## Skill Graph Changes

### New skills to create
1. **[skill-name]** — [what it does]
   - DRY check: [clean / overlaps with X]
   - Recommendation: [create / merge into X]

### Existing skills to update
1. **[skill-name]** — [what changed, why]

### Code to extract to lib/
1. **lib/[name].ts** — [what it does, which skills use it]

### Skills to merge or deprecate
1. **[skill-A] + [skill-B]** → [merged-skill] — [why]
```

On approval: invoke `/skillify` for each new/modified skill.

## Phase 6: CHECK_RESOLVABLE — Verify everything routes

After all filing and skillification:

```bash
gbrain check-resolvable                         # routing-table reachability
gbrain doctor --json                            # health surface
gbrain search "<topic keywords>"                # brain pages findable
gbrain orphans                                  # any pages without inbound links?
```

Confirm:
- [ ] All brain pages have proper frontmatter against active schema pack
- [ ] All entity pages are cross-linked
- [ ] Any new skills have routing entries in `skills/RESOLVER.md`
- [ ] No DRY violations (no duplicated logic across skills)
- [ ] No MECE violations (no ambiguous routing between skills)
- [ ] Active schema pack updated if new content types emerged
- [