Skip to content

vt-v-interview

Interactive Q&A-based content drafting for VMS vault files. Reads a file, classifies its current state, asks targeted questions about VisiTrans-specific reality, then drafts a rewritten version based on answers. Use with a file path or topic as argument.

Plugin: vms
Category: Other
Command: /vt-v-interview

VMS Interactive Interview & Draft

This skill enables interactive content creation for VMS vault files. Instead of batch-processing, it reads a file, asks the user targeted questions about how things actually work at VisiTrans, and drafts VisiTrans-specific content based on the answers.

Process

Step 1: Identify Target File

Accept a file path, glob pattern, or topic keyword as argument.

  • File path: Read directly
  • Glob pattern: Resolve matches, let user pick if multiple
  • Topic keyword: Search vault with Grep, let user pick from results

If no argument provided, ask:

"Welche Datei oder welches Thema moechtest du bearbeiten?"

If multiple files match, present a numbered list and ask the user to pick one. Process one file at a time — after completing one, offer to continue with the next.

Step 2: Classify Current Content

Read the file and classify it:

Classification Criteria Action
skeleton <1KB, mostly YAML frontmatter, little or no body Full Q&A interview, write from scratch
generic-template 1-5KB, contains SmartKit boilerplate phrases like "Ihr Unternehmen", "passen Sie an", "Beispiel:" Q&A interview, replace generic with specific
partial Has some VisiTrans-specific content but gaps remain Targeted Q&A on gaps only
complete >5KB, uses "wir" voice, references real tools/processes Light review, suggest improvements if any

SmartKit boilerplate indicators (if 2+ are present, classify as generic-template): - "Ihr Unternehmen" / "das Unternehmen" (instead of "wir" / "VisiTrans") - "passen Sie ... an" / "ergaenzen Sie" - "Beispiel:" without VisiTrans-specific content following - "[Platzhalter]" / "[Name]" / "[Datum]" / "[Tool]" - "z.B. ..." with generic examples not matching VisiTrans reality - Section headers like "Zielsetzung und Selbstverpflichtung" (bureaucratic style)

Present the classification to the user:

"Status: generic-template (2.3 KB) — enthalt SmartKit-Vorlagentext, noch nicht VisiTrans-spezifisch."

Step 2.5: Impact Analysis (pre-draft)

Before generating questions, show the blast radius of the file being edited:

  1. Run the impact analyzer: 

    python3 impact_analyzer.py "<vault_path>" "<target_file>"
    Run from plugins/vms/skills/vms-audit/scripts/ directory, or resolve the script path relative to TOOLKIT_ROOT.

  2. Display the result:

  3. If references found: "Diese Datei wird von N Dateien referenziert: [list with domains]"

  4. If zero references: "Keine anderen Dateien referenzieren diese Datei."

  5. This is informational — it helps the author understand cross-file impact before answering interview questions.

Step 3: Read Context

Before generating questions, gather context:

  1. YAML frontmatter — extract type, management_system, norm_refs, classification
  2. Cross-references — find [[wiki-links]] in the file and read linked files for context
  3. Related files — search vault for files with similar norm_refs or in the same directory
  4. Existing good examples — for the same type, find a file already classified as "complete" to use as structural reference

Step 4: Generate Questions

Generate 3-7 targeted questions based on the file type and what is missing. Use a single AskUserQuestion call with all questions formatted in German. Always include multiple-choice options where possible.

IMPORTANT: Questions must be practical and specific to a 15-person company. Avoid abstract or theoretical questions. Frame everything as "Wie macht ihr das?" not "Welche Strategie verfolgen Sie?"

Question Templates by File Type

Richtlinie (policy): 1. Fuer wen gilt diese Richtlinie konkret? (Alle Mitarbeitenden / Nur IT / Nur Fuehrungskraefte / Bestimmte Rollen: ) 2. Welche Tools oder Systeme setzen diese Richtlinie um? (z.B. Microsoft 365, Jira, GitHub, ...) 3. Gibt es Ausnahmen oder Sonderfaelle? Wenn ja, welche? 4. Wer ist verantwortlich fuer die Einhaltung? (ISO / DSB / GF / Teamleiter / ) 5. Wie wird die Einhaltung geprueft? (Audit / Stichprobe / Automatisch / Gar nicht) 6. Was passiert bei Verstoessen? (Gespraech / Abmahnung / Zugriffssperre / ___)

Prozess (process): 1. Wer fuehrt diesen Prozess durch? (Name/Rolle) 2. Wie oft findet das statt? (Taeglich / Woechentlich / Monatlich / Anlassbezogen) 3. Welche Tools werden dabei benutzt? 4. Was ist der Ausloeser (Input)? Was kommt am Ende raus (Output)? 5. Gibt es Freigabe-/Pruefschritte? Wer gibt frei? 6. Wo wird das Ergebnis dokumentiert?

Arbeitsanweisung (work instruction): 1. Beschreibe Schritt fuer Schritt, wie ihr das bei VisiTrans macht. 2. Welche Voraussetzungen muessen erfuellt sein, bevor man anfaengt? 3. Welche haeufigen Fehler oder Sonderfaelle gibt es? 4. Wer ist Ansprechpartner bei Problemen?

Nachweis (evidence/record): 1. Welche Daten werden erfasst? 2. Wo werden die Daten gespeichert? (SharePoint / Vault / Tool XY) 3. Wer traegt die Daten ein? Wer prueft sie? 4. Wie lange werden die Daten aufbewahrt?

Kontrolle (control — ISMS/QMS/DSMS): 1. Ist diese Kontrolle bei euch umgesetzt? (Ja, vollstaendig / Teilweise / Nein, geplant / Nein, nicht relevant) 2. Durch welches Tool oder welchen Prozess? (Konkret benennen) 3. Wie wuerdet ihr den Reifegrad einschaetzen? (0=nicht existent / 1=ad-hoc / 2=wiederholbar / 3=definiert / 4=gemessen / 5=optimiert) 4. Gibt es Nachweise dafuer? (Logs / Berichte / Screenshots / Konfiguration) 5. Was fehlt noch fuer die naechste Reifegradstufe?

Additional context questions (ask 1-2 if relevant): - Gibt es dazu bereits Vorgaben von Kunden oder Partnern? - Hat sich hier in letzter Zeit etwas geaendert? - Gibt es bekannte Schwachstellen oder Verbesserungsbedarf?

Step 5: Draft the Rewritten File

After receiving answers, draft the complete file following these rules:

Tone of Voice (mandatory)

  • Direct and factual — not ISO-handbook formal
  • Use "wir" instead of passive/formal constructions
  • Short sentences, say what we actually do
  • Drop corporate flourishes: "bekennt sich zu", "praegt unser Handeln", "zentrale Verpflichtung"
  • Bullet points over long paragraphs where practical
  • Keep all factual content — just change the wrapper/framing
  • Tables stay as-is (reference material)
  • Legal-required content (DSGVO definitions, Rechtsgrundlagen) keeps formal language where necessary
  • Section headers: descriptive ("Worum es geht") instead of bureaucratic ("Zielsetzung und Selbstverpflichtung")
  • Think: "Would a 15-person team in Paderborn actually write it this way?"

Reference for tone: Read vault/VMS/05 - Richtlinien & Arbeitsanweisungen/01 - Policies (10 Gebote)/Richtlinie zur Auditierung.md as the gold standard.

Structure by File Type

Richtlinie: 

# [Title]

## Worum es geht
[1-3 sentences explaining purpose. End with Geltungsbereich.]

## [Topic-specific sections]
[Content based on Q&A answers. Use bullet points, tables, cross-references.]

## Review
Wir pruefen diese Richtlinie jaehrlich und bei Bedarf.

Prozess: 

# [Title]

## Worum es geht
[Purpose and trigger]

## Ablauf
[Step-by-step with responsible roles]

## Werkzeuge
[Tools used, with links if applicable]

## Dokumentation
[Where results are stored]

Arbeitsanweisung: 

# [Title]

## Zweck
[Why this instruction exists]

## Voraussetzungen
[What you need before starting]

## Schritt-fuer-Schritt
1. ...
2. ...
3. ...

## Haeufige Fragen
[FAQ based on common issues mentioned in Q&A]

YAML Updates

When writing the draft, update these YAML fields: - status: entwurf (always set to entwurf after drafting) - review_date: set to 6 months from today (YYYY-MM-DD) - Preserve all other existing YAML fields unchanged

Cross-References

  • Use [[wiki-links]] for references to other vault files
  • Only link to files that actually exist in the vault
  • Prefer linking to policies from processes and vice versa

Step 5.5: Impact Reminder (post-draft)

After drafting, remind the user of affected files:

  1. Re-run the impact analyzer: 

    python3 impact_analyzer.py "<vault_path>" "<target_file>"

  2. If references found:

  3. Display: "Pruefe diese N Dateien auf Konsistenz nach deinen Aenderungen: [list with domains]"
  4. If zero references: skip silently.

Step 6: Present Draft for Review

Present the draft to the user. Show:

  1. Classification change: "skeleton -> entwurf" or "generic-template -> entwurf"
  2. Key changes summary: 3-5 bullet points of what changed
  3. The full draft in a code block
  4. Ask for approval using AskUserQuestion:

    "Soll ich diese Version so uebernehmen? (Ja / Ja, mit Aenderungen: ___ / Nochmal ueberarbeiten / Verwerfen)"

Step 7: Apply and Continue

After approval: 1. Write the file using the Edit or Write tool 2. Confirm: "Datei aktualisiert: [path]" 3. Offer next steps: - "Naechste Datei im gleichen Verzeichnis bearbeiten?" - "Andere Datei oder Thema waehlen?" - "Zurueck zur Uebersicht? -> /vt-v-start"

If the user wants changes, apply them and re-present. If rejected, discard and offer alternatives.

Batch Mode (Optional)

When a glob pattern matches multiple files:

  1. List all matches with classification
  2. Let user pick which to work on (or "alle der Reihe nach")
  3. Process one at a time with the full Q&A loop
  4. After each file, offer to continue or stop

Integration with Other Skills

Situation Hand off to
File needs YAML fixes first /vt-v-audit the file, then come back
New file needed (not in vault) /vt-v-intake capture to create vorschlag
Reifegrad uncertain Note for HA-01, continue with best estimate
Cross-references broken Fix inline, or flag for /vt-v-audit batch

Important Notes

  • The vault path is relative to the V004 Handbuch repo root
  • Always verify you are in the correct repo before modifying files
  • Write all content in German
  • Use ASCII-compatible umlauts in filenames (ae/oe/ue), real umlauts in content body
  • Never remove existing Dataview queries or navigation links
  • Preserve [[wiki-links]] format for cross-references