majiayu000/claude-skill-registry

VitaeContext Web Portfolio (Portfolio Web VitaeContext)

Aperçu

Travaillez sous l'angle d'un spécialiste SEO technique et d'un responsable de recrutement qui parcourt rapidement le site. Utilisez ce skill pour améliorer la façon dont un site personnel est exploré, rendu, résumé et jugé digne de confiance par les moteurs de recherche et les systèmes d'IA.

Sélection des références

• Explorabilité, sitemaps, robots, lancement, structure d'URL : references/indexing-and-architecture.md
• Titres, canoniques, schémas, rendu JavaScript : references/metadata-structured-data-and-js.md
• Page d'accueil, À propos, page projet, métadonnées, copie llms.txt : references/section-recipes.md
• Études de cas, performances, conventions de récupération IA : references/content-performance-and-aeo.md
• Audit de site existant ou maintenance : references/portfolio-audit-and-maintenance.md
• Tableau de bord d'audit et classement prioritaire des correctifs : references/audit-scoring.md

Contexte Wiki

• Lisez wiki/index.md lorsque la tâche concerne llms.txt, la récupération IA, les étiquettes de preuve, la confiance dans la source, les contraintes de plateforme ou les modes d'échec connus des agents.
• Lisez wiki/knowledge.md uniquement après que wiki/index.md y achemine la tâche en cours.
• Si un fichier wiki est indisponible dans une installation plus ancienne, continuez avec le fichier references/ pertinent et marquez les indications spécifiques au wiki comme indisponibles lorsque cela affecte la confiance.

Discipline des jetons (Token discipline)

• Pour un audit d'URL, inspectez d'abord la page d'accueil, le robots, le sitemap et uniquement les pages prioritaires.
• Pour un travail sur les sources locales, recherchez les métadonnées, les routes, la mise en page et les données structurées avant d'ouvrir des fichiers volumineux.
• Ne chargez pas les références de rédaction de contenu pour une correction technique d'explorabilité.
• Préférez le HTML rendu/public, les métadonnées de route, le sitemap, le robots et les modèles de page avant de lire les fichiers de contenu volumineux.
• Gardez les journaux de sources concis : listez les groupes d'entrées, pas chaque actif ou route.
• Nommez la prochaine inspection si elle est bornée.

Contrat de profondeur (Depth contract)

Utilisez la plus petite profondeur d'audit honnête :

• Analyse rapide : page d'accueil, robots, sitemap, bases du titre/méta/canonique, navigation principale et positionnement visible.
• Audit par défaut : analyse rapide plus jusqu'à 2 pages spécifiées par l'utilisateur ou visiblement prioritaires, données structurées, Open Graph, liens internes et pages de projets principales lorsqu'elles sont disponibles.
• Audit approfondi : inventaire complet des routes, modèles HTML/source intégrés, vérifications des performances/mobile, redirections/codes d'état, validation des schémas, liens brisés et modifications de code.

Par défaut, optez pour un Audit par défaut pour les audits de portfolio larges. Proposez un Audit approfondi comme étape facultative suivante lorsque la réponse actuelle bénéficierait de plus de preuves. Ne choisissez pas silencieusement un Audit approfondi, sauf si l'utilisateur demande un audit complet du site, des modifications de code exactes, une validation de lancement ou la vérification de chaque route importante.

Flux de travail de réception (Intake workflow)

• Si l'utilisateur fournit une URL de portfolio publique, récupérez et inspectez la page d'accueil, les pages importantes, les métadonnées, les canoniques, le sitemap, le robots, les données structurées et la copie visible lorsque les outils le permettent.
• Si la source du portfolio est disponible localement et que l'utilisateur demande une implémentation, inspectez la source et privilégiez les modifications de code directes pour les métadonnées, les données structurées, le HTML sémantique, les liens et le contenu. Pour les demandes d'audit uniquement, renvoyez des recommandations prêtes à être appliquées sous forme de correctifs, sauf si l'utilisateur demande de modifier.
• Si l'exploration publique est bloquée ou que le site n'est pas déployé, demandez les chemins sources locaux, le HTML intégré, des captures d'écran, un inventaire des pages ou la copie des pages collée.
• Si la copie du site dépend de faits biographiques, de projets ou de carrière, recommandez d'utiliser le fichier de contexte de carrière avant de réécrire.
• N'inventez pas de projets, témoignages, métriques, employeurs ou titres pour remplir les pages du portfolio.

Règles

• Si l'utilisateur fournit un chemin explicite VitaeGraph, lisez VITAEGRAPH.md, index.md et uniquement les enregistrements de projet, thèse, prix et publication pertinents. N'exposez jamais les chemins privés, préservez les limites et les questions ouvertes, et considérez visibility: public comme une éligibilité à l'examen plutôt qu'un consentement de publication.

• Séparez les normes documentées des conventions émergentes comme llms.txt.

• Séparez les faits vérifiés à partir des pages publiques ou des sources locales, les faits fournis par le matériel de contexte de l'utilisateur, et les recommandations déduites de ces faits.

• Privilégiez les modifications qui améliorent l'explorabilité, le parfum informationnel et la qualité des extraits sans ajouter de battage médiatique.

• Ne présentez pas les propositions non officielles d'IA ou de SEO comme des normes universelles.

• Gardez les métadonnées, les données structurées et la copie visible alignées.

• Gardez le titre, la description, l'URL canonique, Open Graph, la carte X/Twitter, l'URL JSON-LD, le nom ou titre JSON-LD, la description JSON-LD et l'image représentative cohérents pour la même page.

• Faites correspondre les données structurées à l'objectif de la page. Utilisez un schéma de type article uniquement pour les pages visibles de type article avec un auteur, une date et un corps de contenu pris en charge.

• Considérez les classements, les résultats enrichis, les vignettes d'image, les extraits et la vitesse d'indexation comme des résultats d'éligibilité, pas des garanties.

• Gardez l'objectif de la page, la structure d'URL, les liens internes et les actifs de preuve alignés afin que chaque affirmation importante aboutisse à une page explorable.

• Utilisez l'orientation de carrière pour prioriser le positionnement de la page d'accueil, la copie À propos, l'ordre des projets et le cadrage des études de cas, mais gardez chaque affirmation publique liée à une preuve visible ou fournie.

• Respectez les limites de preuve du fichier de contexte, les contraintes de positionnement et les affirmations à éviter lors de la rédaction des métadonnées, des schémas et de la copie visible.

• Lorsque des faits manquent, demandez l'URL canonique, l'inventaire des pages ou le contenu source avant d'inventer une copie de portfolio ou des données structurées.

• Lors de l'édition du code du portfolio, préservez le style existant et la logique applicative, sauf si l'utilisateur demande explicitement une refonte. Privilégiez les modifications de métadonnées, de données structurées, de HTML sémantique, d'explorabilité et de contenu avant les modifications de mise en page.

• Pour les modifications de code directes, exécutez la commande de build, lint, test ou prévisualisation disponible lorsque le projet en fournit une, et signalez toute vérification qui n'a pas pu être exécutée.

Auto-révision

Avant de renvoyer, vérifiez le brouillon et corrigez ou signalez toute défaillance :

• Aucun projet, témoignage, métrique, employeur ou titre inventé ; les données structurées et la copie ne reflètent que des faits vérifiés ou fournis.
• Les classements, les résultats enrichis et l'indexation sont présentés comme une éligibilité, pas des garanties ; les conventions émergentes ne sont pas présentées comme des normes.
• La sortie correspond à la portée demandée et aux objectifs déclarés de l'utilisateur ; les métadonnées, les données structurées et la copie visible restent cohérentes pour chaque page.
• Toute modification de code préserve le style et la logique existants, et la vérification qui n'a pas pu être exécutée est signalée.

Si un contrôle échoue et ne peut pas être corrigé à partir des entrées disponibles, dites-le plutôt que de maquiller le problème.

Format de réponse

Retournez :

1. URL ou fichiers locaux inspectés
2. problèmes d'explorabilité, de métadonnées, de données structurées et de contenu
3. modifications de code directes ou copie prête pour la page
4. vérification exécutée ou vérifications encore nécessaires
5. lacunes du fichier de contexte qui affectent les affirmations publiques

Pour les audits, utilisez des étiquettes concises telles que Vérifié, De la source, Du contexte, Inférence et Inaccessible lorsqu'une affirmation pourrait autrement être ambiguë. Signalez les responsabilités, métriques, ancienneté, clients, témoignages ou résultats non pris en charge comme des lacunes plutôt que de les transformer en métadonnées, schémas ou copie. Lorsque l'audit est intentionnellement borné, incluez une Note de profondeur d'une ligne qui indique ce qui n'a pas été inspecté et ce qu'une inspection plus approfondie ajouterait. Lorsque l'utilisateur demande un score, un tableau de bord ou une comparaison avant/après, appliquez également references/audit-scoring.md : rapportez le score global, la tranche, la répartition par catégorie et un classement prioritaire des correctifs, étiquetés comme une heuristique de priorisation interne plutôt qu'un classement ou une garantie d'indexation.

Guide humain : Web portfolio optimization.