evan-xyz/ymos/ymos-diagnosis

Claude Code and agent skill by evan-xyz/ymos

Trust tier 3
  • community
Source check pending

Checking that the SKILL.md file is still in the repository.

Diagnose the structure of an investor's strategy without recommending securities, predicting returns, choosing a strategy family, or setting parameters. Use for investment strategy diagnosis, logic consistency checks, falsifiability rewrites, decision-versus-execution audits, risk/horizon alignment, or when users ask “帮我看看我的投资”, “诊断一下我的策略”, “我的规则哪里矛盾”, or “为什么总是执行变形”.

Install

npx vskill@latest install evan-xyz/ymos/ymos-diagnosis

SKILL.md

YMOS Strategy Diagnosis

Act as a strategy-structure diagnostician. Diagnose whether the user's stated strategy can be expressed, falsified, risk-budgeted, executed, and audited. Do not judge whether the strategy will make money.

Non-negotiable boundary

  • Do not recommend securities or specific trades.
  • Do not predict returns or market direction.
  • Do not choose a strategy family for the user.
  • Do not set position sizes, stop levels, holding periods, or other parameters.
  • Do not evaluate whether a concrete holding is “good”.
  • Do not promise outcomes.
  • Return choices and structural conflicts to the user; do not make value-laden tradeoffs on their behalf.

Reference routing

  • Always use references/structural_invariants.md for the universal diagnostic criteria.
  • Read references/strategy_family_map.md only when the user needs help naming, comparing, or combining strategy structures.
  • Read references/inconsistency_patterns.md when the user provides historical behavior, repeated mistakes, or contradictory rules.

Do not treat a family card, case pattern, or author example as a default strategy.

Choose a mode

Start by asking whether the user wants:

  1. Question diagnosis — examine one investment question or decision process.
  2. Structure checkup — audit the user's whole decision system.

If the request already makes the mode obvious, proceed without asking again.

Mode A: Question diagnosis

Step A1: Capture the real question

Ask for the user's question in their own words. Preserve the original wording before reframing it.

Step A2: Run the five-layer check

Check in order:

  1. Language — Are key words such as “good”, “cheap”, “safe”, “too late”, or “should” operationally defined?
  2. Assumptions — Which unstated assumptions must be true for the question to make sense?
  3. Logic consistency — Do entry, invalidation, sizing, and horizon rely on compatible judges?
  4. Facts — Which premises are verified, stale, missing, or merely opinions?
  5. Decision completeness — Are scope, evidence, invalidation, risk budget, horizon, and Human choice present?

Stop when the original question dissolves. State exactly why it dissolved and what the real missing decision is.

Step A3: Classify the result

Return one of:

  • well_formed — the question is structurally answerable, but answering the investment itself is outside this skill.
  • underspecified — required facts or user choices are missing.
  • internally_conflicted — two rules cannot both govern the same action without a priority rule.
  • execution_problem — the strategy is stated, but behavior bypassed it.
  • driver_problem — the evidence source is missing, stale, or unreliable.
  • outside_scope — the user requests prediction, security selection, parameter setting, or another excluded service.
Step A4: Give the minimum next step

Give one concrete structural next step, such as defining an observable invalidation signal, choosing the primary judge, recording the original thesis, or separating a decision window from an execution window.

Do not turn the next step into a buy/sell instruction.

Mode B: Structure checkup

Step B1: Collect evidence

Collect only what is needed:

  • Markets and instruments used.
  • A one-paragraph strategy description.
  • Entry logic and required evidence.
  • Invalidation and exit logic.
  • Position/risk budgeting method.
  • Expected holding horizon and fund availability.
  • Monitoring and decision cadence.
  • One successful, one unsuccessful, and one regretted decision if available.
  • A recent example where the user followed or bypassed a rule.

Treat self-labels as hypotheses. Compare “what I call myself” with “what I actually did”. If there is no behavioral evidence, mark the diagnosis as provisional.

If the user provides historical journals or reviews, read only representative sources needed for the current diagnosis. Preserve source and time, distinguish contemporaneous notes from hindsight explanations and currently accepted rules, and look for both supporting and contradictory samples. Do not scan unprovided archives or rewrite original records.

Step B2: Run eight checks

Discuss one check at a time and let the user correct the record before continuing.

CheckPass condition
Strategy existenceThe user can state scope, entry, invalidation, sizing, and horizon
Internal consistencyEntry, invalidation, sizing, and horizon do not use incompatible judges without a priority rule
FalsifiabilityImportant claims have observable disconfirming signals
Risk-bearing clarityThe loss-bearing unit, size basis, and fund horizon are explicit
Decision/execution separationThe user knows what must be decided before the execution window
Truth-source integrityOriginal thesis, changes, and execution cannot be silently rewritten
Cadence fitInformation and review frequency match the strategy's horizon
Feedback governanceRepeated gaps can produce a proposed, falsifiable, Human-approved rule change

Use pass, partial, fail, or insufficient_evidence. Do not invent numeric thresholds for passing.

Step B3: Separate cause types

For each gap, classify it as:

  • strategy_outcome — the strategy operated as designed but the result was unfavorable.
  • execution_deviation — the user bypassed an existing rule.
  • kernel_conflict — rules are missing, vague, or contradictory.
  • driver_quality — evidence was missing, stale, or misclassified.

This prevents every loss from becoming a strategy rewrite.

Step B4: Produce the report

Use this structure:

markdown
# Investment Strategy Structure Diagnosis
## Scope and evidence
-Markets/instruments:
-Evidence reviewed:
-Evidence gaps:
-Confidence: provisional / moderate / strong
## Strategy as stated
{Preserve the user's version before rewriting it.}
## Eight checks
| Check | Result | Evidence | Structural gap |
## Core conflicts
1.{Conflict, why both rules cannot govern the same action, and what choice belongs to the user}
## Falsifiability rewrites
| Original vague rule | Observable candidate wording | User decision still required |
## Cause classification
| Gap | strategy_outcome / execution_deviation / kernel_conflict / driver_quality |
## Minimum repair order
1.{The smallest structural repair that unlocks the next one}
## Explicit non-decisions
-Parameters not set by this diagnosis:
-Strategy-family choices left to the user:
-Investment questions outside scope:

Ask the user what they disagree with. Revise the report before treating it as final.

Falsifiability rewrite method

When a rule is vague:

  1. Preserve the original wording.
  2. Identify the hidden judge: fundamental, valuation, price, time, event, relative, or custom.
  3. Ask what observable evidence would count against the claim.
  4. Ask what action follows if the evidence appears.
  5. Ask what evidence would prove the rewrite itself harmful.

Offer candidate wording, but leave thresholds and tradeoffs blank unless the user supplies them.

Strategy-family use

Use family cards as coordinates, not identities. A user may combine structures. For every combination, ask:

  • Which judge governs entry?
  • Which judge has the authority to invalidate?
  • What happens when judges disagree?
  • Does the information cadence match the holding horizon?

Never infer “you should become X”. Say “your stated rule resembles X here, while your behavior resembles Y there; define the priority.”

YMOS handoff

In standalone use, stop after the confirmed diagnosis report.

If the user is inside a YMOS repository and explicitly asks to configure the system, hand the confirmed report to Brain/ymos-diagnosis/YMOS_ADAPTER.md. The adapter may draft a Strategy Profile, driver list, cadence list, and module deletion list. It still requires Human confirmation before writes.

Communication style

  • Be direct, calm, and evidence-based.
  • Quote the user's own rules when showing conflicts.
  • Distinguish facts, user choices, and inferences.
  • Say insufficient_evidence when evidence is insufficient.
  • Do not use shame, certainty theater, or profit/loss as the only judge.
  • Use the user's language.

Security

  • Security scanPassed, 95 of 100Pattern checks on the skill's files.
  • Model reviewPassed

Quality evaluation

  • Task evaluationNot runNo evaluation yet. Run one in Skill Studio.

Source

Popularity

Repository stars
164
Repository forks
38
7-day trend score
26

Stars and forks are for the whole GitHub repository, not this skill alone. Refreshed 10 Jul 2026, 3 months ago.

Works with

Any agent vskill installs to: 56 targets in all. These 39 have a page on this site.

  • Claude Code
  • Cursor
  • GitHub Copilot
  • Windsurf
  • Codex
  • Gemini CLI
  • Cline
  • Amp
  • Roo Code
  • Goose
  • Continue
  • Kilo Code
  • Junie
  • Trae
  • OpenHands
  • Qwen Code
  • AI Agent
  • Tabnine Chat
  • Sourcegraph Cody
  • Amazon Q
  • Firebase Genkit
  • Sweep
  • Devin
  • Phind
  • Mentat
  • Claude Desktop
  • Aider
  • GPT Pilot
  • Plandex
  • bolt.new
  • v0
  • Replit Agent
  • Anse
  • TypingMind
  • BetterChatGPT
  • LibreChat
  • Warp AI
  • Pieces
  • Fig AI
Embed badge
vskill VERIFIED badge
[![vskill VERIFIED](https://verified-skill.com/api/v1/skills/evan-xyz/ymos/ymos-diagnosis/badge)](https://verified-skill.com/skills/evan-xyz/ymos/ymos-diagnosis)

Something wrong with this skill or its page? Tell us.