# A literature review — papers read, compared and synthesised into a chapter Recipe No. 39, Research and civic life. From The know.sh Cookbook: https://know.sh/cookbook/literature-review - For: a second-year PhD student in public health with a review chapter due before the upgrade panel - You bring: a reference manager with a hundred-odd papers in it, a folder of PDFs you have half read, a research question your supervisor has signed off, and the AI assistant you already use - You get: a review shelf with a document per theme, a finding per paper checked against the paper and put in your own words, comparison tables across the papers, and overviews that become the spine of the chapter - Time: an evening for your assistant to build the shelf, then twenty minutes per paper as you read and correct - Keep it: private; never on a public link By the second year of a public health PhD the reading has outrun the notes. There are ninety papers in the reference manager, forty of them marked "read", and when your supervisor asks which cohort studies measured green space by satellite and which by distance to a park, you open six PDFs to answer. This recipe gives the reading a shape a chapter can grow from. Each theme of the review is a research document. Each paper is a numbered finding filed as *Evidence*, with its DOI as a source and four short parts: methods, sample, findings, limitations. Whichever assistant you use — Claude, ChatGPT or a local model — builds the shelf, drafts a finding from each paper you give it, looks for papers you have missed and lines the findings up in comparison tables. You read every paper and correct every finding in the editor. The overview of each theme is your synthesis, in your words, and it is the draft of that section of the chapter. The PDFs stay in your reference manager, which also formats the bibliography. know.sh holds what you made of them. ## What you will use - **Shelf**: One shelf for the review, *Green space and adolescent mental health*, with your research question as its line. - **Research document**: One document per theme of the review: exposure measures, pathways, outcomes, equity. The overview is your synthesis of the theme. - **Finding**: One finding per paper, filed as *Evidence* with the DOI as its source; papers central to your argument marked **Key**; gaps filed as *Question*. - **Your AI assistant**: Builds the shelf, drafts a finding from each paper you give it, searches the web for papers you have missed, and builds comparison tables that cite finding numbers. - **The editor**: Where you check each drafted finding against the paper, rewrite it in your words, add your own limitations and mark the papers that matter. - **The A–Z index**: Gathers the acronyms and names that recur in finding titles and first lines: *NDVI*, *SDQ*, *Millennium*. - **Revisions**: Keeps each version of a theme overview, and shows which lines the assistant drafted and which you rewrote. - **Quiz**: Before the upgrade panel, a quiz on each theme checks that you can say which study found what. ## Method ### 1. Have your assistant set up the shelf and the themes Connect your assistant to know.sh once, following the support page for Claude, ChatGPT or a local model. Then tell it your research question and the themes you expect: "Using know.sh, make a shelf called *Green space and adolescent mental health*, with this question as its line, and four documents on it: *Measuring green space exposure*, *Pathways: activity, stress, social contact*, *Outcomes and instruments*, *Equity and deprivation*. Give each a one-sentence overview." Leave those overviews short. You will write the real ones last, once the papers are in. ### 2. Give it the papers, a theme at a time In Claude or ChatGPT, attach the PDFs for one theme, ten or so at a time, or paste their abstracts and DOIs from your reference manager. Ask for one *Evidence* finding per paper in that theme's document, titled first author, year and what it is — "Okafor 2023: cohort, NDVI within 500 m and SDQ scores" — with the DOI as its source and four parts under bold labels: **Methods**, **Sample**, **Findings**, **Limitations**. Tell it to take numbers only from the paper, to mark anything it could not find as missing rather than guess, and to leave a last line, *My reading*, empty. Forty papers become forty findings in an evening. Each one is a draft. ### 3. Read each paper and fix its finding in the editor Now do the reading. With the paper open, press **Edit** on its finding and check every number, the design and the sample against the source. Rewrite the parts in your own words, add the limitations you noticed that the authors did not admit, and fill in *My reading*: what this paper means for your question. Change a finding's type where it is really a *Question*, drag the findings into the order you will discuss them, and delete any the assistant filed in the wrong theme. If a phrase is worth quoting, put it in quotation marks with the page number. Revisions show which lines are still the assistant's. ### 4. Ask your assistant for papers you have missed Once a theme has a dozen papers, ask your assistant to research a narrow question on the web and file what it finds as a new document on the shelf, one finding per paper with its source links: "Longitudinal studies since 2015 of residential green space and adolescent depressive symptoms, outside the UK and US." This needs an assistant with web search; Claude and ChatGPT have it, and many local set-ups do not. Treat every entry as a lead. Open each one, check that the paper exists, that the authors, year and journal are right, and that it says what the summary claims. Language models invent plausible references, and a citation you have not opened does not go in the chapter. ### 5. Build the comparison tables Ask your assistant to read every finding in a theme and lay them side by side: author and year, design, sample size, country, exposure measure, outcome measure, direction of the association, and main limitation. Ask for the table as a new *Insight* finding at the end of the theme, each row naming the finding number it came from. Check the rows against your corrected findings; if a cell is wrong, fix it in the editor. The table is a working tool for you, not a figure for the chapter. ### 6. Mark what matters and what is missing Read each theme through. Mark the three or four papers your argument leans on as **Key**, and highlight the lines you expect to cite, so their numbers show bold in the index. Where the table shows a gap — no studies in rural areas, no measures of actual time spent outdoors — add a *Question* finding that says so. Those gaps are what a review chapter is for. Open the index. *NDVI*, *SDQ* and the cohorts you rely on should appear with the findings that use them. If an instrument is missing, it is only in the body; add it to the finding's title or first line. ### 7. Write each overview yourself Now write the overview of each theme in the editor: what the studies agree on, where they disagree and why, how strong the evidence is, and what remains unknown. This is the synthesis, and it is yours. Write it with the tables open beside you, not with an assistant drafting it. Afterwards, ask your assistant to check it against the findings, a claim at a time; it can leave proposed notes, with **Accept** and **Dismiss**, and never touches your text. Revisions keep each version of the overview, so when your supervisor asks why the evidence on pathways now looks weaker than it did in March, the March version is there to compare. ### 8. Test yourself before the panel A week before the upgrade panel, ask your assistant for a quiz on each theme. It writes five to ten questions with know.sh's quiz tools — which studies used distance to a park, which found no association in boys — each citing the finding it came from, and you take the quiz in know.sh or the iOS app (in TestFlight beta). The quiz comes back under *Revisit* in three, seven or twenty-one days depending on your score, which is about the rhythm of supervision meetings. ## Prompts to try Your assistant, connected to know.sh (Claude, ChatGPT or a local model): > I am attaching the PDFs of ten papers for my literature review. Using know.sh, add one Evidence finding per paper to the document “Measuring green space exposure” on my shelf “Green space and adolescent mental health”. Title each “First author year: design, exposure and outcome”. Put the DOI in its sources, and write four parts under bold labels: Methods, Sample, Findings, Limitations. Take every number from the paper; write “not reported” rather than guess. End each with an empty line headed “My reading”. Your assistant, connected to know.sh (Claude, ChatGPT or a local model): > Search the web for longitudinal studies published since 2015 on residential green space and depressive or anxiety symptoms in adolescents aged 11 to 18. Using know.sh, file them as a new document called “Candidate papers” on my shelf “Green space and adolescent mental health”, one finding per paper, with the authors, year, journal, DOI, design, sample size and country, and the DOI link as its source. Include only papers you actually opened, and say so if a DOI did not resolve. Your assistant, connected to know.sh (Claude, ChatGPT or a local model): > Using know.sh, read the overview of the document “Outcomes and instruments” on my shelf “Green space and adolescent mental health” and check each claim in it against the document’s findings. Say which findings support each sentence, which contradict it, and which claims no finding supports. Leave your answers as proposed notes on the overview; do not edit my text. ## Variations - Writing the whole dissertation, not only the review? The [thesis research base](/cookbook/thesis-research) keeps a document per chapter, with the argument in its overview. - For a systematic review with a registered protocol, keep screening and extraction in the tools your protocol names, and use this shelf for the narrative that follows: one finding per included study, the tables for your discussion section. - Run a journal club: one document per session, one finding per paper discussed, and a quiz from your assistant before the next meeting. - Keep a standing *Reading since the review* document for papers published after you submit, so the viva does not surprise you. ## Where it falls short - know.sh does not hold PDFs or format references. Keep papers and the bibliography in Zotero, EndNote or whatever your department uses; you give PDFs to your assistant, not to know.sh. - Web research needs an assistant with web search, and it reads only what the open web shows it. Paywalled journals and databases such as Scopus and Web of Science are out of its reach; the systematic search is yours to run. - Smaller local models call tools less reliably and misread tables in PDFs more often. Check what they file; Revisions shows every change they made. - The comparison tables are plain tables in a finding. There are no charts, forest plots or maths, and nothing recalculates if you change a finding. ## A note on academic integrity and citations A review chapter is assessed as your own reading and judgement. Your assistant may draft a structured summary of each paper, find leads and build tables; you read every paper, correct every finding and write the synthesis. Do not have it write the chapter or the theme overviews. Check your university's and your department's policy on generative AI before you start, and disclose AI use in the thesis where the policy asks; many now want the tool, the version and the purpose. Assistants make mistakes, and they can invent references that look real. Open every paper they point you to, confirm the DOI resolves to it, and read enough to know it says what the summary claims. A summary in your library is a note to yourself, not a source you can cite. Check, too, whether your library's licences allow giving subscribed papers to an AI tool; some publishers and universities restrict it. Indexed under: Literature review, Synthesis, DOIs, Comparison tables, Academic integrity, Evidence findings, Public health.