peer-reviewer
Simulate peer review by constructing reviewer personas from Zotero sources. Identifies relevant perspectives, retrieves full texts, builds reviewer profiles, and generates focused reviews on theory/methods and findings.
What this skill does
# Peer Reviewer You help authors get pre-submission feedback by simulating peer review. You identify 2-3 relevant reviewer perspectives based on the manuscript's theoretical and empirical engagement, retrieve their work from Zotero, construct informed reviewer personas, and generate focused reviews that help authors strengthen their manuscripts before submission. ## What This Skill Does This skill creates **simulated peer reviewers** grounded in actual scholarly work: 1. **Identifies perspectives** - Analyzes the manuscript to find 2-3 relevant reviewer viewpoints (specific scholars or theoretical camps) 2. **Retrieves literature** - Uses Zotero MCP to fetch full texts from those perspectives 3. **Builds personas** - Reads the literature to understand each perspective's core commitments and concerns 4. **Generates reviews** - Each persona reviews the manuscript, focusing on their area of expertise 5. **Synthesizes feedback** - Aggregates reviews into actionable recommendations 6. **Supports revision** - Helps authors address feedback (optional) ## Prerequisites **Required**: [Zotero MCP](https://github.com/54yyyu/zotero-mcp) configured and connected to your Zotero library with relevant full texts. The quality of simulated reviews depends on having relevant sources in your Zotero library. The skill works with whatever is available but produces better results with richer libraries. ## When to Use This Skill Use this skill when you want to: - Get feedback before submitting to a journal - Anticipate reviewer concerns from specific theoretical camps - Check whether you're representing others' work fairly - Identify blind spots in your argument - Practice responding to critical feedback ## What You Can Submit - **Full manuscripts** - Complete drafts with all sections - **Partial manuscripts** - Theory + Findings, or Methods + Findings - **Section drafts** - Individual sections for targeted feedback The skill adapts its review focus based on what you provide. ## Core Principles 1. **Grounded in sources**: Reviewer personas are built from actual texts, not stereotypes about theoretical camps. 2. **Focused reviews**: Each reviewer focuses on 1-2 areas (theory + findings OR methods + findings) based on their expertise. 3. **Constrained by Zotero**: We can only simulate perspectives for which you have full texts available. 4. **User control**: You approve reviewer selection, personas, and response strategy at each step. 5. **Constructive orientation**: Reviews aim to strengthen the manuscript, not just critique. 6. **Honest simulation**: Reviewers represent their perspective faithfully, even when it creates tension with the manuscript. ## The Review Focus Matrix | Reviewer Type | Primary Focus | Secondary Focus | |---------------|---------------|-----------------| | **Theoretical** | Theory section | Findings (theoretical implications) | | **Methodological** | Methods section | Findings (analytic validity) | | **Empirical/Substantive** | Findings | Theory (empirical grounding) | ## Workflow Phases ### Phase 0: Intake & Reviewer Identification **Goal**: Read manuscript and identify 2-3 relevant reviewer perspectives. **Process**: - Read the full manuscript (or available sections) - Identify key theoretical frameworks invoked - Note scholars cited prominently or engaged critically - Identify empirical/methodological traditions - Propose 2-3 reviewer perspectives with rationale - Check Zotero availability for each perspective **Output**: Reviewer identification memo with proposed perspectives. > **Pause**: User confirms reviewer selection (may modify, add, or remove). --- ### Phase 1: Literature Retrieval **Goal**: Fetch relevant full texts from Zotero for each perspective. **Process**: - For each confirmed reviewer perspective: - Search Zotero for relevant works (by author, tag, or collection) - Retrieve full texts (prioritize foundational works + recent pieces) - Note any gaps (perspectives without sufficient sources) - Compile source list for each perspective **Output**: Retrieved sources organized by reviewer perspective. > **Pause**: User reviews retrieved sources, may suggest additions. --- ### Phase 2: Persona Construction **Goal**: Read sources and build reviewer profiles. **Process**: - For each perspective, read retrieved sources to identify: - Core theoretical commitments - Methodological preferences - Key concepts and terminology - Common critiques they make of others' work - What they value in scholarship - Construct a reviewer persona profile - Assign review focus (theory + findings OR methods + findings) **Output**: Reviewer persona profiles with focus areas. > **Pause**: User approves personas (may refine characterizations). --- ### Phase 3: Simulated Reviews **Goal**: Each persona reads the manuscript and writes a review. **Process**: - For each reviewer persona: - Read the manuscript through their lens - Evaluate their assigned sections - Check: Is their work cited? Accurately represented? - Assess theoretical/methodological/empirical engagement - Write a focused review (strengths, concerns, suggestions) - Present each review to the user **Output**: 2-3 simulated reviews. > **Pause**: User reads each review before synthesis. --- ### Phase 4: Synthesis & Response Strategy **Goal**: Aggregate feedback and develop response approach. **Process**: - Identify convergent concerns (raised by multiple reviewers) - Identify divergent concerns (perspective-specific) - Classify feedback as: - **Quick fixes** - Can address immediately - **Minor revisions** - Require some rewriting - **Major revisions** - Require structural changes or new analysis - **Acknowledge but decline** - Valid perspective, but outside scope - Prioritize by impact and feasibility - Draft response strategy **Output**: Synthesis memo with prioritized recommendations. > **Pause**: User confirms response strategy. --- ### Phase 5: Revision Support **Goal**: Help author address feedback. **Process**: - Work through prioritized items - For theory revisions: may invoke lit-writeup patterns - For methods revisions: may invoke methods-writer patterns - For findings: work directly with author - Track changes made - Optionally re-run affected reviewers to verify improvements **Output**: Revised sections + revision log. > **Iterative**: User involved throughout revision process. --- ## Naming Convention: Theory, Not Person **IMPORTANT**: Reviewer personas are always named for theoretical perspectives, methodological traditions, or conceptual frameworks—never for individual scholars. Even when sources come primarily from one author, name the persona for the *perspective* that author represents: | Instead of... | Use... | |---------------|--------| | "Deborah Gould" | "Emotions in Movements Perspective" | | "Corrigall-Brown" | "Movement Disengagement Typology" | | "Fillieule" | "Activist Career Approach" | | "Annette Lareau" | "Cultural Capital in Education" | This avoids the awkwardness of simulating a specific person and keeps focus on the theoretical lens being applied. ## Reviewer Persona Template Each constructed persona includes: ```markdown ## Reviewer: [Theoretical Perspective Name] **Perspective**: [Name of theoretical/methodological framework] **Key sources**: [Authors whose work informs this perspective] **Core commitments**: - [Key theoretical position 1] - [Key theoretical position 2] - [Methodological preference] **Sources consulted**: - [Source 1 - Zotero key] - [Source 2 - Zotero key] - [Source 3 - Zotero key] **What this perspective values**: - [Quality 1] - [Quality 2] **Common critiques from this perspective**: - [Type of critique this tradition makes] **Review focus**:
Related in Code Review
gstack
IncludedFast headless browser for QA testing and site dogfooding. Navigate pages, interact with elements, verify state, diff before/after, take annotated screenshots, test responsive layouts, forms, uploads, dialogs, and capture bug evidence. Use when asked to open or test a site, verify a deployment, dogfood a user flow, or file a bug with screenshots. (gstack)
startup-due-diligence
IncludedLegal due diligence review for seed-stage and Series A startups (US, Delaware C-Corp focus). Supports both investor and founder perspectives. Capabilities include: (1) Interactive document review and issue spotting; (2) Document request list generation; (3) Cap table and SAFE/convertible note analysis; (4) Red flag identification with severity ratings; (5) Diligence report generation. TRIGGERS: due diligence, DD, startup investment, cap table review, Series A, seed round, investor diligence, legal review startup, SAFE analysis, convertible note, 409A, founder vesting.
interview-master
IncludedThis skill should be used when the user asks to "generate interview questions", "prepare for interview", "optimize resume", "conduct mock interview", "analyze git commits for resume", "generate resume from code", "review my resume", or mentions interview preparation, career assistance, or extracting project experience from git history. Provides comprehensive interview and career development guidance for both job seekers and interviewers.
fix-issue
IncludedFixes GitHub issues using parallel analysis agents for root cause investigation, code exploration, and regression detection. Reads issue context from gh CLI, searches codebase and memory for related patterns, generates a fix with tests, and links the resolution back to the issue via PR. Includes prevention analysis to avoid recurrence. Use when debugging errors, resolving regressions, fixing bugs, or triaging issues.
sf-apex
IncludedGenerates and reviews Salesforce Apex code with 150-point scoring. TRIGGER when: user writes, reviews, or fixes Apex classes, triggers, test classes, batch/queueable/schedulable jobs, or touches .cls/.trigger files. DO NOT TRIGGER when: LWC JavaScript (use sf-lwc), Flow XML (use sf-flow), SOQL-only queries (use sf-soql), or non-Salesforce code.
swift-development
IncludedComprehensive Swift development for building, testing, and deploying iOS/macOS applications. Use when Claude needs to: (1) Build Swift packages or Xcode projects from command line, (2) Run tests with XCTest or Swift Testing framework, (3) Manage iOS simulators with simctl, (4) Handle code signing, provisioning profiles, and app distribution, (5) Format or lint Swift code with SwiftFormat/SwiftLint, (6) Work with Swift Package Manager (SPM), (7) Implement Swift 6 concurrency patterns (async/await, actors, Sendable), (8) Create SwiftUI views with MVVM architecture, (9) Set up Core Data or SwiftData persistence, or any other Swift/iOS/macOS development tasks.