Agent Skills › Lumiwealth/lumibot › stock-trading

stock-trading

GitHub

股票与ETF交易决策技能,涵盖仓位管理、行情获取、指标计算及订单执行。指导Agent在交易前读取组合状态与市场数据,严格依据工具计算的信号评估入场/出场规则,确保报价与历史数据准确无误,避免人工估算错误。

lumibot/components/agents/skills/stock-trading/SKILL.md Lumiwealth/lumibot

触发场景

用户询问股票或ETF交易策略 需要执行买入或卖出操作 分析投资组合中的证券持仓 进行量化选股或动量交易

安装

npx skills add Lumiwealth/lumibot --skill stock-trading -g -y
更多选项

非标准路径

npx skills add https://github.com/Lumiwealth/lumibot/tree/dev/lumibot/components/agents/skills/stock-trading -g -y

不安装直接使用

npx skills use Lumiwealth/lumibot@stock-trading

指定 Agent (Claude Code)

npx skills add Lumiwealth/lumibot --skill stock-trading -a claude-code -g -y

安装 repo 全部 skill

npx skills add Lumiwealth/lumibot --all -g -y

预览 repo 内 skill

npx skills add Lumiwealth/lumibot --list

SKILL.md

Frontmatter
{
    "name": "stock-trading",
    "description": "Use before researching, selecting, opening, modifying, or closing a stock or ETF position, including discretionary investing, rotation, breakout, momentum, mean-reversion, opening-range breakout, and VWAP trading. Also use when a broad mandate leads you to consider stocks or ETFs even if the user did not name an asset class initially."
}

Stock Trading

Load this skill before using stocks or ETFs as part of a trading decision. If a broad mandate leads you to a stock idea, load it before submitting an order.

Core workflow

  1. Read portfolio value, cash, current positions, and open orders.
  2. Read market_quote before sizing; prefer market_quotes for a basket. For an immediate buy use a valid ask as its executable cost; for an immediate sell use a valid bid. For an explicit limit, size at that limit. When a quote side is unavailable, its valid current price, or a fresh market_last_price / market_last_prices, is a usable disclosed fallback. Missing bid/ask alone does not make a priced stock untradeable. Do not substitute an old historical close for the execution price. Keep last (price), bid and ask distinct in calculations and reporting. Copy the observed field with its correct label; never relabel last or mid as bid. Retrieve recent price history for every serious candidate. Read that history with market_historical_prices, also for a single symbol; pass table_name to query it with duckdb_query. market_load_history_table does not replace it before a stock order. Compute averages and indicators with a tool (get_indicator, get_indicators, or duckdb_query over loaded bars), never by mental arithmetic, and quote the tool's value. A query returning individual closes has not computed their average. Request the aggregate or indicator and inspect its returned value before using it in a decision or describing it as tool-calculated. For lookback rules, select the requested count of the latest completed bars and match the reported indicator and date window to that tool result. When reporting a date span, retrieve the first and last timestamps of those same selected rows alongside the aggregate. Do not infer their dates from a bar count or an assumed weekday calendar. If the result does not give the window, omit that extra date claim. Do not discard an already-completed bar again or substitute an earlier indicator row. For a historical snapshot select the latest eligible row by timestamp and read that row's close. Selecting MAX(close) alongside MAX(datetime) pairs unrelated values and does not select the snapshot-date price.
  3. Use batch tools for a universe. Do not loop one symbol at a time when a batch price or history tool can return the same evidence.
  4. Evaluate the user's entry, exit, sizing, and frequency rules against current evidence. Write down the decisive condition and whether it is true before submitting an order. Do not invent missing signals. Keep the explanation's comparisons identical to the evaluated rule: a latest price exceeding an average does not establish that every constituent bar exceeded it. If a claim concerns all bars, their count, or a date range, compute and inspect that exact predicate from the returned data before asserting it.
  5. Size from current portfolio value, available cash, current price, volatility or stop distance, and the user's risk rules. For a notional cap, calculate the maximum notional and call risk_calculate_stock_quantity; use its returned whole-share quantity unchanged. Verify its notional is at or below both the cap and available cash before submission. Submit only when the returned quantity is greater than zero; otherwise make a no-trade decision.
  6. Submit the selected order once. Price a limit order from the current quote or current last-price fallback, never from a historical bar's close: a buy limit below the current price usually does not fill. Follow the order tool's guidance when the order must fill this session. This is for a new order; it is never a reason to modify an order that is already pending (see step 8).
  7. Capture the returned identifier, inspect that exact order, and reread positions and open orders. In backtests, a short bounded orders_wait_for_terminal is appropriate immediately after your own market-order submission because it lets the simulator process the pending fill. Do not use an unbounded wait.
  8. If a related order is already open, call orders_get_status with its returned identifier to inspect that exact order; listing open orders alone does not replace this status read. Do not submit another order for the same intended position change. A pending exit already owns the exit: leave it in place and report that it owns the position change. Modify or cancel and replace it only when the user's rules explicitly require changing an existing order. A due exit condition or a nonmarketable limit alone does not authorize changing an already-pending exit.
  9. Keep the final decision evidence compact and exact. For a bar-based signal, identify the particular completed bar used and copy that row's timestamp, close and volume. Do not collapse several bars into one set of values: one bar's volume does not describe every bar in a range. Report an aggregate only when a tool actually returned that aggregate for those rows. Extra market commentary is unnecessary when the requested rule and outcome are clear. Reconcile the final summary with the mutation tools and the final account reads. If an order tool returned a submitted identifier, never say that no order was entered. Report the exact observed status instead. Reconcile cash from confirmed fill quantities, execution prices and fees. Portfolio value already includes cash and current position valuation; do not add cash again or equate that total with the gross purchase debit. Compute any equity or profit/loss comparison with a tool on that same price basis. If it was not computed, report the returned cash/equity without adding an unsupported discrepancy or gain/loss explanation. Purchase cost plus remaining cash need not equal current equity: positions are marked at current prices, which can differ from fills. That expected difference is not an unreconciled account or target mismatch. Flag a mismatch only after comparing quantities, reserves or values on the same basis.

Complete portfolio work

For an authorized allocation or rebalance build one compact full-inventory plan on the requested capital basis: target amounts/quantities, held and pending quantities, funding sells, remaining buys and real exceptions. A prescribed allocation is the trading mandate; do not require a separate discretionary conviction thesis before replicating each requested constituent.

Calculate the capital basis and reserve before quantities: investable capital is the authorized basis times the requested investment fraction (or basis minus the requested reserve). Each allocation cap is investable capital times its target weight. Verify multiplication/division with an available arithmetic tool. An unavailable name keeps its allocation in cash, alongside the original reserve; do not silently use the full account as the allocation basis or renormalize the supported subset unless the user authorized that change.

Compare the sizing tool's returned quantity with the quantity you submit. Do not silently subtract shares or invent extra reserve when the requested allocation is already affordable. If execution uncertainty warrants a smaller first order, reconcile its actual fills, remaining allocation and current price, then complete any affordable residual without breaching the cap or reserve. A residual large enough to buy another share is not whole-share rounding; report it as incomplete until filled or blocked by observed evidence.

Work through every feasible required change in this run. Prefer orders_submit_orders for a jointly sized independent basket: pass explicit order rows, verify all returned identifiers together, then reconcile actual account state. A batch is not atomic; verify funding sells before submitting dependent buys. Preserve atomic option packages through orders_submit_multileg. Use batch quotes and history when the task needs historical analysis; an explicit allocation does not need an invented historical entry signal. After each mutation refresh the account and complete position/open-order pagination, then size only the next intended order against its allocation cap and actual available cash. Do not restart all remaining sizing calculations after each fill. An existing correct holding requires no new purchase; a pending order owns only its own remaining quantity. Verify funding sells before buys.

Before finishing compare the full target set to actual positions and terminal orders. A few confirmed trades or an acknowledgement are not full completion. Continue supported independent trades when one constituent is unavailable. Explain each actual missing price, unaffordable quantity or broker failure; do not invent an exception or finish merely because the basket is long. Never force a token trade, breach an allocation cap, short or overspend to satisfy a count.

Use this stopping rule for the execution loop: after each verified change, remove only that completed quantity from the worklist and continue to the next feasible item. There is no default cap on trades per iteration. An honest report that only a few requested holdings were bought still leaves the task unfinished. When the final comparison finds an affordable missing target with usable current pricing and no conflicting pending order, call the next order tools instead of ending the run. Stop only when the whole inventory is reconciled or every remaining item has its own observed blocker.

Research depth

Match research to the strategy. A broad discretionary investment decision should use relevant technical, news, macro, and company evidence when available. A mechanical intraday strategy should prioritize the exact price, bar, volume, and indicator evidence required by its rules. Do not force irrelevant research merely to increase tool use.

References

Load only the smallest relevant reference:

  • references/research-sizing-and-orders.md: evidence, sizing, entries, exits, rotation, and order verification.
  • references/intraday-setups.md: opening-range breakout and VWAP mechanics.

The user's active strategy rules decide whether a trade should happen. This skill provides reusable stock-trading mechanics and does not invent a strategy.

Explain consequential order actions

Supply an explicit reason before every submission, modification or cancellation. Use at least 200 characters; aim for 600–2,500 when the decision needs it. Explain the thesis, dated evidence, sizing, material risks and what would invalidate it. State missing evidence honestly. This is a decision summary, not hidden internal reasoning, and must contain no credentials or account identifiers. The order service commits it before execution. Report only observed order status and fills; reconcile an uncertain outcome before trying again.

When a separate public_reason is requested, write the qualitative thesis and one material risk in one short sentence, usually 15–25 words. Leave ample room under the tool's 280 UTF-8 byte limit; several explanatory sentences can exceed it even when they look short. Detailed dates, calculations and invalidation conditions belong in the private reason. Keep portfolio-relative sizing percentages, formulas, account value, buying power, owner context and tool purposes in the private reason only. Do not copy its sizing explanation into the public summary. Follow the order tool's public-summary contract before submitting; later omission of an unsafe summary does not make that proposed summary suitable for sharing.

版本历史

  • 113c6c8 当前 2026-11-02 20:55

    合并LumiBot版本分支,修复市场标记与目标不匹配问题,澄清现金包含的权益估值报告,完善通用报价、篮子交易及源账本工作流,确保模拟执行条带准确性。

  • 8b0caca 2026-10-19 04:10

    修正交易解释需忠实于评估证据,修复保留挂单退出和已完成K线回溯的问题,新增执行前记录订单解释功能。

  • 2dfdda1 2026-09-27 21:24

    更新核心工作流:明确使用工具(如get_indicator)计算平均值而非心算;细化订单提交逻辑,禁止修改待处理订单;修复相关测试用例以适配新模型默认配置。

  • f987da3 2026-09-09 03:57

    强化代理和经纪商的安全边界,硬化交易决策及发布闸门逻辑。

  • c99491d 2026-08-27 18:16

同 Skill 集合

lumibot/components/agents/skills/options-trading/SKILL.md
lumibot/components/agents/skills/research-data/SKILL.md
lumibot/components/agents/skills/web-documents/SKILL.md

元信息

文件数
0
版本
113c6c8
Hash
11b8833c
收录时间
2026-08-27 18:16

首页 - Wiki
Copyright © 2011-2026 iteam. Current version is 2.156.0. UTC+08:00, 2026-11-06 23:36
浙ICP备14020137号-1