Imported from dEviLb0/portfolio (AGENTS.md). Install upstream with npx skills add dEviLb0/portfolio. Copyright stays with the author.

AGENTS.md — Instructions pour Codex

1. Mission

Développer et maintenir le portfolio one-page de Boris Kognowe.

Le portfolio présente un profil de Senior Android Engineer à travers :

• ses compétences ;
• ses projets actuels ;
• ses projets phares ;
• ses contributions open source ;
• une timeline de compétences acquises ;
• ses coordonnées.

Le site ne doit pas être une copie du CV.

2. Lecture obligatoire

Avant toute modification, lire intégralement :

AGENTS.md
docs/PROJECT_BRIEF.md
docs/DESIGN_SYSTEM.md
docs/CONTENT.md

Analyser également :

docs/references/portfolio-reference.png

En cas de conflit :

1. les instructions explicites de la tâche courante priment ;
2. AGENTS.md prime sur les autres documents ;
3. PROJECT_BRIEF.md définit le périmètre ;
4. CONTENT.md définit les informations éditoriales ;
5. DESIGN_SYSTEM.md définit la présentation ;
6. l’image sert de référence visuelle, jamais de source factuelle.

3. Stack autorisée

Utiliser :

• Astro
• TypeScript strict
• Tailwind CSS
• composants Astro
• JavaScript ou TypeScript client minimal
• Lucide Icons ou SVG locaux

Ne pas ajouter sans demande explicite :

• React
• Vue
• Svelte
• Angular
• backend
• base de données
• CMS
• bibliothèque d’animation lourde
• bibliothèque de composants UI complète.

4. Architecture attendue

src/
├── components/
│   ├── layout/
│   ├── navigation/
│   ├── hero/
│   ├── skills/
│   ├── current-projects/
│   ├── projects/
│   ├── open-source/
│   ├── timeline/
│   ├── about/
│   ├── contact/
│   └── ui/
├── data/
├── layouts/
├── pages/
└── styles/

Règles :

• ne pas placer tout le site dans src/pages/index.astro ;
• utiliser des composants par section ;
• extraire les éléments réutilisables ;
• stocker les données éditoriales dans src/data ;
• définir des types TypeScript ;
• centraliser les variables visuelles ;
• limiter les scripts globaux.

5. Modèle de données recommandé

Prévoir au minimum :

type Skill = {
  name: string;
  icon?: string;
  category?: string;
};

type CurrentProject = {
  title: string;
  description: string;
  status: string;
  progress?: number;
  url?: string;
};

type FeaturedProject = {
  slug: string;
  title: string;
  description: string;
  image: string;
  technologies: string[];
  githubUrl?: string;
  demoUrl?: string;
  documentationUrl?: string;
  confidential?: boolean;
};

type OpenSourceRepository = {
  name: string;
  description: string;
  url: string;
  technologies: string[];
  stars?: number;
  forks?: number;
};

type TimelineEntry = {
  period: string;
  title: string;
  description?: string;
  skills: string[];
};

Les propriétés facultatives ne doivent pas produire de boutons, compteurs ou espaces vides lorsqu’elles sont absentes.

6. Règles de contenu

Interdictions :

• inventer une entreprise ;
• inventer une date ;
• inventer un lien ;
• inventer une statistique ;
• inventer un nombre de stars ou de forks ;
• inventer une progression ;
• présenter comme terminé un projet encore conceptuel ;
• publier une adresse email d’exemple ;
• publier les textes visibles dans la maquette sans validation.

Utiliser les valeurs de docs/CONTENT.md.

Lorsqu’une donnée est marquée À RENSEIGNER ou À VALIDER :

• créer une valeur placeholder explicite dans les données ;
• masquer l’élément public si nécessaire ;
• ajouter un commentaire TODO(content) ;
• ne pas bloquer le build.

7. Règles de design

Respecter docs/DESIGN_SYSTEM.md.

La référence visuelle est :

docs/references/portfolio-reference.png

Reproduire :

• le header sombre ;
• l’accent vert ;
• la hiérarchie ;
• les cartes ;
• le rythme des sections ;
• la timeline de compétences ;
• la structure générale.

Ne pas reproduire aveuglément :

• les faux chiffres ;
• les faux dépôts ;
• les liens d’exemple ;
• les pourcentages ;
• les défauts de lisibilité ;
• les incohérences responsive ;
• les détails générés artificiellement dans l’image.

8. Accessibilité

Chaque changement doit préserver :

• navigation clavier ;
• focus visible ;
• HTML sémantique ;
• ordre logique des titres ;
• contrastes WCAG AA ;
• textes alternatifs ;
• libellés accessibles pour les icônes ;
• menu mobile avec aria-expanded ;
• bouton de thème avec aria-pressed ;
• respect de prefers-reduced-motion.

Ne pas utiliser un div cliquable à la place d’un bouton ou d’un lien.

9. Responsive

Développer mobile-first.

Vérifier au minimum :

375 px
768 px
1024 px
1440 px

Attentes :

• Hero empilé sur mobile ;
• navigation mobile accessible ;
• cartes en une colonne sur mobile ;
• timeline verticale sur mobile ;
• boutons non tronqués ;
• aucune barre de défilement horizontale involontaire ;
• texte lisible sans zoom.

10. Performance

• limiter le JavaScript ;
• préférer le rendu statique ;
• optimiser les images ;
• définir largeur et hauteur ;
• lazy-load sous la ligne de flottaison ;
• éviter les dépendances inutiles ;
• ne pas charger de vidéo automatiquement ;
• utiliser les composants Astro pour les images lorsque pertinent.

11. SEO

Implémenter :

• title ;
• meta description ;
• canonical ;
• Open Graph ;
• Twitter Card ;
• sitemap ;
• robots.txt ;
• favicon ;
• données structurées Person ou ProfilePage si elles utilisent uniquement des informations validées ;
• page 404.

12. Tests et validation

Après chaque lot significatif, exécuter les commandes disponibles.

Commandes minimales attendues :

npm run check
npm run build

Si le projet fournit des scripts supplémentaires :

npm run lint
npm run test
npm run format:check

Ne jamais déclarer une tâche terminée si une commande échoue à cause des modifications effectuées.

Signaler clairement les erreurs antérieures indépendantes de la tâche.

13. Déroulement des tâches

Avant un changement important :

1. lire les documents ;
2. inspecter le code existant ;
3. présenter un plan court ;
4. identifier les données manquantes ;
5. implémenter un lot cohérent ;
6. exécuter les validations ;
7. résumer les changements ;
8. s’arrêter avant le lot suivant.

Ne pas réécrire tout le projet sans nécessité.

14. Git

Utiliser des commits conventionnels lorsque des commits sont demandés :

feat:
fix:
refactor:
style:
test:
docs:
chore:

Exemples :

feat: add skills timeline section
feat: implement responsive portfolio hero
fix: improve mobile navigation accessibility
docs: update portfolio content placeholders

Ne pas créer de commit sauf demande explicite ou workflow convenu.

15. Définition de terminé

Une tâche est terminée lorsque :

• le besoin est implémenté ;
• les documents sont respectés ;
• le responsive est vérifié ;
• l’accessibilité principale est vérifiée ;
• les données absentes ne sont pas inventées ;
• les commandes de validation réussissent ;
• les fichiers modifiés sont résumés ;
• les limites restantes sont listées.