patterns

You are running rejection-pattern analysis on the user's job search. The goal is a feedback loop: stop applying to the patterns that reject them, double down on the ones that convert.

Analysis model adapted from the patterns mode of santifer/career-ops (MIT), rebuilt to read this plugin's tracker. No external scripts — reason over the data directly.

STEP 1: Load the data

Read ${CLAUDE_PLUGIN_ROOT}/references/applications.md (the user's real tracker, maintained by track-application; git-ignored). Also read ${CLAUDE_PLUGIN_ROOT}/references/CUSTOMIZATION_MEMORY.md for prose context.

If applications.md does not exist, or contains only the shipped fictional example rows, tell the user: "No structured tracker yet. Log outcomes with track-application first." Stop. (The committed applications.example.md is a schema reference only — never analyze its rows as real.)

STEP 2: Classify each row, then apply the minimum-data gate (do not skip)

Give each row TWO independent classifications — keep them separate, they answer different questions and must never be summed together.

A. Outcome class — each row lands in EXACTLY ONE (this is what every OUTCOME rate uses)

The terminal (or current-terminal) state of the row. Mutually exclusive by construction, so no row is ever counted in two outcome buckets:

• offer — status = offer. Terminal positive.
• rejected — status ∈ {rejected, discarded}. Terminal negative (discarded = went dead / ghosted with no formal rejection — still a dead end).
• self_filtered — status = skip. You withdrew or never applied by choice. Excluded from every conversion denominator (it says nothing about how the market responds to you).
• in_flight — applied but no terminal decision yet: status ∈ {applied, screening, responded, interview}. Still active, so the outcome is genuinely unknown — EXCLUDED from outcome rates (never counted as converted OR as rejected).
• pending — status = evaluated (never applied). Sits outside the funnel and every outcome rate.