Initial skills marketplace with 7 personal skill plugins

Structures ghost-writer, hr-manager, interview, meeting-notes, meeting-prep,
quiz, and resolve-todos as installable Claude Code plugins under a
.claude-plugin/marketplace.json manifest. Anthropic's built-in docx/pdf/pptx/xlsx
skills are excluded due to license restrictions, and mcp-builder/skill-creator
are excluded as not authored by me.

.claude-plugin/marketplace.json

@@ -0,0 +1,51 @@
+{
+  "name": "skills-marketplace",
+  "owner": {
+    "name": "Michal Kopec"
+  },
+  "description": "A personal marketplace of Claude Code skills for interviews, meetings, and writing.",
+  "plugins": [
+    {
+      "name": "ghost-writer",
+      "source": "./plugins/ghost-writer",
+      "description": "Rewrite and humanize text to remove AI writing patterns and match your own voice.",
+      "version": "1.0.0"
+    },
+    {
+      "name": "hr-manager",
+      "source": "./plugins/hr-manager",
+      "description": "Run mock job interviews and produce a scored assessment with a prioritised learning plan.",
+      "version": "1.0.0"
+    },
+    {
+      "name": "interview",
+      "source": "./plugins/interview",
+      "description": "Run a structured interview and save the captured knowledge to a markdown file.",
+      "version": "1.0.0"
+    },
+    {
+      "name": "meeting-notes",
+      "source": "./plugins/meeting-notes",
+      "description": "Interview a participant about a meeting and produce structured meeting notes.",
+      "version": "1.0.0"
+    },
+    {
+      "name": "meeting-prep",
+      "source": "./plugins/meeting-prep",
+      "description": "Generate a prioritised list of questions for an upcoming meeting based on wiki knowledge gaps.",
+      "version": "1.0.0"
+    },
+    {
+      "name": "quiz",
+      "source": "./plugins/quiz",
+      "description": "Quiz the user on knowledge captured in the wiki, with scoring and immediate feedback.",
+      "version": "1.0.0"
+    },
+    {
+      "name": "resolve-todos",
+      "source": "./plugins/resolve-todos",
+      "description": "Find and resolve TODO items in a document, asking for input when instructions are unclear.",
+      "version": "1.0.0"
+    }
+  ]
+}

README.md

@@ -0,0 +1,39 @@
+# Skills Marketplace
+
+A Claude Code plugin marketplace bundling personal skills for interviews, meetings,
+and writing. Each skill is packaged as its own installable plugin.
+
+## Plugins
+
+| Plugin | Description |
+| --- | --- |
+| `ghost-writer` | Rewrite and humanize text to remove AI writing patterns and match your own voice. |
+| `hr-manager` | Run mock job interviews and produce a scored assessment with a prioritised learning plan. |
+| `interview` | Run a structured interview and save the captured knowledge to a markdown file. |
+| `meeting-notes` | Interview a participant about a meeting and produce structured meeting notes. |
+| `meeting-prep` | Generate a prioritised list of questions for an upcoming meeting based on wiki knowledge gaps. |
+| `quiz` | Quiz the user on knowledge captured in the wiki, with scoring and immediate feedback. |
+| `resolve-todos` | Find and resolve TODO items in a document, asking for input when instructions are unclear. |
+
+## Installing
+
+Add this marketplace locally and install a plugin:
+
+```bash
+/plugin marketplace add "/Users/michalkopec/Documents/Projects/Skills Marketplace"
+/plugin install ghost-writer@skills-marketplace
+```
+
+Once published to a Git host, others can add it with:
+
+```bash
+/plugin marketplace add <owner>/<repo>
+```
+
+## Licensing
+
+- All plugins (`ghost-writer`, `hr-manager`, `interview`, `meeting-notes`,
+  `meeting-prep`, `quiz`, `resolve-todos`) are original work.
+- Anthropic's built-in `docx`, `pdf`, `pptx`, and `xlsx` skills are **not** included:
+  their license prohibits extracting, copying, or redistributing them outside
+  Claude's Services.

plugins/ghost-writer/.claude-plugin/plugin.json

@@ -0,0 +1,5 @@
+{
+  "name": "ghost-writer",
+  "version": "1.0.0",
+  "description": "Rewrite and humanize text to remove AI writing patterns and match your own voice."
+}

plugins/ghost-writer/skills/ghost-writer/SKILL.md

@@ -0,0 +1,299 @@
+---
+name: ghost-writer
+description: >
+  Use this skill whenever the user wants to improve, rewrite, or humanize text in a document or message — especially to remove AI writing patterns and make it sound natural, personal, and authentic. Trigger on phrases like: "make this sound less AI", "humanize this", "rewrite this naturally", "remove AI signs", "polish my writing", "improve this document", "edit this to sound like me", "make this less robotic", "clean up this text", "ghostwrite this", "fix the AI tone", "improve writing style". Also trigger when the user pastes a document or block of text and asks for edits, rewrites, or style improvements — even if they don't explicitly mention AI. When in doubt, use this skill: it is better to load it and not need it than to miss a writing improvement opportunity.
+---
+
+# Ghost writer skill
+
+Improves writing quality and strips AI writing patterns, producing prose that sounds genuinely human - clear, specific, rhythmic, and authentic.
+
+---
+
+## Before anything else: check for a style profile
+
+Look for `style-profile.md` in the skill folder. If it exists and has content beyond the template comments, read it now.
+
+Treat the profile as the user's personal style constraints. They override the defaults below:
+- **Tone and formality** from the profile replace the "keep existing register" default
+- **Signature phrases** in the profile are preserved even if they appear on the banned vocabulary list
+- **Avoid list** in the profile is added to the banned vocabulary list
+- **Sample writing** in the profile is used as a voice reference during rewriting
+- **Sentence style** in the profile overrides the rhythm guidance in section G
+
+If no profile exists, or the profile is blank, continue with the defaults for this rewrite - but flag it briefly: "(No style profile set up yet - using general defaults for this pass. I'll ask about setting one up at the end.)" Then proceed straight to Step 1. Do not interview the user before delivering value; the profile offer belongs at the end (see Step 6).
+
+---
+
+## Step 1: Identify the input
+
+If the user referenced a specific file, read it in full before doing anything else. If they pasted text directly, use that. If neither is clear, ask: "What text should I rewrite? You can paste it or give me a file path."
+
+Do not skim. Read the whole thing.
+
+---
+
+## Step 2: Establish the style target
+
+Ask: "Any specific voice or style to aim for - e.g. formal report, direct technical writing, conversational, journalistic? Or should I just clean up the AI tells and keep the existing register?"
+
+If the user says "just clean it up," keep the existing register and apply the rules below. Hold this answer before triaging - it affects which patterns are problems and which are intentional.
+
+---
+
+## Step 3: Scan and triage
+
+Run the quick scan protocol in this order:
+
+1. Ctrl+F for banned vocabulary (section A below) - flag every hit
+2. Read the first sentence of every paragraph - are they all the same grammatical shape?
+3. Count em dashes - more than 3 per page is a flag
+4. Find one factual claim - is it specific or vague? (abstraction trap, section E)
+5. Find one transition word - does it appear more than twice per page?
+6. Read 30 seconds aloud - does it have rhythm, or is it a metronome?
+
+Classify findings:
+
+- **High priority** (most detectable, most trust-damaging): abstraction trap, banned vocabulary, hedging, formulaic structure, "serves as" substitutions
+- **Medium priority**: sentence rhythm, transition word overuse, Latinate bias, passive voice
+- **Low priority**: em dash count, rule-of-three overuse, -ing openers
+
+**Exit path:** If the scan finds only 1-2 low-priority issues, do not force a rewrite. Report what was found and ask: "This text is mostly clean - I found [X]. Do you want me to fix just those, or do a full pass anyway?"
+
+If the user only wants a **quick pass**, fix high-priority items only and note what was skipped. For a **deep rewrite**, work through all categories and read `references/ai-signs.md` and `references/good-writing.md` for the extended checklist.
+
+---
+
+## Step 4: Apply the rewriting rules
+
+Work through all categories relevant to what triage found. Preserve intentional stylistic choices - if the author consistently uses a construction across the whole text, treat it as a voice marker, not a tell.
+
+---
+
+### A. Banned vocabulary - replace or cut
+
+Every instance must be replaced with a plain word or the sentence rewritten.
+
+**Remove or replace:**
+testament, pivotal, underscore, watershed, profound, solidifies, stands as, serves as, crucial, vibrant, enduring, intricate, seamless, comprehensive, robust, dynamic, breathtaking, stunning, nestled, groundbreaking, renowned, boasts, bolstered, garner, foster, enhance, delve, tapestry, rich (as in "rich cultural heritage"), landscape (metaphorical), ecosystem (metaphorical), interplay, meticulous/meticulously, align with, highlighting, showcasing, emphasizing, realm, beacon, multifaceted, commendable
+
+**Replace "is/are" substitutes with the plain verb:**
+- "serves as" → "is"
+- "stands as" → "is"
+- "marks" (as synonym for "is") → "is"
+- "represents" → "is" or "shows"
+- "features" (meaning "has") → "has"
+- "maintains" (meaning "has") → "has"
+- "offers" (meaning "has") → "has"
+
+**Remove vague authority phrases entirely:**
+- "industry observers note", "experts argue", "some critics argue"
+- "researchers suggest" (unless a specific researcher is named)
+- "it has been suggested", "it is worth noting", "it is important to note"
+- "scholarship describes", "studies show" (without citation)
+
+If the underlying claim is worth keeping, rewrite it with a named source or direct statement. If it cannot be made specific, cut it.
+
+---
+
+### B. Banned sentence patterns
+
+**"Not X but Y" / "Not only X but also Y"**
+Artificial contrasts that sound insightful but restate the obvious. State the point directly.
+
+Before: "Not just a technical tool, it is also a communication platform."
+After: "It is both a technical tool and a communication platform."
+
+**Trailing -ing phrases that restate the clause**
+Delete any trailing participial phrase that repeats what the main clause already said.
+
+Before: "The system improved reliability, reducing errors across deployments."
+After: "The system improved reliability."
+
+**The rule of three (triplet adjectives or vague phrases)**
+Three-part lists of vague adjectives are an LLM fingerprint. Use one specific detail or none.
+
+Before: "a dynamic, innovative, and forward-thinking organisation"
+After: "an organisation that ships in two-week cycles"
+
+**The "Despite / However" pivot formula**
+Before: "Despite its many advantages, the system faces challenges, but continues to improve."
+After: State the specific challenge as a concrete fact, or cut the paragraph.
+
+**Transition word saturation**
+Remove or replace: furthermore, moreover, additionally, consequently, thus, hence, in addition, it is worth noting, in contrast.
+Replace with direct connectives ("but," "so," "and") or restructure without them.
+
+---
+
+### C. Structural patterns to remove
+
+**"In conclusion" / "As we have seen" / "In summary" openers**
+Delete. Start the final paragraph with its actual content.
+
+**"In today's world" / "In today's [adjective] landscape" openers**
+Delete the opener. Start with the substantive claim.
+
+**"As X continues to evolve" / "With the rise of X" openers**
+Delete. Start with what actually happened.
+
+**Separate "Challenges and Future Prospects" or "Looking Ahead" sections**
+Integrate challenges as concrete statements into the relevant sections. Cut speculation.
+
+**Meta-commentary and structural narration**
+Delete sentences that describe the document rather than saying the thing:
+- "In this article, we will explore…"
+- "As we can see from the above…"
+- "This section covers…" (as a standalone sentence)
+
+---
+
+### D. Formatting tells to remove
+
+**Bullet points with bolded lead phrases**
+The pattern "**Term:** explanation" throughout a document is an LLM fingerprint. Convert to prose. If a list is genuinely needed, use plain bullets without bolded labels.
+
+**Excessive bold mid-sentence**
+Bold is for terms being defined or genuine emphasis only. Remove bold from any word bolded simply because the LLM deemed it important.
+
+**Excessive headers**
+One header per short paragraph is a structural tell. Consolidate sections. A paragraph does not need a heading unless it begins a genuinely new section.
+
+**Em dashes used for decoration or aside**
+Replace em dashes (—) with a hyphen-minus surrounded by spaces ( - ), a comma, or restructure the sentence.
+
+**Symmetrical bullet lists**
+Every bullet the same length, every list the same count, is a tell. Vary: let some bullets be one sentence, others three. Cut a list to two items or expand to six.
+
+---
+
+### E. The abstraction trap (highest priority)
+
+Every generic claim must be replaced with a concrete fact, number, name, or example. If you cannot make it specific, remove it entirely.
+
+Before: "The platform has helped many organisations improve their processes."
+After: "The platform reduced invoice processing time at Morrisons by 40%." (if that fact exists)
+Or: cut the sentence.
+
+Apply to every sentence containing:
+- quantities without numbers ("many," "several," "numerous," "various")
+- superlatives without evidence ("the most," "the best," "leading")
+- outcomes without measurement ("improved," "enhanced," "transformed")
+- time without specifics ("recently," "in recent years," "over time")
+
+---
+
+### F. Voice, clarity and authenticity
+
+**Latinate bias**
+Replace long formal words with short plain ones:
+- "utilize" → "use", "facilitate" → "help", "commence" → "start"
+- "demonstrate" → "show", "approximately" → "about", "endeavor" → "try"
+- "in order to" → "to", "due to the fact that" → "because"
+
+**Passive voice**
+Say who did what. "Mistakes were made" → "The team made mistakes."
+
+**Hedging**
+If the author means it, say it. Cut: arguably, potentially, it could be said, in many ways, one could suggest, somewhat.
+
+**Treadmill effect**
+Cut restatements. If the same idea appears twice, keep the best version, delete the rest.
+
+**Perfect grammar, zero personality**
+Add a fragment. Use a contraction. Let a short sentence stand alone. Like this.
+
+**Preserve the author's voice**
+Do not over-sanitize. Retain domain vocabulary the author uses deliberately. Where the original has opinions, let them land - do not hedge what the author clearly meant to assert. One opinion should land in the final version without softening.
+
+---
+
+### G. Sentence rhythm
+
+LLMs produce sentences of similar length and structure. After all other fixes, check rhythm:
+
+- Are consecutive sentences the same length? Break one up or combine two.
+- Do multiple sentences start with subject + verb? Vary the opening.
+- Does every paragraph have at least one short sentence (under 10 words)?
+- Are all paragraphs roughly the same length? Use a one-sentence paragraph for a point that deserves to stand alone.
+- Read aloud: if every sentence takes about the same time to speak, the rhythm is broken.
+
+---
+
+## Step 5: Deliver the output
+
+**For short texts (under 300 words):** Return the full rewritten version inline.
+
+**For long texts (300+ words):** Save to `outputs/` with `-rewritten` appended to the filename (e.g. `report.md` → `outputs/report-rewritten.md`). Return the rewritten text and the change summary.
+
+**Always provide a change summary.** Lead with the dominant pattern found - not a generic list:
+
+```
+Dominant issue: [the single biggest AI tell in this text]
+Changes made:
+- [what was changed and why]
+- [any claims cut because they could not be made specific]
+```
+
+---
+
+## Step 6: Offer one follow-up
+
+Do not offer a menu. Choose the most relevant follow-up based on what triage found, and offer that one thing:
+
+- **No style profile exists yet** → this takes priority over the other options below. Offer: "You don't have a style profile set up - want me to run a quick calibration (a few questions, optionally using a writing sample) so future rewrites automatically match your voice? Just say 'calibrate my writing style' whenever, or paste a sample now and I'll use it." Do not push further if declined - the defaults are working, this is just an offer.
+- **Vocabulary was the dominant issue** → "I can explain the top 3 AI patterns I found in the original, if that would help you avoid them in future drafts."
+- **Structure was the dominant issue** → "I can show you a before/after comparison of the paragraph that changed most, if you want to see the difference."
+- **Rhythm was the dominant issue** → "I can do a second pass focused purely on sentence rhythm if you want to push it further."
+- **Abstraction was the dominant issue** → "Several claims were cut because they couldn't be made specific. Do you have the numbers or examples to fill those gaps?"
+
+---
+
+## Calibration trigger
+
+If the user says "calibrate my writing style", "tune my style", "learn how I write", "update my style profile", "update my profile", "refresh my style profile", or similar - stop the normal flow and run `references/calibration.md` instead. Do not ask for text to rewrite.
+
+This applies whether or not a profile already exists yet - `calibration.md` handles both the first-time interview and updating an existing profile (see its "Re-calibration" section).
+
+---
+
+## Picking up style signal outside calibration
+
+Not all style information arrives through the dedicated calibration flow. During a normal rewrite, the user may reveal something worth keeping permanently:
+
+- **Self-description**: "I usually write for engineers," "I'm blunter than this in real life."
+- **A standing instruction framed as general, not one-off**: "always cut adverbs," "I never use exclamation points," "from now on keep it this direct."
+- **An unprompted writing sample**: the user pastes or references something they wrote and says "this is how I actually sound" or "match this," without invoking calibration.
+
+Distinguish lasting preferences from one-off requests. "Make this one more formal" applies to the current text only - do not persist it. "I'm always more formal than this" or "from now on..." is a standing preference - it should end up in the profile.
+
+If it's ambiguous which one you're hearing, ask: "Should I remember that for future rewrites too, or just apply it here?"
+
+When something should persist:
+1. Read the current `style-profile.md` (create it from the template if it doesn't exist yet).
+2. Update only the relevant field(s) - Tone, Formality, Sentence style, Vocabulary (Signature phrases/Avoid), Audience, Opinions, or append to Source documents/Sample. Do not touch unrelated fields and do not run the full calibration question set for a single piece of feedback.
+3. Confirm in one line: "Got it - saved to your style profile so future rewrites default to that." Do not make a bigger deal of it than the moment warrants.
+
+This is different from full calibration: calibration is a deliberate 4-5 question interview that builds or replaces the whole profile; passive capture is a lightweight single-field update that happens inline during other work.
+
+---
+
+## Reference files
+
+| File | When to read |
+|------|-------------|
+| `style-profile.md` | At the start of every invocation - user's personal style constraints |
+| `references/ai-signs.md` | Before a deep rewrite - extended checklist of 27 AI writing patterns with examples |
+| `references/good-writing.md` | Before a deep rewrite - principles of strong human prose (Orwell, Strunk & White, Hemingway) |
+| `references/calibration.md` | When the user triggers the calibration flow |
+
+Read `style-profile.md` on every invocation. Read the others only for deep rewrites or calibration.
+
+---
+
+## What this skill does NOT do
+
+- It does not check factual accuracy. Content is preserved as written.
+- It does not add information that was not in the original.
+- It does not rewrite code blocks, technical commands, or quoted material.
+- It does not change the language (British/American English, register) unless asked in Step 2.

plugins/ghost-writer/skills/ghost-writer/references/ai-signs.md

@@ -0,0 +1,139 @@
+# AI Writing Signs — Detection Checklist
+
+Reference for the ghost_writer skill. Scan input text against these patterns before rewriting.
+
+---
+
+## Category A: Surface-Level Tells (Easy to Spot)
+
+### 1. Em Dash Overuse
+**Signal:** More than 3 em dashes per 500 words  
+**Fix:** Replace with period, comma, or restructure the sentence
+
+### 2. Banned Vocabulary
+**Signal:** Any cluster of these words: *delve, showcase, underscores, noteworthy, pivotal, realm, tapestry, beacon, multifaceted, commendable, meticulous, intricate, vibrant, bolstered, fostering, highlighting, crucial, emphasizing, enhance, align with*  
+**Fix:** Replace with plain, direct language. "Shows" not "showcases." "Important" not "pivotal."
+
+### 3. Perfect Grammar, Zero Personality
+**Signal:** No fragments, no deliberate rule-bending, no contractions, no personality  
+**Fix:** Add a fragment. Use a contraction. Let a short sentence stand alone. Like this.
+
+### 4. Formulaic Paragraph Structure
+**Signal:** Every paragraph follows: topic sentence → evidence → summary  
+**Fix:** Vary openings. Start a paragraph with a question, an example, or a one-sentence punch.
+
+### 5. Excessive Hedging
+**Signal:** High density of: *arguably, potentially, it's worth noting, it could be said, in many ways, some might argue, one could suggest*  
+**Fix:** If the author means it, say it. Cut the hedge or restructure to a genuine conditional.
+
+### 6. Meta-Commentary and Structural Narration
+**Signal:** "In this article, we will explore…" / "As we can see…" / "In conclusion, we have discussed…"  
+**Fix:** Delete sentences that describe the document instead of saying the thing.
+
+### 7. Identical Sentence Length
+**Signal:** Every sentence runs 15–20 words with no variation  
+**Fix:** Vary aggressively. Mix a 4-word sentence with a 30-word one.
+
+### 8. Transition Word Saturation
+**Signal:** High frequency of: *furthermore, moreover, additionally, consequently, thus, hence, in addition, it is important to note*  
+**Fix:** Remove or replace with direct connectives ("but," "so," "and") or restructure without them.
+
+### 9. The Rule of Three — Always
+**Signal:** Every list has exactly three items; every comparison hits three points  
+**Fix:** Use two sometimes. Use four sometimes. Break the pattern intentionally.
+
+### 10. Overuse of "-ing" Openers
+**Signal:** Multiple sentences per paragraph starting with an -ing phrase ("Offering a wide range…", "Giving users the ability…")  
+**Fix:** Restructure to lead with the subject.
+
+---
+
+## Category B: Deep Patterns (Harder to Spot, More Damaging)
+
+### 11. The Abstraction Trap ⚠️ HIGH PRIORITY
+**Signal:** Vague language where concrete details belong. "The experience was positive" instead of "Cut setup time from 3 days to 4 hours."  
+**Fix:** For every abstract claim, add one specific detail, number, or named example.
+
+### 12. The Treadmill Effect
+**Signal:** Text circles the same idea across multiple paragraphs without advancing the information  
+**Fix:** Cut restatements ruthlessly. If the same idea appears twice, keep the best version, delete the rest.
+
+### 13. Latinate Bias ⚠️ HIGH PRIORITY
+**Signal:** Preference for long, formal Latinate words over short Anglo-Saxon ones:
+- "utilize" → "use"
+- "facilitate" → "help"
+- "commence" → "start"
+- "demonstrate" → "show"
+- "approximately" → "about"
+- "endeavor" → "try"
+- "in order to" → "to"
+- "due to the fact that" → "because"  
+**Fix:** Audit every 3+ syllable word. Is there a shorter one? Use it.
+
+### 14. Sensing Without Sensing
+**Signal:** Sensory descriptions that feel generic ("the warm, inviting atmosphere" / "a rich blend of flavors")  
+**Fix:** Replace with specific, idiosyncratic detail that only someone who was there would know.
+
+### 15. The Both-Sides Seesaw
+**Signal:** AI presents "both sides" of claims the author clearly believes in, or softens assertions with unnecessary counterpoints  
+**Fix:** If the author has a position, let it land. Remove false balance.
+
+### 16. Model-Specific First-Word Fingerprints
+**Signal:**
+- ChatGPT: sentences starting with "Certainly!", "As an AI…", "Sure!", "Here's…"
+- Claude: "I'd be happy to", "Based on", "I understand"
+- Generic: "Absolutely!", "Great question!"  
+**Fix:** Delete or fully restructure these openers.
+
+### 17. Passive Voice Overuse
+**Signal:** Actions where the agent is hidden: "Mistakes were made." / "The analysis was conducted."  
+**Fix:** Say who did it. "The team made mistakes." "We ran the analysis."
+
+### 18. Uniform Paragraph Length
+**Signal:** All paragraphs roughly the same length (3-5 sentences each)  
+**Fix:** Vary paragraph length. Use a 1-sentence paragraph for impact.
+
+### 19. Overclaiming Comprehensiveness
+**Signal:** "This comprehensive guide covers everything you need to know about…" / "A complete overview of…"  
+**Fix:** Say what it actually covers. "This covers the three most common setup errors."
+
+### 20. Fake Urgency / Motivational Padding
+**Signal:** Closing with generic positivity: "Now that you have the tools, you're ready to succeed!" / "The possibilities are endless!"  
+**Fix:** End with a specific, useful next step or a genuine observation.
+
+---
+
+## Category C: Structural Red Flags
+
+### 21. Symmetrical Bullet Lists
+**Signal:** Every bullet item is the same length; every list has the same count  
+**Fix:** Vary. Let some bullets be 1 sentence, others 3. Cut a list to 2 items or expand to 6.
+
+### 22. Overuse of Bold Headers in Short Text
+**Signal:** H2/H3 headers every 2-3 paragraphs in a short document  
+**Fix:** Reserve headers for genuine section breaks in longer content.
+
+### 23. Redundant Section Summaries
+**Signal:** A paragraph that restates the preceding section at the end of each section  
+**Fix:** Cut. The section speaks for itself.
+
+### 24. The "Despite / However" Pivot Formula
+**Signal:** "Despite its many advantages, [X] faces challenges…" appears formulaically  
+**Fix:** Restructure the critique directly without the softening setup.
+
+---
+
+## Quick Scan Protocol
+
+When scanning a new text, check in this order:
+
+1. Ctrl+F for banned vocabulary (see #2 above)
+2. Read first sentence of every paragraph — are they all the same structure?
+3. Count em dashes — more than 3 per page is a flag
+4. Find one factual claim — is it specific or vague? (abstraction trap)
+5. Find one transition word — does it appear more than twice per page?
+6. Read aloud for 30 seconds — does it have rhythm, or is it a metronome?
+
+---
+
+*Sources: vrid.ai/blog/signs-of-ai-writing (Feb 2026), Wikipedia:Signs_of_AI_writing, academic research from CMU, theaugmentededucator.com, bethz.com pattern analysis*

plugins/ghost-writer/skills/ghost-writer/references/calibration.md

@@ -0,0 +1,103 @@
+# Style calibration flow
+
+Run this when the user says "calibrate my writing style", "tune my style", "learn how I write", "update my profile", or similar - whether or not a profile already exists (see "Re-calibration" below for the existing-profile case).
+
+This is the full, deliberate interview. For a single preference or sample the user mentions in passing during a normal rewrite - not a request to calibrate - use the lighter "Picking up style signal outside calibration" flow in `SKILL.md` instead: update just the relevant field, don't run the full question set.
+
+---
+
+## Purpose
+
+Ask 4-5 targeted questions to extract the user's writing style, then write the results to `style-profile.md`. The user should be able to do this conversationally without editing any files.
+
+---
+
+## How to run it
+
+Ask questions one at a time. Wait for each answer before asking the next. Do not batch them.
+
+### Question 1 - source material (most important)
+
+Ask: "Do you have any documents you've written yourself - emails, reports, blog posts, notes? You can give me file paths, paste text directly, or both. This is the most useful input."
+
+**If they provide file paths:**
+
+Read each file. Supported formats:
+- `.md` and `.txt` - read directly with the Read tool
+- `.pdf` - read directly with the Read tool
+- `.docx` - extract text using:
+  ```
+  python3 -c "from docx import Document; doc = Document('PATH'); print('\n'.join(p.text for p in doc.paragraphs if p.text.strip()))"
+  ```
+  If python-docx is not installed, ask the user to export the file as PDF or paste the text.
+
+Read all provided files before moving to extraction. For large files (over 1,000 lines), read the first 200 lines and the last 100 lines - the opening and closing sections of a document show the most voice.
+
+**Style extraction - run on all documents combined:**
+
+After reading, extract the following. Be specific - note actual examples, not just categories.
+
+1. **Sentence length** - estimate the average word count per sentence. Are there frequent short sentences (under 8 words) used for emphasis?
+2. **Contractions** - does the writer use "it's / don't / can't / we're" or formal "it is / do not / cannot / we are"?
+3. **Fragments** - does the writer use deliberate sentence fragments? Cite an example if found.
+4. **Sentence openers** - what do sentences most often start with? Subject + verb? Time/place phrases? Questions?
+5. **Signature phrases** - any recurring expressions, transitions, or constructions the writer uses across multiple documents? List specific phrases.
+6. **Vocabulary register** - is the language technical, plain, formal, casual? Any domain-specific terms used consistently?
+7. **Paragraph length** - short (1-3 sentences), medium (4-6), long, or mixed?
+8. **Opinions** - does the writer state positions directly ("this approach fails") or hedge ("this approach may have limitations")?
+9. **Tone** - what overall impression does the writing give? Name it in 2-3 words.
+10. **Things to avoid** - note any patterns that appear once or twice inconsistently - these may be habits the writer would want stripped (e.g. occasional passive voice in otherwise active writing).
+
+If multiple documents were provided, note which patterns are consistent across all of them (stronger signal) versus which appear in only one (weaker signal, may be context-specific).
+
+**If they paste text directly:**
+- Apply the same extraction as above, scaled to what's available
+- Note that a single paragraph gives weaker signal than a full document
+
+**If they have nothing to hand:**
+Skip to question 2.
+
+### Question 2 - formality
+
+Ask: "What are you mostly writing? Pick the closest: casual messages and notes / blog posts and reports / business documents and proposals / executive memos and client deliverables / formal or academic writing."
+
+Map the answer to 1-5 (casual = 1, formal/academic = 5).
+
+### Question 3 - sentence style
+
+Ask: "How would you describe your sentence style - short and punchy, long and flowing, or mixed depending on the point?"
+
+### Question 4 - things to avoid
+
+Ask: "Any words, phrases, or habits you actively dislike in your own writing - things you want me to strip out even if they're not AI tells?"
+
+### Question 5 - opinions and hedging
+
+Ask: "When you have a point of view, do you prefer to state it directly or keep the writing neutral?"
+
+---
+
+## After collecting answers
+
+Summarise back to the user in two sentences: "Based on what you've told me, you write [formality description], [sentence style], [opinion style]. I'll treat [sample phrases if any] as signature vocabulary to preserve."
+
+Ask: "Does that sound right?"
+
+Wait for confirmation or correction. Apply any corrections.
+
+Then write the completed profile to `style-profile.md`. Overwrite the whole file - do not append. Use the template format from the existing `style-profile.md`, filling in the fields with the answers collected.
+
+If documents were provided, record their file paths in the Source documents section and paste the most representative 1-2 paragraphs (best example of the writer's voice) into the Sample section.
+
+If only pasted text was provided, paste the best 1-2 paragraphs into the Sample section and leave Source documents blank.
+
+Tell the user: "Style profile saved to `style-profile.md`. The ghost-writer will use it automatically from now on. You can edit the file directly at any time, or re-run calibration with new documents to update it."
+
+---
+
+## Re-calibration
+
+If a `style-profile.md` already exists with content, tell the user: "You already have a style profile. I can update it with new answers, or replace it from scratch. Which would you prefer?"
+
+If updating: read the existing profile first, apply changes to the relevant fields only, leave the rest unchanged.
+If replacing: run the full flow above and overwrite.

plugins/ghost-writer/skills/ghost-writer/references/good-writing.md

@@ -0,0 +1,158 @@
+# Good Writing Principles
+
+Reference for the ghost_writer skill. Apply these when rewriting. These are grounded in enduring style principles (Orwell, Strunk & White, Hemingway) and current research on what distinguishes human from AI prose.
+
+---
+
+## Core Principles
+
+### 1. Clarity First
+The reader should understand every sentence on first read. No re-reading required.
+
+- Use precise words over impressive ones
+- One idea per sentence when the idea is complex
+- Active voice: say who did what
+- Short sentences carry weight. Use them for your most important points.
+
+> Orwell's rule: "If it is possible to cut a word out, always cut it out."
+
+---
+
+### 2. Economy of Words
+Every word must earn its place.
+
+| Cut this | Write this |
+|----------|-----------|
+| in order to | to |
+| due to the fact that | because |
+| at this point in time | now |
+| in the event that | if |
+| it is important to note that | (just say it) |
+| basic fundamentals | fundamentals |
+| end result | result |
+| close proximity | near |
+
+Eliminating redundancy doesn't flatten writing — it sharpens it. The meaning comes through faster and hits harder.
+
+---
+
+### 3. Voice and Authenticity
+Voice is the personality of the writer coming through the text. It can't be faked — it emerges from honest, confident writing.
+
+**What creates voice:**
+- Word choices the author gravitates toward
+- Sentence rhythms that feel natural to them
+- Opinions delivered without apology
+- Specific details only this person would notice
+
+**What kills voice:**
+- Hedging every assertion
+- Replacing personality with formality
+- Writing "correctly" instead of writing truly
+
+When editing, ask: *does this still sound like the author, or does it sound like a textbook?*
+
+---
+
+### 4. Rhythm and Sentence Variation
+Writing without rhythm feels robotic. The goal is a cadence that pulls the reader forward.
+
+**Rhythm tactics:**
+- Mix sentence lengths. A short sentence after a long one lands hard.
+- Vary sentence structure. Not every sentence needs subject → verb → object.
+- Use a one-sentence paragraph for a point that deserves to stand alone.
+- Parallel structures (two or more sentences with the same grammatical shape) create momentum — but only when used intentionally, not by default.
+
+**The metronome test:** Read the text aloud. If every sentence takes about the same amount of time to speak, the rhythm is broken.
+
+---
+
+### 5. Specificity Over Generality
+Concrete details create trust. Vague language signals inexperience or distance from the subject.
+
+| Vague (AI) | Specific (Human) |
+|-----------|-----------------|
+| "significant improvement" | "reduced errors by 40%" |
+| "the experience was positive" | "we spent 3 fewer hours per sprint in review" |
+| "it smelled wonderful" | "burnt espresso and old books" |
+| "many users prefer this" | "7 of the 10 engineers we interviewed chose it immediately" |
+| "recently" | "last Tuesday" / "in Q3" |
+| "a well-known study found" | "the 2024 CMU study of 12,000 texts found" |
+
+When specifics aren't available, name the gap: "we haven't measured this yet" is more trustworthy than a vague positive claim.
+
+---
+
+### 6. Active Voice
+Passive voice hides agents and weakens impact. Use it only when the agent is genuinely unknown or irrelevant.
+
+| Passive | Active |
+|---------|--------|
+| "Mistakes were made." | "The team made mistakes." |
+| "The report was written by Sarah." | "Sarah wrote the report." |
+| "It was decided that..." | "The board decided..." |
+| "Questions should be sent to..." | "Send questions to..." |
+
+---
+
+### 7. Directness
+A direct writer doesn't hide behind jargon or hedged language. They trust that clear, honest prose persuades better than embellishment.
+
+**Signs of indirect writing:**
+- Using formal language to create distance ("leverage synergies")
+- Qualifying assertions that the author clearly believes ("it could be argued that this approach is effective")
+- Softening criticism to the point of meaninglessness ("while this has some limitations, it also shows promise")
+
+**Directness in practice:**
+- Say the bad thing directly: "This approach failed in three ways."
+- Commit to your position: "This is wrong." not "One might argue this is suboptimal."
+- Trust the reader to handle direct information.
+
+---
+
+### 8. Unpretentious Language
+Strunk and White: use words and phrases that come readily to hand. Plain language bridges writer and reader.
+
+The goal is to *express*, not to *impress*. Pretentious writing signals the writer is showing off rather than communicating. Readers sense this and disengage.
+
+**Practical test:** If you'd feel awkward saying it out loud to a colleague, rewrite it.
+
+---
+
+### 9. Structure Serves the Reader
+Good structure is invisible — the reader moves through the document without noticing the architecture.
+
+**Structure principles:**
+- Lead with the most important information (especially in professional writing)
+- Topic sentences that actually commit to a point, not just name a topic
+- Transitions that reflect logic, not just sequence ("but" / "because" / "so" rather than "furthermore" / "additionally")
+- Endings that land — not a summary of what was just said, but a forward-looking observation or call to action
+
+---
+
+### 10. Emotional Honesty
+Human writing carries the writer's actual perspective. It can be measured, professional, and still emotionally present.
+
+AI avoids emotional stakes. It describes things at a distance. Human writers who care about their subject write differently than those who don't — and readers feel it.
+
+**Ways emotional honesty shows up:**
+- An opinion delivered without apology
+- A specific anecdote from real experience
+- Admitting uncertainty without hiding behind vague language
+- Enthusiasm (or frustration, or caution) that's proportionate to the subject
+
+---
+
+## The Writer's Test
+
+Before finalizing any rewrite, ask:
+
+1. Can I read every sentence aloud without stumbling?
+2. Does every paragraph move forward — does it add something the previous didn't?
+3. Is there at least one concrete, specific detail in every major claim?
+4. Would I be comfortable sending this with my name on it?
+5. Does it sound like a person, or does it sound like a template?
+
+---
+
+*Grounded in: Strunk & White "The Elements of Style," Orwell "Politics and the English Language," Hemingway's iceberg principle, journalism.university writing principles, naturalwrite.com elements of good writing (2025)*

plugins/ghost-writer/skills/ghost-writer/style-profile.md

@@ -0,0 +1,82 @@
+# My writing style profile
+
+This file tells the ghost-writer skill how to write in your voice.
+Fill it in manually, or run the calibration flow by saying "calibrate my writing style."
+Leave any section blank to use the skill defaults.
+
+---
+
+## Tone
+
+# How do you want to come across? Examples: dry and direct, warm but professional,
+# sarcastic when appropriate, blunt, measured, informal but credible.
+Tone:
+
+---
+
+## Formality
+
+# Rate 1-5:
+# 1 = very casual (Slack messages, personal emails)
+# 2 = conversational (blog posts, friendly reports)
+# 3 = professional (business documents, proposals)
+# 4 = formal (executive memos, client deliverables)
+# 5 = very formal (legal, academic)
+Formality:
+
+---
+
+## Sentence style
+
+# Which best describes you? Pick one or describe your own.
+# - Short and punchy (average sentence under 12 words, frequent full stops)
+# - Mixed (varied length, short sentences used for emphasis)
+# - Long and flowing (complex sentences, subordinate clauses, rhythm over brevity)
+Sentence style:
+
+---
+
+## Vocabulary
+
+# Words or phrases you use often (preserve these even if they look like AI tells):
+Signature phrases:
+
+# Words or phrases you actively dislike or want avoided:
+Avoid:
+
+---
+
+## Audience
+
+# Who are you usually writing for? Examples: engineers, executives, clients,
+# non-technical stakeholders, general public, internal team.
+Audience:
+
+---
+
+## Opinion and hedging
+
+# Do you prefer to state opinions directly, or keep writing neutral?
+# Examples: "state opinions confidently", "stay neutral", "hedge only on uncertain facts"
+Opinions:
+
+---
+
+## Source documents
+
+# File paths to documents you have written yourself (emails, reports, notes, posts).
+# The ghost-writer will read these during calibration to extract your style patterns.
+# Supported formats: .md, .txt, .pdf, .docx
+# Add one path per line.
+
+Source documents:
+
+---
+
+## Sample writing
+
+# 1-3 paragraphs of your own writing that sound like you.
+# Populated automatically during calibration, or paste manually.
+# The ghost-writer uses this as a direct voice reference when rewriting.
+
+Sample:

plugins/hr-manager/.claude-plugin/plugin.json

@@ -0,0 +1,5 @@
+{
+  "name": "hr-manager",
+  "version": "1.0.0",
+  "description": "Run mock job interviews and produce a scored assessment with a prioritised learning plan."
+}

plugins/hr-manager/skills/hr-manager/SKILL.md

@@ -0,0 +1,187 @@
+---
+name: hr-manager
+description: Conduct a structured mock job interview for a specific role, then provide a scored assessment of strengths and gaps and a prioritised learning plan. Use when the user wants to practise for a job interview, assess a candidate profile against a role, or build a development plan towards a target role.
+---
+
+# HR manager skill
+
+## Purpose
+
+Simulate a realistic job interview for a target role. Ask questions one at a time, probe answers systematically, score each answer immediately, then deliver structured feedback: what went well, where the gaps are, and a prioritised learning plan the candidate can act on.
+
+Works for any role. When the target role has a wiki page in this project (e.g. Forward Deployed Engineer), use it to inform the question design and scoring.
+
+## Trigger phrases
+
+Use this skill when the user says things like:
+- "conduct a mock interview for [role]"
+- "interview me for [role]"
+- "assess my profile against [role]"
+- "prepare me for a [role] interview"
+- "act as a hiring manager"
+- "give me interview practice"
+
+## How to run this skill
+
+### Step 1 - Establish the role and the candidate
+
+Ask these three questions in order. Wait for the answer to each before proceeding.
+
+1. "What role are we interviewing for? Give me the job title and, if relevant, the company or type of company."
+2. "Do you have a job description or any requirements document for this role? If so, where should I look - is it saved in this project, or would you like to paste it here?"
+3. "Should I use your CV or profile from this project, or would you like to describe your background briefly?"
+
+**Job description / requirements:** If the user points to a file, read it before designing questions. Extract: required skills, seniority signals, stated responsibilities, and any explicit competencies or values listed. These become the primary scoring criteria. If no job description is available, rely on the role title, the wiki (if relevant), and the candidate's stated target company type.
+
+**CV:** If the user says to use their CV, check `outputs/` for a CV file (look for filenames containing "cv" or "resume"). Read it before designing questions. Do not ask the user to paste it.
+
+If the wiki contains a page for the target role (e.g. `wiki/concepts/forward-deployed-engineer.md`), read it. Use the skills inventory, seniority expectations, and soft skill requirements to calibrate question difficulty and scoring.
+
+### Step 2 - Design the interview
+
+Based on the role and the candidate's background, design 6-8 interview questions. Cover these areas, weighted by how critical each is to the role:
+
+- Motivation and career narrative (1-2 questions)
+- Core technical skills (2-3 questions)
+- Applied scenario - a realistic problem the role faces (1-2 questions)
+- Customer or stakeholder handling (1 question)
+- Handling ambiguity or failure (1 question)
+
+**Question types:** Mix behavioural and situational questions deliberately. Include at least 2 of each type.
+
+- **Behavioural questions** ("Describe a time when...") draw on past behaviour as a predictor of future performance. Use for competencies the candidate should have already demonstrated.
+- **Situational questions** ("What would you do if...") test reasoning and values for novel scenarios. Use for competencies where direct experience is unlikely or for probing decision-making.
+
+Include one question targeting a visible gap in the candidate's background. Do not show the question list. Ask questions one at a time.
+
+### Step 3 - Conduct the interview
+
+Open with a brief scene-setter:
+
+> "I've reviewed your background. This is a [X]-minute interview for the [role] position. I'll ask you a series of questions - some technical, some situational. Take the time you need to answer fully. Ready?"
+
+Then ask questions one at a time, following this sequence for each:
+
+**a) Record key phrases.** As the candidate answers, note 2-3 verbatim phrases that will anchor your scoring to evidence, not impression.
+
+**b) Check STAR completion.** Before probing, check whether the answer contains all four components: Situation, Task, Action, Result. The Result is the most commonly omitted. If any component is missing, probe for it explicitly.
+
+**c) Probe.** After each answer, follow up with at least one probe. Use the type that fits:
+
+- **Completion probe (missing Result):** "What was the outcome - how did you know it worked?"
+- **Elaboration probe (thin answer):** "Walk me through exactly what you did at that point."
+- **Clarification probe (unclear contribution):** "What was your role specifically, versus the team's?"
+- **Specificity probe (tests for real experience vs rehearsed):** "What did you say to them in that conversation?" or "What was the number at the end of that project?" A candidate with genuine experience can answer unexpected specificity questions; a candidate relying on a memorised story cannot.
+- **Reflection probe:** "What would you do differently now?"
+- **Strategic silence:** After a thin answer, pause without speaking. Candidates often continue and add material they left out. Use before more direct probes.
+
+**d) Name gaps in real time, then move on.** If an answer reveals a clear gap (abstract claim with no example, missing a key component), note it briefly and continue:
+> "Noted - I'll come back to that in the feedback. Next question..."
+
+Do not stop the interview to lecture.
+
+**e) Score immediately.** Before asking the next question, assign an internal score of 1-5 for this answer (see Scoring guidance). Do not reveal the score during the interview.
+
+**Use scenario questions for technical depth.** For any technical role, include at least one scenario the candidate must talk through live - not describe in the abstract. A good scenario has a specific constraint (a time limit, a difficult stakeholder, a system failure) that forces prioritisation decisions.
+
+**Close the interview.** After the last question, say:
+> "That covers the questions. Before I give you my assessment - how do you think that went? Which answer felt weakest to you?"
+
+Wait for the candidate to respond. Their self-assessment informs the feedback and increases how much they act on what follows.
+
+### Step 4 - Deliver the assessment
+
+Structure the output in three sections. Be direct. Do not soften gaps with vague praise.
+
+---
+
+**Overall verdict**
+
+One sentence: hire / strong hire / borderline / not yet. State the primary reason. Include a total score (sum of per-question scores / maximum possible).
+
+---
+
+**Strengths**
+
+List 3-5 genuine strengths observed during the interview. Each strength must be tied to a specific answer or verbatim phrase you recorded - not inferred from the CV. Format: bold label, then one or two sentences of evidence quoting what the candidate said.
+
+---
+
+**Gaps**
+
+List the 3 most critical gaps observed. For each gap:
+- What was missing or weak, anchored to a specific answer
+- Why it matters for this role
+- One specific behavioural fix (e.g. "Replace 'we delivered' with 'I led X, which resulted in Y' to make your contribution clear to the interviewer")
+
+Order by severity - most critical first. Do not list every gap; cap at three.
+
+---
+
+**Learning plan**
+
+Produce a prioritised list of 3 actions the candidate can take in the next 1-3 months to close the most critical gaps. For each action:
+- What to do (specific - name a course, a project type, a behaviour to practise)
+- Why it matters (tied to the gap)
+- A rough timeframe (days / weeks / months)
+
+---
+
+### Step 5 - Offer to save
+
+Ask: "Would you like me to save this feedback and learning plan to `outputs/`?"
+
+If yes, write the full transcript and assessment to:
+
+```
+outputs/YYYY-MM-DD-interview-[role-slug]-feedback.md
+```
+
+Use this frontmatter:
+
+```markdown
+---
+title: [Role] mock interview - feedback and learning plan
+type: analysis
+created: YYYY-MM-DD
+tags: [interview, [role-slug], learning-plan]
+---
+```
+
+Include the full interview transcript followed by the assessment. Label turns **Interviewer:** and **[Candidate name]:** (or **Candidate:** if name is unknown).
+
+---
+
+## Scoring guidance
+
+Score each answer immediately after probing, before the next question. Use a 1-5 scale per question. Record a brief note (one sentence, grounded in a verbatim phrase) alongside the score.
+
+**1 - No evidence:** Answer stays abstract throughout. Cannot give a specific example when probed. Misses a key component of what the role requires. May contradict the CV.
+
+**2 - Weak:** Gives a general example but it is vague or borrowed from team achievement ("we did X"). Action steps are thin. Result is absent even after probing.
+
+**3 - Acceptable:** Covers the substance. A specific example is present, but requires one or two follow-up probes to get there. Result is present but not quantified or not clearly linked to the candidate's actions.
+
+**4 - Strong:** Gives a specific example unprompted. Names the outcome and links it to their actions. Shows some self-awareness about what worked or what they would change. No significant probing required.
+
+**5 - Exceptional:** All STAR components present and specific unprompted. Outcome is quantified or has clear external validation. Candidate reflects on what they learned or how they would do it differently. Could coach others in this area.
+
+**Total score interpretation (for a 7-question interview, max 35):**
+- 28-35: Strong hire
+- 21-27: Borderline - panel review recommended
+- 14-20: Not yet - significant development required
+- Below 14: Decline
+
+Adjust the thresholds proportionally if you use fewer or more questions.
+
+---
+
+## Writing style
+
+- British English spelling
+- Sentence case headings
+- Direct, honest tone - gaps are gaps, not "areas for development"
+- No banned vocabulary: testament, pivotal, seamless, robust, crucial, enhance, delve, tapestry, etc.
+- No em dashes - use hyphens
+- Feedback tied to specific moments and verbatim phrases, not generic impressions
+- Strengths and gaps each capped at 3-5 items - specificity over comprehensiveness

plugins/interview/.claude-plugin/plugin.json

@@ -0,0 +1,5 @@
+{
+  "name": "interview",
+  "version": "1.0.0",
+  "description": "Run a structured interview and save the captured knowledge to a markdown file."
+}

plugins/interview/skills/interview/SKILL.md

@@ -0,0 +1,134 @@
+---
+name: interview
+description: Conduct a structured interview - ask for a purpose, then collect information one question at a time and save the result to a markdown file. Use when asked to run an interview, interview someone, or capture knowledge through questions. Also use when a user says things like "ask me about", "I want to tell you about", "let's capture what I know about", or "collect information from me".
+---
+
+# Interview skill
+
+## Purpose
+
+Conduct a focused interview by asking questions one at a time, confirming your understanding as you go, then saving the result as a structured markdown file in `outputs/`.
+
+Works for any domain: requirements gathering, research, knowledge capture, stakeholder discovery.
+
+## How to run this skill
+
+### Step 1 — Establish purpose, subject and output
+
+Ask these questions one at a time. Wait for the answer before asking the next.
+
+1. "What is the topic of this interview? What should we know or have produced by the end?"
+2. "Who is being interviewed? Give their name, role, and any relevant background."
+3. "How should I record this information - is it going into the wiki, a report, a document, or just kept as a reference?"
+
+Use the answer to question 3 to decide the tone and depth of the output file.
+
+### Step 2 — Design the questions
+
+Based on the stated purpose, generate a focused set of questions (typically 5-10). Structure them in order:
+
+- Start broad and open: context, background, overall picture
+- Move to specifics: key facts, details, constraints, priorities
+- Close on implications: open questions, next steps, gaps
+
+Do not show the full question list. Ask questions one at a time.
+
+### Step 3 — Conduct the interview
+
+Ask each question individually. Wait for the answer before asking the next.
+
+**Use the funnel technique.** Start with broad, open questions that let the interviewee set the frame - "Tell me about...", "How would you describe...", "What is the overall picture of...". This surfaces vocabulary, context and unexpected angles before you narrow in. Only move to specific or closed questions once the broad picture is clear.
+
+**Embrace silence.** After an answer, do not rush to ask the next question. A short pause often prompts the interviewee to elaborate or add something they initially left out. Wait before moving on.
+
+**Paraphrase to confirm.** After any substantive answer, reflect back your understanding before moving on. For example: "So if I understand correctly, you're saying that X, and the main reason is Y - is that right?" Do not move to the next question until the interviewee confirms or corrects your paraphrase.
+
+**Use STAR to probe specific events.** When an answer refers to a specific decision, incident or piece of work, use the STAR structure to get the full picture: Situation (what was the context?), Task (what needed to happen?), Action (what was done?), Result (what came of it?). Use only the parts that are unclear - do not run the full four questions if the answer already covers them.
+
+**Handle tangents with judgement.** Not all digressions are wasted time - they often contain unexpected insights. Before redirecting, assess whether the tangent is revealing something useful. If it is, let it run briefly and note it. If it is not, bring the interview back: "That is useful context - let me come back to where we were..." Do not chain more than two follow-ups on any single topic before returning to the main thread.
+
+**Close with a summary and a final check.** When all substantive questions are answered, briefly summarise the key themes back to the interviewee: "Let me reflect back what I have heard so far: [two or three sentences]. Does that capture it?" Then ask: "Before I put this together - is there anything else you would like to add, or anything I have not asked about that you think is important?" Wait for the answer. Only then say: "That covers everything. Let me put this together."
+
+### Step 4 — Write and save the file
+
+Write the interview record to:
+
+```
+outputs/YYYY-MM-DD-interview-kebab-title.md
+```
+
+Where `YYYY-MM-DD` is today's date and `kebab-title` is a short slug derived from the purpose or subject (e.g. `2026-06-09-requirements-payment-gateway`, `2026-06-10-knowledge-capture-wojciech`).
+
+Use this format:
+
+```markdown
+---
+date: YYYY-MM-DD
+title: Interview title
+interviewee: Name, role
+purpose: One-sentence statement of what this interview was for
+output-use: Where or how this information will be used
+---
+
+# Interview: [Title]
+
+## Purpose
+
+One sentence stating what this interview was meant to produce.
+
+## Interviewee
+
+Name, role, and any relevant background provided.
+
+## Transcript
+
+Record the full dialogue of the interview in order. Include every question asked, every answer given, every paraphrase check, and every correction or confirmation. Use labelled turns:
+
+**Interviewer:** [question or paraphrase]
+
+**Interviewee:** [answer or correction]
+
+**Interviewer:** [paraphrase check - e.g. "So if I understand correctly..."]
+
+**Interviewee:** [confirmation or correction]
+
+(repeat for the full conversation)
+
+Record paraphrases verbatim - they are part of the record because they show how understanding was built and corrected. If the interviewee corrected a paraphrase, record both the original paraphrase and the correction. Do not summarise or compress turns.
+
+## Summary
+
+Two to four sentences. What was learned, what the key findings are, and any gaps or open questions that remain.
+
+## Open questions
+
+- Anything raised but not resolved
+- Any follow-up the interviewee suggested
+
+(Omit this section if nothing is unresolved.)
+```
+
+Save immediately after writing. Tell the user the file path.
+
+---
+
+## Writing style
+
+Follow the project writing style from CLAUDE.md:
+
+- British English spelling (organisation, behaviour, colour)
+- Sentence case headings
+- No banned vocabulary (testament, pivotal, seamless, robust, crucial, enhance, delve, tapestry, etc.)
+- No bullet points with bolded lead phrases
+- No em dashes - use hyphens
+- Record answers faithfully - do not editorialise or add interpretation inside the Q&A section. Save interpretation for the Summary.
+
+---
+
+## Proactive rules
+
+Apply after saving:
+
+1. **Thin answers** - if any answer is a single sentence with no supporting detail, flag it: "The answer to '[question]' is brief. Do you want to add more detail before the file is shared?"
+2. **Open questions remain** - if the summary identifies gaps, say: "There are open questions in this interview. Consider a follow-up session or adding sources to `raw/sources/` if this is research."
+3. **No interviewee background given** - if the user skipped the background question, note: "No background was recorded for the interviewee. Add it to the file if relevant for future readers."

plugins/meeting-notes/.claude-plugin/plugin.json

@@ -0,0 +1,5 @@
+{
+  "name": "meeting-notes",
+  "version": "1.0.0",
+  "description": "Interview a participant about a meeting and produce structured meeting notes."
+}

plugins/meeting-notes/skills/meeting-notes/SKILL.md

@@ -0,0 +1,234 @@
+---
+name: meeting-notes
+description: Run an interview with the participant to collect the information from the meeting and prepare meeting notes in a dedicated form
+---
+
+# Meeting notes skill
+
+## Purpose
+
+Collect meeting information through a structured interview and produce a clean, consistent meeting note saved to `meeting-notes/`.
+
+Works for any meeting type — client calls, internal sessions, kickoffs, status updates, discovery sessions — whether the user attended or facilitated.
+
+## How to run this skill
+
+### Step 1 — Setup: audience and timing
+
+Ask these two questions before the braindump. Ask them one at a time.
+
+1. "Who will read this note — is it for your own reference, for your internal team, or going to the client?"
+2. "When did the meeting take place?"
+
+Use the answers to set two flags that affect everything that follows:
+
+**Audience flag:**
+- *Personal/internal* — include internal deliberations, rough impressions, opinions. Tone can be direct.
+- *Client-facing* — omit internal deliberations and opinions. Tone should be neutral and polished. During gap-filling, probe more thoroughly for completeness since the note will be seen externally.
+
+**Time flag:**
+- *Same day* — normal depth expectations.
+- *More than one day ago* — adjust gap-filling. Do not push hard for exact details that may no longer be remembered. Add a line to the note frontmatter: `recorded: [date recorded]` and note in the Summary that notes were captured retrospectively.
+
+### Step 2 — Free-form input
+
+Ask the user to provide a free-form brain dump of the meeting:
+
+> "Tell me about the meeting — anything you remember. Date, who was there, what was discussed, what was decided, what needs to happen next. Don't worry about structure, just say what comes to mind."
+
+### Step 3 — Confirm understanding and fill gaps
+
+**Paraphrase first.** Before asking anything, reflect back your understanding of the braindump in two or three sentences: "Let me make sure I have this right: [paraphrase]. Is that a fair summary?" Do not move on until the user confirms or corrects it.
+
+**Identify gaps.** From the braindump, note what is missing across these eight areas — but do not list them to the user:
+- Date, time or meeting title
+- Attendees not named or roles unclear
+- Purpose not stated
+- Discussion points too thin to reconstruct context
+- Decisions not captured
+- Actions without owners or due dates
+- Open questions not recorded
+- Next meeting not mentioned
+
+**Fill gaps one at a time using interview techniques.** Do not ask all gaps at once. Work through them individually:
+
+- Prioritise by importance: decisions and actions first (highest risk if lost), then discussion context, then logistics such as date and time.
+- For thin areas, start open before going specific: "Can you tell me more about what was discussed on [topic]?" before asking "Was a decision made?"
+- After each answer, paraphrase to confirm before moving to the next gap: "So the outcome there was X — is that right?"
+- If an answer is unclear, follow up once to clarify, then return to the next gap. Do not chain more than two follow-ups before moving on.
+- Embrace pauses. After an answer, wait briefly — the user may add something before you ask the next question.
+- If a tangent surfaces unexpected context, note it and let it run briefly before returning: "That is useful — let me come back to where we were."
+- If the time flag is *more than one day ago*, accept thinner answers without pushing. Note any section where detail may be incomplete.
+
+**Close before writing.** When all gaps are addressed, briefly summarise the complete picture: "Here is what I will write up: [three or four key points]. Before I do — is there anything you would like to add that I have not asked about?" Wait for the answer, then write the note.
+
+### Step 4 — Choose format and write the note
+
+**Choose the format** based on meeting complexity:
+
+Use the **short format** if the meeting was:
+- 30 minutes or shorter, with three or fewer attendees, and two or fewer distinct discussion topics.
+
+Use the **full format** for everything else, and always for kickoffs, discovery sessions, and strategy meetings regardless of length.
+
+Write the note and save it immediately to:
+
+```
+meeting-notes/YYYY-MM-DD-kebab-title.md
+```
+
+Where `YYYY-MM-DD` is the meeting date and `kebab-title` is a short slug derived from the meeting title or purpose (e.g. `2026-06-09-saffron-kickoff`, `2026-06-10-internal-sprint-review`).
+
+Do not wait for the user to confirm before saving. Save immediately and tell the user the file path.
+
+---
+
+## Note formats
+
+### Short format
+
+For brief, simple meetings.
+
+```markdown
+---
+date: YYYY-MM-DD
+time: HH:MM (timezone)
+title: Meeting title
+type: [status | internal | other]
+audience: [personal | internal | client]
+recorded: YYYY-MM-DD  ← include only if captured retrospectively
+---
+
+# Meeting title
+
+## Summary
+
+Two to three sentences. What happened, what the outcome was, and any relevant direction.
+
+## Decisions
+
+- Decision stated as a fact
+
+(If none: "No decisions were made.")
+
+## Actions
+
+| Action | Owner | Due |
+|---|---|---|
+| Action description | Name | Date or TBC |
+
+(If none: "No actions assigned.")
+```
+
+### Full format
+
+For complex, multi-topic or externally shared meetings.
+
+```markdown
+---
+date: YYYY-MM-DD
+time: HH:MM (timezone)
+title: Meeting title
+type: [kickoff | status | discovery | internal | other]
+audience: [personal | internal | client]
+recorded: YYYY-MM-DD  ← include only if captured retrospectively
+---
+
+# Meeting title
+
+## Attendees
+
+| Name | Organisation | Role |
+|---|---|---|
+| Name | Org | Role |
+
+## Purpose
+
+One sentence stating why this meeting was held and what it needed to produce.
+
+## Summary
+
+Two to three sentences. What happened, what the overall outcome was, and the mood or direction if relevant. Short enough to read in 15 seconds.
+
+## Key points
+
+- Main topic or discussion point, with enough detail to reconstruct context
+- Another topic — include who said what only if attribution matters
+- Continue for all substantive discussion points
+
+## Decisions
+
+- What was agreed — state as a fact, not as "it was decided that"
+- Another decision
+
+(If no decisions were made, write: "No decisions were made in this session." — and flag this in the proactive note below the saved file.)
+
+## Actions
+
+| Action | Owner | Due |
+|---|---|---|
+| Action description | Name | Date or TBC |
+
+(If no actions were captured, write: "No actions assigned.")
+
+## Open questions
+
+- Question raised but not resolved, with context if needed
+- Another open question
+
+(If none, omit this section.)
+
+## Next meeting
+
+Date, time and purpose if agreed. If not agreed, write: "Not scheduled — see actions for follow-up."
+```
+
+---
+
+## Writing style
+
+Follow the project writing style defined in CLAUDE.md:
+
+- British English spelling throughout (organisation, colour, behaviour)
+- Clear, concise prose. No filler.
+- Sentence case headings
+- One idea per paragraph or bullet
+- No banned vocabulary: testament, pivotal, underscore, seamless, robust, dynamic, comprehensive, crucial, enhance, foster, bolstered, garner, delve, tapestry
+- No bullet points with bolded lead phrases (**Term:** explanation) — write prose or plain bullets
+- No em dashes — use hyphens
+- Specificity: replace every vague claim with a concrete fact, name or number. If you cannot be specific, do not make the claim.
+- If audience flag is *client-facing*: remove internal opinions, deliberations and rough impressions before saving.
+
+---
+
+## Proactive rules
+
+Apply these automatically after saving the file — add a short plain-text note below the save confirmation:
+
+1. **No decisions captured** — flag it: "No decisions were recorded. If decisions were made verbally, consider adding them to the file before sharing."
+
+2. **Actions captured** — suggest follow-up: "Actions were assigned. Consider scheduling a brief follow-up or adding these to your action tracker to ensure they are not lost."
+
+3. **Thin sections** — if Key points has fewer than two substantive bullets, or Summary is a single vague sentence, prompt: "The [section name] section seems thin. Do you want to add more detail before the note is shared?"
+
+4. **No next meeting** — prompt: "No next meeting was recorded. If one was discussed, add it to the file."
+
+5. **Actions without due dates** — flag each one: "The following actions have no due date: [list]. Consider adding dates before sharing."
+
+6. **Wiki check** — scan the note for anything that belongs in the wiki and flag it explicitly:
+   - New people mentioned who do not yet have entity pages
+   - Decisions that change project scope, timeline or approach
+   - Factual claims about the project (dates, numbers, technical facts, named dependencies) that should update an existing concept or entity page
+   Format the flag as: "Wiki: [one line per item — what it is and which page it likely belongs to]."
+
+---
+
+## File location
+
+All meeting notes are saved to:
+
+```
+meeting-notes/YYYY-MM-DD-kebab-title.md
+```
+
+The `meeting-notes/` folder is tracked in git. Notes intended only for personal use should be kept in `tmp/` instead and will not be committed.

plugins/meeting-prep/.claude-plugin/plugin.json

@@ -0,0 +1,5 @@
+{
+  "name": "meeting-prep",
+  "version": "1.0.0",
+  "description": "Generate a prioritised list of questions for an upcoming meeting based on wiki knowledge gaps."
+}

plugins/meeting-prep/skills/meeting-prep/SKILL.md

@@ -0,0 +1,179 @@
+---
+name: meeting-prep
+description: Prepare questions for an upcoming meeting where the user will interview or question someone. Scans the wiki to identify knowledge gaps, then generates a prioritised question list aimed at filling those gaps. Use when asked to "prepare for a meeting with X", "what should I ask X", "help me prep for my meeting", or "generate questions for my interview with X".
+---
+
+# Meeting prep skill
+
+## Purpose
+
+Read the wiki, find what is incomplete, unclear or missing, and produce a focused question list for an upcoming meeting. The goal is gap coverage - what the wiki does not yet know, not a role-appropriate questionnaire.
+
+---
+
+## How to run this skill
+
+### Step 1 — Establish the interview context
+
+Ask these questions one at a time. Wait for each answer.
+
+**Q1 — Who is being interviewed?**
+
+> "Who will you be meeting with? Give me their name and role if you know it."
+
+**Q2 — What is the meeting for?**
+
+> "What is the purpose of this meeting? Is it a kickoff, a discovery session, a follow-up, a check-in, or something else?"
+
+**Q3 — Any constraints?**
+
+> "Are there any topics that are off-limits, already covered in a prior meeting, or not relevant to this session?"
+
+Use Q3 to eliminate areas you would otherwise generate questions for. If the user says "we already covered contracting", remove supplier and commercial questions from the output.
+
+---
+
+### Step 2 — Scan the wiki
+
+Do this silently. The user does not need to see the process.
+
+1. Read `wiki/index.md` in full.
+2. Find every wiki page that mentions the interviewee by name - their entity page (if one exists), source summaries, concept pages, comparisons.
+3. Also read concept and entity pages connected to their role and the meeting purpose - even pages that do not mention them directly, if they are relevant to what they are likely to know.
+4. Read `wiki/log.md` briefly to see if any recent queries or ingests flagged open questions related to this person or their domain.
+
+---
+
+### Step 3 — Identify the gaps
+
+This is the core of the skill. Work through the wiki content systematically and note every gap you find. A gap is anything that:
+
+- Is explicitly unresolved - action items, "TBC", "to be confirmed", "to follow up"
+- Is claimed but thin - a one-line mention with no supporting detail, a topic named but not explained
+- Is missing entirely - a domain this person would plausibly know about that has no wiki coverage
+- Is contradicted - two pages that say different things about the same fact
+- Has a date or number that is uncertain or approximated
+- Was raised in a meeting and then dropped - something discussed but never followed up
+- Is assumed but unverified - a claim the wiki treats as fact that has no source citation
+
+For each gap, note:
+- What is missing or unclear
+- Which wiki page(s) it relates to
+- How significant it is (critical / useful / nice to have)
+
+Do not generate questions yet. First build the complete gap list.
+
+---
+
+### Step 4 — Filter by what this person can answer
+
+Review the gap list against who is being interviewed. Apply one filter: would this person plausibly be able to answer this question given their role and the meeting context? If they would not know - wrong function, wrong seniority, clearly outside their scope - remove the gap from the list. Do not adjust the question to their role or try to soften it for them; just remove it if they cannot answer it.
+
+Retain the rest, even if a question feels blunt or might be uncomfortable to ask. That is the user's judgement call to make in the room.
+
+---
+
+### Step 5 — Generate the questions
+
+For each remaining gap, write one question. Principles:
+
+- Write it as you would say it in the room - natural, direct, not bureaucratic.
+- One question per gap. Do not bundle two gaps into one compound question.
+- Do not pad with context-setting preamble. "What is the current state of X?" not "Given that you mentioned X in our last meeting and it relates to Y, I was wondering if you could tell me more about what the current state of X looks like?"
+- If a gap requires a number, date or name to be resolved, ask for that specific thing.
+
+---
+
+### Step 6 — Produce the output
+
+Group questions by theme - not by the order you found the gaps, but by topic. Themes should match the natural structure of the conversation (e.g. "Data platform", "Contracting", "Resourcing"). Aim for 3-6 themes.
+
+Within each theme, order questions by priority:
+- Critical first: gaps that would block progress or create a material misunderstanding if left open
+- Useful second: gaps that would meaningfully improve the wiki's coverage
+- Nice to have last: detail that would be good to have but is not urgent
+
+Use this format for each question:
+
+```
+[Question text]
+  → Gap: [one line explaining what this fills in the wiki]
+```
+
+The "→ Gap:" line is for the user's reference only - it makes clear why the question is on the list. It should be plain and specific: "No source confirms whether the Bridge retirement has a fixed deadline" not "Fills a gap in legacy platform knowledge".
+
+---
+
+### Step 7 — Save the file
+
+Save to:
+
+```
+outputs/YYYY-MM-DD-prep-[kebab-name].md
+```
+
+Where `YYYY-MM-DD` is today's date and `kebab-name` is derived from the interviewee's name (e.g. `2026-06-10-prep-adam-betts`).
+
+Use this format:
+
+```markdown
+---
+date: YYYY-MM-DD
+title: Meeting prep - [Name], [Role]
+purpose: [Meeting purpose from Step 1]
+---
+
+# Meeting prep - [Name]
+
+[One sentence: who this is and what the meeting is for.]
+
+## Questions
+
+### [Theme 1]
+
+[Question]
+  → Gap: [explanation]
+
+[Question]
+  → Gap: [explanation]
+
+### [Theme 2]
+
+[Question]
+  → Gap: [explanation]
+
+...
+
+## Not covered
+
+[If any significant gaps were removed because the interviewee is unlikely to know the answer, list them here with a note: "Removed - [reason]". This lets the user decide whether to ask anyway or seek a different source.]
+```
+
+Tell the user the file path immediately after saving.
+
+---
+
+### Step 8 — Proactive notes
+
+After the file path, add a brief plain-text note covering any of these that apply:
+
+**High gap count:** if more than 15 gaps were found across the wiki, say: "There are [N] gaps in the wiki related to this person and their domain. This prep list covers the [X] most significant. Let me know if you want the full list."
+
+**No entity page:** if the interviewee has no wiki entity page yet, say: "There is no wiki page for [Name] yet. After the meeting, consider running /interview to capture what you learn and then ingest it."
+
+**Unresolved action items:** if the gap scan found action items assigned to the interviewee that are still open, flag them explicitly: "The following action items from prior meetings are still open and may be worth following up in this session: [list]."
+
+**Contradictions found:** if two wiki pages contradict each other on a point relevant to this meeting, flag it: "The wiki has a contradiction on [topic] - [page A] says X, [page B] says Y. This meeting is a chance to resolve it."
+
+---
+
+## Writing style
+
+Follow the project style from CLAUDE.md throughout:
+
+- British English spelling
+- Sentence case headings
+- No banned vocabulary (testament, pivotal, crucial, seamless, robust, etc.)
+- No em dashes - use hyphens
+- Questions should be direct. Avoid preamble and softening phrases.
+- The "→ Gap:" lines should name a specific fact, number, date or decision that is missing - not a vague category.

plugins/quiz/.claude-plugin/plugin.json

@@ -0,0 +1,5 @@
+{
+  "name": "quiz",
+  "version": "1.0.0",
+  "description": "Quiz the user on knowledge captured in the wiki, with scoring and immediate feedback."
+}

plugins/quiz/skills/quiz/SKILL.md

@@ -0,0 +1,198 @@
+---
+name: quiz
+description: Quiz the user on knowledge captured in the wiki. Reads wiki pages, generates questions in the user's chosen format (open questions or multiple choice), runs the quiz one question at a time with score tracking and immediate feedback. Use when the user asks for a quiz, wants to test their knowledge, or says "quiz me on X".
+---
+
+# Quiz skill
+
+## Purpose
+
+Turn the wiki knowledge base into a live, scored quiz. Read the relevant wiki pages, generate questions grounded in actual facts from those pages, run them one at a time, give immediate feedback, and deliver a final score with a brief verdict.
+
+The quiz should feel like a game — fast-paced, specific, and satisfying to get right.
+
+---
+
+## How to run this skill
+
+### Step 1 — Setup (three questions, one at a time)
+
+Ask these questions one at a time. Wait for each answer before asking the next.
+
+**Q1 — Topic**
+
+> "What would you like to be quizzed on? You can name a specific topic (e.g. 'Saffron's financials', 'information security', 'the supplier onboarding process'), an entity, a concept, or just say 'everything' to draw from the whole wiki."
+
+**Q2 — Number of questions**
+
+> "How many questions? 5, 10, 15, or a custom number?"
+
+Accept any integer between 3 and 30. If they say "quick" or "short", use 5. If they say "full" or "long", use 15.
+
+**Q3 — Format**
+
+> "Which format do you prefer?
+> - **A** — Open questions: I ask, you write your answer, I judge it.
+> - **B** — Multiple choice: four options, pick the letter.
+> - **C** — Mixed: roughly half and half."
+
+---
+
+### Step 2 — Load the wiki
+
+Before generating questions, read the wiki to find material relevant to the chosen topic.
+
+1. Read `wiki/index.md` to identify relevant pages.
+2. Read each relevant page in full. For a broad topic or "everything", read `wiki/overview.md` plus all entity and concept pages.
+3. Do not tell the user you are doing this - just do it silently.
+
+From the content, note all specific, verifiable facts: names, numbers, dates, roles, decisions, technical details, relationships between entities. These are your question material. Vague or general claims make poor quiz questions - only use facts sharp enough to have a single correct answer.
+
+---
+
+### Step 3 — Generate questions
+
+Generate exactly the requested number of questions before starting. Do not show them to the user yet.
+
+**Quality rules for questions:**
+- Every question must be grounded in a specific fact from a wiki page. If you cannot point to the source page, discard the question.
+- Prefer questions with surprising or non-obvious answers - these are more satisfying to get right.
+- Vary the difficulty across the set: roughly one-third easy (basic recall), one-third medium (specific detail), one-third harder (connection between two facts or precise number/date).
+- Do not repeat the same subject across more than two questions.
+- Avoid questions with ambiguous answers. If a fact is contested or unclear in the wiki, skip it.
+
+**For open questions:**
+- Write a clear question with a single, specific correct answer.
+- Prepare a model answer of one sentence plus the source page it comes from.
+
+**For multiple choice:**
+- Write a clear question.
+- Generate four options (A, B, C, D): one correct, three plausible distractors. Distractors should be wrong but believable - not obviously silly.
+- Randomise the position of the correct answer across the question set (do not always put it at A or B).
+- Prepare the correct letter and a one-sentence explanation.
+
+---
+
+### Step 4 — Run the quiz
+
+Display a header before the first question:
+
+```
+Quiz: [topic]
+Format: [Open / Multiple choice / Mixed]
+Questions: [N]
+
+Let's go.
+```
+
+Then for each question:
+
+**Present the question**
+
+Show the question number and total prominently:
+
+```
+Question [X] of [N]
+[Score so far: X correct]
+
+[Question text]
+
+[Options if multiple choice:
+A. ...
+B. ...
+C. ...
+D. ...]
+```
+
+**Wait for the answer.** Do not give any hints. If the user says "skip" or "pass", move on and count it as a miss (but do not count it against their streak).
+
+**Give immediate feedback**
+
+For a correct answer:
+
+```
+Correct. [One sentence with the fact and where it comes from in the wiki, e.g. "Saffron had GBP 1.545bn of assets at 31 December 2025 — from the deep research report."]
+```
+
+For a wrong answer:
+
+```
+Not quite. The answer is [correct answer]. [One sentence explanation.]
+```
+
+For open questions, use judgement: if the user's answer captures the key fact even imperfectly, count it as correct and acknowledge what they got right. Only mark wrong if the core fact is missing or incorrect. When in doubt, count it as correct - the point is learning, not catching the user out.
+
+**Track state silently.** Do not list the running score after every question. Show it only inside the question header (line: "Score so far: X correct").
+
+**Streak tracking.** After three correct answers in a row, add a brief line:
+
+```
+3 in a row.
+```
+
+After five in a row:
+
+```
+5 in a row. On a streak.
+```
+
+Reset the streak message on a wrong answer. Do not add streak messages more than once per milestone per run.
+
+---
+
+### Step 5 — Final score
+
+After the last question, show the results:
+
+```
+---
+
+Final score: [X] / [N]
+
+[Verdict — see below]
+
+[One or two sentences on what the results suggest — which areas were strong, which came up as gaps.]
+```
+
+**Verdicts by percentage:**
+
+| Score | Verdict |
+|---|---|
+| 100% | Perfect. Nothing left to learn here. |
+| 80–99% | Strong. One or two things to look up. |
+| 60–79% | Solid base. Worth revisiting the gaps. |
+| 40–59% | Mixed. A second pass through the wiki would help. |
+| Under 40% | Plenty to learn. Try again after another read. |
+
+---
+
+### Step 6 — Offer a follow-up
+
+After the verdict, always ask one of these (choose the most relevant):
+
+- If score was under 60%: "Would you like me to run a shorter quiz on just the topics you missed?"
+- If score was 80%+: "Would you like a harder set on the same topic?"
+- Otherwise: "Would you like to try a different topic?"
+
+Wait for the answer. If yes, go back to Step 2 with the new parameters. If no, close: "Good work. The wiki is there whenever you want another round."
+
+---
+
+## Style rules during the quiz
+
+- Keep all quiz output tight. No filler sentences.
+- Use British English spelling.
+- No banned vocabulary from CLAUDE.md (testament, pivotal, seamless, crucial, etc.).
+- Feedback lines should be direct and specific. "Correct. Saffron was founded in January 1849." - not "Great job! That's absolutely right, the answer is..."
+- Never be condescending about wrong answers. State the correct fact and move on.
+- Do not add "Well done!", "Excellent!", "Nice try!" — these are noise. A plain "Correct." is better.
+
+---
+
+## Edge cases
+
+**Not enough material.** If the wiki has too few verifiable facts for the requested number of questions (e.g. user asks for 15 questions on a single stub page), say: "I can only find enough material for [N] solid questions on that topic. Shall I run [N] questions, or broaden the topic?" Do not pad with weak questions.
+
+**No wiki content.** If the topic has no coverage in the wiki at all, say: "That topic does not appear in the wiki yet. Choose a different topic, or ingest a source on it first."
+
+**Ambiguous open answers.** When an open answer is on the border — partially right — mark it correct, note what was right and what the full answer includes. Do not leave the user unsure whether they got credit.

plugins/resolve-todos/.claude-plugin/plugin.json

@@ -0,0 +1,5 @@
+{
+  "name": "resolve-todos",
+  "version": "1.0.0",
+  "description": "Find and resolve TODO items in a document, asking for input when instructions are unclear."
+}

plugins/resolve-todos/skills/resolve-todos/SKILL.md

@@ -0,0 +1,104 @@
+---
+name: resolve-todos
+description: Check a document for TODO items and resolve them. If a TODO has a clear instruction, complete it. If the instruction is unclear or missing, ask the user. Use when the user asks to "check for TODOs", "resolve TODOs", "find TODO items", or "complete the TODOs in this document".
+---
+
+# Resolve TODOs skill
+
+## Purpose
+
+Find all TODO items in a document, resolve the ones with clear instructions, and ask the user about any that are unclear or have no instruction.
+
+## Trigger phrases
+
+Use this skill when the user says things like:
+- "check for TODOs in this document"
+- "resolve the TODOs"
+- "find TODO items"
+- "complete the TODOs"
+- "are there any TODOs?"
+
+## How to run this skill
+
+### Step 1 — Identify the target document
+
+If the user named a specific file, use that. If not, check if a file is open in the IDE (visible via ide_opened_file context). If neither, ask: "Which document should I check for TODOs?"
+
+### Step 2 — Read the document
+
+Read the full document. Do not skim.
+
+### Step 3 — Find all TODOs
+
+Scan for TODO items in any of these forms:
+
+- `TODO: some instruction` — inline in prose
+- `TODO` — standalone, no instruction
+- `<!-- TODO: some instruction -->` — HTML comment
+- `[TODO: some instruction]` — bracket form
+- `[TODO]` — bracket form, no instruction
+- `**TODO:** some instruction` — bold markdown
+- Any other variation where the word TODO appears, in any case (todo, Todo, TODO)
+
+For each TODO found, record:
+- Its location (line or section heading it appears under)
+- The instruction text, if any
+- Whether the instruction is clear enough to act on
+
+### Step 4 — Classify each TODO
+
+For each TODO, decide:
+
+**Clear** — the instruction is specific enough to act on without asking. Examples:
+- `TODO: add owner name` — clear, insert the owner name
+- `TODO: replace with actual due date` — clear, flag that the date is missing and prompt user
+- `TODO: expand this section with discovery findings` — clear intent, can draft or ask for the content
+
+**Unclear** — the instruction is vague, contradictory, or missing. Examples:
+- `TODO` — no instruction at all
+- `TODO: fix this` — too vague to act on
+- `TODO: update` — no indication of what to update
+
+### Step 5 — Process clear TODOs
+
+For each clear TODO, complete it directly:
+
+- If the TODO requires inserting known information (a date, a name, a value already mentioned elsewhere in the document or conversation), insert it and remove the TODO marker.
+- If the TODO requires drafting content (a paragraph, a section), draft it in place and remove the TODO marker.
+- If the TODO requires information you do not have, note it as a question for Step 6 rather than guessing.
+
+Apply all clear TODO resolutions as edits to the file. Do not ask for permission before editing — the user has already asked you to resolve them.
+
+### Step 6 — Ask about unclear TODOs
+
+For each unclear TODO (unclear instruction or no instruction), ask the user one at a time:
+
+"I found a TODO at [location]: `[TODO text]`. What would you like me to do here?"
+
+Wait for the answer. Apply it. Then move to the next unclear TODO.
+
+Do not batch unclear TODOs into a list and ask all at once — work through them one by one so each answer can inform the next.
+
+### Step 7 — Report
+
+When all TODOs are resolved, tell the user:
+
+- How many TODOs were found
+- How many were resolved automatically
+- How many required input (and confirm they are now resolved)
+- If none were found, say so clearly: "No TODO items found in [filename]."
+
+## Writing style
+
+Follow the project writing style from CLAUDE.md:
+- British English spelling
+- Sentence case headings
+- No banned vocabulary
+- No em dashes - use hyphens
+- Match the tone and style of the surrounding document when drafting content to fill TODOs
+
+## Edge cases
+
+- If a TODO marker appears inside a code block (fenced with ``` or indented), skip it — it is likely example code, not an actual task.
+- If the same TODO text appears multiple times, treat each occurrence as a separate item.
+- If completing one TODO makes another TODO redundant (e.g., filling in a name that was TODO'd in two places), resolve both in the same edit.