eyeball
Document analysis with inline source screenshots. When you ask Copilot to analyze a document, Eyeball generates a Word doc where every factual claim includes a highlighted screenshot from the source material so you can verify it with your own eyes.
What this skill does
# Eyeball
Analyze documents with visual proof. When activated, Eyeball produces a Word document on the user's Desktop where every factual assertion includes an inline screenshot from the source material with the cited text highlighted in yellow.
## Activation
When the user invokes this skill (e.g., "use eyeball", "run eyeball on this", "eyeball this document"), respond with:
> **Eyeball is active.** I'll analyze the document and produce a Word doc with inline source screenshots so you can verify every claim with your own eyes.
Then follow the workflow below.
## Supported Sources
- **Local files:** Word documents (.docx, .doc), PDFs (.pdf), RTF files
- **Web URLs:** Any publicly accessible web page
## Tool Location
The Eyeball Python utility is located at:
```
<plugin_dir>/skills/eyeball/tools/eyeball.py
```
To find the actual path, run:
```bash
find ~/.copilot/installed-plugins -name "eyeball.py" -path "*/eyeball/*" 2>/dev/null
```
If not found there, check the project directory or the user's home directory for the eyeball repo.
## First-Run Setup
Before first use, check that dependencies are installed:
```bash
python3 <path-to>/eyeball.py setup-check
```
If anything is missing, install the required dependencies:
```bash
pip3 install pymupdf pillow python-docx playwright
python3 -m playwright install chromium
```
On Windows, also install pywin32 for Word automation:
```bash
pip install pywin32
```
## Workflow
Follow these steps exactly. The order matters.
### Step 1: Read the source text
Before writing any analysis, extract and read the full text of the source document:
```bash
python3 <path-to>/eyeball.py extract-text --source "<path-or-url>"
```
Read the output carefully. Identify actual section numbers, headings, page numbers, and key language.
**CRITICAL:** Do not skip this step. Do not write analysis based on assumptions about how the document is structured. Read the actual text.
### Step 2: Write analysis with exact citations
For each point in your analysis, you must:
1. **Reference the correct section number as it appears in the document** (e.g., "Section 9" not "Section 8" because you assumed the numbering).
2. **Reference the correct page number** where the section appears in the extracted text.
3. **Select anchors that are verbatim phrases from the source** that directly support your claim.
### Step 3: Select anchors correctly
This is the most important step. Anchors determine what gets highlighted in the screenshots.
**DO:**
- Use verbatim phrases from the source text that directly support your assertion
- Use multiple anchors to span the full range of text the reader should see
- Use specific, uncommon phrases that appear only where you intend
**DO NOT:**
- Use generic topic labels (e.g., "Confidentiality") that appear throughout the document
- Use section titles alone when they appear as cross-references elsewhere
- Use single common words that match in many places
**Examples:**
WRONG -- uses a generic topic label that matches everywhere:
```json
{"anchors": ["User-Generated Content"], "target_page": 8}
```
RIGHT -- uses the specific language that supports the claim:
```json
{"anchors": ["retain ownership", "Ownership of Content, Right to Post"], "target_page": 8}
```
WRONG -- section title appears as a cross-reference on earlier pages:
```json
{"anchors": ["LIMITATION OF LIABILITY"]}
```
RIGHT -- includes the section number for precision, targets the correct page:
```json
{"anchors": ["12. LIMITATION OF LIABILITY", "INDIRECT", "CONSEQUENTIAL"], "target_page": 13}
```
### Step 4: Build the analysis document
Construct a JSON array of sections and call the build command:
```bash
python3 <path-to>/eyeball.py build \
--source "<path-or-url>" \
--output ~/Desktop/<title>.docx \
--title "Analysis Title" \
--subtitle "Source description" \
--sections '[
{
"heading": "1. Section Title",
"analysis": "Your analysis text here. Reference Section X on page Y...",
"anchors": ["verbatim phrase 1", "verbatim phrase 2"],
"target_page": 5,
"context_padding": 40
},
{
"heading": "2. Another Section",
"analysis": "More analysis...",
"anchors": ["exact quote from source"],
"target_pages": [10, 11],
"context_padding": 50
}
]'
```
Section object fields:
- `heading` (required): Section heading in the output document
- `analysis` (required): Your analysis text
- `anchors` (required): List of verbatim phrases from the source to search for and highlight
- `target_page` (optional): Single page number (1-indexed) to search on
- `target_pages` (optional): List of page numbers to search across (screenshots stitched vertically)
- `context_padding` (optional): Padding in PDF points above/below the anchor region (default: 40). Increase for more context.
### Step 5: Deliver the output
Save the output to the user's Desktop. Tell the user the filename and that they can open it to verify each claim against the highlighted source screenshots.
## Self-Check Before Delivery
Before saving the final document, mentally verify:
1. Does each section's analysis text reference the correct section number from the source?
2. Are the anchors verbatim phrases that appear on the target page?
3. Does each anchor directly support the claim in the analysis, not just relate to the same topic?
4. If the screenshot doesn't match the analysis, is the analysis wrong or is the anchor wrong? Fix whichever is incorrect.
## Notes
- The output document includes highlighted screenshots that are dynamically sized. If you provide multiple anchors, the screenshot expands to cover all of them.
- When a search term is not found, the output document will note this. If this happens, the anchor was likely not verbatim enough. Adjust and rebuild.
- For web pages, Playwright renders the page to PDF first. The resulting page numbers may differ from what you see in a browser. Use the extracted text output (step 1) to determine correct page numbers.
- If the user has already provided the source text or you have already read it in the current conversation, you can skip step 1. But always verify section numbers and page references against the actual text before writing analysis.
Related in Writing & Docs
jax-development
IncludedUse this skill when the user is writing, debugging, profiling, refactoring, reviewing, benchmarking, parallelising, exporting, or explaining JAX code, or when they mention JAX, jax.numpy, jit, grad, value_and_grad, vmap, scan, lax, random keys, pytrees, jax.Array, sharding, Mesh, PartitionSpec, NamedSharding, pmap, shard_map, Pallas, XLA, StableHLO, checkify, profiler, or the JAX repo. It helps turn NumPy or PyTorch-style code into pure functional JAX, fix tracer/control-flow/shape/PRNG bugs, remove recompiles and host-device syncs, choose transforms and sharding strategies, inspect jaxpr/lowering/IR, and benchmark compiled code correctly.
nature-article-writer
IncludedDrafts, rewrites, diagnostically critiques, and style-calibrates primary research manuscripts for Nature and Nature Portfolio journals. Use when the user wants a Nature-style title, summary paragraph or abstract, introduction, results, discussion, methods, figure legends, presubmission enquiry, cover letter, reviewer response, or when a scientific draft sounds generic, jargon-heavy, structurally weak, or AI-ish and needs precise, broad-reader-friendly prose without inventing data, analyses, or references. Best for primary research articles and letters rather than reviews or press releases unless explicitly adapting one.
deckrd
IncludedDocument-driven framework that derives requirements, specifications, implementation plans, and executable tasks from goals through structured AI dialogue. Use when user says "write requirements", "create spec", "plan implementation", "derive tasks", "structure this feature", "break down into tasks", or "document this module". Also use for reverse engineering existing code into docs (/deckrd rev). Do NOT use for direct code writing — use /deckrd-coder after tasks are generated. Do NOT use when the user only wants to run or fix existing code without planning.
clinical-decision-support
IncludedGenerate professional clinical decision support (CDS) documents for pharmaceutical and clinical research settings, including patient cohort analyses (biomarker-stratified with outcomes) and treatment recommendation reports (evidence-based guidelines with decision algorithms). Supports GRADE evidence grading, statistical analysis (hazard ratios, survival curves, waterfall plots), biomarker integration, and regulatory compliance. Outputs publication-ready LaTeX/PDF format optimized for drug development, clinical research, and evidence synthesis.
handling-sf-data
IncludedSalesforce data operations with 130-point scoring. Use this skill to create, update, delete, bulk import/export, generate test data, and clean up org records using sf CLI and anonymous Apex. TRIGGER when: user creates test data, performs bulk import/export, uses sf data CLI commands, needs data factory patterns for Apex tests, or needs to seed/clean records in a Salesforce org. DO NOT TRIGGER when: SOQL query writing only (use querying-soql), Apex test execution (use running-apex-tests), or metadata deployment (use deploying-metadata).
accelint-ac-to-playwright
IncludedConvert and validate acceptance criteria for Playwright test automation. Use when user asks to (1) review/evaluate/check if AC are ready for automation, (2) assess if AC can be converted as-is, (3) validate AC quality for Playwright, (4) turn AC into tests, (5) generate tests from acceptance criteria, (6) convert .md bullets or .feature Gherkin files to Playwright specs, (7) create test automation from requirements. Handles both bullet-style markdown and Gherkin syntax with JSON test plan generation and validation.