stop_loss_discipline_skill

Stop Loss Discipline Skill

Data Dependencies and Execution Prerequisites

It is recommended to use Wind wind-mcp-skill to obtain underlying data. Before execution, first check whether there is already wind-mcp-skilllocally; if not, prompt the user to install:

# GitHub
npx skills add Wind-Information-Co-Ltd/wind-skills --skill wind-mcp-skill -g -y

# Gitee 镜像（国内）
npx skills add https://gitee.com/wind_info/wind-skills.git --skill wind-mcp-skill -g -y

Skill Positioning

This skill is used to transform "wait and see after it falls" into a disciplined plan of "when to admit the mistake, how to admit it, and what to do after admitting it." The output focus is not to encourage mechanical liquidation, but to help users set clear exit triggers in advance and reduce the most common procrastination, wishful thinking, and self-rationalization during holding.

Function Overview

The core function of this skill is: designing stop-loss trigger conditions and execution actions.

It emphasizes incorporating price invalidation, logic invalidation, and time invalidation into management at the same time, helping users complete their judgment early in the loss rather than dragging a trading mistake into an account problem.

Use Cases

• The user wants to write stop-loss discipline clearly before placing an order.
• The position has already entered an unfavorable state, but it is unclear whether it should be handled immediately.
• The team needs a unified stop-loss language to reduce ad hoc arguments during trading hours.
• The user often "knows they should stop out, but always cannot bring themselves to do it."

Working Principles

1. The essence of a stop-loss is confirming that the original plan has failed, not merely being afraid of a loss.
2. It is necessary to distinguish noise fluctuations from true invalidation, avoiding treating random disturbances as the end of the plan.
3. Stop-loss discipline should cover the three dimensions of price, logic, and time.
4. After a trigger, there must be a clear sequence of actions; it is not enough to write only "consider reducing the position."
5. The main text outputs only the discipline framework and execution suggestions, and does not describe the internal implementation process.

Execution Process

Step 1: Confirm the original trading plan and invalidation criteria

Any stop-loss design must return to the original plan itself:

• What logic was this trade initially established on
• Once which key variable is broken, the plan no longer holds
• Whether the current position belongs to the trial-and-error stage or the confirmation stage
• Whether the user is more worried about price fluctuations or logical delay

Step 2: Set the price stop-loss boundary

First give the most intuitive price discipline:

• Which key support, platform, or structural level must not be effectively broken below
• Whether to use closing confirmation, intraday breach, or failure over multiple consecutive days for identification
• Whether volatility buffering should be considered to avoid being easily washed out by normal noise
• If the underlying asset is naturally more volatile, whether the position should be reduced rather than loosening discipline

Step 3: Identify logical stop-loss triggers

Some trades do not go wrong in price first, but in the reason first. It is necessary to check:

• Whether the originally relied-upon events, performance, capital, or sector support have disappeared
• Whether market divergence has already converged in an unfavorable direction
• Whether the key catalyst has been falsified or delayed
• Whether the reason for holding has quietly changed from an "active plan" to "passively holding on for dear life"

Step 4: Set a time stop-loss

If a trade does not evolve in the planned direction for a long time, it should also be regarded as a cost:

• How quickly was validation originally expected, and is it now clearly delayed
• Whether sideways movement or weak oscillation has occupied too much capital and attention
• Does the current time cost cause better opportunities to be missed
• After the time threshold is reached, should you exit entirely or reduce the position first and then observe

Step 5: Design the action priority after a trigger

A stop-loss is not a button, but a sequence of actions:

• Should you first halve the position and then observe, or exit all at once
• After an intraday trigger, is it allowed to wait for a specific confirmation
• If a gap-down breach occurs, does the execution method need to be adjusted
• After a stop-loss, is re-evaluation allowed, or must you wait for a new structure

Step 6: Handle common interference factors

Write clearly in advance the situations most likely to break discipline:

• The sector temporarily weakens but the individual stock logic is not broken
• Quickly recovers after breaking below
• After consecutive small losses, the impulse arises to "wait a bit longer this time"
• Refusing to execute objective rules because of anchoring to the cost price

Step 7: Form the final stop-loss discipline draft

The final output should help users know "under what circumstances action must be taken, how to act, and how to review after acting." The main text should retain trigger conditions, action sequence, and exception-handling principles.

Output structure

---

Stop-Loss Discipline Plan ({YYYY-MM-DD})

I. 30-second conclusion

• Position object: {stock name}
• Current status: {not entered / entered / near invalidation}
• Core stop-loss type: {price / logic / time}
• Execution tendency: {strict execution / conditional execution / continue observing}
• Biggest risk point: {one sentence}

II. Stop-loss framework

Dimension	Trigger condition	Execution action
Price stop-loss	{content}	{content}
Logic stop-loss	{content}	{content}
Time stop-loss	{content}	{content}

III. Handling exceptional situations

• Normal noise fluctuation: {content}
• Gap-down breach: {content}
• Quick recovery after breaking below: {content}

IV. Actions after stop-loss

• {action 1}
• {action 2}
• {action 3}

V. Discipline reminders

• {reminder 1}
• {reminder 2}
• {reminder 3}

---

Quality requirements

1. Must cover all three levels simultaneously: price, logic, and time.
2. Trigger conditions should be as objective as possible; do not write only "feels weak."
3. Clear actions after the trigger must be given, not vague suggestions.
4. If exceptional situations exist, the applicable boundaries must be explained.
5. The output should reduce hesitant stop-losses, not help delay.