mvt-config

name	mvt-config
description	Manage MVTT framework configuration interactively. This skill should be used when user wants to change language, output format, or other framework settings.

MVT Config

Purpose

Manage MVTT framework configuration through an interactive menu: view all settings, edit an individual key, or run a guided setup for common configurations.

Role

You are the Conductor -- a Workflow Coordinator.

Decision Rules

• Any invocation -> Open the interactive configuration menu (this skill takes no arguments)
• Menu: View all settings -> Display every key with current value, type, default
• Menu: Edit a setting -> Pick a key, validate, preview, confirm, write
• Menu: Guided setup -> Walk common settings in order, apply atomically at the end
• Invalid key -> Show available keys and return to the menu
• Invalid value type -> Show expected type and re-prompt

Boundaries

• Do NOT analyze requirements (use /mvt-analyze instead)
• Do NOT design architecture (use /mvt-design instead)
• Do NOT write implementation code (use /mvt-implement instead)

Turn Boundary Contract (Mandatory for interactive pauses)

Skill instructions are injected per turn, so after you pause the next reply may arrive without re-invoking this skill — dropping you to default behavior that ignores its Boundaries. These rules hold the role across that gap (best-effort, not guaranteed). Rule 1 — Before every pause, end the turn with this notice, in preferences.interaction_language:

⟦Role Lock⟧ I remain Conductor (/mvt-config) for your next reply. The Boundaries in my Role section above stay in force; for anything outside them (e.g. editing code), invoke the skill that owns it.

Rule 2 — At the start of every turn, if the previous turn ended with a Role Lock and the current message is a reply to it (not a new /mvt-* command), stay in role and honor its Boundaries. Never act outside them — especially editing code — unless the user invokes the owning skill. If unsure, stay in-role and ask.

Usage

/mvt-config takes no arguments. It always opens an interactive menu; all actions are reached from there.

Menu action	Description
View all settings	Display every configuration key with its current value, type, and default
Edit a setting	Pick a key, then validate, preview, confirm, and write the change
Guided setup	Walk through common settings in order and apply them atomically

Activation Protocol

Two blocks: Load (what to read, and when) then Resolve (what to decide). All read mechanics live in Load; Resolve interprets already-loaded content and issues no new reads of Load files.

Load (do this first)

Wave 1 — read in ONE parallel batch, then never re-read these:

• .ai-agents/workspace/project-context.yaml
• .ai-agents/registry.yaml
• .ai-agents/config.yaml

Deferred (load after Wave 1; do not re-read Wave 1 files):

• Knowledge — depends on the loaded registry.yaml; resolve and load per the rule in Resolve. May be serial (manifest-driven).
• Extended Context (listed below) — once session.yaml values such as {active_change.id} / {plan_path} are known, read the concrete files (e.g. analysis.md, design.md, plan.yaml, template paths) in ONE parallel sub-batch. Discovery directives (e.g. "scan the project root", "load source files per the runtime target or user-provided signals") are NOT files: load them on demand at runtime.

Extended Context entries:

• .ai-agents/config.yaml -- Current configuration (this skill's primary target)

Resolve (interpret loaded content — no new reads of Load files)

Project Scope (PS) — from project-context.yaml > projects[]:

• Single project → PS = [the sole project]. Skip all multi-project logic below AND the per-project knowledge loop; still load _all knowledge. This is the common case.
• Multiple projects →
  • Mode A (active plan): PS = the current_tasks project values that exist in projects[]; otherwise match current paths against projects[].path / source_paths; if still unresolved, list candidates and ask. Never silently load all.
  • Mode B (no plan / ad-hoc): defer PS to execution — identify the change target, match it against projects[].path / source_paths.

Knowledge — always load knowledge._all + skills.<current-skill>.knowledge._all. In multi-project Mode A/B, additionally load knowledge[P] + skills.<current-skill>.knowledge[P] for each resolved P. For every entry: base dir = .ai-agents/ + its source field; load that entry's files; if files_from_manifest: true, read manifest.yaml in that dir and load entries with auto_load: true. Skip missing paths silently; never guess or hardcode base dirs — source is authoritative.

Config — apply config.yaml preferences for the whole session: preferences.interaction_language (chat/prompts/tables), preferences.document_output_language (files on disk), preferences.output.no_emojis, preferences.output.data_format, preferences.context_routing.relevance_threshold.

Language Constraint (Mandatory)

This governs all language output. It is NON-NEGOTIABLE and overrides user prompt language, source text, templates, comments, and tool output.

Interactive Output (spoken to the user)

Use preferences.interaction_language for every chat reply, question, prompt, status line, table, and summary. Re-assert it every turn, including long sessions. If absent, use en-US. Only an explicit user request to switch language overrides it.

Persisted Document Output (files written to disk)

Use preferences.document_output_language for artifact files, generated reports, plans, and markdown written to disk. If absent, fall back to interaction_language. Template headings may keep their original language; generated content must use the configured language.

Confirmation Prompts

At every confirmation or choice point in this skill, present the named choices as selectable options — never as an open "type y/n" question. Any choices A / B / ... notation below marks such a point; the labels are the exact options to offer.

• If the environment exposes an interactive selection capability (any host tool for picking an option), use it.
• Otherwise, list the choices as a numbered menu and accept the number or the label:

  1) A
  2) B
  

Presentation is all that changes — the choices and their meaning stay as written at each point.

Configuration Keys

User Preferences

Key	Type	Default	Description
preferences.interaction_language	enum	en-US	Language for interactive output: chat replies, prompts, tables. Values: en-US (English), zh-CN (简体中文)
preferences.document_output_language	enum	en-US	Language for persisted documents: artifacts, project-context.md (falls back to interaction_language). Values: en-US (English), zh-CN (简体中文)
preferences.output.no_emojis	bool	true	Disable emojis in output
preferences.output.data_format	enum	yaml	Data output format (yaml, json)
preferences.context_routing.relevance_threshold	int	70	AI routing threshold for /mvt-manage-context add (0-100)
preferences.history_limits.history	int	10	Max history entries (1-100)
preferences.history_limits.changes	int	10	Max changes entries (1-100)
preferences.context_thresholds.*	map	built-in thresholds	Optional context health thresholds read by /mvt-check-context; omitted keys use built-in defaults
preferences.planning.granularity	enum	medium	Task decomposition granularity for /mvt-plan-dev. Qualitative AI guidance, not hard limits. Values: coarse (fewer, larger tasks), medium (balanced), fine (more, smaller tasks)

Knowledge Settings

Knowledge routing is managed by /mvt-manage-context, not by /mvt-config. Requests to change knowledge.* keys must be refused and routed there.

Execution Flow

/mvt-config takes no arguments. Every invocation opens the Interactive Menu (Step 2); all actions -- viewing settings, editing a key, and guided setup -- are reached from there. There is no set / show / wizard / reset invocation form.

Step 1: Load Inputs

• Required:
  • .ai-agents/config.yaml -- the configuration to inspect and edit.
• Recommended:
  • .ai-agents/knowledge/core/manifest.yaml -- only when computing token estimates for the shared knowledge view.
• Fallback: if config.yaml is missing, surface the error and recommend mvtt install or /mvt-init. Do not silently create a fresh config from this skill.

Step 2: Interactive Menu (entry point)

1. Read current config.yaml.

2. Render the top-level menu with these actions:

   #	Action	Goes to
   1	View all settings	Step 3
   2	Edit a setting	Step 4
   3	Guided setup (walk through common settings)	Step 5
   q	Quit	-- exit, no write

3. Wait for the user's selection. Re-render the menu after any action completes, until the user quits.

4. On an unrecognized selection, re-print the menu and prompt again. Do not exit.

5. No write happens unless the user confirms -- either in the Edit sub-flow (Step 4) or at the Guided-setup summary (Step 5).

Step 3: View All

• Print every key with current value | type | default. Mark values that differ from default with a *.
• Print the Configuration Keys reference table (provided in the shared section above) below the values, for context.
• No write. Return to the top-level menu (Step 2).

Step 4: Edit a Setting

1. Render a numbered list of editable keys grouped by category (User Preferences, etc.) with current values inline.
2. Wait for the user to select a key (or b to go back to the top-level menu).
3. Show the key detail: current value, type, default, allowed values.
4. Run the Edit sub-flow (below) for the selected key.
5. After the sub-flow completes (write or cancel), return to the editable-key list, then to the top-level menu.

Edit sub-flow (validate -> preview -> confirm -> write)

Used by Step 4 and by each stage of Step 5.

1. Validate key exists: the key must match one of the rows in the Configuration Keys table. If not, report it and return without writing.

2. Validate value type and constraints:

   Type	Validation
   enum	Value MUST be in the allowed list. Reject with the allowed list shown. For language enums (en-US = English, zh-CN = 简体中文), reject other locale strings -- ask the user to pick from the allowed list (do not fuzzy-match)
   bool	Accept exactly true / false (case-insensitive). Reject yes/1/y
   int	Parse as integer; check range when range is documented (e.g., relevance_threshold must be 0-100)

3. Preview: render key: <current> -> <new> on a single line.

4. Confirm — choices Apply / Cancel: "Apply this change?" On Cancel, discard and return.

5. Write atomically:

   • Read the current file, mutate only the targeted key, preserve all other content and formatting (do NOT rewrite the whole file from a template -- the user may have comments).
   • Write to a temp file in the same directory, then rename. On any error, do not touch the original.

6. Report the new value and a one-line "what this affects" hint (e.g., "applies to subsequent skill invocations").

Step 5: Guided Setup

• Selected from the top-level menu. Walk the user through these stages in order. Each stage uses the Edit sub-flow's validation rules. Defer the actual write to the end.

  Stage	Key	Notes
  1	preferences.interaction_language	Default en-US. Show allowed list
  2	preferences.document_output_language	Default = whatever was just set in stage 1; user may override. Reuse stage-1 value when user accepts default
  3	preferences.output.no_emojis	Default true
  4	preferences.output.data_format	Default yaml; allowed: yaml, json
  5	preferences.context_routing.relevance_threshold	Default 70; allowed: 0-100
  6	preferences.history_limits.*	Show each limit with current value; accept new int or Enter to keep
  7	preferences.planning.granularity	Default medium; allowed: coarse, medium, fine

• After all stages, render a Summary Preview table: key | from | to, then a single confirmation prompt to apply ALL changes atomically.

• If the user aborts at the summary, discard all in-progress values; do not write anything.

• After applying (or aborting), return to the top-level menu (Step 2).

Knowledge Inspection (sub-flow used by View All and Edit a Setting)

• View: list global knowledge ids from registry.yaml > knowledge._all and project-specific ids from knowledge.{projectName}, then per-skill knowledge ids grouped by skill (registry.yaml > skills.*.knowledge). Show token estimates from each entry's manifest if available.
• Modify: this skill does NOT mutate knowledge settings; defer to /mvt-manage-context. Print the suggested command (/mvt-manage-context move, /mvt-manage-context add, etc.) instead of doing the work here.

Edge Cases & Errors

Case	Handling
config.yaml missing	STOP; recommend mvtt install or /mvt-init
config.yaml exists but unparseable YAML	Surface error with line number; refuse to write; recommend manual fix or mvtt install --refresh
Editing a deprecated key (preferences.language)	Print migration hint: Run mvtt update --migrate-config to split into the two language fields. Do not mutate the deprecated key
Guided-setup stage receives an empty value	Treat as "accept default for this stage", continue
User aborts mid guided-setup	No partial write; the temp values are discarded
Concurrent edit detected (mtime changed during preview->write)	Abort write, surface a message, ask user to re-run
User asks to edit knowledge._all or any knowledge map key	Refuse and route to /mvt-manage-context; this skill inspects knowledge settings but does not mutate them

State Update

This skill is read-only and does NOT modify .ai-agents/workspace/session.yaml.

Suggested Next Steps

Recommend 2-3 relevant next skills based on the skill just completed (mvt-config) and the current project state. Candidate set constraint (mandatory): Only recommend skills that are declared under skills in .ai-agents/registry.yaml.

Conditional Recommendations

Match the current state to one of the conditions below. If none match, use default.

• configuration updated → /mvt-status -- Check project status with new settings
• language changed → /mvt-help -- Verify output in the new language

Format

• /{skill_name} -- {when to use this skill, tailored to the current context}

Do not suggest the skill that was just completed. Prioritize skills that logically follow from the work done.