@v587d/capital-generation 2.7.2 → 2.7.3

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

package/selected-skills/trading-skills/skills/journal-pattern-analyzer/SKILL.md

@@ -0,0 +1,120 @@
+---
+name: journal-pattern-analyzer
+description: Use when the user has a trade journal or trade log and wants repeated strengths, mistakes, environment-dependent patterns, and process changes without turning the review into hindsight theater.
+---
+
+# Journal Pattern Analyzer
+
+Use this skill when the user has a set of trades, journal notes, or review entries and wants to know what patterns are repeating across them.
+
+This skill will not:
+
+- grade the user only by total PnL
+- pretend a small sample proves a durable edge
+- replace single-trade post-mortems when the problem is still one specific position
+
+## Role
+
+Act like a process analyst reviewing a journal, not a cheerleader reviewing outcomes. Your job is to identify repeatable strengths, repeatable mistakes, and where the user's process breaks down under specific conditions.
+
+## When to use it
+
+Use it when the user wants to:
+
+- review a batch of trades instead of one trade
+- identify recurring mistakes in entries, exits, sizing, timing, or catalyst handling
+- see whether performance changes by setup, regime, instrument, or time horizon
+- convert raw journal notes into one or two high-value process changes
+
+## Inputs and context
+
+Ask for:
+
+- a trade log, journal entries, or a summarized set of closed trades
+- the sample window: last 10 trades, last month, last quarter, earnings season, and so on
+- what fields exist: setup type, thesis, entry, stop, target, size, result, notes, adherence, catalyst context
+- whether the user wants to focus on behavioral patterns, setup quality, sizing quality, or environment fit
+
+Helpful but optional:
+
+- regime notes
+- sector or instrument tags
+- whether results are in dollars, percentages, or R multiples
+- any pattern the user already suspects
+
+Use the user's materials first.
+
+If the sample is very small, say so clearly and keep the conclusions provisional.
+
+When the journal is structured enough to count things, the counting does not happen in this role: the analysis role in this plugin has no shell and runs no helper scripts. Hand the brief (the sample, its columns, and the statistics wanted — win rate, average win and average loss, expectancy grouped by setup or environment) to the host's data side, in a role-split host the agent that owns statistics and quality checks, and work only from the numbers it returns. Two or three trades can be counted inside the reply itself; show the arithmetic. A row missing a field stays missing, never defaulted.
+
+## Analysis process
+
+1. Reconstruct the journal sample and what the user is trying to learn.
+2. Group trades by setup, environment, mistake type, instrument, or catalyst context when the data supports it.
+3. Separate outcome patterns from process patterns.
+4. Identify recurring strengths and recurring mistakes.
+5. Check whether the user's mistakes cluster around specific conditions such as open entries, event holds, oversizing, or late exits.
+6. Distill the findings into one or two process changes that are specific enough to test.
+7. End with what the user should keep doing, stop doing, and monitor next.
+
+Use [references/pattern-framework.md](references/pattern-framework.md) when you need the default checklist for journal quality, sample interpretation, and repeatable mistake detection.
+
+## Core Assessment Framework
+
+Assess the journal on five anchors before drawing conclusions:
+
+- `Sample Quality`: whether there are enough trades and enough detail to support pattern claims. Example: 20 tagged trades with notes is more informative than 4 trades with only PnL.
+- `Process Consistency`: whether the user actually followed a recognizable process. Example: repeated pre-trade planning and post-trade notes make the patterns easier to trust.
+- `Mistake Recurrence`: whether the same type of error appears multiple times. Example: widening stops after entry in several trades is a stronger signal than one isolated lapse.
+- `Environment Fit`: whether results change across regimes, catalysts, timeframes, or instruments. Example: momentum setups may work in healthy trend conditions but degrade around heavy event risk.
+- `Actionability`: whether the output can be turned into a specific rule, checklist item, or monitoring metric. Example: "do not enter breakouts in the first 15 minutes" is more actionable than "be more patient."
+
+Use the anchors to classify:
+
+- `useful pattern set`: the journal is detailed enough to support actionable conclusions
+- `suggestive but thin`: there may be a pattern, but the sample or tagging quality is too weak for strong claims
+- `not analyzable yet`: the notes are too sparse or the sample is too small to draw meaningful process conclusions
+
+## Evidence That Would Invalidate This Analysis
+
+- the sample is incomplete or selectively chosen
+- key fields such as setup type, adherence, or notes were missing or mis-tagged
+- the results mix different strategies or timeframes that should not have been analyzed together
+- later entries show that the apparent pattern was only a short-lived cluster
+- the user changes process materially, making the historical pattern less relevant
+
+## Output structure
+
+Prefer this output order:
+
+1. `Pattern Summary`
+2. `What Is Working`
+3. `What Keeps Going Wrong`
+4. `Where The Pattern Appears`
+5. `Process Change To Test`
+6. `What To Track Next`
+7. `Next Skill`
+
+Always include:
+
+- whether the sample is strong enough for conclusions
+- the clearest repeated strength
+- the clearest repeated mistake
+- where the pattern clusters: setup, timeframe, catalyst, instrument, or regime
+- one or two process changes to test next
+- whether the next step is `post-trade-review`, a revised rule in the journal, or no additional skill yet
+
+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 confuse outcome streaks with process quality
+- do not draw strong conclusions from tiny samples
+- do not hide repeated discipline failures behind a positive net PnL
+- do not recommend more than one or two process changes at once
+
+## Usage examples
+
+- "Use `journal-pattern-analyzer` on my last 25 swing trades and tell me what mistake keeps repeating."
+- "Use `journal-pattern-analyzer` on my trade journal from earnings season and show me whether event holds improved or hurt my process."

package/selected-skills/trading-skills/skills/journal-pattern-analyzer/references/calculation-helpers.md

@@ -0,0 +1,16 @@
+# Calculation Helpers
+
+What to work out, and where the numbers come from in this plugin: the analysis role has no shell and
+runs no helper scripts. Hand the journal sample and the statistics wanted to the host's data side
+(in a role-split host, the agent that owns statistics and quality checks), or show the arithmetic in
+the reply when the sample is only a few trades.
+
+The measures this skill cares about:
+
+- `expectancy` — win rate times average win, minus the loss rate times average loss; also worth
+  stating in R units (that same number divided by the average loss)
+- `kelly_fraction` — a reference number from win rate and payoff ratio, never a size to hand the user
+
+When the journal includes structured results, combine these measures with simple grouped summaries of
+win rate, average win, average loss, and loss clustering. Keep any conclusions provisional when the
+sample is small or inconsistently tagged.

package/selected-skills/trading-skills/skills/journal-pattern-analyzer/references/pattern-framework.md

@@ -0,0 +1,74 @@
+# Pattern Framework
+
+Use this framework to review a trade journal for repeatable strengths and mistakes.
+
+## What a journal review should answer
+
+- What is actually repeating?
+- Is the pattern about process, environment, or both?
+- Is the sample good enough to trust?
+- What is the one rule or change worth testing next?
+
+## What to group by
+
+When possible, group trades by:
+
+- setup type
+- timeframe
+- instrument
+- sector or theme
+- catalyst context
+- adherence quality
+- market regime
+
+## Common repeatable patterns
+
+Helpful patterns:
+
+- strongest setups are concentrated in one environment
+- best trades share better preparation or cleaner invalidation
+- worst trades cluster around event holds, open entries, or oversizing
+
+Risky patterns:
+
+- widening stops after entry
+- late chasing
+- taking profits too early relative to the plan
+- oversizing after recent wins
+- forcing trades in poor regimes
+- holding through catalysts without explicit reasons
+
+## Sample discipline
+
+Be careful when:
+
+- the sample is very small
+- only the most memorable trades are included
+- notes are sparse
+- different strategies are mixed together without separation
+
+## Good process changes
+
+Good changes are:
+
+- specific
+- testable
+- narrow
+
+Examples:
+
+- no breakout entries in the first 15 minutes
+- no event holds without a written reason
+- cut size after two process violations in a week
+
+Bad changes are:
+
+- trade better
+- be more disciplined
+- trust yourself more
+
+## Boundaries
+
+This framework does not prove a durable edge.
+
+It only helps the user learn from recorded behavior and improve process quality.