Trading indicator development
Deliver indicator code and evidence of its behavior for the user's chosen platform. These are original ChiefOS instructions informed by the three platform-pattern skill scopes in lgbarn/trading-indicator-plugins; that repository declares no redistribution license, so no source code or skill text is copied. No plugin, command collection, agent, or platform connection is installed.
First action
Identify the requested job: create, explain, debug, refactor, or port. Inspect the supplied code, expected behavior, error, and sample bars before editing. Determine target platform and language version, the indicator formula, input defaults, timeframe, session/timezone policy, and required plots or alerts. Ask only for a missing choice that changes behavior. For a port, establish the source implementation as the baseline; do not silently redesign its formula.
Read `references/platform-routing.md` for the selected target. Inspect the host for a real editor, compiler, test runner, browser, and platform access. Use current official platform documentation to verify API names and version-specific behavior. A source example, familiar function name, or installed skill does not prove that a call exists in the requested platform version.
Build or repair
1. State the calculation and lifecycle contract: inputs, initialization/warm-up, bar-close versus intrabar updates, session resets, history references, and outputs. Distinguish an indicator from an automated trading strategy. 2. Implement the smallest change that satisfies that contract. Preserve valid user behavior during a repair or refactor. Use user-selected naming and project conventions; do not impose an upstream author's initials. 3. Handle first bars, insufficient history, missing prices, zero volume, invalid parameters, timezone/daylight changes, and repeated updates to the same bar. Avoid look-ahead and hidden repainting. Explain any requested provisional intrabar value and when it becomes final. 4. For a port, map indexing, mutable state, execution frequency, historical versus realtime behavior, plot semantics, and session boundaries explicitly. Match calculations on the same bars before judging visual similarity. 5. Use a real platform compiler/runtime if available and authorized. Inspect diagnostics and repair failures. Otherwise give a copy-ready code proposal and a concrete platform check procedure; label it uncompiled and untested in-platform. A generic language parser cannot prove platform API validity.
Validation and deliverable
Check at least one normal calculation and an edge case with known expected results when the host can execute meaningful checks. For session VWAP, for example, a price series 10, 12 with volumes 1, 3 produces 11.5 before any reset; specify whether price means close or typical price. For a port or refactor, compare output series against the baseline with a stated numeric tolerance.
Return the changed code or confirmed file, required platform/version, formula and defaults, lifecycle/session assumptions, actual checks and results, remaining platform checks, and concise installation/use steps. Distinguish source edits, successful compilation, in-platform execution, and visual verification. Do not claim publication, installation, chart rendering, or parity without evidence. If an unsupported API blocks the implementation, show the exact unresolved operation and a documented alternative or bounded next step.
Reading or changing indicator code does not authorize platform credentials, paid data, alerts, broker orders, strategy activation, or live deployment. Return alert logic as code/proposals until a real authorized host creates it.