pattern-analysis

Invoke the analyst agent to run an outcome pattern analysis on the user's application history.

Workflow

1. Confirm data exists

Application data uses the split layout defined in references/tracker-schema.md — read it before any read or write.

Read {user_dir}/CareerNavigator/tracker.json. The threshold check runs on the summary rows' outcome field alone — do not open detail files yet. If the applications array is empty or has fewer than 3 entries with a resolved outcome (phone_screen, interview, offer, rejected, or inactive):

"You don't have enough outcome data yet for pattern analysis — I need at least a few applications with known results. Keep logging updates via /career-navigator:track-application and run this again once you have more history."

Otherwise, proceed.

2. Load the full history

This analysis needs stage history and note text, and tracker.json alone contains none of it — stage_history[] and notes[] moved to the per-application detail files. Computing conversion, drop-off, or timeline patterns from tracker.json by itself silently produces zeros and reports "no patterns found" when patterns exist.

1. Read {user_dir}/CareerNavigator/tracker.json and take applications[].
2. Iterate every row and load its detail_file (relative to CareerNavigator/) to get that application's stage_history[] and notes[]. Skip a row only when stage_count and notes_count are both 0.
3. Where a summary field already answers the question — current stage (latest_stage), date of the last stage change (latest_stage_date), or a count (stage_count, notes_count, contact_count) — use it instead of re-deriving from the detail file.

3. Invoke analyst — Operation 1

Hand off to the analyst agent with:

• CareerNavigator/tracker.json (summary rows) plus the loaded applications/<application_id>.json detail files — pass both; the summary rows alone are not a sufficient input for this operation
• The full artifacts-index.json
• The full CareerNavigator/ExperienceLibrary.json