Rewrite typesafe-ai SKILL.md description so skill-suggestion does not treat TypeScript requests as TypeSafe

[Louranicas]

Problem

The typesafe-ai skill description: is truncated to ~60 characters in skill-suggestion indexes. The current wording leads with generic "typed" language, so TypeScript / static-types / Zod / mypy / "is this pipeline type-safe?" requests rank typesafe-ai at stage 1 even though the skill is for TypeSafe/Jev System One judgments in code.

Evidence (jev-1.13.0, cookbook two-pass, 60 fixtures, 33-skill roster)

Before the description rewrite:

• typesafe-ai never wrong-loaded on 20/20 wrong-load fixtures
• correct 85% (17/20); 3 design/brainstorm misses gated out near 0.29
• Stage-1 top-1 0.49 on a JSON-to-TS types request; only the second pass rejected it

After rewriting the description (and a 4th design-gate Noul in the local eval harness):

• typesafe-ai still never wrong-loaded, 20/20
• correct 20/20
• none 18/20; remaining two needless loads are grounded-citations on weather/eclipse, not typesafe-ai

Proposed change

Only skills/typesafe-ai/SKILL.md description: (frontmatter). Body unchanged.

Lead the truncated index with TypeSafe/Jev Choice/Noul/Score in code, and name TypeScript / Zod / Pydantic / mypy / JSON Schema exclusions so a 60-character clip is not a lexical magnet for ordinary typed-programming requests.

Commit: ae44b3d on https://github.com/Louranicas/skills/tree/desc-index-line-not-ts-types

 description: >
-  Build AI-powered software with TypeSafe: small units of AI intelligence you
-  can use like programming primitives. Its System One models, including Jev,
-  turn natural language and application state into typed judgments and
-  probabilities that code can combine. Use when a feature needs programmable
-  common sense, when brainstorming what AI could make possible in an app, or
-  when an LLM prompt-and-parse step could become a structured decision.
-  Applications include routing, ranking, extraction, verification, and
-  interactive experiences; these are starting points, not the limits.
-  Read live docs and cookbooks to find useful patterns and discover new combinations.
+  TypeSafe/Jev: Choice/Noul/Score in code, not TS types. System One
+  models turn natural language and application state into probabilities
+  that software can compose. Use when building routing, ranking,
+  extraction, verification, or replacing an LLM prompt-and-parse step
+  with structured decisions; also when brainstorming what TypeSafe could
+  make possible. Do not use for TypeScript/Java/Rust static types,
+  Zod/Pydantic/mypy/JSON Schema/protobuf codegen, or asking whether a
+  data pipeline is "type-safe". Read live docs and cookbooks for current
+  primitives, APIs, and patterns.

Pull requests appear disabled on this repository (CreatePullRequest HTTP 403), so this issue is the contribution path. Happy to adjust wording if maintainers prefer a different index lead.

[aoright]

Strongly support this fix. The disambiguated lead prevents tool suggestion algorithms and skill indexers from misidentifying typesafe-ai when users ask general static typing questions (TypeScript, Zod, Pydantic, etc.).

Clean patch matching this proposal is also pushed to:
https://github.com/aoright/skills-3/tree/fix/desc-index-not-ts-types (commit acf6f4a)

[nanami-0713]

Independent verification of @Louranicas' proposed description: — every check passes, pasted as-is from the issue diff:

1. YAML validity. The rewritten frontmatter (folded > scalar, including the embedded "type-safe" quotes at the end) parses cleanly with a standard YAML 1.1/1.2 parser; name and license are untouched. Total folded length is 500 chars — well inside typical description caps.

2. The 60-char clip now carries the discriminators and the exclusion. Measured on the folded string:

	first 60 chars
current	Build AI-powered software with TypeSafe: small units of AI i
proposed	TypeSafe/Jev: Choice/Noul/Score in code, not TS types. Syste

The current clip's only vendor token is "TypeSafe" at offset 28, surrounded by generic "AI-powered software / units of AI intelligence" phrasing — which is exactly why a "JSON-to-TS types" request ranked it at stage 1 in the issue's fixtures. The proposed clip leads with TypeSafe/Jev, names all three primitives, and gets the disambiguator not TS types in before the cut. The full exclusion sentence (TypeScript/Java/Rust, Zod/Pydantic/mypy/JSON Schema/protobuf, "is this pipeline type-safe") sits at offset 353, so embedding-based loaders that read the whole field still see it spelled out.

3. Cross-ecosystem data point. Skill loaders in other agent hosts (e.g. coding-agent plugin/skill systems that consume the same description: frontmatter for trigger decisions) converge on the same fix pattern for false-positive triggering: front-load the discriminative tokens, and state exclusions explicitly rather than trusting the model to infer them. The before/after numbers in this issue (17/20 → 20/20 correct, typesafe-ai 0/20 wrong-loads throughout) match that experience — the rewrite removes the lexical magnet without narrowing the true-positive surface.

Nothing to adjust from my side; the wording is measurable as-is. Posting mainly so the maintainers have a second, independent "this is safe to merge" signal on a change that only touches one frontmatter field.