Skill-as-markdown: polymorphic frontmatter field on MarkdownDef#5244
Draft
lukemelia wants to merge 3 commits into
Draft
Skill-as-markdown: polymorphic frontmatter field on MarkdownDef#5244lukemelia wants to merge 3 commits into
lukemelia wants to merge 3 commits into
Conversation
Foundation for skill-as-markdown-frontmatter (CS-11545): every .md stays a MarkdownDef and skill-ness is a polymorphic field, not a SkillDef subclass. - Extract CommandField into its own module so SkillField can reuse it without depending on the legacy Skill card (skill.gts re-exports for back-compat). - FrontmatterField (base) + SkillField (name/description/commands) subclass. - frontmatter-kinds.ts: the kind -> FieldDef registry, kept above MarkdownDef. - Add `yaml` dep to @cardstack/base for frontmatter parsing. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
… field MarkdownDef now parses YAML frontmatter and, when `kind` maps to a known frontmatter subclass (e.g. `kind: skill` -> SkillField), populates the nested `frontmatter` field and records the concrete subclass so it rehydrates as that type. Flat `kind`/`description` are also written for search. Closes the FileDef write-path gap from the CS-11568 spike: extractAttributes routes per-field meta via a global symbol; the file extractor lifts it into the resource's `meta.fields` (keeping it out of the flat search_doc) and buildFileResource threads it through. Additive — FileDefs that emit no field meta are unchanged. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Covers parseFrontmatter, MarkdownDef.extractAttributes (flat kind + nested frontmatter + routed SkillField marker), the write->read round-trip rehydrating frontmatter as SkillField with commands, and plain-markdown no-op. Requires the host test-services stack / CI to run. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Contributor
Preview deploymentsHost Test Results 1 files 1 suites 1h 34m 55s ⏱️ Results for commit e0c8611. For more details on these errors, see this check. Realm Server Test Results 1 files 1 suites 10m 8s ⏱️ Results for commit e0c8611. For more details on these errors, see this check. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Implements the realm representation for skills as markdown (CS-11545): a skill is not a distinct file type. Every
.mdstays aMarkdownDef; skill-ness is a polymorphic frontmatter field, not aSkillDefsubclass.Design + rationale: Linear CS-11545. De-risking spike: CS-11568.
What this does
MarkdownDefgains@field frontmatter = contains(FrontmatterField).extractAttributesparses YAML frontmatter; akind → FieldDefregistry (kept aboveMarkdownDef) picks the concrete subclass —SkillField(name/description/commands) forkind: skill.meta.fields.frontmatter.adoptsFromand rehydrates as that type on read (field-level polymorphism).kind/descriptionare written tosearch_doc→searchFiles({ filter: { eq: { kind: 'skill' } } }). (nameisn't surfaced flat — it collides with the FileDef filename; it lives infrontmatter.name.)kind; Claude Code discovers them by theSKILL.mdfilename — independent, so one byte-for-byte file serves both.Closes the spike's write-path gap
The FileDef write path was flat (
buildFileResourceemitted only top-levelmeta.adoptsFrom).extractAttributesnow routes per-field meta via a global symbol; the file extractor lifts it into the resource'smeta.fields(kept out of the flatsearch_doc) andbuildFileResourcethreads it through. Additive — FileDefs that emit no field meta are unchanged.Notable
CommandFieldextracted into its own module soSkillFieldreuses it without depending on the legacySkillcard (skill.gtsre-exports for back-compat).yamlto@cardstack/base.Validation
Draft: opened to let CI run the build / type-check / tests — these were not runnable locally (needs the full host test-services stack). The half the spike couldn't exercise live — whether
meta.fieldssurvives the index storage→read bridge — is what the round-trip test (markdown-skill-frontmatter-test.gts) is here to confirm under CI.Not in this PR (remaining Phase B)
markdownDef.frontmatter.commands(spec §6).migrate-skillcommand + chooser/search surfacing.🤖 Generated with Claude Code