# Proposal Write > 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. - **Type:** Skill - **Install:** `agentstack add skill-hutzelmann-thesis-proposal-skills-proposal-write` - **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior - **Seller:** [hutzelmann](https://agentstack.voostack.com/s/hutzelmann) - **Installs:** 0 - **Category:** [Developer Tools](https://agentstack.voostack.com/c/developer-tools) - **Latest version:** 0.1.0 - **License:** MIT - **Upstream author:** [hutzelmann](https://github.com/hutzelmann) - **Source:** https://github.com/hutzelmann/thesis-proposal-skills/tree/main/skills/proposal-write - **Website:** https://www.skills.sh/hutzelmann/thesis-proposal-skills ## Install ```sh agentstack add skill-hutzelmann-thesis-proposal-skills-proposal-write ``` Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent. ## About # 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-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, `.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 `.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 `-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/skills/proposal-write/scripts/check.py .md ``` Paths are relative to the workspace root for a standard project install; the script really lives in `scripts/` next to this SKILL.md, so use that location if the skill is installed elsewhere. 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 two 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. Two 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. ## 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. ## Source & license This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code. - **Author:** [hutzelmann](https://github.com/hutzelmann) - **Source:** [hutzelmann/thesis-proposal-skills](https://github.com/hutzelmann/thesis-proposal-skills) - **License:** MIT - **Homepage:** https://www.skills.sh/hutzelmann/thesis-proposal-skills Install and usage instructions live in the source repository linked above. ## Pricing - **Free** — Free ## Security capabilities Automated source analysis of v0.1.0 — what this tool can access: - **Network access:** no - **Filesystem access:** no - **Shell / process execution:** no - **Environment & secrets:** no - **Dynamic code execution:** no *"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.* ## Versions - **0.1.0** — security scan: passed — Imported from the upstream source. ## Links - Listing page: https://agentstack.voostack.com/l/skill-hutzelmann-thesis-proposal-skills-proposal-write - Seller: https://agentstack.voostack.com/s/hutzelmann - Browse the marketplace: https://agentstack.voostack.com/browse --- Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.