Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

release skill 4d: document the ledger's title, layout and required sections

Fermée Adaptée aux débutants
  • Quelque chose ne va pas ?
#5,343 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
2/5
Temps estimé
1-3 heures
Accessibilité débutants
78/100
Type d'issue
Documentation
Clarté
Clairement spécifiée
Activité
Active
Stack technique
typescript
Domaine
documentation

Piste de recherche

Modifie l’étape 4d, « The ledger », dans .claude/skills/release/SKILL.md. Lis la section existante ainsi que le titre, la mise en page, les sections requises, les colonnes du tableau, les pastilles d’état et les consignes concernant la deuxième PR de merge demandés dans l’issue ; assure-toi que chacun de ces éléments est spécifié et que les exigences existantes sont conservées. Le travail est terminé lorsque l’étape couvre tous les détails demandés et que npm run verify:skills réussit.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

documentation v2

Problem

Release skill step 4d (.claude/skills/release/SKILL.md, "The ledger") lists what a release ledger must contain: the masthead, verdict, gate cells, packaging table, what will publish, one table per theme, and findings. It says nothing about how the ledger is titled or laid out, or about building on the previous one. The v2.0.0, v2.1.0 and v2.2.0 ledgers share one design only because each was copied from the last by hand. The only record of that is a CSS comment in the page ("Same system as the v2.0.0 ledger"), and a session that doesn't know about it builds a different page.

The last two ledgers also carry sections step 4d doesn't ask for, which were the useful ones:

  • SDKs and Toolchain lines in the masthead: the MCP SDK versions locked, and the Node, uv, Inspector, Playwright, Docker and Claude Code versions used.
  • Preparation PRs: the audit (or its report, when no fix was forced), Version Packages and Prepare Python Release, each with what was checked.
  • Tool schemas against the previous release: each TypeScript server's tools/list (input and output schemas, annotations, descriptions) against the versions the previous release published, in both eras.
  • LLM client: one headless Claude Code run (--strict-mcp-config) calling one tool on each of the seven release-candidate builds.
  • Also shipping: advisory fixes: fixes that shipped through an advisory and not a milestone issue.

Proposal

Amend step 4d so that it:

  1. Titles the page Servers vX.Y.Z Release Ledger, for both the <title> and the <h1>.
  2. Starts from the previous release's ledger, which is linked from the latest published Release's notes ("Release ledger: …"). It reuses that page's stylesheet and section structure, changing content only. The skill links to the previous Release rather than naming an artifact URL, so it never holds a link that goes stale.
  3. Lists the five sections above as required, alongside the existing ones.
  4. Names the issue-table columns: Issue · Title · What was driven · Observed · Status. Each Issue cell is tagged client, web UI or probe, and each Status is a pill (PASS, or a named exception).
  5. Covers a second merge PR. When a fix lands after the first merge PR (v2.2.0 needed #5342 after #5338 for the certifi lockfile), the masthead names both merge PRs, and the page says which checks ran on which head and what differs between the two trees.

Done when

.claude/skills/release/SKILL.md step 4d says all of the above, and npm run verify:skills passes. The release skill is name-only (disable-model-invocation: true), so no eval cases change.

Langage dominant
TypeScript
Étoiles
91.6k
Forks
11.9k
Merge moyen
4 h 31 min
PR mergées (30 j)
236

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de modelcontextprotocol/servers

Toutes les issues de modelcontextprotocol/servers

Issues similaires

Plus d'issues TypeScript

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.