wiki-theorieseite

wiki-theorieseite

Generate a DokuWiki theory page in the style of the BZZ Modulwiki (wiki.bzz.ch).

First step: read the config

Before generating anything, read config.txt in this skill's folder. It contains the author footer and license values that get pasted at the bottom of every page. The user (or their colleagues) edits this file once after installing the skill, so always read the current values rather than hardcoding them.

What the user provides vs. what you ask for

A theory page needs these pieces of metadata. Pull whatever the user has already given you out of their request, then ask once for the rest in a single compact prompt — don't drip-feed questions.

Field	Example	Notes
Module	m319	Lowercase. Default to m319 if not specified — it's by far the most common.
LU number	01	Two digits, zero-padded.
Sub-letter	c	Optional ordering letter within an LU (a, b, c, d…). Look at the existing LU's start page if unsure — the next letter follows the last existing one.
Page slug	variablen	Lowercase, hyphen-separated, no umlauts (use ae/oe/ue if needed). This becomes the URL part.
Title	Variable und konstante Werte	The human-readable title. The full H1 becomes LU01c - Variable und konstante Werte.
Topic / outline	(free-form)	What the page should cover. Can be a short brief, an outline, or a draft the user wants formatted.
Competence tags	b1g c1g	Optional. Theory pages typically have one or two competence-grid tags in addition to the LU tag. If the user doesn't mention any, ask whether to include them or skip — don't invent them.

If the user gives you a draft of content already, respect it. Translate their structure into DokuWiki markup and add the standard wrapping (top tags, footer). Don't rewrite their explanations into your own voice unless they ask.

Page structure

Every theory page on this wiki follows this skeleton. Reproduce it faithfully:

{{tag>mNNN-luXX [competence-tags…]}}

====== LUXX<letter> - <Title> ======

//Siehe auch [[<canonical-reference-url>|<reference title>]]//

<lead-in prose: 2-4 sentences introducing the concept>

===== <First main concept> =====

<prose explanation>

==== <Subsection like "Beispiel" or "Programmbeispiel"> ====

<code python>
…code with optional inline `# output` comments…
</code>

<code>
…multi-line program output (only if it adds value)…
</code>

===== <Second main concept> =====

…

----

{{tag>mNNN-LUXX}}

{{<license-image-url>}} <author footer>

Patterns that show up on most theory pages — follow them unless the user asks otherwise:

• The H1 immediately follows the top {{tag>…}} line, separated by a blank line.
• Optional //Siehe auch …// italic link directly after H1, before any H2 — links to the canonical reference (Python docs, MDN, etc.). Use when there's an obvious primary source for the topic. Skip if not.
• Each major concept gets its own H2. Within a concept, use H3/H4 for "Beispiel", "Programmbeispiel", comparison tables, etc.
• Code examples: <code python>…</code>. For showing what an example prints, prefer one of two patterns (no ==== Output ==== heading):
  • Inline # comment at the end of print() lines when the output is short and 1:1 with the prints — e.g. print(animals[1]) # Gepard. This is the preferred default.
  • A second plain <code> block right after the code, when the output is multi-line or several prints combine into one block. The two blocks sit visually adjacent — that's enough cue, no heading needed.
  • Skip the output entirely when the snippet is illustrative only (showing a literal form, an empty list, an import) and the output adds no information.
• WRAP boxes for important content. Anywhere prose would otherwise say **Vorsicht:** …, **Hinweis:** …, **Achtung:** …, or warn about a common pitfall, prefer a <WRAP alert>…</WRAP> (or info / tip / important depending on tone). See references/dokuwiki-syntax.md for the full WRAP class list. Use sparingly — one or two per major H2 section, not on every paragraph.
• Comparison tables (e.g. Algebra vs. Programm) are a recurring device. Use ^ for header cells if there's a header row, otherwise | only.
• For Blockly diagrams, embed the image with {{:de:modul:mNNN:learningunits:luXX:<image>.png?w=400|caption}}.

Do NOT embed graded exercises in theory pages. Theory and exercises live on separate pages — a Theorieseite explains, an Aufgabe is solved. The user's convention is no embedded tasks at all on theory pages by default. If the user explicitly asks for an in-page reflective exercise (rare), call it ==== Übung ==== — never ==== Aufgabe ====.

DokuWiki syntax cheat-sheet

For the actual markup details (headings, code blocks, links, images, tables, what's different from Markdown), see references/dokuwiki-syntax.md. Read it before generating output if you're unsure about any specific syntax — DokuWiki has several gotchas where it looks like Markdown but isn't (italic is //…//, inline code is ''…'', images are {{…}}).

Real examples

references/examples.md contains three full theory pages from the actual wiki, copied verbatim, so you can see the conventions in practice. Read it for any non-trivial page — pattern-matching from real examples is far more reliable than reconstructing from rules.

Output

Print the complete DokuWiki source as a single fenced code block in chat (use a triple-backtick block with no language tag, since the contents themselves contain DokuWiki markup that shouldn't be re-parsed). The user copies it into the DokuWiki editor.

After the code block, briefly state:

1. The full page ID (e.g. de:modul:m319:learningunits:lu01:variablen) so they know where to create the page.
2. Any media files referenced that they'll need to upload separately to the media manager (with the namespace path where each goes).
3. Anything you assumed or guessed that's worth a sanity check (e.g. "I picked sub-letter c assuming a and b already exist — adjust if not").

Do not wrap the output in additional commentary inside the code block. Keep the code block clean — it's going straight into the wiki.

Style notes

• The wiki is in German (Swiss German educational context). Keep prose in German unless the user explicitly writes in English. Use du form (informal, addressing the student) — that's the established voice on m319 pages.
• Prefer concrete examples over abstract definitions. The existing pages lead with a real-world scenario (football scoring for "Konstante", circle area for "Variable") before introducing terminology.
• Code identifiers in examples should be English (radius, circumference, count_chicken) — that's the convention on m319 even though prose is German.
• Don't pad. The wiki style is direct and concise. A theory page is typically 50–150 lines of source, not a textbook chapter.