Bug Reports Summary

1. Built-in skills do not appear in Web UI for binary installs

Summary
When GoClaw is installed as a standalone binary, built-in/core skills do not appear in the Skills page.

Expected
Built-in skills should be visible in UI after startup without requiring external skills/ directories.

Actual
Skills UI is empty.

Suspected cause
Startup/seed flow still depends on filesystem paths like bundled-skills, /app/bundled-skills, or skills, which may not exist in binary installs.

2. Docs claim bundled/embedded core skills, but runtime still depends on external directories

Summary
Docs describe core skills as bundled/embedded, but runtime behavior suggests they still depend on skill directories on disk.

Expected
Binary installs should not need external skill folders if core skills are truly bundled.

Actual
Binary installs can start with no visible core skills unless directories exist on disk.

Suspected cause
Loader/seeder still resolves skills from filesystem paths rather than a true embedded source.

3. Manifest deps: overrides auto-detected dependencies and causes required deps to disappear

Summary
Declaring deps: in SKILL.md replaces auto-detected dependencies instead of merging with them.

Expected
Explicit deps should either merge with auto-scan or produce a very obvious warning that they replace scan results.

Actual
Adding a short deps: list can make many detected dependencies disappear.

Suspected cause
deps: is treated as authoritative and overwrites scan-derived dependencies.

4. Skill dependency frontmatter parser silently drops unsupported YAML forms

Summary
Dependency frontmatter uses a narrow YAML subset, so some common formats can be ignored or dropped silently.

Expected
Common YAML should parse correctly, or invalid syntax should return a clear error.

Actual
Dependencies can disappear with weak or no diagnostics.

Examples

• deps: [a, b]
• nested maps
• malformed list syntax

5. Invalid dependency entries are dropped with insufficient diagnostics

Summary
Malformed dependency entries can be filtered out, making required deps appear missing.

Expected
Rejected dependency entries should surface clear validation errors in UI/API.

Actual
Entries can be dropped with insufficient feedback.

Examples

• pip:>=1.0
• pip:[binary]

6. Docs do not clearly warn that deps: replaces auto-scan results and only supports a narrow YAML subset

Summary
Current docs do not make the destructive behavior of deps: obvious enough.

Expected
Docs should clearly state that:

• deps: replaces auto-scan results
• only a limited YAML grammar is supported
• unsupported syntax may drop deps

Actual
Users can reasonably assume deps: is additive or that common YAML styles will work.

Suggested GitHub issue titles

1. Built-in skills do not appear in Web UI for binary installs
2. Docs claim bundled core skills, but runtime still depends on external skill directories
3. Manifest deps override auto-detected skill dependencies and cause required deps to disappear
4. Skill dependency frontmatter parser silently drops unsupported YAML forms
5. Invalid dependency entries are dropped with insufficient diagnostics
6. Docs do not clearly warn that deps replaces auto-scan results and supports only a narrow YAML subset

No files or tests are named. Separate the six reports into binary skill loading, the Skills UI, dependency scanning and frontmatter parsing, diagnostics, and documentation; then trace the startup/seed flow and parser entry points. Done means each behavior has a decided scope, reproducible coverage, clear diagnostics where needed, and matching documentation.