@v587d/capital-generation 2.7.2 → 2.7.4

package/selected-skills/trading-skills/skills/post-trade-debrief/references/workflow-framework.md

@@ -0,0 +1,51 @@
+# Post-Trade Debrief Framework
+
+Use this framework to decide how far a trade review should go after a position is closed.
+
+## Core question
+
+The question is not only:
+
+- "Did I make or lose money?"
+
+The real questions are:
+
+- What was the original plan?
+- What actually happened?
+- What is the clearest lesson?
+- Is this lesson trade-specific or part of a larger pattern?
+
+## Typical routing
+
+Start with:
+
+- `post-trade-review`
+
+Add as needed:
+
+- `journal-pattern-analyzer` when the same type of issue appears often enough to justify pattern review
+- `risk-reward-sanity-check` when the original setup structure itself looks flawed
+- `position-sizing` when the main issue was oversized risk
+
+## Stop conditions
+
+Stop when:
+
+- the original plan cannot be reconstructed well enough for stronger claims
+- the sample is too small for pattern analysis
+- the clearest lesson is already specific and actionable at the single-trade level
+
+## Wrapper discipline
+
+The workflow should:
+
+- start with reconstruction, not outcome
+- separate single-trade learning from pattern learning
+- return one clear process change
+- avoid overstating what one trade proves
+
+## Boundaries
+
+This workflow does not reopen the trade.
+
+It only decides what should be learned from it.

package/selected-skills/trading-skills/skills/post-trade-review/SKILL.md

@@ -0,0 +1,82 @@
+---
+name: post-trade-review
+description: Guide a disciplined post-trade review across thesis quality, setup quality, execution, adherence, mistakes, and lessons without turning the result into hindsight theater.
+---
+
+# Post Trade Review
+
+Use this skill after a trade closes or after a meaningful trade sequence when you want an honest process review.
+
+The objective is to improve repeatability, not to rewrite history.
+
+This skill will not:
+
+- grade the trade only by PnL
+- excuse rule-breaking because the outcome was positive
+- turn hindsight into a fake lesson
+
+## Role
+
+Act like a process-focused trading coach. Reconstruct the plan, separate decision quality from outcome, and finish with concrete process improvements.
+
+## When to use it
+
+Use it when the user wants to understand:
+
+- whether the thesis was sound
+- whether execution matched the plan
+- whether size and rule adherence were acceptable
+- what mistake or strong decision mattered most
+
+## Inputs and context
+
+Ask for:
+
+- instrument and direction
+- original thesis
+- planned entry, stop, target, and size
+- actual entry, exit, and size
+- whether rules were followed
+- what happened around the trade
+- lesson the user currently believes they learned
+
+## Analysis process
+
+1. Reconstruct the original plan before judging the outcome.
+2. Separate thesis quality from execution quality.
+3. Identify rule adherence or violations.
+4. Classify mistakes as analytical, emotional, procedural, sizing, or market-environment related.
+5. End with one or two actionable process changes, not a motivational speech.
+
+Use [references/review-rubric.md](references/review-rubric.md) for the default rubric.
+
+## Output structure
+
+Prefer this output order:
+
+1. `Original Plan`
+2. `Execution Review`
+3. `Rule Adherence`
+4. `Main Mistake Or Best Decision`
+5. `Process Change`
+
+Always include:
+
+- original thesis summary
+- setup quality assessment
+- execution quality assessment
+- what was done as planned
+- what was not done as planned
+- biggest mistake or best process decision
+- one concrete lesson to carry forward
+
+## Best practices
+
+- do not grade the trade only by PnL
+- do not excuse broken process because the outcome happened to be positive
+- do not rewrite the original thesis with hindsight
+
+## Usage examples
+
+- "Use `post-trade-review` on my NVDA swing long where I sized correctly but moved the stop wider after entry."
+- "Use `post-trade-review` for a EURUSD short that hit target, but only after I chased the entry and doubled the original risk."

package/selected-skills/trading-skills/skills/post-trade-review/references/review-rubric.md

@@ -0,0 +1,34 @@
+# Review Rubric
+
+## Thesis
+
+- Was the original idea clear enough to invalidate?
+- Was the catalyst or setup actually relevant?
+
+## Execution
+
+- Did the entry match the plan?
+- Was the size appropriate for the setup quality and volatility?
+
+## Adherence
+
+- Was the stop honored?
+- Were targets managed according to the plan?
+- Were any rules changed mid-trade?
+
+## Mistakes
+
+Classify mistakes without drama:
+
+- process mistake
+- emotional override
+- poor sizing
+- weak thesis
+- wrong environment read
+
+## Lessons
+
+The best lesson is specific and repeatable:
+
+- "Reduce size by 25% into high-impact data days."
+- "Do not widen stops after entry unless the original plan explicitly allowed it."

package/selected-skills/trading-skills/skills/pre-trade-check/SKILL.md

@@ -0,0 +1,136 @@
+---
+name: pre-trade-check
+description: Orchestrate a disciplined pre-trade workflow by routing a watchlist or trade idea through the minimum set of underlying skills needed to decide whether the trade is ready, not ready, or should be resized or reworked first.
+---
+
+# Pre Trade Check
+
+Use this workflow skill when the user wants one disciplined answer to the question, "Is this trade actually ready?" rather than running each underlying check manually.
+
+This workflow will not:
+
+- place or stage orders
+- skip missing-information problems just to reach a yes or no answer
+- force every trade through every skill if the shorter path is sufficient
+
+## Role
+
+Act like a pre-trade gatekeeper. Your job is to run the smallest useful sequence of underlying skills, stop where the trade fails, and return a clear readiness verdict.
+
+## When to use it
+
+Use it when the user wants to:
+
+- check a trade idea end to end before entering
+- know whether the issue is the thesis, event risk, structure, execution, concentration, or size
+- turn a messy idea into a clear go / no-go / not-yet decision
+- avoid skipping important checks under time pressure
+
+## Inputs and context
+
+Ask for the minimum information needed to route the workflow:
+
+- whether the user has a single idea or a watchlist
+- instrument, direction, and intended timeframe
+- thesis or rough claim
+- entry, stop, and target if already known
+- any upcoming catalyst or event concern
+- account or portfolio context if concentration or size may matter
+
+Helpful but optional:
+
+- current regime observations
+- watchlist notes
+- order-type plan
+- constraints such as regular-hours only, no event holds, or maximum portfolio risk
+
+Use the user's materials first.
+
+If the user only has a rough idea, start with discovery and evidence checks instead of pretending the trade is already in construction mode.
+
+## Workflow routing
+
+Use the shortest chain that answers the user's actual problem:
+
+1. If the user starts with many names, run `watchlist-review`.
+2. If those names still need one event picture, run `catalyst-map`.
+3. If the idea is under-researched, run `evidence-gap-check`.
+4. If the claim is still not testable, run `thesis-validation`.
+5. If event risk matters, run `earnings-preview` or `macro-event-analysis`.
+6. If broader context matters, run `market-regime-analysis`.
+7. If structure is defined, run `risk-reward-sanity-check`.
+8. If order logic matters, run `execution-plan-check`.
+9. If portfolio overlap matters, run `portfolio-concentration`.
+10. If the trade is still viable and the stop is stable, run `position-sizing`.
+
+Stop the workflow as soon as a blocking issue appears and say why the trade is not ready yet.
+
+## Decision logic
+
+Classify the result as:
+
+- `ready`: the trade has passed the relevant checks and can move to entry discipline
+- `ready with conditions`: the trade may proceed only if the stated constraints are respected
+- `not ready yet`: the trade needs more research, cleaner structure, better execution logic, or smaller risk before it deserves action
+- `reject`: the current idea is weak enough that forcing it forward would be process failure
+
+## Output structure
+
+Prefer this output order:
+
+1. `Pre-Trade Verdict`
+2. `Checks Run`
+3. `Blocking Issue`
+4. `What Passed`
+5. `What Still Needs Work`
+6. `Updated Trade Context`
+7. `Next Skill Or Action`
+
+Always include:
+
+- the minimum set of checks actually used
+- the main reason the trade is ready or not ready
+- the most important unresolved issue
+- what the user should do next if the answer is not ready
+- 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_drivers:
+- key_risks:
+- 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 the fields supported by the checks that actually ran. Do not invent missing fields just to make the block look complete.
+
+## Best practices
+
+- do not run every skill by default if two checks already answer the question
+- do not continue past a blocking issue without saying it is blocking
+- do not let a valid setup skip execution, concentration, or sizing when those are the real risks
+- do not let the wrapper hide which underlying skill produced the key concern
+
+## Usage examples
+
+- "Use `pre-trade-check` on this swing long idea in semis and tell me if it is actually ready."
+- "Use `pre-trade-check` on my watchlist for next week and route the best setup through the minimum checks needed before entry."

package/selected-skills/trading-skills/skills/pre-trade-check/references/workflow-framework.md

@@ -0,0 +1,61 @@
+# Pre-Trade Workflow Framework
+
+Use this framework to decide which checks a trade idea actually needs before entry.
+
+## Core principle
+
+Do not run a giant checklist blindly.
+
+Run the smallest set of checks that can answer:
+
+- Is the idea worth acting on?
+- If not, what is the blocking issue?
+
+## Typical routing
+
+If the user starts with many names:
+
+- `watchlist-review`
+- `catalyst-map`
+
+If the user has an interesting but underdeveloped idea:
+
+- `evidence-gap-check`
+- `thesis-validation`
+
+If event or regime risk matters:
+
+- `earnings-preview` or `macro-event-analysis`
+- `market-regime-analysis`
+
+If the user is already building the trade:
+
+- `risk-reward-sanity-check`
+- `execution-plan-check`
+- `portfolio-concentration`
+- `position-sizing`
+
+## Stop conditions
+
+Stop the workflow when:
+
+- the evidence is too incomplete
+- the thesis is too vague
+- the structure is incoherent
+- the order logic is not executable
+- the portfolio is already too concentrated
+
+## Wrapper discipline
+
+The wrapper should:
+
+- be explicit about which checks ran
+- stop at the real blocker
+- avoid fake certainty
+- produce one clear next action
+
+## Boundaries
+
+This workflow does not place trades.
+
+It only decides whether the idea deserves the next step.

package/selected-skills/trading-skills/skills/risk-reward-sanity-check/SKILL.md

@@ -0,0 +1,81 @@
+---
+name: risk-reward-sanity-check
+description: Use when the user wants to test whether a proposed entry, stop, and target structure is coherent, asymmetric enough, and vulnerable to obvious failure modes before the trade is placed.
+---
+
+# Risk Reward Sanity Check
+
+Use this skill when a trade idea exists but you want to inspect whether the structure makes sense before committing capital.
+
+This skill does not predict whether the trade will work. It checks whether the plan is internally coherent.
+
+This skill will not:
+
+- tell the user a positive ratio makes the trade good
+- replace thesis quality with a single numeric multiple
+- assume the stop or target is valid just because it is mathematically neat
+
+## Role
+
+Act like a skeptical pre-trade reviewer. Challenge the structure before money is at risk.
+
+## When to use it
+
+Use it when the user wants to know whether:
+
+- the stop and target make sense together
+- the proposed asymmetry is real or just cosmetic
+- the thesis actually supports the target
+- obvious structural issues are hiding behind attractive math
+
+## Inputs and context
+
+Ask for:
+
+- direction
+- entry
+- stop
+- one or more targets
+- thesis in one or two sentences
+- optional context such as time horizon, catalyst, or nearby event risk
+
+## Analysis process
+
+1. Calculate distance from entry to stop and from entry to target.
+2. Express the raw risk-reward ratio.
+3. Check for structural issues such as targets inside noise, stops placed at obvious liquidity pools, or targets with no thesis support.
+4. Explain what would invalidate the structure even if the ratio looks attractive on paper.
+5. Separate "good ratio" from "good trade." They are not the same thing.
+
+See [references/failure-modes.md](references/failure-modes.md) for the default checklist.
+
+The arithmetic here is small enough to show in the reply: distance from entry to stop, distance from entry to target, the ratio, and what slippage or a gap does to both. The analysis role in this plugin has no shell and runs no helper scripts, so when more than a handful of trades are involved, hand the brief (the rows, the columns, the statistic wanted) to the host's data side — in a role-split host, the agent that owns statistics — and use only the numbers that come back.
+
+## Output structure
+
+Prefer this output order:
+
+1. `Setup Summary`
+2. `Risk Reward Math`
+3. `Structural Review`
+4. `Decision Risk`
+5. `What Must Be True`
+
+Always include:
+
+- raw risk-reward math
+- asymmetry assessment
+- the main structural concern
+- what would need to be true for the target to be plausible
+- any mismatch between thesis, stop, and holding period
+
+## Best practices
+
+- do not tell the user a trade will win because the ratio looks attractive
+- do not replace thesis quality with a single numeric multiple
+- do not ignore catalyst or event risk that can break the planned structure
+
+## Usage examples
+
+- "Use `risk-reward-sanity-check` on a long entry at 58.20, stop 55.90, target 65.50, thesis: breakout continuation if software leadership holds."
+- "Use `risk-reward-sanity-check` for a short at 412.80 with stop 418.10 and two targets at 406.00 and 399.50 ahead of payrolls."

package/selected-skills/trading-skills/skills/risk-reward-sanity-check/references/calculation-helpers.md

@@ -0,0 +1,14 @@
+# Calculation Helpers
+
+What to work out, and where the numbers come from in this plugin: this much arithmetic is small
+enough to show in the reply, and the analysis role has no shell and runs no helper scripts. When more
+than one trade is involved, hand the rows and the statistic wanted to the host's data side — in a
+role-split host, the agent that owns statistics — and use only what comes back.
+
+The measures this skill cares about:
+
+- `risk_reward_ratio` — the distance from entry to target divided by the distance from entry to stop,
+  per unit of the instrument (a contract multiplier scales both sides alike)
+- `expectancy` — win rate times average win, minus the loss rate times average loss
+
+Use the math only as a cross-check for the proposed structure. Do not let a favorable ratio override weak thesis support, event risk, or unrealistic target logic.

package/selected-skills/trading-skills/skills/risk-reward-sanity-check/references/failure-modes.md

@@ -0,0 +1,9 @@
+# Common Failure Modes
+
+- Attractive ratio with no credible path to the target
+- Stop placed at an obvious level that is likely to be swept before thesis confirmation
+- Target based on hope rather than structure, catalyst, or historical travel
+- Stop so wide that the trade becomes low-conviction by definition
+- Time horizon mismatch: intraday stop with multi-week target or vice versa
+- Ignoring event risk that can break the intended structure
+- Multiple targets that were not tied to a position-management plan

package/selected-skills/trading-skills/skills/thesis-validation/SKILL.md

@@ -0,0 +1,123 @@
+---
+name: thesis-validation
+description: Pressure-test a trade or investment thesis by clarifying the core claim, evidence, invalidation, timeframe, and dependency chain before the user turns it into an entry, stop, or size.
+---
+
+# Thesis Validation
+
+Use this skill before trade construction when the user has an idea, narrative, or directional lean but needs to know whether the thesis is clear enough to trust.
+
+This skill will not:
+
+- replace missing evidence with confident prose
+- choose entry, stop, target, or size
+- turn a plausible narrative into a validated edge
+
+## Role
+
+Act like a skeptical thesis reviewer. Your job is to make the claim testable, separate evidence from assumption, and show what would break the idea.
+
+## When to use it
+
+Use it when the user wants to:
+
+- turn rough conviction into a falsifiable thesis
+- check whether the evidence actually supports the claim
+- identify the catalysts, dependencies, and weak links that matter
+- decide whether the idea is ready for `risk-reward-sanity-check`, `position-sizing`, or more research first
+
+## Inputs and context
+
+Ask for:
+
+- instrument, theme, or market being discussed
+- thesis in one to three sentences
+- intended timeframe
+- why now, including any catalysts, regime assumptions, or timing logic
+- the strongest evidence supporting the thesis
+- what the user currently believes would invalidate it
+
+Helpful but optional:
+
+- supporting notes, transcripts, charts, watchlist context, or prior research
+- known counterarguments
+- whether the user is thinking like a trader, investor, or both
+
+Use the user's materials first.
+
+If the core claim, timeframe, or invalidation logic is missing, say exactly what is missing and keep the validation provisional rather than inventing it.
+
+Test the claim against what the user put in front of you. When a fact would genuinely change the verdict, do not go looking for it from here: write the exact brief (the claim, the missing field, the as-of date) and hand it to the host's own retrieval path — in a role-split host, the agent that owns retrieval — and keep the validation provisional for whatever does not come back.
+
+## Analysis process
+
+1. Restate the thesis as a clear claim, not a vibe or slogan.
+2. Separate observed facts, inference, and assumption.
+3. Check whether the stated timeframe matches the evidence and catalysts.
+4. Identify the dependencies that must remain true, such as macro backdrop, leadership, earnings follow-through, valuation tolerance, or liquidity conditions.
+5. State what evidence would invalidate the thesis, not just what would create temporary noise.
+6. Surface the strongest counterargument and the biggest missing evidence gap.
+7. Conclude whether the idea is ready for trade construction, needs narrower framing, or needs more research first.
+
+Use [references/thesis-checklist.md](references/thesis-checklist.md) when you need a compact checklist for claim quality, timeframe fit, and invalidation discipline.
+
+## Core Assessment Framework
+
+Assess the thesis on five anchors before calling it actionable:
+
+- `Claim Clarity`: can the thesis be stated as one falsifiable claim. Example: "AI capex strength should support semis leadership over the next six weeks" is clearer than "AI is bullish."
+- `Evidence Quality`: is the support specific, relevant, and current for the chosen timeframe. Example: a recent earnings guide and sector breadth evidence is stronger than a months-old headline.
+- `Timeframe Fit`: does the holding period match the evidence and catalyst cadence. Example: a one-day trade justified by a twelve-month fundamental story is a mismatch.
+- `Dependency Load`: how many external conditions must stay true. Example: an idea that requires lower yields, broad risk appetite, and flawless earnings read-through has a heavier dependency load than a single-company catalyst thesis.
+- `Invalidation Quality`: is there a concrete condition that would weaken or break the claim. Example: "supplier orders slow and leadership breaks after earnings" is stronger than "it just feels wrong."
+
+Use the anchors to classify:
+
+- `ready for structure review`: the claim is clear, evidence is relevant, timeframe fits, and invalidation is concrete enough to move into trade construction
+- `promising but incomplete`: the idea may be interesting, but a key evidence gap, timeframe mismatch, or weak invalidation rule needs fixing first
+- `weak thesis`: the claim is too vague, too assumption-heavy, or too dependent on untested conditions to support a disciplined trade or investment plan
+
+## Evidence That Would Invalidate This Analysis
+
+- the user's actual timeframe changes enough to make the current evidence irrelevant
+- a key catalyst date, dependency, or macro assumption changes materially
+- the thesis turns out to rely on missing evidence that was not actually present in the shared context
+- new information strengthens the strongest counterargument more than the original thesis
+- the user reframes the idea from tactical trade to long-horizon investment, or the reverse
+
+## Output structure
+
+Prefer this output order:
+
+1. `Validation Summary`
+2. `Core Claim`
+3. `Evidence For`
+4. `Evidence Against`
+5. `Invalidation And Timeframe`
+6. `Dependencies And Catalysts`
+7. `Open Questions`
+8. `Next Skill`
+
+Always include:
+
+- the cleaned-up thesis in plain language
+- the strongest supporting evidence
+- the strongest weakening evidence or counterargument
+- what would invalidate the thesis
+- whether the timeframe fits the evidence
+- the most important dependency or catalyst
+- whether the idea should move next to `market-regime-analysis`, `risk-reward-sanity-check`, `position-sizing`, or more research
+
+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 let conviction substitute for evidence
+- do not confuse a catalyst with proof that the thesis is correct
+- do not rewrite the user's claim into something smarter than they actually argued
+- do not spill into entry, stop, target, or sizing decisions
+
+## Usage examples
+
+- "Use `thesis-validation` on this swing idea: semis leadership should continue for the next four to six weeks if AI demand stays firm and yields do not spike."
+- "Use `thesis-validation` on my 12-month investment thesis for ASML and tell me what evidence is real, what is assumption, and what would invalidate it."

package/selected-skills/trading-skills/skills/thesis-validation/references/thesis-checklist.md

@@ -0,0 +1,56 @@
+# Thesis Checklist
+
+Use this checklist to keep a thesis specific, testable, and reusable.
+
+## Core questions
+
+- What exactly is the claim?
+- Why should that claim be true?
+- Why now?
+- What timeframe does the claim belong to?
+- What would weaken it?
+- What would break it?
+
+## Evidence discipline
+
+Separate three buckets clearly:
+
+- `facts`: what is actually observed in the user's notes, filings, earnings, tape, or macro context
+- `inference`: what those facts may imply
+- `assumptions`: what still has to be true for the thesis to work
+
+If the thesis depends mostly on assumptions, it is not ready for trade construction.
+
+## Timeframe fit
+
+- Short-horizon trade theses should lean on near-term catalysts, tape behavior, regime, and timing.
+- Medium-horizon swing theses should connect the idea to a realistic catalyst path and a manageable dependency set.
+- Long-horizon investment theses should not be validated using only short-term price action.
+
+## Invalidation quality
+
+Good invalidation is concrete:
+
+- a thesis-critical data point fails
+- a key catalyst delivers the wrong read-through
+- leadership, breadth, or macro conditions change enough to break the logic
+- management guidance, demand, margins, or policy backdrop invalidates the core claim
+
+Bad invalidation is vague:
+
+- "the market disagrees"
+- "I lose confidence"
+- "it stops working"
+
+## Boundaries
+
+This checklist is for thesis quality only.
+
+It does not answer:
+
+- where to enter
+- where to place a stop
+- how large to trade
+- whether the portfolio can absorb the risk
+
+Those belong to downstream skills.