# Merge main into alisha/refactor `932a360`· alishakawaguchi·2mo ago·8 files·+367 added/-4 removed Resolutions: - Versions: keep 0.3.0 across all manifests (avoids collision with main's 0.2.0) - Layout: keep flat ./skills/ paths from this branch (.cursor-plugin, marketplace.json source) - Content: bring forward main's "what-happened" skill, additional keywords, and the updated codex shortDescription - Move plugins/entire/skills/what-happened/ to skills/what-happened/ to fit the flattened layout - Restore GEMINI.md (and contextFileName in gemini-extension.json) so Gemini context loading still works, with paths updated to ./skills/ Co-Authored-By: Claude Opus 4.7 (1M context) ## Sessions 365164ad6988View transcript ## Changes 8 - .claude-plugin - Mplugin.json+1 - .codex-plugin - Mplugin.json+2/-1 - .cursor-plugin - Mplugin.json+1/-1 - M.gitignore+2/-1 - AGEMINI.md+4 - MREADME.md+22 - Mgemini-extension.json+2/-1 - skills/what-happened - ASKILL.md+333 ### `what-happened` Explains what happened to a specific code block by tracing the latest change for a file line, range, or pasted snippet through git blame and Entire checkpoints. Current behavior: - resolves file lines, ranges, or pasted snippets to exact line numbers - asks for a concrete file line, range, or snippet before running provenance commands - deduplicates commit and checkpoint lookups before running expensive transcript commands - asks before expanding broad ranges with many unique commits - summarizes `entire explain` output without dumping raw transcripts by default; raw transcript expansion is opt-in - falls back to clearly labeled current-code analysis when checkpoint-backed context is unavailable Examples: - "tell me why this code is like that" - "why does this code look like this?" - "what happened here: `src/auth.ts:42-57`" - "what happened at `src/auth.ts:42`" - "what happened to this block?" plus a pasted snippet ### `search` Searches Entire checkpoint history and transcripts to find prior work by topic, repo, branch, author, or time window. --- name: What Happened description: > Explain why code looks the way it does by tracing the latest change for a file range or pasted snippet through `git blame` and deduplicated `entire explain` lookups. Use when the user asks what happened, says "tell me why" about a code block, is confused about a section of code, asks "wtf is going on", "why is this like this", "why was this changed", or wants provenance for a specific file block. --- # What Happened Use this skill when the user wants a provenance-focused explanation for a code block. Supported inputs: - `path:line` - `path:start-end` - `path` plus a pasted code snippet from that file ## Goal Find the most recent change blocks matching the user's target lines, list the matching commit hashes and checkpoint state, then summarize why each block was changed using the best available context. When checkpoint-backed context is unavailable, still explain what the current code does as an explicit fallback and clearly mark that explanation as not checkpoint-backed. ## Rules 1. Do not guess about file contents or line numbers. Resolve the exact target lines before explaining anything. 2. Use the installed `entire` binary from `PATH`, not `./entire` from the current repo. 3. Prefer `git blame` for provenance and `entire explain --commit` for transcript-backed context. Do not use experimental `entire why` for this skill. 4. Use this skill for latest-change provenance on a specific block. For broad original intent of a symbol, file, or feature, prefer the `explain` skill. 5. Do not manually hunt through `.git/entire-sessions/` or raw transcript files for commit provenance. If `entire explain` cannot provide transcript context, report the exact missing or unavailable state. 6. If multiple blame blocks match, include all distinct ranges. Deduplicate commit hashes before running `entire explain`; run transcript lookups once per unique commit, not once per range. Also deduplicate checkpoint IDs before expanding checkpoint transcripts; run checkpoint expansion once per unique checkpoint, not once per commit or range. 7. Distinguish these states explicitly: - no checkpoint is referenced for the commit - a checkpoint is referenced but is unavailable locally or remotely - a checkpoint is available, but full transcript expansion failed and raw transcript expansion was not explicitly requested - Entire transcript lookup failed (the `entire explain` command itself errored) - the code is untracked, uncommitted, or otherwise has no committed history - any other provenance command fails after the target code was resolved 8. For every resolved code block, include either checkpoint-backed history or a fallback explanation of what the current code does. Label fallback explanations as "not checkpoint-backed" and do not imply intent or historical rationale from checkpoints. 9. Treat `entire explain` command output as intermediate source material for summarization. Do not paste raw command output or full transcripts into the user response unless the user explicitly asks for raw output. Include only short error excerpts when they help the user fix a failed lookup. 10. Keep the final explanation concise and block-focused. Do not summarize unrelated parts of the file. ## Response format Begin the first successful resolved-code response to this skill invocation with the line: `Entire What Happened:` followed by a blank line, then the content. - Apply the header to the **first successful resolved-code response of the invocation only.** If an earlier unresolved-input response omitted the header and the user later disambiguates the target, include the header on the resolved-code response. Do not re-print it on later follow-up turns within the same invocation. - Do **not** include the header on unresolved-input responses (e.g. snippet not found, ambiguous snippet, invalid path or range). If the target code was resolved but no checkpoint-backed context exists, still use the header and clearly label the answer as current-code fallback analysis rather than a checkpoint summary. ### Snippet guidance: - Prefer the exact matched lines from the file. - Keep snippets tight to the matched block; avoid unrelated surrounding code unless needed for readability. - If the block is long, include the smallest contiguous excerpt that still lets the user recognize it and say that it was truncated.