critique-thesis
Skill0 starsChanged 11 days agoMITView on GitHub
Critique a student thesis or proposal before its exam, or its revision after one — every finding with its page and recomputed evidence, delivered as a Word file. Use when handed a thesis or research report to critique (วิพากษ์ปริญญานิพนธ์, ตรวจเล่ม).
In this repository18 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- adopt-poolSkill
- analyze-resultsSkill
- assessment-layoutSkill
- audit-brainSkill
- brain-anatomySkill
- critique-mcqSkill
- design-courseSkill
- digestSkill
- grill-pointSkill
- init-brainSkill
- item-defectsSkill
- learning-outcomesSkill
- make-examSkill
- make-practicalSkill
- new-subjectSkill
- thai-office-filesSkill
- update-portfolioSkill
The file
Files
critique-thesis — critique a student thesis
This skill is an ordered checklist: each step opens when the one before it has produced its result. Its findings rest on numbers recomputed from the book and sources looked up outside it, never on an impression of the text. The checks and the report's shape are in THESIS-CHECKS.md — read it before step 4. It writes the critique and its evidence table: the thesis is never filed into the vault, and its text is not kept after the run, because it carries students' names and IDs.
Whenever a step puts more than one decision to the user, it asks them in the round shape the grill-point skill gives in its step 3.
The critique's text lives in a Markdown file beside the Word file, and the Word file is rendered from it: a later change is made in the Markdown and rendered again, rather than in a script that carries the critique's text and is lost with the session. A script this run writes to recompute or look something up is saved beside the host's renderer, so the next run finds it.
Steps
- Discover the project's conventions — read the host project's agent instructions file (
AGENTS.md, orCLAUDE.md) and inspect what it names for thesis critiques: where a critique is written (often outside the vault, since it is about named students), how the file is named, the renderer that turns the Markdown into the institution's Word layout and an example critique in that layout, the thesis regulations or interpretation criteria the institution sets, and the language critiques are written in. Where the project names none of these, ask; a critique saved into the vault beside its notes is personal data in the vault. Then show the user the plan for this run — its steps by number with a 🛑 on each one that stops for the user, then one line of what this step found and one of what it could not find, labelled in the user's language — and wait for the user's go-ahead, or take the dispatch as the go-ahead when this run was sent to work without the user, as a sub-agent; name each later step by its number as it starts. - Locate the thesis and decide which run this is — the thesis file, usually in staging, and whether an earlier critique of the same thesis exists. Look for one by title and topic in the critiques folder, not only by what the user calls it: a resubmission can arrive described as another group. Where one exists this is a revision run: find the earlier critique as it was sent (a copy the students returned may be a re-save; compare the two), its Markdown if it has one, and the version it critiqued if the user has it. A full thesis whose earlier critique was of its proposal is a revision run against that critique. Then decide whether the book is a proposal run: a research proposal — the chapters up to the methods, with no results chapter — rather than the finished book, read from its title page and table of contents, not from what the user calls it. A proposal run is the same checklist on a book that has no results yet.
- Extract the text, page by page — read the thesis as text, with a marker for each page so every finding can cite one; on a revision run, extract the earlier critique's text too. A Thai extraction that comes out as digits and Latin letters only is the extractor's encoding, not a missing text layer: use one that writes UTF-8 before concluding the text is absent, and copy a file with a Thai name to an ASCII one where the tool cannot open it. A page with no text layer — a scanned certificate, a signed approval — is listed for the user to look at, not read as an image, since an image read misreads names and numbers. The extracted text and the ASCII copy go in the session's scratch space, and step 9 deletes them.
- Run every check — work through every group of THESIS-CHECKS.md against the whole book, writing the evidence table to its file beside where the critique will be saved as you go: one row per check per place it applies, including the checks that found nothing and the ones that cannot apply here, each with why. Recompute rather than estimate; look sources up rather than recall them. On a proposal run, record the checks that need results as THESIS-CHECKS.md gives under A proposal. On a revision run, build the status tables of the earlier findings first, then run every check on the whole revised book, since a revision breaks things outside what it changed.
- Triage the findings — sort them into the report's sections by severity, merge findings one change resolves, and drop any finding without its page — or, for an absence, the page range searched — and its evidence. Name people by role, never by name or ID.
- Summarise in the chat and wait — the overall verdict, then a table with one row per finding: its section, page, the evidence in a phrase, and the proposed change; then the checks that could not run, with what stopped them. The user can judge each row on its face, so they answer row by row or for the whole table, and a question that is about no single finding follows the table as a round. They sit on the committee or advise the group and decide what goes to the students; a finding they reject here costs a row rather than a rebuild. Apply their answers before going on.
- Write the critique — in Markdown, in the order THESIS-CHECKS.md gives under Reporting and in the layout of the project's example critique, saved where step 1 found and named as the project names critiques; a revision run's name says it is the revised version's critique, and a proposal run's that it is the proposal's.
- Render the Word file — with the project's renderer, from the Markdown. Where the project has none, build the file under the
thai-office-filesskill's rules. Either way the file is finished only when the rendered check in thethai-office-filesskill has passed. - Verify — run the project's check script where one exists, then confirm: every finding in the critique cites its page or searched range and carries its evidence, and every finding outside formatting and typing has its row in the table of what to change; the evidence table holds a row for every check in every group, including the empty ones; on a revision run, every earlier finding has a status; the critique, the Word file, and the evidence table name no student, advisor, or committee member, and carry no ID or phone number; the Word file was rendered from the Markdown beside it; the rendered check's evidence table exists; nothing from the thesis was written into the vault; and the extracted text and the thesis copy in the scratch space have been deleted.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

