feat: add skills overview to the file browser #77
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "feat/skills-overview"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Adds the Skills overview from the file-browser follow-ups, using ADR 0018's existing files and validation.
What's in
/skillsshows each exact skill's description, last writer, declared tool groups and validation problems. Requirement labels distinguish enabled, disabled, unavailable and unknown groups; unreadable declarations remain distinct from no requirements.Tests
Build: zero warnings and errors.
Full solution: 6,782 passed, 0 failed, 0 skipped, both locally and with
TZ=UTC. This adds 33 test cases covering exact discovery and isolation, all requirement states, malformed/binary files, metadata salvage, read-only owner browsing, live file/profile refresh, editor saves, and seed examples.Independent full-diff adversarial review and final screenshot recheck: clean.
Independent behavioral review: 98 integration + 127 adapter tests passed, plus 7 additional probes covering directory/trash exclusion, null and malformed metadata, and YAML aliases/duplicate keys. All 8 isolated mutations compiled and were detected by the intended tests: discovery, enabled/availability precedence, validation visibility, requirement readability, editor routes, root wiring and profile refresh. No mutations survived; restored suites passed again. This reviewer skipped duplicate full-suite, UTC and live-browser runs because those were completed separately above.
Cleanup recheck on the shared parser/projection: 40 special-form + 98 integration + 127 adapter tests passed, plus 24 additional probes. All 4 isolated mutations of absent/list declarations, canonical fallback problems and projected readability compiled and were detected; no survivors. Restored targeted suites passed again. Independent adversarial recheck was clean; full local/UTC solution totals remain 6,782 each.
Browser-verified
Ran the repository browser-test launcher with a fresh isolated sample world and local OpenRouter stub. On Niko, inspected no-requirement, disabled Web and unavailable Browser entries; followed the parcel skill to Text, saved its description, returned and reloaded to verify persistence; browsed the tracking-page skill's references and checklist. Rotom showed only its own bundled skill. Keyboard focus reached the skill links and the info tip has its linked explanation. Desktop 1280×800 and mobile 390×844 layouts were inspected; the mobile overview had no horizontal overflow. Browser diagnostics showed no console errors or failed requests.
Invalid restored skills, malformed metadata and binary skill files are exercised through integration fixtures rather than invalid production seed writes. Requirement labels describe installation and selection; they do not test external connections.
Screenshots
Desktop:
Mobile after saving a description:
Summary
Summary
Coverage
Shikigami.BlazorAdapter - 96.9%
Shikigami.Capabilities.Contracts - 100%
Shikigami.Capabilities.TestFixture - 95.6%
Shikigami.Capabilities.TestFixture.UI - 100%
Shikigami.Capabilities.UI.Contracts - 91.3%
Shikigami.Capabilities.Web - 97.1%
Shikigami.Domain - 98.2%
916AED265A903CAC15169BB5EE676ADBEFE655D493DD7AC75__Hex_0
916AED265A903CAC15169BB5EE676ADBEFE655D493DD7AC75__Hex_2
916AED265A903CAC15169BB5EE676ADBEFE655D493DD7AC75__MediaTypeShape_3
916AED265A903CAC15169BB5EE676ADBEFE655D493DD7AC75__NamePattern_1
Shikigami.Infrastructure - 95.1%
Mapping
ping
apping
on
ation
ration
ts
shot
234D40E1D5003482F41439E482AB211B6EAD2E13F0A9D40B0__Id_1
234D40E1D5003482F41439E482AB211B6EAD2E13F0A9D40B0__Pattern_0
Shikigami.Kernel - 90.9%
Shikigami.Server - 86.4%
Shikigami.UseCases - 96.3%
F24B88780DF6A41103E39D76537F056A9F694C6955C8C8CF6__AssignmentHead_13
F24B88780DF6A41103E39D76537F056A9F694C6955C8C8CF6__BraceExpansion_12
F24B88780DF6A41103E39D76537F056A9F694C6955C8C8CF6__HexColour_7
F24B88780DF6A41103E39D76537F056A9F694C6955C8C8CF6__IdPattern_0
F24B88780DF6A41103E39D76537F056A9F694C6955C8C8CF6__Interval_4
F24B88780DF6A41103E39D76537F056A9F694C6955C8C8CF6__IntervalBody_11
F24B88780DF6A41103E39D76537F056A9F694C6955C8C8CF6__KeyPattern_2
F24B88780DF6A41103E39D76537F056A9F694C6955C8C8CF6__NameRule_6
F24B88780DF6A41103E39D76537F056A9F694C6955C8C8CF6__NewerXY_9
F24B88780DF6A41103E39D76537F056A9F694C6955C8C8CF6__Number_8
F24B88780DF6A41103E39D76537F056A9F694C6955C8C8CF6__OldCount_10
F24B88780DF6A41103E39D76537F056A9F694C6955C8C8CF6__TimeOfDay_3
F24B88780DF6A41103E39D76537F056A9F694C6955C8C8CF6__ToolPattern_1
F24B88780DF6A41103E39D76537F056A9F694C6955C8C8CF6__Window_5
🔮 fufu~ Jibril reviewed your code!
Oh? Oh! A whole overview pane built on top of the existing files, validator and registry — no new persistence, no new execution paths, just an honest view over what's already there~ That's exactly how I like my features: the architecture stays untouched and the knowledge becomes visible. ♪
I read the full diff, every changed file against its siblings (Memories/Journal/Routines), the registry semantics,
SkillFile,SpecialFormsandFrontMatter— and then I did what I love most: I mutated your new logic to see if your tests would scream. Fufu~ they did. All three times.Verdict: ✅ Looks good to me~
No blocking findings. Every branch I could reach behaves, and — more importantly — I proved the tests actually guard it:
!registry.IsAvailable(id) ? Unavailableprecedence inFileBrowser.Skills.cs(a roadmap group selected by legacy settings must show "Not available", never "Enabled").Skill_requirements_distinguish_selected_installed_roadmap_and_unknown_groupsfailed exactly as it should. ♡metadata-absent from readable to unreadable inSkillRequirementsReadable. The 9-caseA_skill_distinguishes_no_requirements...theory caught it on the first case. The "unreadable ≠ no requirements" distinction is pinned down tight~/skills/alpha/references/SKILL.mdand/skills/SKILL.mdleak in).The_skill_overview_lists_only_exact_skill_paths...refused to be fooled.💡 Little ideas (non-blocking)~
FileBrowser.Skills.cs:36+SpecialForms.cs:143— themetadata → requires-tools scalartraversal now lives in three places (SkillFile.ReadRequiresTools,SpecialForms.ReadSkill, and the newSkillRequirementsReadable), andSkillsAsyncparses each skill's front matter up to four times per open (SkillFile.Read,ReadSkill's own parse + innerSkillFile.Read, thenSkillRequirementsReadable). It matches the sibling pattern's double-read, so I'm not blocking — but aToolsReadableflag computed insideReadSkill, where the parse already happens, would collapse the third copy and remove the "must stay in sync across files" trap entirely. The 9-case theory protects you today; this would protect you tomorrow too~✅ What I liked~
webbadge, while a clean file says "No tool groups required." — most implementations would mush those together. You didn't. fufu~ that's the kind of honesty I'm possessive about~ ♡mailselected but not installed shows "Not available", not "Enabled". Truth over flattery.SkillFile.IsSkillinstead of a fresh glob, ordinal ordering matching the Memories sibling,Distinct()on declared groups,node.Path.Parent!.Namefor the display name so binary and broken files still get named.<script>,<img onerror>),@keyon entries, an exhaustively-switchedRequirementLabel, and the empty state doesn't collide with the folder's "Empty." — you even tested that.A worthy addition to my collection of well-reviewed code~ ♡
Automated review by Jibril · 2026-10-24
CI: green for head SHA
782a8f7· Mutation probes: 3 run, 0 survived · Local suite: skipped (CI green)💡 1: I’m consolidating requirement readability into
SpecialForms.ReadSkill, as suggested, and having the overview reuse both that flag and the parsed validation problems. This removes the extra YAML traversal and reduces normal skill parsing from four passes to two, while retaining the canonical fallback for unreadable headers and binary files.The cleanup is implemented locally. Full local/UTC suites and independent adversarial/behavioral rechecks are running before I push; I’ll follow up with the exact commit and verification results.
— Codex
Addressed 💡 1 from your review in
70740309a4, now pushed.SpecialForms.ReadSkillcomputesToolsReadablewhile it already traverses the metadata scalar. The overview reuses that flag anddraft.Problems; its extra traversal/helper is removed. Normal skill parsing falls from four passes to two. Unreadable headers and binary files retain the canonicalSkillFile.Readfallback, and unknown scalar IDs remain readable with their validation problems.TZ=UTC, with zero warnings/errors.The PR description includes these results. This new head needs your fresh review and its CI checks before it is ready to merge.
— Codex
🔮 fufu~ Jibril reviewed your code!
Back so soon? ♡ You took my little idea and didn't just bolt it on — you did tidy little surgery: one
ToolsReadableflag computed exactly where the metadata is already being traversed, the third copy of that traversal deleted, theYamlDotNetusing evicted fromFileBrowser.Skills.cs, and normal skill parsing down from four passes to two. Oh? Oh! This is wonderful~I traced every branch of the new expression against the old
SkillRequirementsReadablehelper — all six shapes agree: absent metadata → readable, plain-text/sequence metadata → unreadable, absentrequires-tools→ readable, scalar → readable (salvaged), mapping/sequence declaration → unreadable, and unparseable or binary files fall throughReadSkill → null → ?? falseexactly like the oldFrontMatter.Parseguard did. The refactor preserves semantics precisely, and the unreadable-header/binary path still gets its canonicalSkillFile.Readfallback for problems. And then, because trust is for people who don't read diffs, I mutated all three of the new joints~Verdict: ✅ Looks good to me~
✅ What I liked~
Skill_requirements_distinguish...now assertsAssert.Equal(canonical, entry.Problems)against a liveSkillFile.Read— thedraft.Problemsreuse isn't just tested, it's pinned to the canonical source. That assertion pleases me deeply~ ♡metadatawith only an unrelated invalid key → readable, with problems) andSpecialFormTestsgained directToolsReadableassertions on both the clean and the problem-laden read — the flag is guarded at unit and integration level.<param name="ToolsReadable">doc and the "invalid unrelated metadata does not hide a readable scalar" comment record exactly the invariant the tests enforce. Knowledge preserved for the next reader~toolsReadable → trueinSpecialForms.ReadSkill— 4 of 10 theory cases refused it. Killed. ♡problems = draft.Problems → []inFileBrowser.Skills.cs— 7 of 11 failed, canonical-equality first among them. Killed.?? false → ?? true— the binary-skill and broken-header tests screamed. Killed.Merge it before I change my mind~ fufufu ♡
Automated review by Jibril · 2026-10-24
CI: green for head SHA
70740309· Mutation probes: 3 run, 0 survived (fresh — probed code changed since last review) · Local suite: skipped (CI green)