---

name: indicator-generator description: Create, modify, debug, and convert trading indicators AND STRATEGIES for TradingView (Pine Script v5/v6) and NinjaTrader 8 (NinjaScript C#). Use when writing indicators, strategies, adding features, refactoring, converting between platforms, or debugging. Follows Luther Barnum's coding standards. Triggers: "create indicator", "create strategy", "strategy for", "Pine Script", "NinjaScript", "convert to", "add feature", "VWAP", "keltner strategy", "ema cross strategy", "generate strategy from backtest". allowed-tools: Read, Write, Edit, Grep, Glob, Bash(dotnet:, npm:)

Trading Indicator & Strategy Generator

Generate professional trading indicators and automated strategies following Luther Barnum's coding standards for TradingView (Pine Script) and NinjaTrader 8 (NinjaScript C#).

Quick Start

For Indicators

1. Identify the target platform(s)
2. Reference the platform-specific template and patterns
3. Apply common conventions (author attribution, feature toggles, theming)
4. Follow indicator type patterns based on what you're building

For Strategies

1. Run /strategy:new or describe the strategy you want
2. Answer interactive prompts about signal, parameters, and features
3. Receive generated code for your target platform (Pine Script or NinjaScript)

See strategy/WORKFLOW.md for the full interactive workflow.

---

When to Use This Skill

Use this skill when:

• Creating a new indicator from scratch
• Generating automated trading strategies from backtested configurations
• Adding features to an existing indicator or strategy
• Converting indicators/strategies between platforms
• Refactoring code for performance or organization
• Debugging indicator/strategy calculation issues
• Understanding platform-specific patterns and conventions

Do NOT use for:

• CI/CD configuration (use ci-cd-setup skill)
• General code review unrelated to trading
• Non-trading-related code or scripts
• Tradovate strategies (indicators only for Tradovate)

---

Critical Rules (Quick Reference)

Pine Script - Must Know

See pine/PATTERNS.md for complete patterns.

NinjaScript - Must Know

See ninja/PATTERNS.md for patterns and ninja/TESTING.md for TDD guide.

Tradovate - Must Know

See tradovate/PATTERNS.md for complete patterns.

All Platforms - Mathematical Stability

Copy// Always guard against:
- Division by zero: `sumV > 0 ? sumPV / sumV : defaultValue`
- Negative sqrt: `Math.sqrt(Math.max(0, variance))`
- Array out of bounds: Check size before access
- NaN/Infinity: Validate data before calculations

---

Additional Resources

---

Strategy Generation

Generate automated trading strategies from backtested configurations for Pine Script and NinjaScript.

Commands

Available Entry Signals (11)

Metrics from 219-day NQ futures backtest with ADX di_rising, threshold 35.

Strategy Features (All Configurable)

• Entry Signals: All 11 backtested signals supported
• ADX Filter: 5 modes (traditional, di_aligned, di_rising, adx_rising, combined)
• ATR-based Exits: Stop loss, take profit, trailing stop
• Re-entry Logic: Trend continuation after profitable exits
• Volume Filter: Require volume > MA
• Session Filter: Trading hour restrictions

Strategy References

Example Usage

CopyUser: Create a keltner strategy for Pine Script
Assistant: [Runs interactive workflow]
  - Signal: keltner (EMA=20, ATR Mult=2.75)
  - ADX: threshold=35, mode=di_rising
  - Exits: SL=3.0×ATR, TP=3.0×ATR, Trail=0.15×ATR
  - Features: Re-entry, Volume Filter, Session Filter
  - Platform: Pine Script v6

[Generates LB_Keltner_Strategy.pine]

---

Platform References

Cross-Platform Examples

See EXAMPLES.md for complete examples of each indicator type across all platforms.

---

Common Conventions (All Platforms)

Author Attribution

• Pine: // by Luther Barnum - [Indicator Name]
• Ninja: // Author: Luther Barnum in file header
• Tradovate: tags: ["Luther Barnum"] in module.exports

Feature Toggles

All indicators use master enable/disable booleans in a "Feature Toggles" group:

Copy// Pine Script
enableVWAP = input.bool(true, "Enable VWAP", group="Feature Toggles")

Copy// NinjaScript
[Display(Name = "Enable VWAP", GroupName = "Feature Toggles", Order = 1)]
public bool EnableVWAP { get; set; }

Copy// Tradovate
params: {
  enableVWAP: predef.paramSpecs.bool(true),
}

Session Handling

• Default timezone: America/New_York (Eastern)
• Support RTH (Regular Trading Hours) and ETH (Extended)
• Handle midnight-crossing sessions
• Detect session start/end boundaries

Color Palette

Consistent colors across platforms:

Naming Conventions

• Variables: camelCase (vwapValue, ibHigh, sumPriceVolume)
• Prefixes: show*, enable*, prev*, cached_*, theme_*
• Suffixes: *Color, *Width, *Style, *_line, *_label

---

Indicator Types

1. VWAP Variants

Features: Daily/Weekly/Monthly VWAP, SD bands, anchored start times, MTF dashboard

Key calculations:

• Cumulative TPV (Typical Price × Volume)
• Standard deviation bands
• Session reset logic

2. Session-Based (IB, Opening Range)

Features: Time window detection, high/low tracking, extension levels, labels

Key calculations:

• Session start/end detection
• Running high/low within window
• Extension multipliers (0.5x, 1x, 1.5x, 2x)

3. Oscillators (RSI, ADX, Stochastic)

Features: Bounded values, overbought/oversold zones, signal crossovers

Key calculations:

• Period-based lookback
• Smoothing (EMA, SMA)
• Zone thresholds

4. Multi-Feature Composites (Pro Indicators)

Features: Multiple toggleable components, unified settings, dashboard

Architecture:

• Master feature toggles
• Modular calculation sections
• Combined plot management
• Performance optimization

---

Workflow

Creating a New Indicator

1. Start with the platform TEMPLATE.md
2. Replace placeholder values:
   • [INDICATOR_NAME] → Your indicator name
   • [SHORT_NAME] → Abbreviated name
   • [DESCRIPTION] → User-facing description
3. Add inputs following PATTERNS.md grouping conventions
4. Implement calculations in the appropriate lifecycle method
5. Add plots/drawing objects
6. Test on platform

NinjaScript TDD Workflow

For NinjaTrader indicators, follow TDD (Test-Driven Development):

1. Write tests first for calculation logic

   Copydotnet new nunit -n LB.Indicators.Tests -f net48
   

2. Create helper class with testable methods

   • Extract calculations to *Helper or *Calculator classes
   • Use dependency injection (pass bar data as parameters)

3. Run tests to verify (red-green-refactor)

   Copydotnet test
   

4. Integrate helper into indicator

   • Keep indicator thin (lifecycle methods only)
   • Call helper methods from OnBarUpdate

5. Verify all tests pass before completion

See ninja/TESTING.md for complete guide.

Adding Features to Existing Indicator

1. Add feature toggle in "Feature Toggles" group
2. Add feature-specific inputs in dedicated group
3. Add calculation variables
4. Implement calculation logic (guarded by toggle)
5. Add conditional plots/graphics
6. Update any dashboards

For NinjaScript: Write tests for new feature calculations first, then implement in helper class.

Refactoring Existing NinjaScript Indicator

When refactoring indicators that lack tests:

1. Identify pure calculations - VWAP, standard deviation, session detection
2. Write characterization tests - Capture current behavior
3. Extract to helper class - Move logic out of OnBarUpdate
4. Refactor with test protection - Tests prevent regressions
5. Run dotnet test - Verify all tests pass

Converting Between Platforms

1. Read source indicator thoroughly
2. Map inputs to target platform conventions
3. Translate calculation logic (watch for API differences)
4. Adapt plotting/drawing to target platform
5. Apply target platform naming conventions
6. Test thoroughly on target platform

---

Best Practices

Performance

• Cache repeated calculations (especially time conversions)
• Use var (Pine) or class fields (Ninja/Tradovate) for persistent state
• Avoid recalculating on every bar what only changes on session change
• Only render graphics on last bar when possible

User Experience

• Group related inputs logically
• Provide tooltips explaining each input
• Use sensible defaults matching common use cases
• Support both light and dark themes

Code Quality

• Use section dividers for organization
• Follow platform-specific naming conventions
• Comment complex calculations
• Keep functions focused and reusable