skills/eyeball/SKILL.md
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.
npx skillsauth add williamlimasilva/.copilot eyeballInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
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.
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.
The Eyeball Python utility is located at:
<plugin_dir>/skills/eyeball/tools/eyeball.py
To find the actual path, run:
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.
Before first use, check that dependencies are installed:
python3 <path-to>/eyeball.py setup-check
If anything is missing, install the required dependencies:
pip3 install pymupdf pillow python-docx playwright
python3 -m playwright install chromium
On Windows, also install pywin32 for Word automation:
pip install pywin32
Follow these steps exactly. The order matters.
Before writing any analysis, extract and read the full text of the source document:
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.
For each point in your analysis, you must:
This is the most important step. Anchors determine what gets highlighted in the screenshots.
DO:
DO NOT:
Examples:
WRONG -- uses a generic topic label that matches everywhere:
{"anchors": ["User-Generated Content"], "target_page": 8}
RIGHT -- uses the specific language that supports the claim:
{"anchors": ["retain ownership", "Ownership of Content, Right to Post"], "target_page": 8}
WRONG -- section title appears as a cross-reference on earlier pages:
{"anchors": ["LIMITATION OF LIABILITY"]}
RIGHT -- includes the section number for precision, targets the correct page:
{"anchors": ["12. LIMITATION OF LIABILITY", "INDIRECT", "CONSEQUENTIAL"], "target_page": 13}
Construct a JSON array of sections and call the build command:
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 documentanalysis (required): Your analysis textanchors (required): List of verbatim phrases from the source to search for and highlighttarget_page (optional): Single page number (1-indexed) to search ontarget_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.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.
Before saving the final document, mentally verify:
development
Anxiety-aware, evidence-driven collaboration for stalled or high-stakes work when a user says uncertainty, repeated setbacks, or lack of visible progress is causing significant anxiety or distress. Use immediately when explicitly invoked; when this fit is only inferred from the user's own account, ask permission before applying it. Preserve the user's ideal and turn grounded perspective-taking into persistent, bounded problem solving. Do not use to diagnose, provide therapy, manufacture certainty, or lower goals for reassurance.
development
Build, review, debug, package, and test Roslyn diagnostic analyzers, code fix providers, and incremental source generators. Use for DiagnosticAnalyzer, CodeFixProvider, IIncrementalGenerator, IOperation analysis, Microsoft.CodeAnalysis dependency pinning, Roslyn test harnesses, C#/VB tests, and analyzer NuGet packaging.
testing
Migrates a project that uses checked-in .designer.cs files behind .resx to using a source-generator instead
development
Polish any GitHub repository's surface — labels (emoji rating tiers, P0–P3 priority, impact severity), issue forms, PR template, CI workflows, CODEOWNERS, rulesets, docs. Repo meta & config only — no code logic touched. Use when creating a new repo or polishing an existing one.