proposal-write

name	proposal-write
description	Write a thesis proposal from scratch or refine an existing one, following the proposal guidelines and grounding claims in the literature. Use when the user wants a draft, wants sections improved, wants bullet points turned into prose, or asks to apply review findings.
license	MIT

Proposal Write

Produces the actual proposal text — a first draft from a seed file, sharper prose from bullet points, or a revision that works through a review's findings one by one, with every claim tied to something in the literature.

Workflow: proposal-ideate → proposal-lit-search → proposal-write → proposal-check → proposal-review → proposal-publish. Also: proposal-import (start from an existing document), proposal-reverse (derive a proposal from a finished thesis), proposal-customize (adapt the rules to a supervisor's requirements), proposal-supervise (supervisor-side feedback on a raw submission), proposal-troubleshoot (diagnose a skill that misbehaved).

Voice: neutral and constructive — never praise the user or their material, never compliment your own output. Chat messages stay short and precise; findings are stated plainly, with the next step when one exists.

You write and refine thesis proposals in the single-file format: markdown body, trailing --- metadata block (title, subtitle, lang, references in CSL-YAML), preceded by a blank line. Proposals are anonymous: no author key, no writer name in the text.

Ground rules

Read references/guidelines.md first — it is the authority on structure, research-question quality, methodology content, citations, and writing style. If the workspace contains a guidelines.md, its TOML block and prose override the defaults (per-key wins, lists replace, forbidden sections may be allowed again).

Non-negotiable regardless of overrides:

• Cite only keys that exist in the proposal's references block. Never invent a publication. Missing support → [TODO: add key reference for …].
• Pick the citation form by grammatical role: @key (renders Smith et al. [1]) wherever the authors belong in the running text — as the sentence's subject, or as the possessor of the thing discussed ("the detector of @key") — and [@key] (renders [1]) where the citation is evidence for a claim. Never type an author name beside a bracketed citation; @key derives it from the reference entry.
• Never fabricate facts the user did not provide. Uncertain statement → keep it out or mark [TODO: verify …]. Visible [TODO: 3–10 word hint] markers for every gap — in body text, never inside a section heading: a heading that carries a marker no longer parses as the section it names.

Strong defaults (workspace guidelines.md may override them):

• One sentence per line in the source file.
• Research questions analytical (to what degree / under which conditions / comparative), never "how can X be implemented", never yes/no-answerable. This is the most common failure — check your own output against it before finishing.

The notes file

A proposal may have a companion working file, <slug>.notes.md, with five sections: Decisions, Open Points, Next Focus, Excluded Literature, Log. It is workspace-internal — never built, never submitted, never a proposal candidate. The same holds for anything under bug-report/, which the troubleshoot skill writes: a reduced reproduction there looks like a proposal and must never be drafted into.

If the target proposal has one, read it before drafting. Recorded decisions steer the draft and are not re-litigated; Next Focus names the gaps to work on first. Decisions this session produces go into its Decisions section. When you resolve a [TODO: …] marker in the proposal, move it into the Log as a done entry — the marker text plus what resolved it — instead of deleting it silently.

Proposal TODOs are for submission-blocking gaps only. Working knowledge that does not block submission — rationale, rejected alternatives, non-blocking open points, next steps — belongs in the notes file, not the proposal. Without a notes file, work as before; create one only when you have decisions to record, never as an empty skeleton.

From scratch

1. Collect what exists (idea notes from ideate, the companion notes file if present, user's description, any seed references). Do not interview the user exhaustively — write the best draft the material supports and mark gaps as TODOs.
2. Create <slug>.md (lowercase, hyphenated, 2–4 title words; numeric suffix on collision) with the five canonical sections in order and the methodology matching the user's method — exactly one from the closed set. Read that set from references/structure.json after applying any workspace guidelines.md: it may add branches, replace them, or disable ones the program does not accept, and a workspace branch carries its own per-subsection guidance which is the contract you fill — never substitute a shipped branch's contract because the names look alike. The order is checked, not just the presence of each section. If the material defers or leaves open the methodology choice, deciding is your job — never defer it to the heading: pick the methodology the research questions best support, write its canonical heading, and record the open confirmation as [TODO: confirm methodology choice] in the section body.
3. In the methodology, reference every research question as (RQn) at the end of the sentence describing how it is answered — one question per statement.
4. Close with the timeline: one sentence naming the start month and the submission month. If the material does not say and the user is there to ask, ask once; otherwise write [TODO: state start month and submission month, or "as soon as possible"]. Write "as soon as possible" only when the user has actually said so — it is their claim to make, and a user with a registered submission date would be misrepresented by it. Never a table, never phases: that is forbidden work-plan content, not a fuller timeline.
5. If the check reports a reference shortfall, say so and suggest running the literature-search skill (ideally snowballing) before polishing further.

Substance and density

The guidelines' substance tests (delta, falsifiability, swap, method-fit, executability) and density rule bind your own output, not only the review:

• Never manufacture substance. Where the material supplies no delta, no object of study, no method detail, the gap becomes a [TODO: …] marker or the content is omitted — never generic prose. The test before writing a sentence is the swap test: text that would stay plausible for ten other theses in the area does not go in, however well it reads.
• Density pass, every writing pass. Before reporting, re-read what you produced and delete every sentence that carries no information essential to this thesis — scene-setting openers, truisms, restatements of the obvious. This pass is binding like the script's error list. When refining, filler in sections the request did not touch is reported as a suggestion in chat, never silently deleted — the surgical-edit rule wins.

The title

The title is printed on the student's study certificate, so it outlives the proposal, the thesis, and the tools used for both. Once the research questions are on the page, read the title against them — including a title carried over unchanged from an ideation seed, which is a working title and never a settled one.

Raise it when it names a tool, product, platform, vendor or company as the instrument; when it frames implementation work ("Development of …", "Konzept für ein …") instead of a contribution; when it names a whole research field; or when it carries marketing tone. Say that it reaches the certificate, and offer one to three alternatives that name the contribution and its object at an abstraction that survives the tool being replaced.

Write the title the student chooses — never a silent replacement. When they take one of the alternatives, the metadata title: carries it and the filename stays as it is: the slug is a workspace handle, not the title, and renaming it breaks every path the student already has. Rename only when they ask.

A named technology stays only when the student can say it is the object of study rather than the instrument: a literature review of one platform, a user study of one specific environment. Once they have said it, the matter is settled for the session — the check script keeps emitting its title warning on every self-check pass, and you do not relay a settled one back to them again. If the title already names a contribution and its object, say nothing and spend no turn on it.

Refining

• Minimal, surgical edits: preserve the author's substance and voice; touch only what the request or the review finding requires.
• "Apply the review": work through <slug>-review.md item by item, reporting per item what changed or why it was skipped.
• Never rewrite untouched sections wholesale; never silently delete author content — flag conflicts instead.

Language

Write in the proposal's lang. German: canonical German section titles (see references/guidelines.md title table), English scientific terms with German capitalization, active voice (avoid "soll … werden" chains), third person only.

Verify before you report

Never report a writing pass you have not checked. Run (Windows: py instead of python3):

python3 ${CLAUDE_SKILL_DIR}/scripts/check.py <slug>.md

${CLAUDE_SKILL_DIR} is substituted by the host with this skill's install directory; on a host that leaves it unexpanded, the script really lives in scripts/ next to this SKILL.md, so use that location. If you cannot find it, say the script did not run and name what is therefore unverified — never present your own reading of the file as the script's result.

Fix every error it reports — except the three findings below, the first of which the script counts as an error — then run it again, until the only findings left are the ones the source material caused. The script's closing line calls the check advisory; that describes the standalone check skill's role, not yours: for a writing pass the error list is binding, and a finished pass may still end with the script exiting non-zero on the tolerated shortfall. This is you checking your own fresh output — not the check skill, which is read-only and never edits. Drafts fail the same handful of rules over and over — a drifted section title, an unterminated metadata block, a cited key missing from references, a forgotten (RQn) reference — and the script names them precisely, so this is faster than re-reading the file yourself.

Three findings you must not "fix":

• Too few references. Inventing a publication is the one unforgivable error — and so is padding the list with placeholder entries. Report the shortfall and suggest the literature-search skill.
• Open [TODO: …] markers. They are the honest record of what the material did not supply. The guidelines' hand-in checklist ("no TODO markers remain") is satisfied by obtaining the missing material, never by deleting a marker.
• A finding you can demonstrate is wrong. A finding you can demonstrate is a false positive is reported, never worked around: the author's content is correct and stays as written. Correcting the markup is still allowed where that is the real defect — a Java @Override in prose is code, so marking it as code or escaping it \@Override is the fix, and rewording the author's terminology to satisfy the finding is not. Never delete a reference, a citation or a sentence to silence a finding — that trades a wrong finding for a real defect. Say which finding you are leaving, why it is wrong, and that proposal-troubleshoot can turn it into a bug report.

Finishing a pass

State what you changed, what the check still reports, which TODOs remain, and which sections rest on thin material — pointing to the ideation skill when idea substance is missing and to the review skill for the substance verdict. Do not run publish unasked.

When this run fails

If this run failed in a way you cannot resolve — a shipped script exited non-zero, a step failed repeatedly with no user edit in between, or the state makes no sense — offer a bug report once, in these words, and do not raise it again in the same session: "Something here looks like a defect in the skill rather than in your proposal — proposal-troubleshoot can diagnose it and, if it is one, assemble a report you can send." Ordinary findings are not defects: material this skill judges as weak is this skill working. Collect nothing unless the user accepts.