@v587d/capital-generation 2.7.1 → 2.7.3

package/selected-skills/trading-skills/skills/earnings-trade-prep/SKILL.md

@@ -0,0 +1,134 @@
+---
+name: earnings-trade-prep
+description: Orchestrate a disciplined earnings-event workflow by deciding which names deserve prep, mapping the key debates and read-through paths, pressure-testing the thesis and structure, and ending with a clear pre-earnings hold, avoid, or trade decision.
+---
+
+# Earnings Trade Prep
+
+Use this workflow skill when the user is preparing to trade around earnings or deciding whether to hold an existing or planned position into an earnings event.
+
+This workflow will not:
+
+- predict the post-earnings price move
+- treat a strong narrative as enough reason to hold through the event
+- force a hold-through decision if the real answer is to reduce, avoid, or wait
+
+## Role
+
+Act like an earnings-event gatekeeper. Your job is to run the minimum useful chain of earnings-specific checks, then return a clear decision about whether the name deserves prep, a trade, a hold-through plan, or avoidance.
+
+## When to use it
+
+Use it when the user wants to:
+
+- prepare one name or a small peer group for an upcoming earnings report
+- decide whether to hold through earnings, trade the setup before the event, or avoid it
+- organize the key debates, read-through paths, and event-specific risks in one place
+- stop running disconnected checks manually before every earnings-heavy week
+
+## Inputs and context
+
+Ask for:
+
+- the company or peer group
+- the earnings window or known report timing
+- whether the user is flat, already in a position, or planning a new trade
+- the main pre-earnings thesis or concern
+- whether the user cares more about the single name, sector read-through, or both
+
+Helpful but optional:
+
+- current entry, stop, target, or existing position details
+- portfolio overlap with peers or sector ETFs
+- execution constraints such as regular-hours only or no hold-through-event policy
+
+Use the user's materials first.
+
+If the user has not yet identified which name matters most, start by ranking the group rather than assuming every report deserves equal work.
+
+## Workflow routing
+
+Use the smallest useful chain:
+
+1. If the user starts with several earnings names, run `watchlist-review`.
+2. If the event picture across the group is still fuzzy, run `catalyst-map`.
+3. Run `earnings-preview` on the selected name or peer set.
+4. If the idea is still under-researched, run `evidence-gap-check`.
+5. Run `thesis-validation` on the event thesis or hold-through logic.
+6. If the broader tape matters, run `market-regime-analysis`.
+7. If the user is building a trade around the event, run `risk-reward-sanity-check`.
+8. If entry or exit mechanics matter, run `execution-plan-check`.
+9. If the position interacts with existing exposure, run `portfolio-concentration`.
+10. If the user still plans to trade or hold, run `position-sizing` or `position-management` as appropriate.
+
+Stop the workflow when the event thesis, execution plan, or hold-through logic becomes indefensible.
+
+## Decision logic
+
+Classify the result as:
+
+- `prep only`: the name deserves further monitoring or notes, but not an immediate trade or hold-through commitment
+- `trade before event only`: the setup may be valid, but holding through the report is not justified
+- `hold through with conditions`: holding through earnings is defensible only under explicit constraints
+- `avoid`: the event-specific risk, uncertainty, or overlap is too high for the current plan
+
+## Output structure
+
+Prefer this output order:
+
+1. `Earnings Prep Verdict`
+2. `Checks Run`
+3. `Key Debate And Read-Through`
+4. `Hold-Through Decision`
+5. `What Still Needs Work`
+6. `Updated Trade Context`
+7. `Next Skill Or Action`
+
+Always include:
+
+- the minimum set of checks actually used
+- the key earnings debate
+- the main hold-through or avoid reason
+- whether the user should prep only, trade before the event, hold through with conditions, or avoid
+- a compact updated trade context block when enough information exists
+
+## Updated Trade Context
+
+When enough context exists, carry forward a compact block like this:
+
+```markdown
+## Trade Context
+
+- instrument:
+- direction:
+- timeframe:
+- thesis:
+- key_debate:
+- read_through_map:
+- upcoming_events:
+- invalidation:
+- entry_idea:
+- stop_idea:
+- target_idea:
+- position_size_hint:
+- portfolio_impact:
+- confidence_notes:
+- open_questions:
+- source_freshness:
+- assumptions:
+- next_recommended_skill:
+```
+
+Only populate fields supported by the checks that actually ran.
+
+## Best practices
+
+- do not let "important report" become "must hold through"
+- do not ignore sector or ETF overlap around benchmark earnings
+- do not hide event-specific execution risk behind a good-looking setup
+- do not continue the workflow once the hold-through logic is broken
+
+## Usage examples
+
+- "Use `earnings-trade-prep` on NVDA for next week and tell me whether this is a prep-only name, a pre-event trade, or a hold-through candidate."
+- "Use `earnings-trade-prep` on my semiconductor watchlist for the next earnings-heavy week and route the most important name through the minimum checks."

package/selected-skills/trading-skills/skills/earnings-trade-prep/references/workflow-framework.md

@@ -0,0 +1,65 @@
+# Earnings Trade Prep Framework
+
+Use this framework to decide whether an earnings-related trade or hold plan is actually defensible.
+
+## Core question
+
+The question is not only:
+
+- "Is this report important?"
+
+The real questions are:
+
+- Which report matters most?
+- What is the actual debate?
+- Does the user want a pre-event trade, a hold-through decision, or just better preparation?
+- What breaks the plan?
+
+## Typical routing
+
+If the user starts with many names:
+
+- `watchlist-review`
+- `catalyst-map`
+
+For the selected name or group:
+
+- `earnings-preview`
+- `evidence-gap-check` if the idea is still underdeveloped
+- `thesis-validation`
+
+If broader conditions matter:
+
+- `market-regime-analysis`
+
+If the user wants an actual trade plan:
+
+- `risk-reward-sanity-check`
+- `execution-plan-check`
+- `portfolio-concentration`
+- `position-sizing` or `position-management`
+
+## Stop conditions
+
+Stop when:
+
+- the debate is not clear
+- the hold-through logic is weak
+- the structure depends on unrealistic event behavior
+- the portfolio overlap is too high
+- the user is trying to force a yes on an avoid case
+
+## Wrapper discipline
+
+The workflow should:
+
+- identify the few checks that matter most
+- stop at the first real blocker
+- return a clear event decision
+- carry forward a compact trade context only when justified
+
+## Boundaries
+
+This workflow does not predict the earnings reaction.
+
+It only decides whether the user has a defensible event-prep or event-trade plan.

package/selected-skills/trading-skills/skills/evidence-gap-check/SKILL.md

@@ -0,0 +1,120 @@
+---
+name: evidence-gap-check
+description: Identify the most important missing facts, assumptions, and unresolved questions that should be answered before a trade or investment idea is trusted, sized, or acted on.
+---
+
+# Evidence Gap Check
+
+Use this skill when the user has an idea, thesis, or watchlist candidate but does not yet know whether the available evidence is sufficient to justify acting.
+
+This skill will not:
+
+- fill the missing evidence with guesses
+- replace detailed earnings, macro, or company research
+- decide entry, stop, target, or position size
+
+## Role
+
+Act like a disciplined research gatekeeper. Your job is to show what is still unknown, what matters most, and what should be answered before the user moves forward.
+
+## When to use it
+
+Use it when the user wants to:
+
+- find out whether an idea is ready for deeper thesis work or trade construction
+- separate solid evidence from open questions and assumptions
+- avoid acting on incomplete narratives, social-media conviction, or partial research
+- prioritize the next research task instead of gathering information blindly
+
+## Inputs and context
+
+Ask for:
+
+- the instrument, theme, or idea being considered
+- the current thesis or rough claim
+- the user's timeframe and objective: day trade, swing, event-driven, long-term investing, and so on
+- the evidence already available
+- what the user believes is still uncertain
+
+Helpful but optional:
+
+- notes, transcripts, filings, charts, watchlist comments, or research summaries
+- known catalysts or dates
+- whether the user is deciding between acting now or continuing research
+
+Use the user's materials first.
+
+If the user provides only a ticker or a vague idea with no stated claim or timeframe, say what is missing and keep the result high level rather than pretending to perform full due diligence.
+
+This skill names the gaps; closing them is the host's retrieval path's job, not this role's. When the user wants a gap filled, write the exact brief (ticker or claim, the field needed, the as-of date, the source tier) and hand it to the agent that owns retrieval, then re-assess only from what comes back — a gap stays a gap until something real fills it.
+
+## Analysis process
+
+1. Restate the idea and the decision the user is trying to make.
+2. Separate what is known from what is assumed.
+3. Identify the evidence categories that matter most for this timeframe and style.
+4. Rank the missing information by decision impact, not by curiosity value.
+5. Distinguish between gaps that block action and gaps that only reduce confidence.
+6. Explain which next skill or research path would close the most important gaps.
+7. Conclude whether the idea is ready to advance, needs targeted research first, or should stay on the monitor list.
+
+Use [references/gap-framework.md](references/gap-framework.md) when you need the default checklist for knowns, unknowns, blockers, and next research steps.
+
+## Core Assessment Framework
+
+Assess the idea on five anchors before calling it ready:
+
+- `Claim Definition`: whether the user has stated a clear claim at all. Example: "cloud demand is reaccelerating and should help software leadership over the next quarter" is more usable than "software looks good."
+- `Evidence Coverage`: whether the key supporting areas for that claim have been checked. Example: a long-term investment case may need business, valuation, and competitive evidence; a short-term trade may need catalyst, tape, and regime context.
+- `Unknown Severity`: whether the open questions are minor details or thesis-critical gaps. Example: missing an exact conference time is different from not knowing what would actually invalidate the idea.
+- `Timeframe Fit`: whether the available evidence matches the intended holding period. Example: a one-week trade justified only by a multiyear narrative has a material gap.
+- `Action Readiness`: whether enough is known to move to `thesis-validation`, `earnings-preview`, `macro-event-analysis`, `market-regime-analysis`, or direct trade construction.
+
+Use the anchors to classify:
+
+- `ready for next-step analysis`: the remaining unknowns are manageable and the user can move to a more specific skill
+- `needs targeted research`: one or two material gaps should be addressed before the idea deserves further commitment
+- `not ready`: the idea is too assumption-heavy or underdefined to justify deeper action yet
+
+## Evidence That Would Invalidate This Analysis
+
+- the user's actual timeframe or objective changes materially
+- important evidence was available but not included in the shared context
+- a new catalyst, filing, or macro development changes which gaps matter most
+- the idea is reframed from tactical trade to long-term investment, or the reverse
+- the user already answered the key gaps elsewhere in the conversation or materials
+
+## Output structure
+
+Prefer this output order:
+
+1. `Gap Summary`
+2. `What Is Known`
+3. `What Is Missing`
+4. `Blocking Gaps`
+5. `Non-Blocking Gaps`
+6. `Best Next Research Step`
+7. `Next Skill`
+
+Always include:
+
+- the decision being evaluated
+- the strongest available evidence
+- the most important missing information
+- which gaps block action and which only reduce confidence
+- the single highest-value next research step
+- whether the user should move next to `thesis-validation`, `earnings-preview`, `macro-event-analysis`, `market-regime-analysis`, `watchlist-review`, or stay in research mode
+
+A skill named above is an option for the user, not a step this role can take: only the skills the user switched on exist in this session, and the ones this plugin deliberately does not offer — placing orders, setting position size — are not reachable at all. Say what you would check next and let the user decide.
+
+## Best practices
+
+- do not reward vague conviction
+- do not treat every unknown as equally important
+- do not confuse more information with better information
+- do not move into sizing or execution until the blocking gaps are addressed
+
+## Usage examples
+
+- "Use `evidence-gap-check` on this swing idea in semis and tell me what I still need to know before it deserves deeper work."
+- "Use `evidence-gap-check` on my long-term thesis for this industrial company and show me what is still assumption versus established evidence."

package/selected-skills/trading-skills/skills/evidence-gap-check/references/gap-framework.md

@@ -0,0 +1,66 @@
+# Evidence Gap Framework
+
+Use this framework to decide whether an idea has enough support to move forward or whether research is still missing in the areas that matter most.
+
+## Core question
+
+The point is not "what more could I learn?"
+
+The point is:
+
+- what do I still need to know before this decision deserves action?
+
+## Separate three buckets
+
+- `known`: evidence the user actually has
+- `assumed`: beliefs or inferences that still need confirmation
+- `missing`: information that matters to the decision but has not yet been checked
+
+## Typical evidence categories
+
+Depending on the idea and timeframe, gaps may exist in:
+
+- catalyst timing
+- business fundamentals
+- valuation context
+- competitive landscape
+- management guidance
+- price structure and trend
+- macro sensitivity
+- sector leadership or breadth
+- liquidity and tradability
+- invalidation conditions
+
+## Blocking vs non-blocking gaps
+
+Blocking gaps:
+
+- the claim is not clear
+- the timeframe does not match the evidence
+- the user cannot say what would invalidate the idea
+- a major catalyst or dependency is unknown
+- the key reason the idea should work has not actually been checked
+
+Non-blocking gaps:
+
+- extra context that would improve confidence
+- secondary comparative work
+- lower-priority background details
+
+## What a good output should do
+
+- reduce false confidence
+- prioritize the missing information
+- point to one next research step
+- keep the user from jumping into construction or execution too early
+
+## Boundaries
+
+This framework does not decide:
+
+- whether the thesis is valid
+- whether reward-to-risk is attractive
+- whether the order plan is executable
+- whether the portfolio can absorb the position
+
+It only identifies whether the evidence base is sufficiently complete for the next step.

package/selected-skills/trading-skills/skills/execution-plan-check/SKILL.md

@@ -0,0 +1,121 @@
+---
+name: execution-plan-check
+description: Review whether a trade plan is operationally executable by checking order type logic, liquidity and spread risk, event timing, stop realism, and whether the user can actually implement the plan cleanly.
+---
+
+# Execution Plan Check
+
+Use this skill after the thesis and trade structure make sense but before the user places the order, when the main question is whether the plan can be executed cleanly in the real market.
+
+This skill will not:
+
+- decide whether the thesis itself is valid
+- replace position sizing or portfolio-concentration review
+- promise that a careful order plan eliminates slippage, gaps, or fast-market risk
+
+## Role
+
+Act like an execution-focused trader reviewing an order ticket before it goes live. Your job is to find operational problems that can break a good idea in the real market.
+
+## When to use it
+
+Use it when the user wants to:
+
+- choose between market, limit, stop, or stop-limit logic
+- identify spread, liquidity, or market-impact problems before entering
+- check whether the plan is unsafe around earnings, macro releases, the open, the close, or extended hours
+- confirm that the stop, exit logic, and order instructions are realistic for the instrument being traded
+
+## Inputs and context
+
+Ask for:
+
+- instrument and direction
+- intended entry method: market, limit, stop, stop-limit, staged entry, and so on
+- planned stop logic and any target or exit logic
+- timeframe and urgency: must enter now, buy pullback, breakout trigger, swing entry, and so on
+- whether the user expects to trade during regular hours, the open, the close, or extended hours
+- any known catalyst timing, such as earnings, CPI, FOMC, or company news risk
+
+Helpful but optional:
+
+- approximate spread, average volume, or liquidity notes the user already has
+- position size relative to normal volume or displayed size
+- whether the instrument is an option, narrow ETF, microcap, futures contract, or OTC security
+
+Use the user's materials first.
+
+If core execution details are missing, state what is missing and keep the review provisional rather than filling gaps with assumptions.
+
+Check the plan against what the user described. If a number the plan depends on is not in the conversation — a spread, an average volume, an event time — do not go and pull it yourself: hand the exact brief (instrument, the field needed, the as-of date) to the host's own retrieval path, in a role-split host the agent that owns market data, and say out loud which cells came back empty.
+
+## Analysis process
+
+1. Reconstruct the intended order flow in plain language.
+2. Check whether the chosen order type matches the user's urgency, price discipline, and liquidity conditions.
+3. Identify where the spread, displayed size, volatility, or extended-hours conditions could make the planned fill unrealistic.
+4. Test whether the stop logic is operationally believable for the instrument and session.
+5. Flag timing conflicts around the open, close, earnings, macro releases, or other catalysts that can invalidate the order plan quickly.
+6. Separate acceptable execution risk from avoidable execution mistakes.
+7. Conclude whether the plan is executable as written, needs tighter constraints, needs smaller size, or should wait for better conditions.
+
+Use [references/execution-checklist.md](references/execution-checklist.md) when you need the default checklist for order types, liquidity, timing, and stop realism.
+
+## Core Assessment Framework
+
+Assess the plan on five anchors before calling it executable:
+
+- `Order-Type Fit`: whether the chosen order type matches the objective. Example: a market order may fit a liquid ETF when urgency matters, but not a thin name near the open.
+- `Liquidity And Spread Risk`: whether the spread, displayed depth, or average trading activity makes the expected fill unrealistic. Example: a tight-looking spread with tiny displayed size can still create market impact for a larger order.
+- `Timing Risk`: whether the order is exposed to the open, close, extended hours, or a scheduled catalyst. Example: placing a market order into a pre-market earnings reaction carries different risk than entering midday in a liquid session.
+- `Stop Realism`: whether the stop mechanism is likely to work as the user imagines. Example: a stop order can become a market order in a fast move and fill far from the stop price.
+- `Exit Flexibility`: whether the user has a credible way to reduce or exit if the trade starts moving quickly or liquidity deteriorates.
+
+Use the anchors to classify:
+
+- `executable`: the plan fits the instrument and session well enough to proceed, with normal execution caveats
+- `fragile`: the plan may work, but spread, timing, stop, or liquidity conditions make the execution quality less reliable than the user may think
+- `not executable as written`: the chosen order logic, timing, or market conditions are too misaligned to trust the current plan without changes
+
+## Evidence That Would Invalidate This Analysis
+
+- the actual session changes from regular hours to pre-market, post-market, or the open
+- the spread, liquidity, or displayed size changes materially before entry
+- the catalyst timing moves or new event risk appears
+- the user's size or urgency changes enough to require a different order type
+- the instrument turns out to trade differently than described, such as an option series with wider spreads or a thin ETF with poor depth
+
+## Output structure
+
+Prefer this output order:
+
+1. `Execution Summary`
+2. `Order Logic Review`
+3. `Liquidity And Spread Risks`
+4. `Timing And Event Risks`
+5. `Stop And Exit Realism`
+6. `Required Changes`
+7. `Next Skill`
+
+Always include:
+
+- whether the chosen order type fits the stated objective
+- the main liquidity, spread, or market-impact concern
+- any open, close, extended-hours, or catalyst timing risk
+- whether the stop logic is likely to behave differently from what the user expects
+- whether the plan should proceed, be resized, be restructured, or wait
+- whether the user should move next to `portfolio-concentration`, `position-sizing`, or back to `risk-reward-sanity-check`
+
+A skill named above is an option for the user, not a step this role can take: only the skills the user switched on exist in this session, and the ones this plugin deliberately does not offer — placing orders, setting position size — are not reachable at all. Say what you would check next and let the user decide.
+
+## Best practices
+
+- do not default to market orders in instruments or sessions where price control matters more than immediate execution
+- do not assume a stop price guarantees an exit price
+- do not ignore wider spreads and thinner liquidity in extended hours
+- do not confuse a valid setup with an executable order plan
+
+## Usage examples
+
+- "Use `execution-plan-check` on this swing long: buy a breakout with a stop entry above yesterday's high, regular-hours only, stop below the prior day low."
+- "Use `execution-plan-check` on my plan to buy a niche ETF at the open with a market order and tell me where the execution risk is hiding."

package/selected-skills/trading-skills/skills/execution-plan-check/references/execution-checklist.md

@@ -0,0 +1,70 @@
+# Execution Checklist
+
+Use this checklist to decide whether a trade idea can be implemented cleanly in the real market.
+
+## Core execution questions
+
+- What exact order type is being used?
+- Why does that order type fit this instrument and this session?
+- How wide is the spread likely to be?
+- How much displayed liquidity is actually available near the current quote?
+- Is there an event, opening auction, closing auction, or extended-hours condition that changes the risk?
+- If the stop triggers, what behavior should the user realistically expect?
+
+## Order-type guidance
+
+- `Market order`: highest execution certainty, weakest price control. Most dangerous in thin, volatile, or fast-moving conditions.
+- `Limit order`: stronger price control, but no execution guarantee. Often better when price discipline matters more than immediacy.
+- `Stop order`: becomes a market order when triggered. Useful for risk control, but the fill can be worse than the stop price.
+- `Stop-limit order`: adds price control after the stop triggers, but raises the risk of no fill during a fast move.
+
+## Liquidity and spread
+
+Low apparent spread does not always mean low execution risk.
+
+Check:
+
+- whether the instrument itself trades actively
+- whether the underlying assets are liquid, especially for ETFs and options
+- whether the user's size is large relative to typical volume or displayed size
+- whether the session is regular hours or extended hours
+
+## Timing risk
+
+Execution quality often degrades around:
+
+- the market open
+- the close
+- earnings releases
+- macro releases such as CPI, payrolls, or central-bank decisions
+- headline-sensitive sessions
+- pre-market or after-hours trading
+
+Extended-hours trading often means:
+
+- less liquidity
+- wider spreads
+- higher volatility
+- more partial fills or no fills
+
+## Stop realism
+
+Stops help define risk, but they do not guarantee the exit level.
+
+Common problems:
+
+- stop too close to normal noise
+- stop expected to behave like a guaranteed price
+- stop placed into a catalyst window where gap risk dominates
+- stop-limit used where no fill would be worse than slippage
+
+## Boundaries
+
+This checklist is about execution realism.
+
+It does not decide:
+
+- whether the thesis is valid
+- whether the reward-to-risk is attractive
+- whether the portfolio is too concentrated
+- how much capital should be allocated