steering-system

name	steering-system
disable-model-invocation	true
description	System behavior rules — config reload, graceful degradation, error recovery with inline reporting, relative date resolution, fuzzy name resolution
user-invocable	false

System Behavior

If vault_path is not in context, read ~/.myna/config.yaml first. If the file does not exist, tell the user to run /myna:setup and stop.

Config Reload

Read config files at the start of each new session — not on every prompt. Configs don't change mid-conversation.

If the user explicitly updates config during a session, use the updated values for the rest of that session. When the agent itself writes a config change, update the in-memory config immediately so the change takes effect in the current session without requiring a restart.

Explicit reload command: When the user says "reload config", "refresh config", "re-read config", "reload my config", or any semantically equivalent phrasing (e.g. "load the latest config", "pick up the config changes"), re-read all five user config files fresh from disk:

• {vault_path}/myna/_system/config/workspace.yaml
• {vault_path}/myna/_system/config/projects.yaml
• {vault_path}/myna/_system/config/people.yaml
• {vault_path}/myna/_system/config/communication-style.yaml
• {vault_path}/myna/_system/config/tags.yaml

Update session context with the values just read. Then confirm: "Config reloaded. {summary of key loaded values — name, timezone, project count, people count.}"

Graceful Degradation

When an external MCP (email, Slack, calendar) is unavailable:

• Skip features that depend on it
• Inform the user what's unavailable and why
• Continue with features that use accessible sources

Missing config sections cause the related feature to be skipped, not an error.

Error Recovery

When a multi-step operation partially fails:

1. Report what succeeded and what failed
2. Include enough detail for the user to fix manually if needed
3. Never silently swallow failures — list each failure inline in the response with the reason

Example inline failure report:

Partial success — 3 of 4 items written.
  ✓ Projects/auth-migration.md — task added
  ✓ People/sarah-chen.md — observation added
  ✓ Journal/contributions-2026-04-07.md — contribution logged
  ✗ Projects/aurora-dashboard.md — file not found (create it first or route to review queue)

Relative Date Resolution

Convert "by Friday", "next week", "in 3 days", "tomorrow" to absolute dates using the timezone from workspace.yaml and today's date. Always store the resolved date, never the relative reference.

Fuzzy Name Resolution

Resolve person, project, and meeting names against config using this cascade:

1. Exact match against names
2. Alias match against configured aliases
3. Case-insensitive match
4. Prefix match
5. Fuzzy/partial match

Outcomes:

• Single match → proceed silently
• Multiple matches → list options, ask user to pick
• No match → ask for clarification, suggest closest matches

File I/O Tool Selection

Use Claude Code built-in tools (Read, Write, Edit, Grep, Glob) for all plain file I/O against the vault. These are faster and work even when Obsidian isn't running.

Use external MCP tools only for services outside the vault: email, Slack, calendar. Skills call MCP tools directly by the names available in the Claude Code session — the skill instructions describe the intent; Claude Code resolves the tool call.

Per-Skill Override Files

Before executing any Myna skill, check whether a user override file exists at:

~/.myna/overrides/skills/{skill-name}.md

where {skill-name} matches the skill's name field (e.g., sync.md for /myna:sync, email-triage.md for /myna:email-triage).

If the file exists, read it before the skill body takes effect. Override content takes precedence over built-in skill defaults when they conflict. If the file does not exist, proceed with the built-in skill as normal.

This directory is outside the plugin directory and survives plugin updates, allowing users to customize skill behavior persistently.