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

name, description

name	description
kst4contest-change	Analyze or implement KST4Contest Java/JavaFX changes, bug fixes, refactorings, protocol handling, contest workflow behaviour, callsign/band logic, AirScout/logging/rotor/DXCluster integrations, threading and state management. Use current code as source of truth and follow the mandatory concept-and-question gate before edits.

KST4Contest change workflow

Read the relevant reference files before proposing a concept.

Phase 1: read-only analysis

• Inspect the current code and tests.
• Identify the current data flow and thread ownership.
• Identify user-visible and protocol-visible behaviour.
• Check relevant docs/PROJECT_CONTEXT.md sections when they exist.
• Check whether the task overlaps a known invariant in the references.
• Do not modify files.

Phase 2: report understanding in German

Explain:

• what Marc wants changed;
• what must remain unchanged;
• which components appear affected;
• what evidence in the current code supports that understanding;
• any conflict between current code and historical project context.

Never resolve a conflict by guessing.

Phase 3: questions and final concept in German

Before finalizing the concept:

• identify all material implementation choices;
• ask Marc questions that are not already answered by code, project instructions or prior confirmed decisions;
• wait for answers when needed.

Then present:

• intended data/control flow;
• exact behavioural changes;
• compatibility impact;
• thread/UI impact;
• persistence impact;
• test strategy;
• likely documentation impact;
• likely durable project-context impact;
• related-project impact when relevant.

Ask for explicit concept approval and wait before editing.

Phase 4: implementation

After approval:

• implement the smallest coherent change;
• preserve unrelated behaviour;
• keep comments/Javadoc in English;
• add/update focused tests;
• keep external protocol parsing defensive;
• avoid hidden defaulting for unknown values.

Phase 5: verification and documentation impact

Run focused checks, then appropriate broader checks.

Because KST4Contest build configuration may ignore failures/findings, inspect summaries and reports rather than only command exit status.

Then use $software-project-context:

• do a low-cost documentation-impact classification;
• inspect only likely affected manual/README/website sections;
• update targeted documentation when clearly required by the approved implementation;
• update docs/PROJECT_CONTEXT.md for significant durable technical decisions/state changes;
• do not perform a full manual audit unless there is a specific trigger.

Phase 6: report

Report in German:

• files changed;
• implementation summary;
• tests/checks;
• warnings/findings;
• documentation-impact result;
• documentation/context updates or why none were required;
• related-project impact when relevant;
• unresolved issues;
• no Git publication action unless explicitly requested.