--- name: os-weekly-review description: Reads the signals log and recent artifacts, finds what the human changed and what worked, and proposes specific edits to context files, signal weights, message templates, and skill parameters for approval. Use when the user says "weekly review", "what did we learn", "evolve the OS", "what should change", "run the retro", or on a weekly cadence. --- # os-weekly-review Produce `evolve/-proposals.md`. Propose; never apply. This is how the loop becomes a graph that learns. ## Preflight (every run) 1. Confirm `GTM-AI-OS/` is accessible. If not: "I need access to your GTM-AI-OS folder. Select it in Cowork's folder picker, or run `os-install` from the core plugin." Stop until it is. 2. Read `CLAUDE.md`, `INDEX.md`, and the last 20 lines of `signals/log.md`. 3. Check the prerequisites below. For anything missing, ask the cold-start questions and offer: (a) run the earlier skill now, or (b) fast path: answer the questions and this skill writes a minimal version of the missing artifact marked `status: draft (fast path)`. 4. On finish, update the artifact row in `INDEX.md` and append one line to `signals/log.md`: ` | | | | `. ## Prerequisites - At least five lines in `signals/log.md` since the last review. Cold-start (first run ever): "Tell me three things that happened with AI in your revenue team this week: something that worked, something you had to fix by hand, something you're unsure about." Write them to the log and run the review on those. ## Step 1: Read the week Signals log since the last review; artifacts modified this week; account records with new replies or outcomes; pilot weekly control row. ## Step 2: Link outcomes Read every account record's Touches and Outcome sections updated this week. Each reply, meeting, opportunity, or closed outcome links to: the account, the signal rows it cited, the persona, and the message path. Build the table: outcome · account · signals · persona · path · draft rounds. This is the evidence base for every proposal below. ## Step 2b: Find patterns - Corrections: what did the human change in AI output, more than once? That's a template or context fix. - Signals: which signals preceded replies or stage moves? Which never did? Propose weight changes and retirements in `signal-library.md`. - Messages: which beats got replies? Propose keeping the thesis that worked and retiring the one that didn't in `messaging.md`. - ICP: any won or lost deal that contradicts `icp.md`? Propose an evidence note. - Data: any field that was wrong twice? Propose a fix to the inventory and a governance note. - Skills: any step the user skipped every time, or added every time? Propose a parameter change to that skill (write it as a diff suggestion; do not edit the skill). ## Step 3: Write proposals For each: the file, the exact change, the evidence lines from the log, and the expected effect. Rank by evidence strength. Cap at seven. ## Step 4: Ask for approval Present the list. For each approved item, apply the change to the context file and log it as ` | os-weekly-review | applied: | approved by |`. Skill-file proposals are logged as approved but left for the plugin author to ship in the next version; note the version in the log. ## Step 5: Graph check Read `INDEX.md` wikilinks. Flag: a context file no skill read this month (dead node); two files carrying the same fact (duplicate); a skill that ran with a required file missing (broken link). Propose the fix; never delete. ## Step 6: Report Append a three-line summary to `evolve/REPORT.md`: runs this week, changes approved, metric movement since the first review. Over time this is the proof the OS is learning. ## Quality gate Never apply a change without an explicit yes on that item. Never propose more than seven changes in a week.