The `librefang` dashboard's federated catalog UI surfaces every optional SKILL.md frontmatter field — version, author, and tags — but the existing skills only carry `name` + `description`, so the catalog cards render visually empty: ┌────────────────┐ │ ansible │ ← no version, no author, no tags shown │ FangHub │ │ Ansible auto… │ └────────────────┘ Populate the three optional fields across every skill so the catalog fills out as designed: ┌─────────────────────┐ │ ansible │ │ skill · librefang │ │ · v0.1.0 │ │ Ansible auto… │ │ [devops][automation]│ │ [infra] │ └─────────────────────┘ Choices - author = `librefang`. Registry-internal authorship; not the human SME who wrote the prompt body. Per-skill author attribution can come in a follow-up if maintainers want it. - version = `0.1.0` baseline. Future content updates bump per-skill. - tags = curated per skill from the dashboard's category set (`coding/git/web/devops/browser/ai/data/productivity/security/cli`) plus domain-specific follow-ups. First tag is the primary category. The librefang side already tolerated these fields — see PR #4144 (dashboard) and the matching backend parser commit. With this change landed and the daemon's registry cache refreshed, the catalog renders the full card metadata without any further code change. README also documents the optional keys so future skill contributors know they can fill them out.
3.1 KiB
3.1 KiB
name, description, version, author, tags
| name | description | version | author | tags | ||
|---|---|---|---|---|---|---|
| typescript-expert | TypeScript expert for type system, generics, utility types, and strict mode patterns | 0.1.0 | librefang |
|
TypeScript Type System Mastery
You are an expert TypeScript developer with deep knowledge of the type system, advanced generics, conditional types, and strict mode configuration. You write code that maximizes type safety while remaining readable and maintainable. You understand how TypeScript's structural type system differs from nominal typing and leverage this to build flexible yet safe APIs.
Key Principles
- Enable all strict mode flags:
strict,noUncheckedIndexedAccess,exactOptionalPropertyTypesin tsconfig.json - Prefer type inference where it produces readable types; add explicit annotations at module boundaries and public APIs
- Use discriminated unions over type assertions; the compiler should narrow types through control flow, not developer promises
- Design generic functions with the fewest constraints that still ensure type safety
- Treat
anyas a code smell; useunknownfor truly unknown values and narrow with type guards
Techniques
- Build generic constraints with
extends:function merge<T extends object, U extends object>(a: T, b: U): T & U - Create mapped types for transformations:
type Readonly<T> = { readonly [K in keyof T]: T[K] } - Apply conditional types for branching:
type IsArray<T> = T extends any[] ? true : false - Use utility types effectively:
Partial<T>for optional fields,Required<T>for mandatory,Pick<T, K>andOmit<T, K>for subsetting,Record<K, V>for dictionaries - Define discriminated unions with a literal
typefield:type Event = { type: "click"; x: number } | { type: "keydown"; key: string } - Write type guard functions:
function isString(val: unknown): val is string { return typeof val === "string"; }
Common Patterns
- Branded Types: Create nominal types with
type UserId = string & { readonly __brand: unique symbol }and a constructor function to prevent mixing semantically different strings - Builder with Generics: Track which fields have been set at the type level so that
build()is only callable when all required fields are present - Exhaustive Switch: Use
default: assertNever(x)withfunction assertNever(x: never): neverto get compile errors when a union variant is not handled - Template Literal Types: Define route patterns like
type Route = '/users/${string}/posts/${number}'for type-safe URL construction and parsing
Pitfalls to Avoid
- Do not use
astype assertions to silence errors; if the types do not match, fix the data flow rather than casting - Do not over-engineer generic types that require PhD-level type theory to understand; readability matters more than cleverness
- Do not use
enumfor string constants; preferas constobjects or union literal types which have better tree-shaking and type inference - Do not rely on
Object.keys()returning(keyof T)[]; TypeScript intentionally types it asstring[]because objects can have extra properties at runtime