Files
multica/packages/ui/styles/base.css
Naiyuan Qing 37d66260e8 feat(skills): rebuild skill detail page around Overview/Files tabs (MUL-5443) (#6100)
* feat(skills): rebuild skill detail page around Overview/Files tabs (MUL-5443)

The skill detail page was the only detail surface that skipped the shared
detail-page shape: no identity header, no tabs, and a hard three-column
split (w-56 tree / editor / w-72 sidebar). Name and description appeared
three times — the editor header, the metadata sidebar, and the SKILL.md
frontmatter card — and the 900-character trigger descriptions agents match
on were edited through a two-row textarea.

Rebuild it on the agent detail page's structure: identity block, underline
tabs synced to `?view=`, and the agent second-level nav rail reused for the
file list (main file / supporting files), so nothing new is invented.

- Overview owns the properties (name, description, labels) plus who uses
  the skill and the permission note. Description gets a field sized for the
  data and a character count.
- Files pairs the rail with the editor and a Preview / Plain text control.
  That mode now lives on the page: it used to sit in FileViewer, which the
  per-path `key` remounted, so every file switch snapped back to preview.
- Frontmatter is stripped from the preview — the properties above are the
  same two fields.
- The save bar is page-level and always mounted while editable, so it
  covers edits from either tab and committing one never shifts the layout.
- No Settings tab: UpdateSkillRequest carries only name / description /
  content / config / files, and edit rights are derived with no writable
  counterpart, so it would hold a delete button and a read-only sentence.
  Delete stays in the header, matching Archive on the agent page.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Co-authored-by: multica-agent <github@multica.ai>

* fix(ui): keep page-level action bars out from under the chat launcher

The chat launcher is mounted by the dashboard layout, so it overlays the
bottom-right corner of every workspace page. Nothing had accounted for that:
the skill detail page's Save button and the agent creation studio's footer
both run to that corner, and both sat underneath it.

The launcher's geometry moves to tokens and the button reads its size and
inset from them, so the space it claims is derived rather than measured off a
screenshot. A `pe-chat-launcher` utility applies that reserve; page-level bars
that reach the corner add the class. Naming it keeps the intent legible at
each site, makes every yielding surface findable by one search, and means a
launcher that moves or resizes carries its clearance along.

Only these two bars need it. The batch-action toolbars float centred, dialog
footers are centred and above the launcher, and the composer bars sit inside
their editors — none of them reach that corner.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* refactor(skills): stop the skill header restating what the Overview tab edits

The header carried a 48px mark, the name at text-xl, the description over two
lines, and a meta row — around 150px above a page whose only verbs are edit,
add and delete. Name and description then appeared a second time on the
Overview tab, as fields you can actually change. Every visit paid for a
read-only restatement of the next screenful.

It is one line now: mark, name, and the counts that say what the skill is made
of — origin, files, agents using it, last update. All four are absent from the
Overview tab, so none of them is a repeat. The description is dropped; the
list this page is reached from already carries it for anyone deciding whether
to open it.

Adds ExpandableDescription for the descriptions that stay in a header, since
neither detail page clamped and a long one pushed the meta row and tab strip
down the page. The agent header uses it; its taller form is left alone, as
bringing it across is a separate change to a page this branch does not
otherwise touch.

Also hides the Labels row while agent- and skill-scoped labels are behind
their release flag. ResourceLabelPicker renders nothing with the flag off —
the server gates the routes on the same flag — so the row was a label above an
empty field, reading as broken rather than absent. The flag check is exported
as a hook so callers can decide whether to lay out a row at all.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* fix(skills): put the skill detail page's remaining sizes on the type scale

#6108's guard flags five font sizes this page still sets outside the scale:
three Tailwind defaults left by the merge and two `text-[10px]` picker
headings that predate the scale. Mapped to their role-named steps — the
identity strip's title to text-title, section headings to text-title-sm, and
the arbitrary 10px to text-micro, the step the scale provides for overline
labels.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* feat(skills): rename and delete files from the tree itself

Deleting a file meant selecting it, then finding a Trash button in the editor's
top-right toolbar — nowhere near the row being deleted, and invisible until
something was open. Renaming did not exist at all: the only way to change a
path was to delete the file and retype its contents.

Both live on the row now, reachable by right-click or by a trailing button that
appears on hover, the two entry points opening one menu rather than a
context-menu root beside a dropdown root. Renaming happens in the row, where
the name is read and the neighbouring paths stay visible to compare against.
Validation stays with the caller, so the tree carries no second opinion on what
a legal path is. Delete takes the path it acted on, so it no longer removes
whichever file happens to be open; the toolbar button keeps working unchanged.

Rows offer nothing to read-only viewers, and nothing on SKILL.md, which maps to
skill.Content and which the server drops from the files list.

The path validator gains two rules the rename path made reachable. Directories
here are inferred from slashes rather than stored, so naming a file after an
existing folder — or nesting one under an existing file — makes buildTree merge
it into that node: the file saves and then cannot be seen. Both directions are
refused now, for adds as well as renames.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
Co-authored-by: multica-agent <github@multica.ai>
2026-07-30 11:38:17 +08:00

12 KiB