URU Thesis Reviewer
Iterative feedback skill for URU theses. Each invocation produces a review session folder with numbered Markdown files the author reads, accepts/rejects, and applies to the source document. File templates in TEMPLATES.md; formal/linguistic check catalog in CHECKS.md; URU norms in NORMAS_URU_2020.md.
When to use
- User shares a
.docx(or a converted.md/.txt) of a URU thesis or chapter and asks for review, feedback, suggestions, or revision. - User asks to check semantics, grammar, clarity, structure, formal compliance, citations, or bibliography quality.
- User asks to compare against URU norms.
Do not use for:
- Editing the source document directly (this skill never touches the
.docx). - Evaluation / grading (this is improvement feedback, not a verdict).
- Non-URU theses (use a generic editor — URU norms are baked in).
1. Operating principles
- Read-only on source. Never edit, rewrite, or replace the
.docx. All output is review files the author applies manually. - Sequential & ordered. Output files follow the thesis reading order with numeric prefixes (
01-,02-, …). - One session per invocation. Each review goes in a fresh
YYYY-MM-DD/folder. Multiple sessions in one day → suffix-a,-b, … (2026-05-21-a/). - Diff format, not prose. Show the exact text to remove (
-) and the proposed replacement (+). - Severity-tagged. Every block carries one of:
[blocking](norm violation or factual error),[suggest](real improvement),[nit](taste/polish). - Cite the rule. When the suggestion is driven by URU norms, link the section (e.g.,
NORMAS §V. CITAS). For language, cite RAE if relevant. - Bibliography: suggest, don't fabricate. When flagging a weak source, propose a concrete replacement using
find-docs/WebSearch. If no credible alternative is found, mark as[suggest] needs stronger source — none found in search. - Spanish output. Feedback prose and rewrites are in Spanish. Tags, headers, and metadata stay English for grep-ability.
2. Inputs
User provides:
- Source path —
.docx(preferred) or already-converted.md/.txt. - Output base path — directory where
YYYY-MM-DD/session folder is created. - (Optional) Scope filter — e.g., "only Capítulo II", "skip bibliography", "focus on grammar only".
If the user only provides the .docx and no output path, ask before proceeding.
3. Ingestion (.docx → reviewable text)
Claude cannot Read .docx directly. Pick the first available path:
- Anthropic official
docxskill (preferred). Preserves structure (headings, lists, tables, footnotes, comments). Check the available-skills list at session start. - Pandoc fallback —
pandoc "<source>.docx" -t markdown -o "<source>.review.md". - Manual. Ask the user to paste content or "Save as .txt" from Word.
The intermediate .review.md (from pandoc) is scratch — don't commit it, don't put it in the session folder.
After ingestion, identify section boundaries by matching headings against URU's expected structure (§6.1).
4. Output structure
Sessions live under <output-base>/YYYY-MM-DD/ with one numbered file per thesis section (01-INDEX.md, 02-RESUMEN.md, …, 11-REFERENCIAS.md, 12-ANEXOS.md). Full folder layout and naming rules in TEMPLATES § 5.
5. File templates
Three templates drive the output:
01-INDEX.md— executive summary, severity counts, file map, cross-cutting themes. Template in TEMPLATES § 1.NN-SECTION.md— per-section diffs grouped by severity. Template + diff shape in TEMPLATES § 2.11-REFERENCIAS.md— bibliography-specific structure (missing/orphan sources, weak-source replacements, format fixes). Template in TEMPLATES § 3.
For substantive issues, the + side is a prompt for the author, not rewritten text — see TEMPLATES § 4.
6. Review dimensions (what to check, in order)
For each section, walk these dimensions in order. Stop reading prose once a [blocking] structural issue makes downstream feedback premature (note it in INDEX and move on).
Dimensions split into two groups:
- Substantive (§6.1–6.2 below): does the research itself hold up? This is the headline value of the review.
- Formal & linguistic (CHECKS.md): URU norms, prose quality, citation hygiene. Six checklists — formal aspects, redacción, grammar, semantics, citations, bibliography.
6.1 Structural compliance (URU §II)
- Are all required preliminary sections present? (portada, frontispicio, índices, resumen, abstract)
- Are chapters in URU order? (I. Problema → II. Marco Teórico → III. Marco Metodológico → IV. Resultados → V. Propuesta opt.)
- Does each chapter have the expected sub-sections per URU template?
- Are conclusiones organized by objetivos específicos?
6.2 Substantive content (proposals, information, argument)
Evaluate the thesis on its own merits as a piece of research, independent of URU formatting. Read each chapter as a domain reviewer would.
Cap. I — El Problema
- Problem clearly defined and bounded? Can the reader state it back in one sentence?
- Justification specific and evidence-backed, or generic ("este tema es muy importante")?
- Objetivo general: singular, measurable, achievable within the thesis scope?
- Objetivos específicos: decompose the general into independently-verifiable steps? Actionable verbs (
analizar,diseñar,evaluar), not vague (estudiar,conocer)? - Delimitación: clear scope boundaries.
Cap. II — Marco Teórico
- Antecedentes: actually relevant to this thesis's problem, or padding? Each should connect explicitly.
- Bases teóricas: depth matches the thesis's needs (not textbook summary, not off-topic monograph).
- Currency: dominant sources reasonably recent (varies by field — flag pre-2010 in fast-moving areas).
- Coverage gaps: obvious schools, key authors, recent developments missing?
- Operational definitions: key terms defined precisely and consistently.
Cap. III — Marco Metodológico
- Tipo y nivel: chosen design (descriptiva / explicativa / correlacional) appropriate for the objectives? Mismatches are
[blocking]. - Diseño: experimental / no-experimental / documental — justified or just declared?
- Población y muestra: defined, sampling method explained, size justified (statistically or by saturation).
- Instrumentos: validated? Reliability reported? If self-built, validation process described?
- Procedimiento: replicable from the description alone.
Cap. IV — Resultados
- Do results actually address each objetivo específico? Cross-check explicitly.
- Claims proportional to the evidence? Flag overreach ("se demuestra que…" when data only suggests).
- Tables/figures show what the text claims? Internal contradictions are
[blocking]. - Statistical / analytical method appropriate for the data type.
- Discussion: results contextualized against the marco teórico.
Cap. V — Propuesta (if present)
- Derived from the results, not pre-decided.
- Feasibility addressed (resources, time, constraints).
- Validation plan: how would adoption be measured?
Conclusiones
- One conclusion per objetivo específico (URU expects this alignment).
- Each conclusion supported by results — no new claims introduced.
- No overreach beyond the studied population/scope.
Recomendaciones
- Actionable, not platitudes ("se recomienda seguir investigando").
- Addressed to identifiable audiences.
Cross-chapter coherence (highest-value check)
- The chain
problema → objetivos → marco → metodología → resultados → conclusionesmust be intact. - Verify: every objetivo específico has