[BUG] (skills): unparseable SKILL.md frontmatter is listed but fails skill_view as backend_unhealthy #535

CompozyOS version

compozy 0.3.0-beta.22

Operating system

Linux (x86_64)

Area

Core / daemon, Extensions / MCP / skills, Workspaces

ACP agent

Claude Code

Model / provider

Not model-specific.

Steps to reproduce

1. In a workspace skills root, create <workspace>/.agents/skills/semantic-commit/SKILL.md whose description is an unquoted YAML scalar containing : (colon + space):

   ---
   name: semantic-commit
   description: Records what is already in the worktree: it never edits code.
   ---
   
   # Semantic Commit

   YAML reads worktree: it never edits code. as the start of a new mapping entry, so the frontmatter block fails to parse.

2. Let the daemon scan the workspace.

3. Observe that the skill is listed as an available skill named semantic-commit.

4. From a managed session, call compozy__skill_view with {"name": "semantic-commit"}.

What happened, and what did you expect?

What happened

The tool call fails with reason backend_unhealthy, so the agent reports something like "the native read of semantic-commit returned backend_unhealthy" and concludes the daemon is unhealthy. The real cause is a single malformed line of YAML in a skill file.

Three distinct problems combine here:

1. The list path and the read path disagree about whether the skill is valid.

The workspace scanner tolerates the parse failure and falls back to the directory name, so the skill is published to the catalog as if it were fine (internal/workspace/scanner.go:316-330):

skillName, err := loadWorkspaceSkillName(skillFile)
if err != nil {
    skillName = filepath.Base(skillDir)
    slog.Warn("workspace: falling back to skill directory name", ...)
}

compozy__skill_view then re-parses the same file for real and fails hard — skillView (internal/daemon/native_tool_registry_skills.go:127) → Registry.LoadContent (internal/skills/registry.go:202) → ReadSkillContent (internal/skills/loader.go:82) → parseSkillContent (internal/skills/loader_declarations.go:17).

The result is a skill an agent can select but can never read.

2. The failure reason names the wrong subsystem.

LoadContent returns a plain error, and any untyped error coming out of a native tool backend is bucketed into ErrorCodeBackendFailed / ReasonBackendUnhealthy (internal/tools/dispatch_errors.go:29-42, 67-88). A user-authored YAML typo is therefore reported to the agent as backend ill health, which sends both the agent and the operator debugging the daemon instead of the file.

3. The warning is emitted per scan, not per file version.

In a single daemon run, this one file produced 146,661 identical WARN lines in 47 minutes — the file is re-parsed on every scan and the same failure is logged every time, with no dedup or backoff.

What I expected

• A skill whose frontmatter does not parse is either withheld from the catalog or surfaced with an explicit broken/degraded status, so list and read agree.
• compozy__skill_view fails with a reason that names the real cause (invalid frontmatter, plus the file path and YAML line), not backend_unhealthy.
• The parse failure is logged once per file version, not once per scan.

Logs

# ~/.compozy/logs/compozy-2026-09-02T01-38-04.135.log — 146,661 occurrences between 22:10 and 22:57
2026/09/01 22:10:57 WARN workspace: falling back to skill directory name \
  path=/…/.agents/skills/semantic-commit/SKILL.md \
  name=semantic-commit \
  error="workspace: decode skill identity \"/…/.agents/skills/semantic-commit/SKILL.md\": yaml: line 2: mapping values are not allowed in this context"

# Read path, reproduced against internal/skills with the SKILL.md above:
ReadSkillContent err = skills: parse "…/semantic-commit/SKILL.md": decode YAML frontmatter: \
  yaml: line 2: mapping values are not allowed in this context
ReadSkillContent content = ""

Final checks

• I searched existing issues and this is not a duplicate.
• I can reproduce this on the latest release.