kst4contest/.agents/skills/kst4contest-documentation/SKILL.md

name, description

name	description
kst4contest-documentation	Perform targeted KST4Contest documentation-impact checks and update affected German/English manuals, README, website feature text, changelog, release notes and durable project context. Avoid full audits by default; keep documentation aligned with implemented behaviour and use the praktimarc-writing-style skill.

KST4Contest documentation workflow

Use $software-project-context and $praktimarc-writing-style.

Default behaviour

Do not read the complete manual or website after every code change.

Start with a documentation-impact classification and search for the affected feature, setting, UI label, protocol/integration or operational concept.

Escalate to a broader audit only when:

• Marc explicitly requests it;
• a major release is being prepared;
• the change is broad across UI/workflows;
• multiple targeted checks reveal wider drift.

Before editing documentation

1. Inspect the actual implementation or approved specification.
2. Explain in German what documentation is probably affected.
3. Ask only unresolved behaviour/scope questions.
4. If documentation updates are already part of an approved implementation concept, no second approval is required for obvious synchronisation.
5. If documentation reveals a new material product decision, stop and ask Marc.

Manuals

When user-facing behaviour is affected:

• search English and German manual content under github_docs/ for the relevant feature/labels first;
• inspect surrounding sections only;
• keep both language versions semantically equivalent;
• do not translate mechanically; English must be idiomatic;
• preserve exact UI labels, values, callsigns, ports and protocol terminology;
• document current behaviour only;
• if code and manual disagree and it is unclear which behaviour is intended, report the conflict;
• identify outdated/missing screenshots explicitly.

README / website

Check only when the changed feature, installation, configuration, capability or compatibility is represented there or should reasonably be represented there.

• Keep feature descriptions concise.
• Explain real contest/operating benefit, not marketing slogans.
• Avoid duplicating large manual sections on the website.
• Keep the main manual/download destinations consistent with the current site strategy.

Durable project context

Update docs/PROJECT_CONTEXT.md for significant:

• architectural decisions;
• threading/state ownership;
• callsign/category semantics;
• protocol/integration contracts;
• persistence/configuration changes;
• durable workarounds;
• deployment/website relationships;
• cross-project dependencies;
• planned propagation/API architecture when it becomes concrete.

Keep current-state sections current rather than using the file as a raw changelog.

Changelog / release notes

• Compact factual bullets.
• Include user-visible changes and important reliability/compatibility fixes.
• Do not invent version scope; derive it from actual commits/changelog/release context.
• Keep release posts short and operationally relevant.