Personal knowledge base
Notes
Structured notes with condensed revision views, quizzes, and study prompts.
AI · study policy
Use AI to think better, not less
AI is most useful here as a tutor, critic and study partner. It should make difficult ideas easier to enter without removing the technical detail needed to understand them properly.
Based on current guidance fromOpenAI,Anthropicand the Agent Skills specification.
Use AI to create effort in the right places, not to remove effort altogether.
Good uses
- Ask for a simpler route into a difficult idea, then return to the formal version.
- Ask it to question you, compare two concepts, generate examples or diagnose a mistake.
- Use retrieval practice — recalling an idea without looking at the answer — instead of repeatedly rereading it.
Avoid passive fluency
Fluency is the feeling that something is familiar and easy to read. That feeling is not the same as being able to explain or apply it. After an AI explanation, close it and reproduce the idea in your own words, solve a fresh problem, or state when the method would fail.
Clear writing and technical accuracy should reinforce each other.
Ask for the correct technical term whenever it names an important concept precisely. On its first use, the response should immediately define that term in plain language. For example: asymptotic complexitydescribes how an algorithm's resource use grows as its input becomes larger.
A good explanation should
- lead with the central idea before adding qualifications;
- define every new technical term at first use;
- connect notation to what it represents in words;
- use a concrete example, then state where that example stops being representative;
- separate facts, assumptions and inferences.
Ask the AI to preserve necessary complexity. “Make this understandable” should mean improve the route through the material, not silently remove edge cases or turn a precise claim into a vague analogy.
An AI can produce a clear, confident answer that is still wrong.
A hallucination is content generated without reliable support — in plain terms, the model has invented or distorted a fact, quotation, source or step. Confidence, detail and polished wording do not make a claim verified.
Match checking to risk
- For revision, compare key definitions and results with lecture notes or a trusted textbook.
- For code, run it and test boundary conditions — inputs at the edges of what the code must handle.
- For current or consequential claims, ask for primary sources and open those sources yourself.
- When a claim cannot be checked, label the uncertainty instead of presenting it as settled.
Use AI within the rules of the work and with respect for other people's information.
- Do not paste passwords, private messages, personal data, unpublished work or confidential material into a model.
- Follow the stated rules for coursework, exams and collaboration. If AI assistance must be declared, record what you used and how.
- Keep authorship honest: understand, check and take responsibility for anything you submit under your name.
- Watch for automation bias — the tendency to trust a computer-generated answer because it appears systematic or neutral.
If the acceptable use of AI is unclear, ask the relevant lecturer or supervisor before using it on assessed work. A productivity gain is not worth making the status of your work ambiguous.
There is no universal magic phrase. A dependable prompt supplies the smallest set of details that can materially change the answer, then improves the result through follow-up messages.
Goal [State the result you want, not every step the AI should take.] Context [Give the relevant background, source material, audience and what you have already tried. Omit unrelated detail.] Output [Specify the useful format, length and level of technical detail. Ask for correct technical terms, with a clear plain-language definition when each new term first appears.] Boundaries [State the one or two constraints that would make a wrong answer unusable. Say what must remain unchanged, what sources to use, and what requires your approval.] Final check [Ask it to verify the important requirements, flag uncertainty and identify anything it could not check.]
Use this when a definition is technically correct but has not yet become intuitive.
Explain [concept] clearly without removing the technical detail. Start with the central idea in plain language, then give the formal definition. Define every new technical term immediately in clear words. Connect each symbol or piece of notation to what it represents. Give one concrete worked example and one edge case where the simple intuition needs qualification. Finish by asking me to explain the concept back to you so you can identify any gap in my understanding. My current level: [level] What I already understand: [context]
Use this when the answer depends on current facts or when you need to inspect the evidence yourself.
Research [question or decision] using current, credible sources. Scope - The decision I need to make: [decision] - Relevant location or date range: [scope] - Important constraints: [budget, eligibility, time, risk] Prefer primary sources: original documentation, official statistics, laws, standards or research papers. Use secondary sources only when they add useful analysis. Link each important factual claim to the source that directly supports it. Separate verified facts, reasonable inferences and unresolved uncertainty. If reputable sources disagree, explain the disagreement rather than averaging it away. Define every new technical term in plain language when it first appears. Output 1. concise answer; 2. evidence and trade-offs; 3. recommendation with assumptions; 4. what I should verify before acting. Before finishing, check that every citation supports the nearby claim and that no current claim relies only on memory.
A skill is a reusable workflow packaged as instructions, references and optional scripts.
Codex initially sees only each skill's name and description. It loads the complete SKILL.md file when the task matches. This is called progressive disclosure: revealing detailed information only when it is needed, so unrelated instructions do not crowd the working context.
Skills are best for repeatable methods such as producing a verified PDF, analysing a notebook or following a team's review process. A plugin is the distributable package to prefer when a workflow also needs connectors, tools or several skills.
These are useful starting points currently returned by Codex's official installer. The linked source catalogue is now labelled legacy, so prefer installing by name and use the links to inspect the exact files, scripts and licence rather than as the source of future product guidance.
$skill-installer jupyter-notebook $skill-installer pdf $skill-installer transcribe $skill-installer define-goal
Use the built-in installer for the simplest and safest setup.
From the official catalogue
$skill-installer jupyter-notebook
From a GitHub folder
$skill-installer install https://github.com/OWNER/REPOSITORY/tree/main/path/to/skill
Manual project or personal setup
Copy the complete skill folder—not just its Markdown file—to.agents/skills/skill-name/ for one repository, or$HOME/.agents/skills/skill-name/ for all repositories. The folder must containSKILL.md. Codex normally detects changes automatically; restart it if the skill does not appear.
Claude and Codex both support the open Agent Skills directory format: a folder containing aSKILL.md file and optional scripts, references and assets. That makes many instruction-only skills portable—usable by another compatible agent without rewriting the basic structure.
Compatibility is not guaranteed. A skill may name Claude-only tools, permissions, model names or directory conventions. Read it first and adapt those dependencies rather than assuming the shared file format makes all behavior interchangeable.
$skill-installer install https://github.com/anthropics/skills/tree/main/skills/skill-creator
Package a workflow only after you can describe when it should run and what a good result looks like.
- Keep the skill focused on one job.
- Write a precise description covering when it should and should not trigger.
- Use imperative steps with explicit inputs, outputs and verification.
- Prefer instructions; add scripts only when deterministic behavior or external tooling is genuinely needed.
- Test prompts that should trigger the skill and nearby prompts that should not.
$skill-creator Create a repository skill for [workflow]. It should trigger when [situations] and should not trigger when [boundaries]. The required inputs are [inputs]. A successful output is [definition of done]. Include [verification], and keep it instruction-only unless a script is necessary for deterministic behavior.
This creates a Socratic dialogue: learning through guided questions rather than receiving the complete answer immediately.
Tutor me on [topic] using one question at a time. Begin by checking the prerequisite ideas I need. Then move from recall to explanation and finally to application. Wait for my answer before continuing. When I am wrong, identify the exact misconception and give the smallest useful hint first. Do not reveal the full answer unless I ask or remain stuck. Use correct technical language, but define each new technical term in plain language when you introduce it. At the end, summarise what I understand well and what I should practise next.
Use questions that test transfer — applying knowledge in a different situation — rather than recognition alone.
Test my understanding of [topic]. Ask [number] questions, one at a time. Mix: 1. precise definitions and recall; 2. explanation of why a result holds; 3. application to an unfamiliar example; 4. edge cases and failure conditions; 5. comparison with a closely related concept. Do not make the answer obvious from the wording. After each response, mark it strictly, explain the specific gap clearly, and use the correct technical terminology with a plain-language definition for every new term. Keep a short list of weaknesses and revisit them in the final question.
Useful feedback is diagnostic: it identifies the cause of a weakness, not merely its location.
Critique my answer to the question below. First state the approach my answer takes. Then separate your feedback into: - correct claims; - incorrect or misleading claims; - missing reasoning or assumptions; - unclear technical language; - the single highest-value improvement. Quote only the short phrase you are discussing. Explain each problem in clear language while retaining the correct technical term, defining any new term you introduce. Do not rewrite the whole answer. Ask me to repair it, then assess my revision. Question: [paste question] My answer: [paste answer]
A useful plan allocates most of the time to producing answers, solving problems and checking gaps.
Design a [duration]-minute study session for [topic]. My goal is: [goal] My current confidence is: [low / medium / high] My available material is: [notes, problems, past papers] Use active recall (trying to retrieve knowledge without looking) and deliberate practice (focused work on a specific weakness). Give the session a realistic minute-by-minute structure with a clear output for each block. Include a short diagnostic at the start, progressively harder practice, time to correct mistakes, and a final test I can do without notes. Explain any new technical study term in plain language. End with a simple rule for deciding what to study next.