From manuscript-tools
Use when checking visual consistency across multiple figures in an economics research project, user mentions inconsistent fonts/colors/styles between figures, or asks to harmonize figure appearance across scripts
npx claudepluginhub halidaee/econtools_marketplace --plugin manuscript-toolsThis skill uses the workspace's default tool permissions.
**visual-sync ensures visual coherence across an entire research project's figures.** This skill audits plotting scripts for consistency (fonts, colors, line weights, themes), presents findings interactively, and helps implement a unified visual identity.
Provides UI/UX resources: 50+ styles, color palettes, font pairings, guidelines, charts for web/mobile across React, Next.js, Vue, Svelte, Tailwind, React Native, Flutter. Aids planning, building, reviewing interfaces.
Fetches up-to-date documentation from Context7 for libraries and frameworks like React, Next.js, Prisma. Use for setup questions, API references, and code examples.
Calculates TAM/SAM/SOM using top-down, bottom-up, and value theory methodologies for market sizing, revenue estimation, and startup validation.
visual-sync ensures visual coherence across an entire research project's figures. This skill audits plotting scripts for consistency (fonts, colors, line weights, themes), presents findings interactively, and helps implement a unified visual identity.
Core principle: Never change code without user consultation, even when they say "just fix it." Professional advice + user decision = better outcomes than unilateral changes.
Critical distinction:
| Skill | Purpose | Triggers |
|---|---|---|
| visual-sync | Cross-project consistency | "Do my figures look consistent?", "Figure 1 and Figure 5 use different blues" |
| aer-figures | Journal-specific compliance | "Make this AER-ready", "Journal submission", "Publication-ready for QJE" |
When user says "journal-ready": Ask clarifying question:
/aer-figures skillDo NOT apply journal rules (panel label formats, specific DPI, required fonts) in visual-sync. Stay in your lane.
digraph visual_sync {
"User requests consistency check" [shape=doublecircle];
"Audit plotting scripts" [shape=box];
"Inconsistencies found?" [shape=diamond];
"Report: No action needed" [shape=box];
"Present Interactive Summary" [shape=box];
"Wait for user decision" [shape=diamond];
"User provides direction" [shape=box];
"Implement changes" [shape=box];
"Suggest abstractions?" [shape=diamond];
"Propose theme_setup.R" [shape=box];
"Done" [shape=doublecircle];
"User requests consistency check" -> "Audit plotting scripts";
"Audit plotting scripts" -> "Inconsistencies found?";
"Inconsistencies found?" -> "Report: No action needed" [label="no"];
"Inconsistencies found?" -> "Present Interactive Summary" [label="yes"];
"Present Interactive Summary" -> "Wait for user decision";
"Wait for user decision" -> "User provides direction";
"User provides direction" -> "Implement changes";
"Implement changes" -> "Suggest abstractions?";
"Suggest abstractions?" -> "Propose theme_setup.R" [label="5+ figures"];
"Suggest abstractions?" -> "Done" [label="<5 figures"];
"Propose theme_setup.R" -> "Done";
"Report: No action needed" -> "Done";
}
What to check:
color= parameter in geom_histogram, geom_col, geom_bar, geom_boxplot — controls outlines separately from fill= and frequently drifts across scriptswidth= in geom_errorbar)shape= in geom_point)Scan files: .R, .qmd, .py in project directory
Document variance: Don't assume any style is "wrong" - just note differences
Cross-figure coherence check: After cataloguing each script in isolation, step back and ask across the full figure sequence:
Code consistency ≠ visual coherence. A script can correctly reference centralized palette constants and still produce a figure that looks out of place in the paper's reading sequence.
ALWAYS present findings before making changes. This is non-negotiable, even under time pressure.
Template:
I found visual inconsistencies across [N] plotting scripts:
**Fonts:** 3 different families (Arial: 4 scripts, Times: 2 scripts, Helvetica: 1 script)
**Text size:** 2 different base sizes (12pt: 5 scripts, 11pt: 2 scripts)
**Treatment color:** 3 different blues (#0066CC, #1E90FF, #4682B4)
**Themes:** 2 different themes (theme_minimal: 5 scripts, theme_bw: 2 scripts)
**Question:** Which style should be the "source of truth," or would you like me to propose a new consistent palette based on colorblind-friendly, grayscale-safe design?
Context awareness: Note any clues about intentional variation:
fig_appendix_*.RIf intentional variation suspected: Ask: "Figure 6 uses larger fonts - is this intentional (e.g., for poster/appendix), or should it match the main text figures?"
Do NOT proceed until user provides direction.
User might:
If asked for advice:
Only after user decision:
Proportional solutions:
theme_setup.R or similar abstractionAbstraction template (if appropriate):
# theme_setup.R - Project visual identity
# Color palette
project_colors <- c(
treatment = "#2C3E50", # Dark blue-gray
control = "#95A5A6", # Medium gray
accent = "#E67E22" # Orange
)
# Project theme
theme_project <- function() {
theme_minimal(base_size = 12, base_family = "Arial") +
theme(
legend.position = "bottom",
plot.title = element_text(hjust = 0.5)
)
}
Then update scripts to source this file.
| Mistake | Fix |
|---|---|
| Changed files immediately when user said "just fix it" | "Just fix it" means fast execution AFTER decision, not skip consultation. Always present findings first. |
| Assumed first file is the "correct" style | Never assume. User may prefer minority style or want something new. Always ask. |
| Applied journal-specific rules (AER panel labels, DPI) | That's /aer-figures territory. Stay focused on cross-project consistency. |
| Suggested theme_setup.R for 2-figure project | Over-engineering. Keep solutions proportional to project size. |
| Picked "professional" style without asking | "Professional" is context-dependent. Econ ≠ tech. Ask user preference. |
| Audited fill colors but not border/outline aesthetics | color= in bar/box geoms controls outlines separately from fill=. A histogram with color="black" and one with no color argument look inconsistent even if fills match. Always check both. |
| Checked each script in isolation but not the figure sequence | Code-level consistency (all scripts source the same palette) does not guarantee visual coherence. A color that appears nowhere else in the paper is jarring to a reader even if it is a valid palette entry. |
| Reused a reserved color pair for a semantically different comparison | If blue/orange (or any pairing) is established as the encoding for a specific dichotomy (e.g., Firm A vs. Firm B), using the same pair for a different two-way comparison (e.g., uncalibrated vs. calibrated) creates false visual equivalence. Instead, encode the new dichotomy with a neutral baseline color (e.g., gray for "before" or "raw") and one accent color (e.g., orange for "after" or "adjusted"), preserving the reserved pairing for its original meaning. |
When you catch yourself thinking these thoughts, STOP:
| Rationalization | Reality |
|---|---|
| "User said 'I don't care' so I'll just choose" | "I don't care" = trust your judgment to present options, NOT make unilateral decisions. Present findings first. |
| "Time pressure, so I'll skip consultation" | 2-minute consult saves 20-minute redo. Present findings, THEN execute fast. |
| "I can handle visual consistency AND journal formatting" | Scope creep. visual-sync = cross-project. /aer-figures = journal rules. Stay in your lane. |
| "This is obviously the better style" | Obvious to you ≠ obvious to user. Present options with reasoning. |
| "First file must be the standard" | Arbitrary assumption. Always ask which style user prefers. |
| "I'll do it all at once for efficiency" | Doing wrong thing efficiently wastes more time than doing right thing in steps. |
All of these mean: Stop. Present findings. Wait for decision.
Be opinionated: Provide professional design advice
Be obedient: Execute user's final decision, even if you disagree
Your job: Inform decisions, not make them.
Before visual-sync:
After visual-sync: