Structured pre-trade thesis builder — bull/bear cases, invalidation criteria, and sizing rationale before any live deployment. Read this page when a user proposes a trade idea, says 'should I trade X', asks for a bull/bear case, wants a pre-trade analysis, or before the agent deploys a new strategy live for the first time.
npx skills add https://github.com/Superior-Trade/superior-skills --skill trade-thesis
A structured framework the agent produces before any live deployment of a new strategy idea. Forces two-sided analysis and a measurable invalidation level so every trade has a thesis that can be killed.
Produce all six sections below. Each section is 2-4 bullet points max. This is a pre-trade checklist, not a research paper.
One sentence: what is the bet, which direction, what timeframe.
Force clarity. "Long ETH perp on a funding squeeze setup, targeting a 3-5% move over 24-48h" is a thesis. "ETH looks bullish" is not.
2-3 concrete reasons this trade works. Every reason must reference observable, checkable data:
price_check (e.g., "price reclaimed the 4h EMA-50 and is holding above")volume_momentum_check (e.g., "RVOL is 2.3x on the breakout candle")No vague claims like "market sentiment is improving" or "BTC looks strong." If it cannot be checked with a tool call, it does not belong in the bull case.
2-3 concrete reasons this trade fails. Same data-grounding rules as the bull case.
The agent must argue AGAINST the trade honestly. This is adversarial analysis, not a strawman disclaimer. Examples of real bear points:
A specific, measurable condition that kills the thesis. This becomes the logical stoploss anchor.
Acceptable invalidation criteria:
The stoploss in the deployment config should be anchored to this level, not an arbitrary percentage.
Which agent tools to call right now to verify the thesis before proceeding:
| Check | Tool | What to look for |
|---|---|---|
| Current price and recent structure | price_check | Is price where the thesis assumes it is? Has structure changed since the idea was formed? |
| Volume and momentum | volume_momentum_check | RVOL level, momentum acceleration/deceleration, any divergence |
| Available capital | balance_check | Main wallet balance on Hyperliquid — enough for the proposed stake? |
| Pair ranking | alpha_scan | Where does this pair sit in the current scan? Is the setup confirmed or fading? |
| Pair tradability | pair_validate | Is the pair active on Hyperliquid? What are the margin requirements and minimum order size? |
Run these checks and update the bull/bear case with the results before proceeding. If the data contradicts the thesis, say so.
stake_amount and max_open_trades)max_open_trades — if multiple positions may be open, total portfolio risk = risk per trade x max open tradesSetup: Funding squeeze on ETH perps, 1h timeframe.
1. Thesis statement
Long ETH/USDC:USDC on a funding squeeze — shorts are deeply underwater with funding APR at -22%, price has reclaimed the 4h EMA-21 with rising volume, targeting a 4-6% forced-unwind move over 24-48h.
2. Bull case
3. Bear case
4. Invalidation level
Below $3,420 (the pre-breakout consolidation low). If ETH gives back the entire reclaim candle, the squeeze is not catching and shorts are right. Stoploss anchored at -0.045 from entry to cover this level plus slippage.
Time stop: if the move hasn't produced +2% within 24h, the catalyst is stale. Exit via custom_exit timeout.
5. Data check
price_check ETH/USDC:USDC — confirm price is still above $3,540 and the reclaim is intactvolume_momentum_check ETH — confirm RVOL is still > 1.5xbalance_check — confirm at least $150 USDC available (stake $100 + buffer)alpha_scan — confirm ETH ranks in the squeeze-fuel bucket with score > 0.7pair_validate ETH/USDC:USDC — confirm pair is active, check margin requirements6. Position sizing rationale
Wallet balance: $1,200 USDC. Using stake_amount: 100 with max_open_trades: 1. Invalidation at $3,420 with expected entry near $3,560 = 3.9% downside. Stoploss at -0.045 covers the invalidation level. Risking ~$4.50 on a $1,200 wallet = 0.375% account risk. Conservative sizing — appropriate for a first deployment of this setup. Room to scale up on the next squeeze if this one validates.
Assess Kubernetes workloads and cluster configuration for AKS Automatic compatibility. Identifies incompatibilities, generates fixes, and guides migration from AKS Standard to AKS Automatic. WHEN: migrate to AKS Automatic, check AKS Automatic readiness, validate manifests for Automatic, assess cluster for Automatic compatibility, fix deployment for Automatic compatibility, identify AKS Automatic migration blockers, is my cluster ready for AKS Automatic.
Discovers available Azure OpenAI model capacity across regions and projects. Analyzes quota limits, compares availability, and recommends optimal deployment locations based on capacity requirements. USE FOR: find capacity, check quota, where can I deploy, capacity discovery, best region for capacity, multi-project capacity search, quota analysis, model availability, region comparison, check TPM availability. DO NOT USE FOR: actual deployment (hand off to preset or customize after discovery), quota increase requests (direct user to Azure Portal), listing existing deployments.
Interactive guided deployment flow for Azure OpenAI models with full customization control. Step-by-step selection of model version, SKU (GlobalStandard/Standard/ProvisionedManaged), capacity, RAI policy (content filter), and advanced options (dynamic quota, priority processing, spillover). USE FOR: custom deployment, customize model deployment, choose version, select SKU, set capacity, configure content filter, RAI policy, deployment options, detailed deployment, advanced deployment, PTU deployment, provisioned throughput. DO NOT USE FOR: quick deployment to optimal region (use preset).
Unified Azure OpenAI model deployment skill with intelligent intent-based routing. Handles quick preset deployments, fully customized deployments (version/SKU/capacity/RAI policy), and capacity discovery across regions and projects. USE FOR: deploy model, deploy gpt, create deployment, model deployment, deploy openai model, set up model, provision model, find capacity, check model availability, where can I deploy, best region for model, capacity analysis. DO NOT USE FOR: listing existing deployments (use foundry_models_deployments_list MCP tool), deleting deployments, agent creation (use agent/create), project creation (use project/create).
Intelligently deploys Azure OpenAI models to optimal regions by analyzing capacity across all available regions. Automatically checks current region first and shows alternatives if needed. USE FOR: quick deployment, optimal region, best region, automatic region selection, fast setup, multi-region capacity check, high availability deployment, deploy to best location. DO NOT USE FOR: custom SKU selection (use customize), specific version selection (use customize), custom capacity configuration (use customize), PTU deployments (use customize).
This skill should be used when working with LaminDB, an open-source data framework for biology that makes data queryable, traceable, reproducible, and FAIR. Use when managing biological datasets (scRNA-seq, spatial, flow cytometry, etc.), tracking computational workflows, curating and validating data with biological ontologies, building data lakehouses, or ensuring data lineage and reproducibility in biological research. Covers data management, annotation, ontologies (genes, cell types, diseases, tissues), schema validation, integrations with workflow managers (Nextflow, Snakemake) and MLOps platforms (W&B, MLflow), and deployment strategies.
Latch platform for bioinformatics workflows. Build pipelines with Latch SDK, @workflow/@task decorators, deploy serverless workflows, LatchFile/LatchDir, Nextflow/Snakemake integration.
Run Python code in the cloud with serverless containers, GPUs, and autoscaling. Use when deploying ML models, running batch processing jobs, scheduling compute-intensive tasks, or serving APIs that require GPU acceleration or dynamic scaling.
Take superior-trade/trade-thesis from the repository into ~/.claude/skills for personal
use, or into .claude/skills inside a project.
The agent identifies a skill by the name field in its header. Two skills with the
same name cannot sit side by side — one of them will be ignored.