chore: add Codex project context and agent guidance

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

@@ -0,0 +1,74 @@
+---
+name: kst4contest-documentation
+description: 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.

.agents/skills/kst4contest-documentation/agents/openai.yaml

@@ -0,0 +1,7 @@
+interface:
+  display_name: "KST4Contest Documentation"
+  short_description: "Keep KST4Contest manuals, website and release text aligned"
+  default_prompt: "Review the implemented KST4Contest behaviour, explain the documentation impact in German, propose a concept, ask questions, and wait for approval before editing."
+
+policy:
+  allow_implicit_invocation: true

.agents/skills/kst4contest-documentation/references/current-feature-context.md

@@ -0,0 +1,26 @@
+# User-facing feature context
+
+This is a documentation coverage reminder, not a canonical feature list. Verify each item in current code before documenting it.
+
+Areas repeatedly documented or changed include:
+
+- simultaneous ON4KST chat categories;
+- priority candidates;
+- sked timeline/reminders;
+- known active bands / B+ / NOT-QRV;
+- worked indicators;
+- DXCluster;
+- AirScout integration;
+- map/path analysis;
+- filtering and reachability;
+- PSTRotator/rotor integration;
+- UCXLog/DXLog and Win-Test log synchronization;
+- beacon/autoanswer behaviour;
+- connection status/reconnect behaviour;
+- dark/light UI behaviour;
+- QTF/bearing workflow;
+- download/update behaviour.
+
+When one of these changes, search both language manuals and website copy for affected references.
+
+Do not specialize documentation beyond actual behaviour. A useful example from prior work is callsign monitoring: entering an SSID-style variant can intentionally monitor the base call rather than requiring every suffix to be configured individually.

.agents/skills/kst4contest-documentation/references/manual-and-website.md

@@ -0,0 +1,47 @@
+# Manual and website context
+
+## Manual location
+
+KST4Contest documentation is maintained in `github_docs/` with English and German Markdown pages plus screenshots.
+
+The documentation build is automated through repository workflows.
+
+## Audit workflow established with Marc
+
+The normal review method is:
+
+1. compare documentation with actual code/behaviour;
+2. propose exact changes;
+3. note missing/outdated screenshots and their intended repo location;
+4. if code must change to match the manual, stop and confirm that code change first;
+5. keep German and English content aligned;
+6. prefer one thorough update over many cosmetic iterations.
+
+With Codex editing locally, the old copy/paste insertion-guide step is replaced by direct edits, but the approval logic remains.
+
+## Examples and easter eggs
+
+Deliberate examples/test strings must not be "cleaned up" merely because they are informal.
+
+A known example uses:
+
+```text
+DO5AMF
+Testing DXC-Spot: Congrats, you donated $100!
+```
+
+Preserve such deliberate easter eggs unless Marc explicitly asks to remove or replace them.
+
+## Website
+
+The website under `website/` uses Eleventy/Nunjucks.
+
+Style direction:
+
+- modern and concise;
+- technically focused;
+- no promotional tone;
+- English primary where appropriate;
+- documentation remains the detailed source; website text should not duplicate entire manual sections.
+
+Current website architecture/scripts must be inspected before changes.

.agents/skills/kst4contest-documentation/references/release-communications.md

@@ -0,0 +1,35 @@
+# Release communications
+
+## Changelog
+
+Write concise English change descriptions.
+
+Prioritize:
+
+- behaviour users notice;
+- contest workflow impact;
+- protocol/integration compatibility;
+- bug/reliability fixes;
+- documentation improvements.
+
+Avoid internal refactor trivia unless it materially changes reliability or maintainability relevant to the release.
+
+## Social release post
+
+Use `$praktimarc-writing-style`.
+
+Typical structure:
+
+- version;
+- short statement of what the release contains;
+- compact highlights;
+- operational context where relevant, e.g. preparation for a VUSHF contest or planned use at DM5M;
+- one clear download/manual destination.
+
+Do not oversell.
+
+## Download/manual direction
+
+Marc has preferred routing users to the HamRadioOnline/KST4Contest download/manual pages rather than scattering multiple download links.
+
+Before publishing new text, inspect the current website URLs and release setup instead of copying an old link.