academic-writing
Write or revise thesis and paper prose section by section (abstract, introduction, related work, method, results, discussion, conclusion) with the conventions…
Choose and justify a research design for each research question: controlled experiment, quasi-experiment, case study, survey, interview study, design science, action research, or mixed methods, with the data collection, sampling, analysis, ethics, and validity threats each
$ npx -y skills add KhaledSaeed18/dotclaude --skill research-methodology --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
/research-methodologyContext preview
The summary Claude sees to decide when to auto-load this skill.
Choose and justify a research design for each research question: controlled experiment, quasi-experiment, case study, survey, interview study, design science, action research, or mixed methods, with the data collection, sampling, analysis, ethics, and validity threats each
name: research-methodology description: "Choose and justify a research design for each research question: controlled experiment, quasi-experiment, case study, survey, interview study, design science, action research, or mixed methods, with the data collection, sampling, analysis, ethics, and validity threats each entails, and write the method chapter's design section from the choice. Use when moving from research questions to a study plan, when a supervisor asks how the question will be answered, or when reviewers say the method cannot support the claims." argument-hint: "(optional) the research question record or the questions to design for"
The method exists to answer the question; it is chosen after the question and before the data. A method chosen for familiarity or convenience produces a thesis whose conclusions the examiner cannot accept. This skill matches each research question to a design and writes down why.
| Question asks | Design | Evidence produced | | --- | --- | --- | | Does X cause Y? / Is A better than B? | controlled experiment (randomised, with baselines) | effect size with confidence, under controlled conditions | | Does X cause Y in a real setting where randomisation is impossible? | quasi-experiment (pre/post, difference-in-differences, matched groups) | effect estimate with stated confounds | | How and why does X happen in context? | case study (single or multiple, embedded) | rich description, mechanisms, propositions | | How prevalent is X? What do people think or do? | survey (questionnaire) | distributions, correlations, at scale | | What is the lived experience or reasoning behind X? | interview study, focus groups, observation | themes, categories (thematic analysis, grounded theory) | | How can we build an artifact that solves X, and does it? | design science (build and evaluate) | artifact plus evaluation against requirements | | How can we improve practice X while studying it? | action research | cycles of change and reflection | | What does the literature say about X? | systematic review or mapping study | synthesis with explicit protocol (`systematic-review`) | | Does the finding hold across settings? | replication | confirmation or boundary conditions |
Most master's theses in computing combine two: a design-science build with an experimental evaluation, or a survey followed by interviews (explanatory sequential mixed methods). Name the combination and the order.
**Participants, subjects, or objects**: population, sampling (random, stratified, convenience with its limitation stated, purposive for interviews), sample size with the reason (power analysis for experiments via `statistics-advisor`; saturation for interviews; the whole population for a census of repositories).
**Variables**: independent (manipulated), dependent (measured), controlled, and the confounds you cannot control. Operationalise each: "usability" becomes SUS score and task completion time.
**Procedure**: step by step, with timing, instruments (questionnaires, tasks, scripts), and the exact conditions. A reader should be able to run it.
**Instruments**: validated where they exist (SUS, NASA-TLX, TAM); if you write your own, pilot it and say so.
**Data**: what is collected, in what format, where stored, retention, anonymisation.
**Analysis plan**, decided before data collection: the statistical tests (`statistics-advisor`) or the qualitative coding approach, the significance level, the effect size measure, how missing data is handled. Pre-register it in the proposal; deviations are reported as such.
**Ethics**: informed consent, approval body and reference, data protection, the right to withdraw. Studies of open-source repositories still raise questions (developer names in data).
**Validity threats**, using the standard four and what you did about each:
For qualitative work use credibility, transferability, dependability, confirmability, and the tactics (triangulation, member checking, audit trail).
A design section for the method chapter, per research question:
### RQ2: Does feedback style affect fix time? Design: between-subjects controlled experiment, two conditions (rule-based, LLM-based), random assignment. Participants: 40 second-year students (power analysis: d = 0.8, alpha 0.05, power 0.8 gives 26 per group; 40 allows attrition), recruited via course announcement (convenience; see External validity). Variables: IV feedback style; DV time to correct fix (seconds, from logs), secondary DV SUS; controlled: assignment, IDE, time limit. Procedure: consent; 5-minute tutorial; three tasks in fixed order; SUS; debrief. 45 minutes. Analysis: Welch's t-test on log-transformed time; Cohen's d; Mann-Whitney U as robustness check; alpha 0.05. Ethics: approved by <board>, ref <n>; data pseudonymised at collection. Threats: internal, task order fixed (mitigated by counterbalancing tasks 2 and 3); external, students; construct, fix time measures speed not learning.
Write it to the method chapter file or return it; then update `research/QUESTION.md` with the design per question so `thesis-proposal` and `thesis-reviewer` see the same plan.
Reusable Claude Code extension registry. skills, subagents, slash commands, and hooks for engineering, git, testing, and security workflows. Distributed as a shadcn GitHub registry and as installable plugins.
Write or revise thesis and paper prose section by section (abstract, introduction, related work, method, results, discussion, conclusion) with the conventions…
Report computational benchmarks and experimental comparisons the way examiners and reviewers expect: fair baselines run under the same conditions, multiple…
Maintain the thesis .bib file as a single source of truth: fetch verified BibTeX from a DOI, arXiv id, or title via CrossRef and arXiv, normalise citation keys…
Expand a set of key papers into the literature around them by walking the citation graph with the Semantic Scholar and OpenAlex APIs: backward (references),…
Audit every citation in a chapter, paper, or proposal against the .bib file and the real world: each cite key must exist, each entry must resolve to a live DOI…
Structure a thesis whose contribution is a built artifact (tool, system, method, model) using design science research: explicit problem and requirements,…