I learn most of my technical analysis from a YouTuber who draws harmonic patterns fast, by feel, after years of doing it. I've spent real time trying to spot Gartleys and Crabs the way he does and I'm not as good at it. TradingView's harmonic indicators don't follow his specific rules: his ratio definitions, his tolerance bands, his read on which patterns are reliable. One member of his Discord built a version that does follow those rules, but it's private. I could watch it work; I couldn't open it up or build on it.
So the rules existed, I just had no way to build against them. That's what sent me into Pine Script to reverse-engineer it.
The rulebook I could see but not run
The framework is eight harmonic patterns (Gartley, Bat, Alt Bat, Butterfly, Deep Butterfly, Crab, Deep Crab, Shark), each with its own Fibonacci ratios at every leg, plus tolerance bands at 5% and 10% for how far price can drift from the ideal ratio before the pattern is invalid. What I lacked was code that checked a live chart against it. The public TradingView scripts use a generic six-pattern set with no tolerance scoring. The Discord member's script follows the rules but is closed-source, so I could only compare against its output.
Starting from someone else's code
I started from a public-domain Pine Script harmonic detector: six pattern types (Gartley, Bat, Butterfly, Crab, Shark, Cypher), decent at drawing XABCD structures, no ratio framework. The job was less "write an indicator" and more "rebuild this until it implements the rules I'm trying to learn." First change was the pattern set: drop Cypher, add Alt Bat, Deep Butterfly, and Deep Crab.
Where find-and-replace fell short
The original hardcodes each pattern type into its own array and its own branch of logic, repeated across four or five places: storage, coloring, label symbols, target calculation. That's fine for six contiguous numbers. Dropping one type and adding three with non-contiguous IDs meant new cases by hand in every location. I replaced it with one lookup that maps each pattern type ID onto a dense index; colors, names, symbols, and arrays all read off that index. A ninth pattern is one new line in one place.
The line-drawing code had the same problem: it assumed leg three is always the X-A line, leg four always C-D, which breaks once pattern types share drawing logic across shapes. I rewrote it to check actual coordinates first and only fall back to positional guessing if that fails. Slower to write, much harder to silently get wrong.
A bias that was the absence of a rule
Testing against real charts, the rebuild kept favoring one shape when multiple patterns were plausible in the same zone. There was no tie-break logic at all: when more than one type matched, whichever was checked first in a hardcoded list order won every time. The fix was to score candidates by how closely each key ratio fits the ideal Fibonacci level and keep the best fit.
A related bug surfaced once better-scoring patterns started replacing others: lines and fills from the discarded pattern stuck around on the chart. A couple of deletion paths weren't cleaning up their drawings. I routed all deletions through one shared cleanup function.
Why the loop looks ugly
Pine Script has no recursion, and the script scans pivot lengths from 3 to 20 bars. Written cleanly as a shared loop body, every length re-evaluates and redraws on every pass. The version that doesn't redraw the same pattern eighteen times a bar is eighteen explicit calls, each gated by its own if. The real fix for slow loads was a minimum pivot length floor so the script skips lengths nobody asked for. I also collapsed the original's per-pattern profit-target config (six pairs of dropdowns, a dozen-plus options each) into one shared Fibonacci extension from point D. Less configurable, a fraction of the code, one less place to drift out of sync.
Checking the math
Without the mentor's chart-reading years or the Discord member's source, I checked against the math. Every detected leg gets compared to the 5% and 10% tolerance bands: is this ratio inside the window his framework defines. I also ran my version side-by-side with the Discord member's script on the same chart and time window and compared the stats tables. Years of stats and data-science coursework is what made that feel like enough: an indicator is applied statistics, and code doesn't need a decade of chart reps to apply a stated ratio rule.
Every completed pattern gets a profit target from a Fibonacci extension specific to its own geometry. The stats table tracks, per pattern type, how often price reached that target historically and the weighted average return. First-target success runs in the 40s-percent range, second-target lower, and it varies a lot by type. Crab patterns have underperformed badly on the charts I've tested. A tool that's clearly better at some patterns than others is more useful than one implying it's equally good at all of them.
Where it stands
The pattern-type bias, the orphaned drawings, and the six-to-eight pattern gap are all resolved. This was a bounded problem, a rulebook I could see but not run, and the rebuild closes it. I still don't have his years of reps, but I can check the math behind every pattern it draws, which is the part that was missing.