Gestion du Risque de Portefeuille

Que fait Gestion du Risque de Portefeuille ?

Configuration de la Compétence

Instructions Communes de la Compétence

OBLIGATOIRE : Avant de rechercher des connecteurs, de récupérer des preuves ou de rédiger une sortie, lisez et appliquez le contrat d'exécution partagé dans ../public-equity-investing/SKILL.md## Cross-Skill Runtime Contract. Ensuite, vérifiez la carte des compétences du routeur et ../../shared/plugin-routing-playbook.md pour les compétences adjacentes qui doivent être enchaînées avec ce flux de travail. N'effectuez pas de configuration ou d'inspection du contexte utilisateur pendant le travail de flux de travail ordinaire ; acheminez uniquement les demandes explicites de contexte sauvegardé, de configuration de source, d'intégration ou d'automatisation vers ../user-context/SKILL.md.

Résolution des Sources

Chargez ../../shared/workflow-source-resolution.md. Résolvez uniquement les catégories nécessaires pour ce flux de travail : internal_research, portfolio_models_trackers et market_data_estimates. Utilisez le contrat d'exécution partagé pour mapper chaque catégorie tentée à une application, un connecteur, un fichier, une exportation ou une entrée fournie par l'utilisateur.

Catégories de Dépendances Pertinentes

Voici les catégories de sources les plus susceptibles d'être importantes pour ce flux de travail. Utilisez le contrat du routeur pour résoudre uniquement les catégories dont la tâche a réellement besoin, préférez d'abord les sources nommées par l'utilisateur et indiquez toute limitation matérielle de source.

• Modèles et Suivis de Portefeuille
• Données de Marché et Estimations
• Recherche Interne

Support Interne

Lorsque ce flux de travail a besoin de rendu, de préparation de preuves/données, de style ou de contexte sectoriel, acheminez le support via le routeur visible public-equity-investing et ses playbooks internes groupés. Acheminez les questions de classeur ou d'assurance qualité du modèle via le flux de travail visible model-audit-tieout.

Réception des Livrables

Avant la collecte de sources ou l'analyse pour un nouveau livrable principal substantiel, chargez ../../shared/deliverable-intake-policy.md et utilisez son pré-contrôle adaptatif request_user_input pour les choix de format, de profondeur, de public/utilisation ou de concentration qui ne sont pas matériellement résolus. Pour un plan intégré position-et-couverture substantiel ou une demande explicite de rapport de risque HTML, la valeur par défaut résout la surface de présentation en un rapport de décision de risque HTML autonome et soigné, sauf si l'utilisateur demande une autre surface, une réponse rapide/sans fichier, une sortie de classeur ou un tableau de bord standardisé. Réutilisez les préférences résolues dans les étapes en aval ; lorsque vous agissez uniquement en tant qu'entrée pour un flux de travail propriétaire, ne demandez pas à nouveau.

Objectif

Transformer une opinion d'investissement en actions cotées en une posture de risque exécutable : la bonne taille, toute couverture appropriée, l'exposition intentionnellement retenue et les règles de réajustement ou de suppression de la protection. Cette compétence couvre les actions longues, les actions courtes, les paires de transactions, les ETF/constituants d'indices, les options cotées, les couvertures factorielles sur actions, les contrats à terme/indices et les proxies macroéconomiques lorsque la décision reste une décision d'actions cotées.

Ne traitez pas le dimensionnement et la couverture comme des réponses indépendantes lorsque l'un modifie l'autre. Dimensionnez à partir de la contrainte la plus stricte crédible ; couvrez uniquement les risques qui peuvent être réduits sans détruire l'alpha prévu. Un résultat de réduction de taille/sans couverture est valable lorsque le risque de base, le coût, la liquidité ou la complexité de la couverture est pire que l'exposition non désirée.

Pour un package de risque réutilisable substantiel, produisez un rapport de décision de risque HTML autonome et soigné suivant ../../shared/html-artifact-standard.md ; conservez les atouts structurés des feuilles de décision avec des tableaux de dimensionnement, des comparaisons de couverture, des scénarios et des déclencheurs de surveillance sans forcer une coque de tableau de bord standardisée. Utilisez dashboard-builder uniquement lorsque l'utilisateur demande explicitement un tableau de bord standardisé, un tableau de bord de surveillance récurrent, un modèle validé réutilisable ou un rendu structuré piloté par les données.

Sélection du Mode

Déduisez le mode de la décision demandée et du contexte disponible :

Mode	Utiliser lorsque	Résultat principal
position_sizing	L'utilisateur demande combien posséder ou vendre à découvert, les seuils d'ajout/réduction/sortie, les budgets de perte, la capacité de liquidité ou l'impact sur l'exposition du portefeuille.	Taille recommandée, contrainte contraignante, P&L par scénario, sortie de liquidité, règles de surveillance.
hedge_design	L'utilisateur demande comment couvrir, neutraliser, protéger, dé-bêta, classer les candidats à la couverture ou comparer les instruments de couverture.	Objectif de couverture, ensemble de candidats, registre du risque de base, méthode de dimensionnement, vérifications de préparation, règles de sortie.
integrated_risk_plan	L'utilisateur demande à la fois la taille de la position et la couverture, ou le choix de la couverture pourrait modifier matériellement la taille recommandée.	Comparaison non couvert vs couvert/réduit, package recommandé, exposition retenue, règles d'action.

Ne demandez pas à l'utilisateur de choisir un mode lorsque l'invite ou l'artefact fourni rend la décision claire. Posez une seule clarification ciblée uniquement lorsque le choix du mauvais mode modifierait matériellement le livrable, comme une demande ambiguë de "gérer le risque" sans position indiquée, exposition non désirée ou action demandée.

Lentille PM/Risque Actions Cotées

Chargez ../../shared/pm-judgment-heuristics.md et ../../shared/credit-markets-handoff.md avant de produire une recommandation de risque substantielle.

Modes d'audience :

• long_only_pm : mettez l'accent sur le poids actif par rapport à l'indice de référence, l'erreur de suivi, la liquidité/capacité, la tolérance aux baisses, la discipline d'ajout/réduction et le rôle dans le portefeuille.
• long_short_hf : mettez l'accent sur l'impact brut/net/bêta/facteur, l'emprunt, le risque de short squeeze, le chemin du catalyseur, l'adéquation de la couverture et les règles de couverture/réduction.
• market_neutral_pairs_pm : mettez l'accent sur le dimensionnement des jambes, la neutralité bêta/facteur/moteur, le risque de spread résiduel, l'emprunt et la liquidité.
• event_driven_equity_pm : mettez l'accent sur l'écart défavorable, le retard de calendrier, les résultats pondérés par les probabilités, la liquidité des options/emprunts et le slippage d'événement.
• etf_index_benchmark_pm : mettez l'accent sur le poids des constituants, le poids actif, l'exposition aux flux ETF/indices, le risque de rééquilibrage, la liquidité et l'impact sur l'erreur de suivi.

Chaque résultat substantiel doit indiquer l'alpha prévu, le risque non désiré, l'exposition retenue, la contrainte contraignante, la posture de liquidité/sortie, le compromis couverture ou réduction de taille, les déclencheurs de surveillance, la préparation à la mise en œuvre et les preuves manquantes qui pourraient modifier la décision. Incluez le risque de base et un scénario d'échec de la couverture chaque fois qu'une protection est proposée.

Frontière avec les Marchés de Crédit

Cette compétence peut utiliser les niveaux de CDS, les spreads de crédit, les notations, les échéances, la pression de refinancement, les gros titres de covenants ou le stress de liquidité uniquement comme signaux de baisse des actions ordinaires.

Utilisez les CDS/spreads uniquement comme contexte de risque des actions ordinaires. Les niveaux de CDS et les spreads de crédit ne peuvent apparaître que comme signaux de risque actions ou contexte de baisse des actions ordinaires ; ne les traitez jamais comme une mise en œuvre de couverture détenue localement.

Utilisez les Marchés de Crédit pour les CDS, les obligations, les prêts, le DV01/CS01 de spread, les couvertures de spread de crédit, les couvertures de structure de capital, les couvertures de détresse, les cascades de recouvrement, l'analyse de covenants ou les couvertures de covenants, le dimensionnement des titres de créance et la valeur relative des titres de crédit. Ne présentez pas un instrument de crédit comme une recommandation de couverture locale.

À Ne Pas Utiliser

• Thèse, perception variante ou construction de pitch : utilisez long-short-pitch ou memo-builder.
• Souscription de probabilité et de gain d'événement daté : utilisez event-driven-analyzer.
• Cartographie de transmission macroéconomique/économique : utilisez economic-impact-report.
• Calendrier de catalyseurs ou travail de surveillance uniquement : utilisez catalyst-calendar ou thesis-tracker.
• Conseils d'investissement personnels, exécution de transactions ou conclusions juridiques/de conformité.

Modes de Contexte

Contexte	Comportement par défaut
Aucun contexte	Demandez le titre/l'exposition, l'action souhaitée, l'horizon, les contraintes et les données disponibles ; fournissez un cadre de réception utilisable sans inventer de recommandation.
Contexte partiel	Produisez un écran de risque conditionnel ou un plan intégré de qualité écran avec des hypothèses explicites et des vérifications de données manquantes ; ne recommandez pas l'initiation lorsque les entrées de mise en œuvre requises sont manquantes.
Source complète	Normalisez les entrées, rapprochez les sources, exécutez des scénarios et produisez des conseils de risque prêts à la décision.
Révision ou actualisation	Préservez le travail antérieur, identifiez les entrées obsolètes et les expositions cachées, et montrez ce qui modifie la taille ou la couverture.

Flux de Travail

1. Définir la décision. Capturez le titre, la direction, la taille actuelle/proposée, l'exposition de la thèse à retenir, le risque non désiré, le prix/date de référence, l'horizon/catalyseur, le contexte du portefeuille, les limites du mandat, la liquidité et l'action demandée.
2. Résoudre l'interprétation du budget de perte. Distinguez un scenario loss budget, qui limite la perte dans le cadre d'un mouvement adverse indiqué, d'un absolute loss cap, qui doit rester satisfait même si l'action dépasse ce scénario. Lorsque l'utilisateur donne une limite de perte pour une position courte sans préciser l'interprétation, posez une seule question ciblée dans un run interactif. Dans un run non interactif, présentez les deux branches et ne transformez pas silencieusement une ampleur de squeeze supposée en recommandation d'initiation. Pour une position courte avec un plafond absolu, exigez une protection contre les pertes définie par le prix ou recommandez l'absence de position.
3. Cartographier les expositions. Séparez les expositions idiosyncratiques, événementielles et factorielles/macroéconomiques choisies du risque bêta, sectoriel, factoriel, de change, de matière première, de liquidité, d'emprunt, de financement, d'encombrement, d'écart et de concentration du portefeuille non désirés.
4. Construire les cas de risque. Estimez les résultats haussiers/de base/baissiers/de stress, le rendement pondéré par les probabilités lorsque c'est soutenable, le P&L par scénario, les implications de liquidité/sortie et tout cas d'échec de la couverture. Étiquetez les ampleurs de stress supposées comme illustratives jusqu'à confirmation par l'utilisateur ou une politique de risque applicable.
5. Appliquer le mode sélectionné.
   • Pour position_sizing, triangulez les contraintes de budget de perte, de volatilité, de liquidité, de limite d'exposition, d'indice de référence/facteur, d'emprunt/squeeze, de catalyseur et d'adéquation au portefeuille ; recommandez la taille crédible la plus restrictive.
   • Pour hedge_design, classez les expositions comme à conserver, à couvrir, à réduire ou à surveiller ; évaluez les alternatives d'actions directes, d'ETF/indices, de facteurs, de paires, d'options cotées, de contrats à terme/indices, de proxy macroéconomique causal, de couverture de portefeuille et d'absence de couverture/réduction de taille.
   • Pour integrated_risk_plan, comparez les résultats non couverts, couverts et de réduction de taille/sans couverture ; recommandez le package avec l'alpha retenu le plus clair et un coût/risque de base acceptable.
6. Évaluer la faisabilité. Indiquez la fraîcheur des données de marché, les jours d'ADV/sortie, les contraintes d'emprunt/rappel/squeeze, la chaîne d'options/grecques le cas échéant, le coût/portage, le risque de base, les vérifications de mandat/conformité et les lacunes de préparation à la mise en œuvre. Pour une recommandation de vente à découvert, un prix exécutable actuel, une capacité d'ADV/sortie, des conditions de localisation/emprunt et des entrées actuelles de squeeze/encombrement sont requis avant d'utiliser initiate ou tout autre langage prêt à la mise en œuvre ; les conditions d'option en direct sont en outre requises avant de recommander une couverture par options.
7. Recommander et surveiller. Si les entrées de mise en œuvre sont manquantes, étiquetez le résultat Conditional risk screen ou Not implementation-ready et indiquez la taille/package conditionnel plutôt que d'ordonner l'initiation. Sinon, indiquez la taille et/ou la couverture recommandée, l'action, la contrainte contraignante, l'exposition retenue, l'alternative rejetée le cas échéant, les déclencheurs d'ajout/réduction/sortie/couverture/réduction/roulement/suppression, la confiance et les preuves manquantes.
8. Rendre et inspecter lorsque le HTML est livré. Dans un rapport HTML autonome, placez en tête un tableau compact d'interprétation des contraintes, une action conditionnelle ou exécutable, un compromis de couverture et les entrées manquantes avant l'entrée. Gardez les citations lisibles : ne fragmentez pas les tickers, dates, pourcentages, montants en points de base, termes d'instruments tels que GLP-1 ou étiquettes de scénario avec des liens en ligne. Pour un fichier HTML local, inspectez la fenêtre d'affichage d'ouverture et les sections critiques en aval de la décision avec des captures d'écran du navigateur sans tête local plutôt qu'avec le plugin Browser dans l'application.

Carte de Référence

Chargez uniquement les références nécessaires au mode sélectionné :

• Tous les modes substantiels : references/source-and-context-protocol.md, references/exposure-and-factor-risk.md et references/liquidity-drawdown-scenarios.md.
• position_sizing : references/sizing-framework.md, references/strategy-nuance.md, references/position-sizing-output-templates.md et references/quality-control.md.
• hedge_design : references/hedge-workflow.md, references/instrument-playbooks.md, references/hedge-output-templates.md et references/hedge-scorecard-schema.md.
• integrated_risk_plan : les références de dimensionnement et de couverture nécessaires au package recommandé ; évitez de charger des playbooks d'instruments inutilisés.
• Livrables HTML autonomes : ../../shared/html-artifact-standard.md et le modèle de sortie du mode sélectionné.
• Livrables de tableau de bord standardisé explicites : references/DASHBOARD_PACK.md.

Scripts Déterministes

Utilisez les assistants groupés lorsque des entrées structurées sont fournies ou que l'utilisateur demande des modèles/fichiers :

python scripts/create_position_sizing_templates.py --out path/to/templates
python scripts/position_sizing_calculator.py --input path/to/input.json --out path/to/outputs
python scripts/score_hedge_candidates.py hedge_candidates.csv --output-dir path/to/outputs

Les assistants de dimensionnement écrivent des fichiers de support de calcul/vérification transparents, notamment position_summary.csv, sizing_cases.csv, scenario_pnl.csv, exposure_impact.csv, liquidity_exit.csv, monitoring_rules.csv, support_note.md, run_log.json et manifest.json. L'assistant de couverture écrit hedge_scorecard_support_note.md, hedge_scorecard.csv, hedge_scorecard.json et basis_risk_ledger.csv.

Ces assistants ne récupèrent pas de données en direct, n'exécutent pas de systèmes de risque de portefeuille, ne satisfont pas aux vérifications de conformité ou ne remplacent pas le jugement du gestionnaire de portefeuille. Les fichiers CSV, Markdown, JSON, de journal d'exécution et de manifeste sont des artefacts de support, sauf si l'utilisateur demande explicitement ces formats. Pour les packages réutilisables substantiels, commencez par un rapport de décision de risque HTML autonome et soigné, sauf si l'utilisateur demande explicitement un tableau de bord standardisé.

Transfert vers le Tableau de Bord

Si l'utilisateur demande explicitement un tableau de bord standardisé ou récurrent, utilisez references/DASHBOARD_PACK.md. portfolio-risk-management possède le jugement sur la taille, la couverture, l'exposition retenue, la contrainte contraignante, le risque de base, le scénario, la liquidité et la surveillance ; dashboard-builder possède le rendu et la validation. Construisez un public_equity_investing_dashboard qui reflète le jugement du gestionnaire de risque avec les contrôles et sorties de dashboard-builder ; ne sautez pas de sections de risque critiques pour s'adapter à une coque de tableau de bord standard.

Gestion d'Erreurs

• Données de marché manquantes ou obsolètes : Utilisez le mode Market Data de public-equity-investing ou une récupération directe ; si aucune n'est possible, étiquetez Conditional risk screen et indiquez les entrées manquantes.
• Saisie non liée aux actions cotées : Renvoyez aux flux de travail crédit-marché, événementiel ou macro des playbooks de routage.
• Conflit entre le contexte et l'invite : Préférez l'entrée la plus récente ; documentez l'ambiguïté dans le résultat.
• Données insuffisantes pour une recommandation : N'inventez pas de prix, de taille ou d'instrument de couverture ; demandez ou étiquetez Not implementation-ready.

Sécurité et Gestion des Accès

Suivez ../../shared/security-and-entitlements.md. Les données client/portefeuille réelles ne doivent être utilisées que lorsque l'utilisateur les fournit explicitement. Aucune information d'identification de compte ou d'API ne doit être écrite dans la sortie.