Xu-125/portfolio-collection-skill

Portfolio Collection / Création et maintenance de collections

Transformez des travaux dispersés en une collection consultable ; gardez sa source de données réelle maintenable.

1. Confirmer le périmètre

Classez la demande comme discussion de conception, construction, mise à jour incrémentielle, réparation ou planification. Ne mettez rien en œuvre lors d'une simple demande de discussion.

Inspectez les liens/fichiers fournis et les artefacts existants avant de poser des questions. Ne confirmez que les inconnues matérielles, de préférence en un seul lot de trois questions maximum :

• Nom de la collection, public et sources autorisées ; distinguez les liens publics, les documents sources privés et les téléchargements utilisateur.
• Application/source de données existante par rapport à une nouvelle construction ; maintenance partagée, champs modifiables requis et modèle d'accès.
• Catégories, référence visuelle et comportement attendu du titre/couverture. Pour les travaux récurrents, obtenez séparément la fréquence, l'heure locale exacte, le fuseau horaire et la destination de mise à jour.

Utilisez le style du projet existant et la pile choisie. Pour une nouvelle collection sans référence, proposez une mise en page sobre et prioritaire au contenu avant une implémentation coûteuse. N'imposez jamais une marque, une plateforme, une taxonomie à six catégories ou un calendrier quotidien particulier.

2. Acheminer selon les capacités disponibles

Découvrez et lisez les compétences pertinentes de l'hôte avant d'utiliser leurs outils.

• Utilisez Browser Use par défaut pour la collecte de sites Web/flux : observez → naviguez → inspectez un article → enregistrez les preuves. Lisez les schémas d'outils exacts ; ne devinez jamais les noms de connecteurs ou les indicateurs.
• Utilisez un connecteur authentifié approuvé par l'hôte pour les documents/messages privés. Recherchez dans l'historique privé uniquement sur demande explicite ou lorsque cela est nécessaire dans le périmètre autorisé de l'utilisateur.
• Utilisez le constructeur d'applications Web de l'hôte pour les applications interactives. Une collection partagée nécessite une persistance partagée et une autorisation côté serveur ; le stockage local n'est pas un substitut.
• Une vitrine statique unique peut utiliser la compétence HTML de l'hôte. Expliquez son absence d'édition partagée ou de collecte automatique.
• Utilisez la compétence tableur/base de données de l'hôte lorsque la source choisie est une feuille de calcul, une Base ou une base de données.
• Utilisez le planificateur de l'hôte uniquement après approbation du planning et configuration réussie. Une invite écrite n'est pas une tâche planifiée.

Si les capacités ne sont pas disponibles, terminez le travail indépendant et identifiez la capacité manquante exacte. Ne remplacez pas silencieusement une application partagée par une démo locale. Ce package est un workflow d'agent, pas une application autonome ou un robot d'exploration.

3. Collecter et réconcilier

Pour la construction/mise à jour/réparation, lisez références/data-and-maintenance.md.

1. Relisez la source de données réelle actuelle et capturez instantanément les enregistrements existants avant toute modification. Localisez le chemin de lecture/écriture réel, pas une table inutilisée ou une copie de la source.
2. Utilisez un lien source exact fourni par l'utilisateur ou une identité de compte officielle vérifiée. Ne substituez pas un autre compte, une republication ou un résultat de recherche générique à la source demandée.
3. Enregistrez l'URL d'origine textuellement, le vrai titre, la couverture vérifiée, le type de média, la date réelle si disponible, les catégories et les preuves. Gardez les champs incertains marqués comme inconnus.
4. Obtenez les couvertures d'articles à partir des métadonnées de couverture/partage d'article, pas d'un avatar, d'une image corporelle décorative ou d'une capture d'écran. Utilisez les couvertures vidéo réelles de la plateforme ; utilisez une image vidéo uniquement si autorisée comme solution de secours. Enregistrez les actifs durables et préservez la provenance.
5. Faites correspondre le titre d'affichage d'une entrée à la politique convenue. Par défaut, les titres d'articles sont des originaux textuels. Les étiquettes de vidéos courtes peuvent résumer le texte source vérifié uniquement lorsque cela est autorisé ; conservez l'original et l'étiquette courte séparément. N'appelez jamais une description un transcript audio.
6. Dédupliquez par identité source vérifiée, puis réconciliez manuellement les versions multiplateformes du même travail corroborées. Stockez plusieurs sources/catégories sur une seule entrée, pas de cartes en double.
7. Recherchez les originaux privés uniquement sur demande ; lisez le contenu candidat pour distinguer les brouillons finaux des briefs, des calendriers ou des plans d'entretien. Préservez les autorisations du document original.
8. Appliquez uniquement les modifications de champ autorisées, protégez les modifications manuelles et vérifiez le résultat stocké. Si une écriture expire, inspectez l'état réel avant de réessayer.

4. Présenter la collection

Pour le travail d'interface utilisateur, lisez références/presentation-and-access.md.

• Utilisez des couvertures authentiques, un champ de recherche clair et les catégories approuvées par l'utilisateur. Séparez les filtres de format média des catégories de sujet.
• Laissez chaque carte prendre sa hauteur naturelle. Pour les médias mixtes horizontaux/verticaux, utilisez une véritable disposition en maçonnerie à colonne la plus courte ou une mise en page vérifiée équivalente. Ne tordez pas une carte d'article courte pour ressembler à une carte vidéo haute.
• Dérivez les ratios du brief ou des actifs originaux. Recommandation facultative : 2,35:1 pour les articles larges et 3:4 pour les vidéos portrait ; pas un invariant pour tous les projets.
• Gardez un titre concis et les actions nécessaires. N'ajoutez pas de résumés, de dates, de métriques ou de badges que l'utilisateur n'a pas demandés.
• Faites en sorte que les clics sur le corps de la carte ouvrent l'URL du travail public. Un bouton séparé pour l'original privé ouvre le document source ; ni ce bouton ni les commandes de mention « J'aime » ne doivent déclencher le lien du corps de la carte.
• Appliquez l'ordre confirmé ; si une catégorie est prioritaire, triez ce groupe et le reste par dates réelles indépendamment. Ne fabriquez pas de dates et ne réinitialisez pas les dates anciennes pour qu'elles paraissent récentes.
• Proposez une simple entrée de maintenance propriétaire soutenue par la même source de données. Affichez des titres reconnaissables et uniquement les champs modifiables choisis.

5. Isoler l'usage public et l'administration privée

Exigez une identité de propriétaire vérifiée par le serveur pour toutes les lectures/écritures administratives. Un bouton caché ou un compte connecté quelconque ne constitue pas une autorisation. Gardez l'identité/configuration du propriétaire hors des clients publics. Les lecteurs anonymes reçoivent uniquement les champs publics publiés ; gardez les données de contact et le contenu des documents privés hors des réponses publiques. Référez-vous aux tests d'accès dans la référence de présentation.

La publication, la visibilité Internet et le code d'application sont des couches séparées. Demandez un périmètre précis avant d'activer le partage public. N'ouvrez jamais les autorisations d'un original privé simplement parce que la collection est publique. Utilisez le chemin de déploiement autorisé de l'hôte ; si la publication doit être effectuée par l'utilisateur, amenez-le à l'entrée de développement/publication vérifiée et arrêtez-vous avant cette action.

6. Planifier la maintenance incrémentielle

Pour la planification, lisez références/recurring-update.md. Confirmez le planning et la cible, résolvez les tâches existantes pour éviter les doublons et utilisez le planificateur réel. Conservez l'identité de la collection, les sources de compte, la fenêtre de chevauchement, les champs protégés et le comportement d'échec/rapport dans les instructions de la tâche. Enregistrez les points de contrôle réussis uniquement après des écritures vérifiées. Signalez les sources non prises en charge ou bloquées par authentification plutôt que de les ignorer silencieusement.

7. Vérifier et livrer

Lisez références/verification.md avant de déclarer la tâche terminée. Le vérificateur local facultatif est :

python3 scripts/validate_manifest.py chemin/vers/manifest.json
python3 scripts/validate_manifest.py chemin/vers/after.json --baseline chemin/vers/before.json --allow-update cover,original_urls --require-cover-proof

Ces commandes effectuent uniquement des vérifications d'intégrité locales ; elles ne récupèrent pas de pages, ne prouvent pas qu'une image en direct se charge, n'authentifient pas les utilisateurs, n'écrivent pas dans une base de données et ne planifient pas de travaux. Lisez la référence pour la forme du manifeste et les règles de preuve.

Signalez le nombre réel d'éléments ajoutés, les candidats en double ignorés, les originaux liés, la couverture réelle de chargement des couvertures, les bloqueurs et si l'aperçu et la production diffèrent. Vérifiez chaque élément revendiqué ; étiquetez les vérifications basées uniquement sur un échantillon. Livrez l'artefact actuel en utilisant le mécanisme de livraison de l'hôte. Ne livrez pas de preuves temporaires, de journaux privés ou de secrets.

Invites facultatives / Prompts réutilisables

Utilisez références/prompts.md pour les invites bilingues de construction/mise à jour. Remplissez uniquement les valeurs approuvées par l'utilisateur ; les paramètres matériels non résolus nécessitent des éclaircissements, pas des valeurs par défaut inventées. Gardez la configuration privée et les identifiants en dehors de ce package réutilisable.