Imported from ScottSavaiano/project-mentor (skills/develop-research-question/SKILL.md). Install upstream with npx skills add ScottSavaiano/project-mentor --skill develop-research-question. Copyright stays with the author.

Develop Research Question

Name: develop-research-question
Author: ScottSavaiano

2026-07-06 educator voice-read applied (three-stream counts + canonical output titles). Last edited: 2026-07-06 (Cowork — three-stream / 25-stage architecture adoption (supersedes the same-day 17-stage two-stream redesign demoted to Prior below; source of truth: design/three-stream-architecture-2026-07-06.md + spec §4.2). This skill now owns cycle-template Stages 1–4. Stage 1 exploration is grounded in all three Project Reference streams (Topic-Related / Core-Methods / Extension-Methods). The old two-RQ pair becomes three research questions, one per stream, each a separate sequential stage folding develop+write + a per-output teacher approval + its own per-stream writing_handoff: Stage 2 develops the Topic research question (Topic-Related stream) and hands off its paragraph; Stage 3 develops the Core-Methods research question — whether and how well the chosen core method can answer the topic question, taking the topic question as its object (Core-Methods stream) — and hands off its paragraph; Stage 4 develops the Extension-Methods research question — whether and how well the chosen extension method can deepen or extend the topic question (Extension-Methods stream) — and hands off its paragraph. So the single combined writing_handoff becomes three per-stream handoffs (topic at Stage 2, core-methods at Stage 3, extension-methods at Stage 4) and three per-output teacher approvals, one per paragraph (spec §4.5). Still NOT a five-question rationale trigger — each RQ paragraph carries its own per-output approval, recorded as an approval/sign-off entry, not a five-question rationale; on the ordinary path the only decisions.md append remains the feasibility-doubt referral's standalone entry. Downstream re-pointed to the 25-stage table (memo §3): construct operationalization / dataset validation now Stage 5 (its failed-validity bounce returns to this skill's Stage 1 (exploration)); the three Literature Reviews & Syntheses now Stages 6–8 (topic 6, core-methods 7, extension-methods 8); the three gaps now Stages 9–11 (topic 9, core-methods 10, extension-methods 11; the gap decision's five-question rationale sits at Stage 11); detailed methodology now Stage 14; proposal + cycle seal now Stage 16. The blocked-on-upstream-reopening method-approach-contradiction edge case still targets the activation methods-setup rationale gate, but now names which method (core or extension) is implicated. "push" → "extension" throughout (educator, 2026-07-06 — the pairing is core + extension; the distinction is one of level, not reachability). The scaffold keys are now three — foundational.research_question_topic (Stage 2), foundational.research_question_core_methods (Stage 3), foundational.research_question_extension_methods (Stage 4); each handoff lays only its own paragraph's marker. The companion scaffold-section / section-scaffolds.yaml three-way split is a separate tracked follow-up (open item 4), NOT done here — those files still carry the earlier two-way split and must be re-split to these three keys. Moment 3 (the writing handoff) gains a third per-stream beat (extension-methods), marked "pending educator voice read (2026-07-06)"; Moments 1–2's blessed quotes still say "two" research questions and are FLAGGED for the educator's three-question re-read — no quote edit was made (see open item 3). The Stage 2–4 ↔ Stage-14 firewall was reframed for the three streams and flagged (open item 5). Per the three-stream architecture memo 2026-07-06 + spec §4.2 + decision-log 2026-07-06.) Prior — 2026-07-06 (Cowork — activation/methods-setup redesign adoption. Renumbered this skill's own work from cycle-template Stages 4–6 to Stages 1–3 (the old Stages 1–2 — method-approach choice and reference consolidation — were absorbed into the expanded activation sequence). The two research questions split into separate sequential stages, each folding develop+write into one stage: Stage 2 develops the Topic-related question (drawing the Topic-Related Project Reference stream) and hands off its paragraph; Stage 3 develops the Methods-related question (drawing the Methods-Related stream) and hands off its paragraph — so the single combined writing_handoff for a "research-questions section" becomes two per-stream handoffs. Per-output/per-stream teacher approval (revised same day 2026-07-06, superseding the intra-day folded-pair-rationale adoption): the educator ruling makes teacher approval per writing output, per stream, so develop-research-question is NOT a five-question rationale trigger — each research-question paragraph gets its own per-output teacher approval instead (the topic-RQ paragraph at Stage 2, the methods-RQ paragraph at Stage 3), submitted for the teacher's approval before the project advances (spec §4.5). This reverts the earlier same-day adoption of a Stage-3 folded five-question rationale for the RQ pair; on the ordinary path this skill produces no five-question rationale in decisions.md (the per-output approvals are recorded as approval/sign-off entries, not five-question rationales) — the only decisions.md append on the ordinary path returns to being the feasibility-doubt referral's standalone entry. The two questions are still developed as a pair across Stages 2–3 (a pair-level revision can still reopen the topic question), but the human touchpoint is now the per-output approval of each paragraph, not a folded pair rationale. The blocked-on-upstream-reopening method-approach edge case is retargeted from a cycle Stage 1 to the activation methods-setup rationale gate (method-approach is now chosen in activation, not a cycle stage); and the Stage-4 operationalization bounce returns to this skill's Stage 1 (exploration). The single "Project Reference Articles" set → the two streams (Topic-Related / Methods-Related; exploration uses both, each RQ its own stream). Downstream refs re-pointed: literature reviews now Stages 5–6 (two), gaps 7–8, detailed methodology 11, seal 13. Companion edit (done 2026-07-06): the foundational.research_questions scaffold was split into foundational.research_question_topic (Stage 2) and foundational.research_question_methods (Stage 3) in scaffold-section / section-scaffolds.yaml.research_questions scaffold into per-stream markers laid at their stages (topic at Stage 2, methods at Stage 3) — *not* done here. Per decision-log 2026-07-06 + architecture spec §4.2 + dispatch contract §4.2/§4.3.) Prior — 2026-07-01 (Cowork — **move-noun ban fix**: swapped a banned noun "move" for step/choice/act/lesson per the standing voice ban, now mechanically caught by voice_lint moves_noun; decision-log 2026-07-01.) Prior — 2026-06-10 (Cowork — **foundational-skill reconciliation to the handoff model** (per the identify-gap pattern-setter): Phase 3's inline working_paper.mdresearch-question-paragraph write replaced by the cross-trackwriting_handoff(contract §5.1/§4.4); the demonstration-discipline layer relocated to its consolidated home inscaffold-section(a pointer remains); §4.5/§4.6/§5.1 citations re-grounded (F5.2 — the skill no longer writesworking_paper.md); the mid-skill-revision staleness wiring re-grounded to the standard §5.2/§6.2 mechanism; open item 2 resolved (now that scaffold-sectionis authored); a thin transition closing Moment (Moment 3) added). Prior: 2026-06-06 (Cowork — numeric "Type N" reference-article labels retired per the educator nomenclature ruling of this date; practical names throughout: Research Problem / Method Exemplar / Project Reference / Paper Structure Articles). Prior: 2026-06-04 (Cowork — delta-review seams fixed per the conduct-literature-review critique Part B: sweep grammar residue (article agreement, header capitalization), retired term "synthetic literature review" → Literature Synthesis, convention header wording. Earlier: nomenclature ruling applied: Topic-related/Methods-related Research Question names with sanctioned short forms, RQ1/RQ2 retired from live prose (dated markers retain their original wording). Earlier same day: first draft; same-day educator-review revisions (feasibility/reachability framing, referral protocol); first teacher-admin critique pass applied (12 findings); then the educator's two-research-questions restructure: one two-component question → RQ1 (topic) + RQ2 (methodological, taking RQ1 as object), two paragraphs at stage 6, Moments 1–2 rewordings) *Editing convention: see00-handoff.md` → "Editing conventions" for editor identifiers and revision-marker rules. This skill also carries a Status section at the bottom recording the draft-vs-promoted lifecycle; the two coexist.*

What this skill is

develop-research-question is the first cycle-template stage-skill, owning cycle-template Stages 1–4 (architecture spec §4.2). It receives a student who has a fixed research problem, a chosen core + extension method pair (selected in the activation methods-setup, §4.1), and three consolidated Project Reference streams — the Problem-Related, the Core-Methods, and the Extension-Methods — and walks them from that grounding to the cycle's three research questions, each specific enough to study successfully and rigorously, with variables specified precisely enough to measure (the SOUL's bar, "What the work looks like"). The topic, core-methods, and extension-methods work run as separate, sequential stages — each folding "develop the question" and "hand its paragraph off for writing" into one stage. By the time this skill completes a full run, the student has:

An exploration of theories, variables, datasets, and methods mined from all three Project Reference streams, recorded in project_design.md (Stage 1).
The Problem-Related Research Question (short form in speech: the problem-related question; what the student wants to know about their subject, including when the subject is a method), developed Socratically against the bar above out of the Problem-Related stream, recorded in project_design.md under ## Research Questions (Cycle N), and its paragraph handed off for writing (Stage 2). Full names are used in headings, records, and first introductions; the short forms carry running speech (educator nomenclature ruling, 2026-06-04 — RQ1/RQ2 indexing retired).
The Core-Methods Research Question (short form in speech: the core-methods question; whether and how well the chosen core method can answer the problem-related question, taking the problem-related question as its object), developed Socratically out of the Core-Methods stream, recorded in the same block, and its paragraph handed off for writing (Stage 3).
The Extension-Methods Research Question (the extension-methods question; whether and how well the chosen extension method can deepen or extend the problem-related question), developed Socratically out of the Extension-Methods stream, recorded in the same block, and its paragraph handed off for writing (Stage 4).
Three research question paragraphs handed off for writing — one per stream, at its own stage, each submitted for per-output teacher approval. The problem-related RQ paragraph handoff fires at Stage 2, the core-methods-RQ paragraph handoff at Stage 3, the extension-methods-RQ paragraph handoff at Stage 4; each returns the writing_handoff outcome (contract §5.1) naming its paragraph. paper-walkthrough dispatches scaffold-section for the named paragraph and the student writes their own prose into it; once written, each paragraph is submitted for the teacher's per-output approval before the project advances (spec §4.5) — the problem-related paragraph's approval at Stage 2, the core-methods paragraph's at Stage 3, the extension-methods paragraph's at Stage 4. Foundational paper sections per architecture spec §5.1; the substance is this skill's, the writing is the paper-track's (contract §4.5). Scaffold wiring (companion edit NOT done here — a separate tracked follow-up, open item 4): the foundational.research_questions scaffold must be split three ways in section-scaffolds.yaml into foundational.research_question_topic (laid at Stage 2), foundational.research_question_core_methods (Stage 3), and foundational.research_question_extension_methods (Stage 4); each handoff lays only its own paragraph's marker. The current section-scaffolds.yaml still carries the earlier two-way split (topic / methods) and does not yet match these three keys — FLAGGED, not edited.

This skill is NOT a five-question rationale trigger — each research-question paragraph carries a per-output teacher approval instead (contract §4.2; spec §4.5). The human touchpoint here is the lighter, per-stream per-output teacher approval: after the student writes each RQ paragraph, the teacher approves that written output before the project advances — the problem-related RQ paragraph at Stage 2, the core-methods-RQ paragraph at Stage 3, the extension-methods-RQ paragraph at Stage 4, exactly the way a classroom assignment is submitted and graded. This is distinct from (and lighter than) the five-question consultation gate, which attaches to the major design decisions — the method-approach (activation), the detailed methodology (Stage 14), the proposal (Stage 16), the gap decision (identify-gap, Stage 11), and the new-cycle decision — none of which is this skill's. On the ordinary path this skill produces no five-question rationale in decisions.md; the per-output approvals are recorded as approval/sign-off entries, not five-question rationales.

In Cycles 2 and 3, the skill runs against the dispatch payload's prior_cycle_research_questions: the work is developing the revised research questions the new cycle's direction calls for — the core-methods and extension-methods questions are rebuilt against the new cycle's core and extension methods; the problem-related question is revised in light of the prior cycle's findings — written into the new cycle's own block. The prior cycle's questions and paragraphs are sealed and are never edited (cross-cycle supersession, architecture spec §9; contract §6.3).

When this skill fires

Dispatched by project-walkthrough when cycle_template_stage reaches 1 (entry), or on resumption when last_skill_dispatched = develop-research-question per contract §2.1. Skill-specific dispatch fields (contract §4.3): theories_variables_state (whether the Stage-1 exploration has begun — the resumption anchor) and prior_cycle_research_questions (Cycles 2–3 only).

This skill is NOT a five-question rationale trigger (contract §4.2: develop-research-question is no longer a trigger row). The research questions are not a five-question decision; instead each research-question paragraph gets its own per-output teacher approval — the problem-related RQ paragraph at Stage 2, the core-methods-RQ paragraph at Stage 3, the extension-methods-RQ paragraph at Stage 4 — submitted for the teacher's approval before the project advances (spec §4.5). The three questions are still developed as a set across Stages 2–4 (a set-level revision surfacing at Stage 3 or 4 can still reopen an earlier question — most often the problem-related question the two methods questions take as their object), but the human touchpoint is the per-output approval of each written paragraph, not a folded set rationale. On the ordinary path the skill produces no five-question rationale in decisions.md; the only decisions.md append on the ordinary path is the feasibility-doubt referral's short standalone entry (see the edge case), and the per-output approvals are recorded as approval/sign-off entries, not five-question rationales.

The skill's internal phases

Phase 1 — Theories, variables, datasets, methods exploration (Stage 1; teaching-forward). Per the SOUL's mode taxonomy, exploration is taught, not quizzed — asking Socratic questions about literatures the student has not yet been shown would be unhelpful. The mentor works through all three Project Reference streams (the Problem-Related, the Core-Methods, and the Extension-Methods) with the student along four threads, in whatever order the articles make natural:

1a. Theories — what explanatory frames the reference articles use; which the student finds credible for their research problem.
1b. Variables — what the articles measured and how they operationalized it; which constructs in the student's problem space have established measures and which would need inventing.
1c. Datasets — what data the articles used, and what the student's project could actually run on. Two categories, both first-class (per the 2026-06-04 decision-log entry "Feasibility includes collectible data"): data that exists — public datasets, archives, repositories the reference articles point at — and data the student can readily collect working with their research agent — scraped public-web corpora, API-gathered data, synthetic-participant runs, fielded surveys. IRB attaches only to data the student collects directly from human subjects — a survey, experiment, or interview they run. All public and secondary data is exempt (public datasets, archives, published data, scraped-public-web / API corpora need no IRB). Where IRB is required, it is a budget constraint, never a feasibility verdict — it carries the timeline price the SOUL's ethics section names, and the mentor surfaces that price here, before a question hardens around it. (The local articles/ copies and the articles' own data sections are the first mine; the research agent's data-collection support arrives at execution.)
1d. Methods — how the articles analyzed; how their methods relate to the student's chosen core and extension methods.

The exploration is calibrated, not exhaustive — its purpose is to give the student real material out of which a question can be built, and to surface feasibility facts (especially 1c) before a question hardens around data that does not exist. Findings are recorded in project_design.md under ## Cycle N — Exploration: Theories, Variables, Datasets, Methods. The stop-condition ties Phase 1's exit to Phase 2's entry bar: the exploration is sufficient when the student has enough theory, variable, dataset, and method material that questions specific enough to study successfully and rigorously — with variables specified precisely enough to measure — can be built and reachability-checked. It is a sufficiency test, not an exhaustiveness count.

Phase 2 — The Problem-related research question: development and its writing handoff (Stage 2; Socratic). The mode shifts back to asking — the question has to be the student's. Drawing on the Problem-Related Project Reference stream, the mentor opens with the topic-versus-question distinction (Moment 1 below) and builds the problem-related question from the student's instinct through the bar the SOUL sets — specific enough to study successfully and rigorously, variables specified precisely enough to measure. Two structural facts govern this stage:

The problem-related question must address the research problem — which is fixed for the life of the project (architecture spec §4.1). The problem-related question is the problem made answerable, not a new direction. The method-as-topic case resolves naturally — when something missing or unexplored about a method is the project's subject, the problem-related question is about that method-as-subject.
The problem-related question must be buildable on reachable data (per 1c). It must be answerable by this project, with data the student and research agent can reach. Tension here is handled honestly, not absorbed silently — see the edge cases.

The developed problem-related question is recorded in project_design.md under ## Research Questions (Cycle N) — stated in full, with one sentence connecting it to the research problem. Then, the question settled, the skill hands off its paragraph for writing: it returns the writing_handoff outcome (contract §5.1) naming the cycle's problem-related research-question paragraph; the dispatching walkthrough records a pending-scaffold marker (§10) and paper-walkthrough dispatches scaffold-section to lay that paragraph's scaffold (what the problem-related question is, how it follows from the research problem, what contribution answering it makes), customized against the student's Problem-Related stream, and the student writes their own prose into it. Once written, the problem-related RQ paragraph is submitted for the teacher's per-output approval before Stage 3 opens (spec §4.5) — the paper track's lighter, per-stream grading touchpoint. The stage closes with a thin transition Moment (Moment 3 below, the problem-stream instance).

Phase 3 — The Core-Methods research question: development and its writing handoff (Stage 3; Socratic). Drawing on the Core-Methods Project Reference stream, the mentor introduces the multi-question structure (Moment 2 below) and builds the core-methods question with the problem-related question as its object. Three structural facts govern this stage:

Three research questions, developed as a set across Stages 2–4 (architecture spec §4.2 as restructured by the 2026-06-04 educator ruling, split into per-stream stages by the 2026-07-06 activation redesign, and expanded to three streams by the 2026-07-06 three-stream architecture memo; decision-log entries of those dates — supersedes both the spec's original "topic, methodological, or both" and the same-day two-question framing). The Core-Methods Research Question asks whether, and how well, the chosen core method can answer the problem-related question. The core-methods question is built from the problem-related question; the questions never merge into one compound question. It is a genuine research question that the project's execution answers — not a reachability checkbox (reachability, 1c, is the data test; the core-methods question is methodological inquiry). It carries a real contribution even when the core method is well-established: applying an established instrument to an open question is itself something the field does not yet have. That nuance lives here in the harness — it is deliberately not lectured at the student in Moment 2, and it surfaces naturally at gap identification (Stage 10), where the core-methods question anchors the core-methods gap. The set maps cleanly downstream, stream by stream: the problem-related question ↔ the Problem-Related Literature Review & Synthesis (Stage 6) and the Problem-related gap (Stage 9); the core-methods question ↔ the Core-Methods Literature Review & Synthesis (Stage 7) and the Core-Methods gap (Stage 10); the extension-methods question ↔ the Extension-Methods Literature Review & Synthesis (Stage 8) and the Extension-Methods gap (Stage 11). One firewall, reframed for the three streams and flagged (open item 5): the three research questions are Stage 2–4 properties of what is being asked — the problem-related question asks about the subject, the core- and extension-methods questions ask whether each chosen method can serve — while the core + extension two-part design is a Stage-14 property of how the study is built. The core- and extension-methods questions do align with the core and extension halves of the design by stream, but the question (what is asked, now) is not the design (how it is built, at Stage 14); the mentor holds the what-vs-how line and never lets a question be mistaken for its execution design.
The set must be buildable on reachable data (per 1c). The core-methods question asks whether the core method can answer the problem-related question; every question must be answerable by this project, with data the student and research agent can reach. If the core-methods question's development genuinely strains the core method, that is handled honestly — see the edge cases.
The three questions are developed as a set, but each paragraph carries its own approval. Stage 3 is not a folded five-question sign-off (this skill is not a rationale trigger); the human touchpoint is the per-output teacher approval of each written paragraph (spec §4.5) — the problem-related paragraph approved at Stage 2, the core-methods paragraph at Stage 3, the extension-methods paragraph at Stage 4. Because the questions are developed as a set, an earlier question (the problem-related question at Stage 2) can still be reopened by a set-level revision surfacing at Stage 3 or 4 (the mid-skill-revision path in the edge cases), which would send its already-approved paragraph back through the paper track for a fresh write and approval.

The core-methods question is recorded in the same ## Research Questions (Cycle N) block — stated in full, with one sentence stating how it takes the problem-related question as its object. Then, the question settled, the skill hands off its paragraph for writing: it returns the writing_handoff outcome (contract §5.1) naming the cycle's core-methods research-question paragraph; the dispatching walkthrough records a pending-scaffold marker (§10) and paper-walkthrough dispatches scaffold-section to lay that paragraph's scaffold (what is being asked of the chosen core method, how it pairs with the problem-related question, what answering it contributes methodologically), customized against the student's Core-Methods stream, and the student writes their own prose into it. Once written, the core-methods-RQ paragraph is submitted for the teacher's per-output approval before Stage 4 opens (spec §4.5). The stage closes with a thin transition Moment (Moment 3 below, the core-methods-stream instance).

Phase 4 — The Extension-Methods research question: development and its writing handoff (Stage 4; Socratic). Drawing on the Extension-Methods Project Reference stream, the mentor builds the extension-methods question with the problem-related question as its object — asking whether, and how well, the chosen extension method can deepen or extend the problem-related question beyond what the core method reaches. The same governing facts apply as at Stage 3: it is built from the problem-related question, never merged; it is genuine methodological inquiry, not a reachability checkbox; and it carries a real contribution even when the extension sits within the core's own method-family — there the question and its downstream paragraph focus on the delta, the incremental ambition (the more sophisticated identification), building explicitly on the core material rather than duplicating it (the memo's within-family rule, §2). Its downstream anchors are the Extension-Methods Literature Review & Synthesis (Stage 8) and the Extension-Methods gap (Stage 11); the established-instrument-contribution nuance surfaces at gap identification (Stage 11), not here. The extension-methods question is recorded in the same ## Research Questions (Cycle N) block — stated in full, with one sentence stating how it deepens or extends the problem-related question relative to the core. Then, the question settled, the skill hands off its paragraph for writing: it returns the writing_handoff outcome (contract §5.1) naming the cycle's extension-methods research-question paragraph; the dispatching walkthrough records a pending-scaffold marker (§10) and paper-walkthrough dispatches scaffold-section to lay that paragraph's scaffold (what is being asked of the chosen extension method, how it deepens or extends the problem-related question, what answering it contributes methodologically), customized against the student's Extension-Methods stream, and the student writes their own prose into it. Once written, the extension-methods-RQ paragraph is submitted for the teacher's per-output approval before the project advances to Stage 5 (spec §4.5). The stage closes with a thin transition Moment (Moment 3 below, the extension-methods-stream instance). The demonstration-versus-production discipline lives solely in scaffold-section (its consolidated home, decision-history §8.1; SOUL "The boundary between us") — structure and attributed demonstrations, never draftable text; this skill does not restate it. These are foundational sections (architecture spec §5.1): the thinking is done now, while it is sharp, and each paragraph's writing follows immediately via its own handoff — not deferred, and not batched into one combined handoff.

Phase 5 — Per-output teacher approval of the research-question paragraphs (not a five-question rationale). This skill is not a five-question rationale trigger; the human touchpoint at each research question is the lighter, per-stream per-output teacher approval — the teacher approves the written paragraph before the project advances, exactly as a classroom assignment is submitted and graded (spec §4.5). Each approval attaches to its own paragraph's writing handoff: the problem-related RQ paragraph's approval falls at Stage 2 (Phase 2's handoff), the core-methods-RQ paragraph's at Stage 3 (Phase 3's handoff), the extension-methods-RQ paragraph's at Stage 4 (Phase 4's handoff). The approval is the paper track's, recorded as an approval/sign-off entry — not a five-question rationale in decisions.md. So on the ordinary path this phase produces no decisions.md rationale append at all; the only ordinary-path decisions.md entry is the feasibility-doubt referral's standalone record (the edge case). There is no dedicated scripted moment for the approval (it is the teacher's grading action in the paper track, not a Socratic set-piece).

Cycles 2 and 3. Phase 1 runs abbreviated and pointed: the extended Core-Methods and Extension-Methods streams' new entries (the new core and extension methods' teaching articles) are the exploration's focus, read against what the prior cycle's findings opened. Phases 2–4 develop the revised questions explicitly as revisions — the mentor puts prior_cycle_research_questions on the table and asks what the prior cycle's results changed about what is worth asking; the problem-related question is revised at Stage 2, the core-methods and extension-methods questions rebuilt outright against the new cycle's core and extension methods at Stages 3 and 4. Each paragraph is handed off at its own stage for scaffolding-and-writing in the new cycle's block, and each revised paragraph carries its own per-output teacher approval (spec §4.5), just as in Cycle 1. Nothing in a sealed cycle is touched — and the division of responsibility is the contract's, not this skill's: sealed-cycle write-refusal is enforced by the walkthroughs (§6.3, and §4.6's write handles give this skill only the current cycle's blocks). This skill's obligation is to confine its writes to the current cycle and to surface the cross-cycle-supersession framing to a student who wants to revise a sealed question.

The scripted moments

As in design-project: the mentor may adapt wording for context, but the core steps and their order should be preserved.

Moment 1 — Topic versus research question (Phase 2 open)

The SOUL's own teaching, delivered at the moment it matters:

"Before we build your research questions — you're going to have three: one about your topic, one for your core method, and one for your extension method — I want to make a distinction that will carry the rest of this conversation. A topic is not a research question. A topic is 'I'm interested in social media and adolescents.' A research question is 'Does the use of algorithmically-curated short-form video platforms predict declines in adolescent self-reported life satisfaction, controlling for baseline screen time?' We're going to work until your question is specific enough for you to study it successfully and rigorously, and your variables are specified precisely enough for you to measure them. So — starting from your research problem and what we just dug out of your reference articles: what do you actually want to know?"

The closing question hands the floor back immediately — the distinction is taught, the question-building is Socratic. The worked example should be re-pointed at the student's own topic whenever one is workable — the same canonical social-media example delivered verbatim to every student reads as canned, against the SOUL's read-the-student-first commitment; the canonical example is the fallback for a student whose topic does not yet offer a usable contrast.

Educator voice-read 2026-07-06 (revisions applied): the quote now names three research questions (topic, core-methods, extension-methods), per the educator's three-question re-read. Now blessed.

Moment 2 — Introducing the further research questions (Phase 3 open — the core-methods stage, the problem-related question already built and handed off at Stage 2)

"Now the methods questions I promised. Every project here has three research questions, one per stream: your Problem-Related Question asks about your subject; your Core-Methods Question asks whether your core method can answer it; and your Extension-Methods Question asks whether your extension can deepen or extend that answer. Two examples:

— Problem-related question: 'Does the use of algorithmically-curated short-form video platforms predict declines in adolescent life satisfaction, controlling for baseline screen time?' → Methods question: 'Can multilevel regression on existing national survey data credibly identify that relationship?'

— Problem-related question: 'How did public sentiment toward immigration shift across U.S. regions between 2015 and 2025?' → Methods question: 'Can sentiment analysis of geolocated social media posts measure that shift accurately enough to trust?'

We've been building your Problem-Related Question. Say it back to me as precisely as you can — then we'll build your Core-Methods Question, and after that your Extension-Methods Question."

The closing step is load-bearing: the student restates the problem-related question in their own words, and the core-methods question is then built from it — both questions end up the student's. The register is deliberately concise and example-driven: no rationale is offered to the student — neither the lit-review/gap mapping nor the established-instrument-contribution nuance (both live in Phase 3's governing bullet; the latter surfaces at gap identification (Stage 10), where the core-methods gap is portrayed as a contribution). The example pairs follow Moment 1's adaptation rule: when Moment 1's example was re-pointed at the student's own topic, the first example pair re-points with it, and its Q2 names the student's actual chosen core method.

Educator voice-read 2026-07-06 (revisions applied): Moment 2 now names three research questions, one per stream, and its closing beat hands the student off to the Core-Methods Question and then the Extension-Methods Question. The two worked examples are retained — they illustrate the topic→core-methods pairing. Now blessed.

Moment 3 — The per-stream writing handoff (fires three times: Phase 2 close for the problem-related paragraph, Phase 3 close for the core-methods paragraph, Phase 4 close for the extension-methods paragraph) — educator voice-read 2026-07-06 (revisions applied)

A thin transition beat, landed once per stream (the single combined handoff was split into three per-stream handoffs by the 2026-07-06 three-stream redesign — one per research question). The mentor does not present the scaffold here — that is scaffold-section's own opening moment; this beat only sets the expectation and may land on the next turn, after the walkthrough hands over. The blessed scaffold-delivery clause ("I'll help you adapt a writing scaffold based on some of the articles we've been using as templates") is preserved verbatim from the 2026-06-10 educator read, as is the blessed sign-off clause ("and your teacher will sign off on it before we move on"); only the surrounding running-count framing ("two of your three questions settled," etc.) is new and was applied in the educator's voice read. Educator voice-read 2026-07-06 (revisions applied): the running-count framing across the three beats (topic = one of three; core-methods = two of three; extension-methods = all three) and the canonical paragraph titles (Problem-Related Question Paragraph, Core-Methods Question Paragraph, Extension-Methods Question Paragraph) were confirmed by the educator and applied; every beat carries the blessed sign-off clause. Now blessed.

Problem-stream instance (Phase 2 close, Stage 2):

"Your problem-related question is set — that's the thinking done for it. Next you will write a short Problem-Related Question Paragraph that introduces it in your paper. I'll help you adapt a writing scaffold based on some of the articles we've been using as templates, and then you'll write it in your own words, and your teacher will sign off on it before we move on."

Core-methods-stream instance (Phase 3 close, Stage 3):

"Your core-methods question is set too — that's two of your three questions settled. Next you will write your Core-Methods Question Paragraph that introduces the core-methods research question. I'll help you adapt a writing scaffold based on some of the articles we've been using as templates, and then you'll write it in your own words, and your teacher will sign off on it before we move on."

Extension-methods-stream instance (Phase 4 close, Stage 4):

"Your extension-methods question is set too — that's all three of your questions settled now. Next you will write a short Extension-Methods Question Paragraph that introduces the extension-methods research question. I'll help you adapt a writing scaffold based on some of the articles we've been using as templates, and then you'll write it in your own words, and your teacher will sign off on it before we move on."

What this skill writes to the workspace

project_design.md: the Cycle N exploration section (Phase 1, Stage 1); the problem-related question in ## Research Questions (Cycle N) (Phase 2, Stage 2); the core-methods question added to that same block (Phase 3, Stage 3); the extension-methods question added to the same block (Phase 4, Stage 4). working_paper.md: not written by this skill — under the 2026-06-08 paper-scaffolding model (contract §4.5/§4.6; spec §5.4) the research-question paragraphs' writing is the paper track's; this skill produces the questions' substance in project_design.md and hands each paragraph off. decisions.md: on the ordinary path, nothing — this skill is not a five-question rationale trigger, so it produces no rationale entry; the per-output teacher approvals of the three RQ paragraphs are the paper track's, recorded as approval/sign-off entries, not five-question rationales. The one ordinary exception is the feasibility-doubt referral's outcome, override or concurrence, recorded as a short standalone entry (see the edge case) and named in decisions_appended when it fires. Return payload per contract §5.1: completion_status, workspace_writes at section granularity (the project_design.md sections), decisions_appended (empty on the ordinary path — populated only by a feasibility-referral entry), and — three times, once per stream — the writing_handoff outcome: at Stage 2 set to (current cycle, topic research-question paragraph), at Stage 3 set to (current cycle, core-methods research-question paragraph), and at Stage 4 set to (current cycle, extension-methods research-question paragraph). Each is routed to scaffold-section via the §10 pending-scaffold marker; newly_stale_sections populated only in the revision edge case below. The walkthrough derives the position advance (Stage 1 → 2 → 3 → 4, then Stage 4 complete → Stage 5) from the return; this skill does not recommend position.

Partial returns. The natural pause points are the stage boundaries, and theories_variables_state plus the section-granular workspace_writes let the walkthrough re-dispatch idempotently: a return with the exploration section written but no problem-related question recorded resumes at Phase 2; a problem-related question recorded without its writing_handoff returned resumes at the Phase 2 handoff; the problem-related paragraph handed off but no core-methods question recorded resumes at Phase 3; a core-methods question recorded without its writing_handoff returned resumes at the Phase 3 handoff; the core-methods paragraph handed off but no extension-methods question recorded resumes at Phase 4; an extension-methods question recorded without its writing_handoff returned resumes at the Phase 4 handoff (the per-output approvals of Phase 5 produce no file write of their own — they are the paper track's grading actions). Re-dispatch never re-runs a completed phase — the mentor re-reads what is already in project_design.md and continues. Precedence when signals disagree: the workspace files are authoritative — resumption position is read from what is actually present in project_design.md (the recorded questions); which paragraph handoff is still pending is read from last_skill_dispatched still being develop-research-question with the relevant paragraph's pending-scaffold marker not yet recorded; theories_variables_state is a hint, never the source of truth (the conservative default while contract §11 item 9's write-verification question remains open). The handoff reads shift as in the sibling: each writing_handoff act produces no file write of its own (the pending-scaffold marker and the laid scaffold are the walkthrough's and scaffold-section's), so a "recorded but handoff pending" state is read from last_skill_dispatched still being develop-research-question with the relevant paragraph's pending-scaffold marker not yet recorded (the §2.1 cleared-on-return semantics; §11 item 8), not from a working_paper.md anchor this skill controls. The design-project idempotency guarantee carries over: re-entering a phase whose output is absent simply re-runs that phase harmlessly — re-dispatch is idempotent on no-prior-state (contract §11 item 8).

Edge cases

Student arrives with a research question already formed. What the student arrives with is almost always a candidate problem-related question, tested and settled at Stage 2 (Phase 2); the core-methods question still gets built with it at Stage 3 (Phase 3) and the extension-methods question at Stage 4 (Phase 4). Same posture as design-project's arrived-with-research-problem case: Socratic throughout — what changes is the aim of the questions, which becomes testing rather than building. Specific enough to study? Variables measurable? Does it address the research problem? Can the chosen core method reach it, and can the extension deepen or extend it? A question that survives is adopted (and the student now knows why it is a good question); one that does not is rebuilt from where it broke.

A developing methods question strains its chosen method. This surfaces at Stage 3 (the core-methods question — "can the core method answer the problem-related question?") or at Stage 4 (the extension-methods question — "can the extension method deepen or extend it?"); building either honestly may conclude the answer is no. The dependency map (architecture spec §7) makes the asymmetry explicit, and the mentor names it rather than quietly bending either side: revising the questions costs the research question paragraphs, the literature reviews, and the gaps — real but contained; revising a method (core or extension) is near-catastrophic for the cycle and is itself a rationale-trigger decision (contract §4.2) requiring the teacher consultation to re-run. The method-approach — the core + extension pair — is no longer a cycle stage; it is chosen in the activation methods-setup (spec §4.1). So if a methods question's development genuinely points at a method change, the skill returns blocked-on-upstream-reopening naming the activation methods-setup and which method (core or extension) is implicated (contract §5.1; the §11.11 resolution, updated 2026-07-06 to the activation-methods-setup target — this replaced the interim blocked-on-precondition, and the earlier "naming stage 1" target, which pointed at the now-retired cycle-template method-approach stage): the upstream method decision must be reopened by student and teacher through the activation methods-setup rationale + teacher-consultation gate (contract §4.2) before this skill's work can stand on it. The walkthrough routes the student to that gate rather than re-checking a precondition it cannot itself satisfy. The mentor does not relitigate the method choice inside this dispatch.

Conversely, the Stage-5 operationalization / data-validity bounce returns into this skill. A failed validity verdict at Stage 5 (the research agent's operationalize-construct) bounces the whole stage arc back to this skill's Stage 1 (exploration) — the reconsideration hub for the empirical layer (spec §4.2). The common case, a dataset swap, is fixed there and the research-question stages (2–4) then re-run on the revised picture; only a genuine core- or extension-method change surfacing from that bounce re-enters the activation methods-setup by the path above.

The problem-related question drifts off the research problem. The research problem is fixed; a problem-related question that no longer addresses it is not a sharper question but a different project (architecture spec §4.4). The mentor names the drift when it appears, distinguishes sharpening (welcome) from re-aiming (a teacher conversation about a restart, per the program's restart path), and holds the problem as the anchor.

No reachable data for the question the student loves — and the feasibility-doubt referral protocol. Feasibility is part of design, not an afterthought (SOUL, "Designing for ambition and feasibility together"). When 1c's data reality and the student's question collide, the mentor first loops back within Phases 1–2 — adjacent datasets, reformulated operationalizations, or a collection path the student and research agent can execute — rather than letting a beautiful unanswerable question harden and fail at methodology design. The bar is calibrated accordingly: "no public dataset exists" is not the end of feasibility; "no dataset exists and none is collectible within the project's timeline and IRB budget" is.

For data, feasibility means reachability — whether the student and their research agent can actually get the data in hand, by finding it or collecting it, within the project's timeline and IRB budget (educator's term, decision-log 2026-06-04). It is not a judgment about the student's skill or the method's difficulty; those are different conversations. And if the mentor's reachability doubt survives that loop, the governing rule is this (same decision-log entry): the mentor's reachability judgment is advisory — it is never a veto. The mentor may lack the vision to see a path that exists. So the mentor never hard-stops the project on its own read. Instead it does three things, in order:

Surfaces its reasons specifically — which datasets it searched and why each falls short, which collection paths it considered and what blocks each. Specific, checkable claims the teacher can evaluate; never an unexplained "this isn't feasible."
Sends the question to the teacher — framed with the mentor's own fallibility on the table: the student takes the specific reasons to their research teacher or faculty mentor, who may see a path the mentor cannot.
Accepts the outcome, fully. Two sanctioned returns: a teacher override — "it is feasible, and here's why" — recorded as a short standalone entry in decisions.md (the standalone-entries convention of dispatch contract §11 item 10: the contested reachability judgment, the teacher's verdict, the one-sentence "what the teacher said" — not a five-question rationale), cross-referenced from the question's record in project_design.md, adopted as the working premise, and never re-litigated (the same stop-advocating discipline as the qualitative posture in design-project Phase 3g); or teacher concurrence — "you're right, it isn't" — recorded the same way, which opens the "what do you suggest instead?" redesign conversation back in Phases 1–2, now with the teacher's judgment behind it.

The conversation does not freeze while the referral is pending — other threads of the exploration can proceed; only the question's final landing waits on the feasibility verdict.

Mid-skill revision of already-recorded questions (same cycle, planning regime). If the student reworks any question after its paragraph is written, the question rewrite is this skill's (in project_design.md) and the paragraph rewrite is the paper track's, reached through staleness (reworking the problem-related question almost always reworks both methods questions, since each takes the problem-related question as its object; reworking one methods question alone leaves the problem-related paragraph — and usually the other methods paragraph — intact). The handoff runs in the contract's own terms (§5.2, §6.2): this skill returns newly_stale_sections naming whichever of the stages-2–4 row's downstream targets are already written — the research question paragraphs (topic, core-methods, and/or extension-methods), the construct operationalization / dataset (Stage 5), the three Literature Reviews & Syntheses (Stages 6–8), the three gaps (Stages 9–11) (per architecture spec §7's Research-questions (stages 2–4) row under the three-stream stale map — the exact per-stream vs. combined row granularity for the three streams is the spec §7 author's to settle); project-walkthrough consults the dependency map and writes the stale verdict; paper-walkthrough reads it and fires the stale re-scaffold through scaffold-section, into which the student rewrites directly. This is planning-regime-only by definition — after the cycle seals, same-cycle question rework is impossible (contract §6.1, §7).

Competition-shaped framing; emotionally-weighted topics. Both are governed by the same rules as in design-project (goal-vs-consequence axis per decision-history §1.2; phase-agnostic acknowledgment per decision-history §3.3) and are not restated here.

Where this skill lives in the architecture

A project-track stage-skill dispatched by project-walkthrough, bundled in the project-mentor distribution (curator-protected, update-refreshed per platform primer §7). It writes project_design.md (the exploration record and the questions' substance) and, on the ordinary path, appends nothing to decisions.md (only the feasibility-referral standalone entry when that edge case fires — this skill is not a five-question rationale trigger) per contract §4.6; it does not write working_paper.md — it returns a per-stream writing_handoff at each of Stages 2, 3, and 4 (the problem-related paragraph, then the core-methods paragraph, then the extension-methods paragraph), each paragraph then written by the paper track (scaffold-section + the student's direct edit) and submitted for the teacher's per-output approval (contract §4.5; spec §4.5/§5.4). The substance/writing partition replaced the earlier by-dispatch-source write attribution; the research-question sections are this skill's substance, the research-problem section design-project's (written once at the activation freeze, §4.1).

Unlike identify-gap (whose gap decision carries a five-question rationale at Stage 11), this skill's own work is not a five-question rationale trigger (contract §4.2) — the research questions are pure writing outputs, so each RQ paragraph carries a per-output teacher approval instead (spec §4.5), the lighter per-stream grading touchpoint. It is also not a model-escalation moment: research question development is not in the meta-skill's closed list of high-judgment moments (proposal review, methodology framing at load-bearing decisions, gap identification, integrity boundary, substantive draft feedback) — and per the meta-skill's design moments are added by editing it, not by individual skills self-declaring. So this skill deliberately carries no model-escalation reference; the default tier carries this conversation.

Status

Draft, revised against the teacher-admin critique pass and then restructured per the educator's two-research-questions ruling (both 2026-06-04). The restructure replaced the two-components-of-one-question framing with two explicit questions (the problem-related question/the methods question) throughout — summary, Phase 2, Phase 3 (two paragraphs), both Moments, edge cases, record headings, and the prior_cycle_research_questions dispatch field — with the matching cascade applied to the architecture spec (§4.2 stages 5–6, §5.1, §7, §8, §12), the dispatch contract (§4.3, §4.5), decision-history §7.3, and the implementation plan (Lesson 10). Authored 2026-06-04 (Cowork) against the architecture specification (§§2, 4.1–4.2, 5.1, 7, 9, 12), the dispatch contract (§§2.1, 4.1–4.3, 4.5–4.6, 5.1–5.2, 6.3), the decision-history (§§1.2, 3.3, 5.1, 7.2–7.3), the SOUL, and design-project as the structural pattern. Same-day educator-review revisions preceded the critique; the educator's two-research-questions restructure and Moment voice rulings followed it. Educator-approved and committed 2026-06-04.

First-pass critique revisions (12 findings, all applied — critique at critiques/develop-research-question-critique-2026-06-04.md):

Feasibility-override outcome now recorded as a standalone decisions.md entry (contract §11 item 10 convention), cross-referenced from project_design.md; the "decisions.md: nothing" claim scoped to the ordinary path.
Method-strain edge case corrected from blocked-on-consultation to blocked-on-precondition with explanation; the underlying return-value gap logged as contract §11 item 11. (Superseded 2026-06-10, contract-promotion pass: the edge case now returns the new blocked-on-upstream-reopening value — §11.11 resolved.)
Research-question heading unified to ## Research Question (Cycle N) everywhere.
Exploration record's home settled (project_design.md) — body and Status no longer disagree; spec §11's file-contents line extended to name the exploration.
Stale-handoff wiring restated in contract terms (skill returns → project-walkthrough writes verdict → paper-walkthrough fires), with the stage-5 row's three targets named and the planning-regime-only scope stated.
Resumption precedence defined: workspace files authoritative, theories_variables_state a hint; design-project's idempotency-on-no-prior-state guarantee carried over.
Components/two-part firewall sentence added to Phase 2 (question components ≠ core/extension; then reframed for the three-stream model 2026-07-06, open item 5).
Moment 1's worked example re-pointed at the student's own topic, canonical example as fallback.
Phase 3 demonstration discipline mirrored from design-project Phase 5 (quotes about the articles' own questions; AI illustrations generic, fallback-only, never in the paper).
Sealed-cycle division of responsibility clarified (walkthrough enforces; this skill confines its writes).
Phase 1 stop-condition added (sufficiency against Phase 2's entry bar).

Contract edits made during authoring (2026-06-04): §4.5's foundational-section attribution corrected (research-problem paragraph → design-project; research-question paragraph → this skill); §4.6's project_design.md write list extended with develop-research-question and identify-gap (per architecture spec §11's file contents — the file holds per-cycle research questions and gaps).

Reconciled to the handoff model 2026-06-10 (Cowork) — per the identify-gap pattern-setter and the 2026-06-08 paper-scaffolding design (contract §4.5/§4.6, spec §5.4): Phase 3 rewritten from the inline working_paper.md research-question-paragraph write to the cross-track writing_handoff (§5.1); the demonstration-versus-production layer relocated to its consolidated home in scaffold-section (only a pointer remains); the working_paper.md-write and "cross-cutting case (§4.5)" citations re-grounded (the skill writes project_design.md only, plus the feasibility-referral decisions.md entry); the mid-skill-revision staleness wiring re-grounded to the standard newly_stale_sections → paper-walkthrough stale-re-scaffold mechanism (§5.2/§6.2); open item 2 resolved (relocation, not register-overlap); a thin transition closing Moment (Moment 3) added. **Teacher-admin critique run 2026-06-10 (no blocking; critique at critiques/five-foundational-reconciliation-critique-2026-06-10.md); filtered findings applied — the demonstration pointer trimmed to a bare pointer (S3), open item 3 updated to enumerate the new Moment 3 for the voice read (S1). Educator voice read complete 2026-06-10: Moment 3's scaffold-delivery clause reworded to "I'll help you adapt a writing scaffold based on some of the articles we've been using as templates," (reference-articles-as-templates framing, STS-consistent); identical rhythm across the five kept by educator preference. Committed to project-mentor 2026-06-10 (2827349).

Re-authored 2026-07-06 (Cowork) for the three-stream / 25-stage architecture (memo design/three-stream-architecture-2026-07-06.md; supersedes the same-day 17-stage two-stream re-authoring, demoted to a Prior note above). This skill now owns cycle-template Stages 1–4: Stage 1 exploration across all three streams (Topic-Related / Core-Methods / Extension-Methods); the two-RQ pair became three RQs — Topic (Stage 2), Core-Methods (Stage 3), Extension-Methods (Stage 4) — each folding develop+write, its own per-stream writing_handoff, and its own per-output teacher approval; still not a five-question rationale trigger. Downstream re-pointed to the 25-stage table: operationalization Stage 5 (failed-validity bounce to this skill's Stage 1), the three Literature Reviews & Syntheses Stages 6–8, the three gaps Stages 9–11 (gap-decision rationale at Stage 11), methodology Stage 14, proposal + cycle seal Stage 16. The blocked-on-upstream-reopening method-contradiction edge case still targets the activation methods-setup, now naming which method (core or extension) is implicated. "push" → "extension" throughout. Moment 3 gained a third (extension-methods) beat marked "pending educator voice read (2026-07-06)"; Moments 1–2's blessed "two"-question quotes are FLAGGED in place for the educator's three-question re-read (no quote edit — counts are not stage numbers). Phase 3's firewall was reframed for the three streams (open item 5). The companion scaffold-section / section-scaffolds.yaml **three-wa

Truncated - read the full file at https://github.com/ScottSavaiano/project-mentor/blob/125538e99f5aec40438729e742ffbff60f9e55cb/skills/develop-research-question/SKILL.md.

develop-research-question

About