stop_loss_discipline_skill

Stop Loss Discipline Skill

Data dependencies and execution prerequisites

It is recommended to use Wind wind-mcp-skill to obtain the underlying data. Before execution, first check whether there is already wind-mcp-skill; 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 drops" 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 stage rather than dragging a trading mistake into an account problem.

Use cases

• The user wants to write the 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 debates 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 to confirm that the original plan has failed, not simply to fear losses.
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 triggering, there must be a clear sequence of actions; it cannot merely say "consider reducing the position."
5. The main text only outputs the discipline framework and execution recommendations, 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 originally 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 logic delays

Step 2: Set the price stop-loss boundary

First give the most intuitive price discipline:

• Which key support, platform, or structural level cannot be effectively broken below
• Whether to use closing confirmation, intraday breach, or failure over multiple consecutive days as the determination
• Whether volatility buffer should be considered to avoid being easily shaken out by normal noise
• If the underlying is naturally highly volatile, whether position size should be reduced rather than loosening discipline

Step 3: Identify logic stop-loss triggers

Some trades do not go wrong in price first, but in 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 key catalysts have been falsified or delayed
• Whether the holding reason has quietly changed from an "active plan" to "passive stubborn holding"

Step 4: Set a time stop-loss

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

• How quickly it was originally expected to be validated, and whether it has now clearly been delayed
• Whether sideways movement or weak oscillation has occupied too much capital and attention
• Whether the current time cost causes better opportunities to be missed
• After the time threshold is reached, should you exit entirely or first reduce the position 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 cut the position in half and then observe, or exit all at once
• After an intraday trigger, is waiting for a specific confirmation allowed
• If a gap-down breaks the level, does the execution method need to be adjusted
• After a stop loss, is reevaluation 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 think "wait a little longer this time"
• Refusing to execute objective rules because of anchoring to the cost price

Step 7: Form the final draft of stop-loss discipline

The final output should help users know "under what circumstances they must act, 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 subject: {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 break of the level: {content}
• Quickly recovers 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. It must cover all three levels at the same time: price, logic, and time.
2. Trigger conditions should be as objective as possible; do not only write "feels weak."
3. It must give clear actions after a trigger, not vague suggestions.
4. If exceptional situations exist, the applicable boundaries must be explained.
5. The output should reduce hesitation about stop-losses, not help delay them.