From 77ffb33f3bd0a7c474176e958a737b2d477a89c0 Mon Sep 17 00:00:00 2001 From: Russ Rutledge Date: Tue, 11 Aug 2026 10:53:24 -0500 Subject: [PATCH 1/6] Add analyze-innersource-video Claude Code skill Adds a Claude Code skill that analyzes an InnerSource Commons community call video against this repo's pattern library: it fetches the talk's transcript and metadata, surveys adjacent patterns, and categorizes the talk's content into Known Instance candidates, clarifications to an existing pattern, or genuinely new pattern candidates - applying a "uniquely InnerSource" filter to screen out generic engineering advice that isn't specific to cross-team, cross-org contribution dynamics. The skill always proposes and asks for confirmation before editing any pattern file or opening a PR - it never auto-commits. This was already used manually to produce the Thales Group Known Instance PR (#909); this commit is the first time the skill itself is checked into the repo rather than living only on one contributor's machine. Co-authored-by: Claude Sonnet 5 --- .../skills/analyze-innersource-video/SKILL.md | 178 ++++++++++++++++++ 1 file changed, 178 insertions(+) create mode 100644 .claude/skills/analyze-innersource-video/SKILL.md diff --git a/.claude/skills/analyze-innersource-video/SKILL.md b/.claude/skills/analyze-innersource-video/SKILL.md new file mode 100644 index 000000000..904d3fb94 --- /dev/null +++ b/.claude/skills/analyze-innersource-video/SKILL.md @@ -0,0 +1,178 @@ +--- +name: analyze-innersource-video +description: Analyze an InnerSource conference talk or community video on YouTube and relate it to the InnerSourcePatterns library. Identifies which existing patterns the talk instantiates (Known Instance candidates), where it suggests clarifications to an existing pattern, and whether it justifies drafting a new pattern. Use when given a YouTube URL of an InnerSource-related video and asked to relate it to this repo's pattern library. +--- + +# Analyze InnerSource Video + +## When to use + +The user provides a YouTube URL of an InnerSource talk and asks you to compare it to the patterns in this repo. Goals: surface known instances, propose surgical clarifications to existing patterns, and identify genuinely new InnerSource pattern candidates. + +## Default behavior + +**Propose, never auto-edit.** Always present analysis and use `AskUserQuestion` to confirm direction before making file changes. Never commit or PR without explicit confirmation. + +## Workflow + +### Step 1 — Fetch transcript and metadata + +**Transcript** — use the `youtube-transcript-api` Python library (already available; pip-installable if not). Do *not* try `WebFetch` on YouTube watch pages — it returns only the footer. + +Write a script to `.tmp/fetch_transcript.py`: + +```python +from youtube_transcript_api import YouTubeTranscriptApi + +video_id = "" +api = YouTubeTranscriptApi() +transcript = api.fetch(video_id) +with open(".tmp/transcript_raw.txt", "w", encoding="utf-8") as f: + for s in transcript: + f.write(f"[{s.start:.1f}] {s.text}\n") +``` + +Then collapse it to a flat readable form in `.tmp/transcript_flat.txt` (strip timestamps, join, normalize whitespace). + +**Metadata** — use `yt-dlp` via `python -m yt_dlp` (the `yt-dlp` binary may not be on PATH on Windows even when the package is installed). Write `.tmp/fetch_metadata.py`: + +```python +import json, yt_dlp +opts = {"quiet": True, "skip_download": True, "no_warnings": True} +with yt_dlp.YoutubeDL(opts) as ydl: + info = ydl.extract_info("", download=False) +keys = ["title", "uploader", "channel", "upload_date", "duration", "description", "tags"] +out = {k: info.get(k) for k in keys} +with open(".tmp/video_metadata.json", "w", encoding="utf-8") as f: + json.dump(out, f, ensure_ascii=False, indent=2) +print(out["title"]); print(out["channel"]); print(out["description"]) +``` + +**The description usually contains speaker name and affiliation when the transcript does not** — this is the single most important reason to fetch metadata even when you have the transcript. Speakers often introduce themselves with just a first name or nickname. + +**Fallback for title + channel only:** the YouTube oEmbed endpoint (`https://www.youtube.com/oembed?url=&format=json`) works through `WebFetch`. + +### Step 2 — Summarize the talk + +Produce a brief synthesis covering: + +- **Title** (from metadata, not from the transcript's spoken title — they often differ) +- **Speaker** — full name from the description; note any nickname the speaker uses in the talk +- **Organization** — from the description +- **Channel / event** — typically the InnerSource Commons channel; the description often names a specific summit or webinar +- **Upload date** — useful for citation +- **Core thesis** in one or two sentences +- **Main artifacts / frameworks** the speaker introduces (named structures, checklists, blueprints, mantras) +- **Memorable lines** — verbatim quotes can become useful in the pattern's Known Instance description + +### Step 3 — Survey adjacent patterns + +Extract every pattern's title + patlet via a small script (write to `.tmp/extract_patlets.py`). Read the resulting file in full — you want the patlet, not just the title, to judge relevance. + +Then pick the 3–6 patterns whose patlets sit closest to the talk's theme and read those in full. Don't rely solely on patlets to judge a match: the talk's content may overlap meaningfully with parts of a pattern that the patlet doesn't surface. + +### Step 4 — Categorize the talk's content + +For each substantive point in the talk, assign it to one of: + +**A. Known Instance candidate** — the talk validates, exemplifies, or vividly re-derives an existing pattern's solution. The right action: add a citation under the pattern's `## Known Instances` section. + +**B. Clarification candidate** — the talk surfaces a real gap or vagueness in an existing pattern. The right action: a small, surgical edit that fills the gap without reframing the pattern. Bias toward additions over rewrites; bias toward concrete guidance over editorial framing. + +**C. New pattern candidate** — the talk presents a problem/solution pair that no existing pattern covers. The right action: propose drafting a new pattern using the AI-assisted prompt in `meta/pattern-drafts-with-ai.md`. + +### Step 5 — Apply the "uniquely InnerSource" filter + +**This is the most important judgment call and the easiest mistake to make.** A talk can contain genuinely good engineering advice that is *not* uniquely InnerSource. Examples that look like new patterns but probably aren't: + +- "Treat docs like code" — general dev advice; well-trodden outside InnerSource. +- "Write better READMEs" — general OSS / dev advice. +- "Use linters / CI / automation" — general engineering. + +What *is* uniquely InnerSource — the signal you're looking for: + +- It addresses the specific dynamic of **contributors who are not on the host team** (no shared context, no shared OKRs, no shared manager). +- It addresses **cross-team collaboration friction** inside one company (Trusted Committers, escalation, ownership ambiguity, dual-line-management tension). +- It addresses **incentive misalignment** between a developer's team goals and contributing to a shared project. +- It addresses **scaling InnerSource adoption** across an organization (ambassadors, ISPO, governance levels). + +If the talk's central insight would be equally at home in a generic "good engineering" talk, it is not new-pattern material. It may still be a Known Instance or a clarification. + +### Step 6 — Present analysis + +Present a clear, three-part writeup to the user: + +1. **Talk summary** (5–10 lines: speaker, org, thesis, blueprint) +2. **Mapping to existing patterns** with confidence labels (strong match, partial match, tangential) +3. **Candidate actions** organized as: Known Instances to add, clarifications to make, new pattern candidates (with the "uniquely InnerSource" filter applied) + +Then use `AskUserQuestion` to confirm which actions to take. **Do not edit any file before this confirmation.** If the user is non-committal ("you decide"), make a confident recommendation in your own voice rather than asking again. + +### Step 7 — Apply chosen actions + +**For Known Instance citations:** + +- Match the existing style of that pattern's Known Instances section — typically `* **** - ` with the URL inline. +- The lead bold should be the speaker's *organization*, not "Community talk" or similar meta-labels — the existing entries are all organizational, so use the same convention. If you cannot find an organization, ask the user before defaulting to a placeholder. +- Quote a memorable line or describe the framework concisely. Cite the YouTube link. + +**For clarifications:** + +- Stay surgical. Prefer adding a new subsection or bullet over rewriting an existing one. +- If the change touches the pattern's templates (e.g. `templates/README-template.md`), edit those too. +- Cross-link to other related patterns when distinguishing what the talk adds vs. what's already covered (e.g. distinguishing a contributor-facing system map from ADRs). + +**For new patterns:** + +- Use the prompt in `meta/pattern-drafts-with-ai.md` as the basis for drafting. +- File name: lowercase, hyphenated, matching the title. Place in `patterns/1-initial/`. +- Set Status to `Initial`, Known Instances to the talk itself, Author to TBD, omit Acknowledgments. +- Be honest about what evidence the talk provides — one talk is one data point, not proof a pattern is widely applicable. + +### Step 8 — Git workflow + +- **Always branch off `main`**, not whichever branch the user is currently on. Confirm with `git status` and `git branch --show-current` first. +- **One concern per PR** when possible: a Known Instance citation, a pattern clarification, and a new pattern draft are three separate concerns and may deserve separate PRs. +- Match the repo's commit message style: sentence-case subject, no conventional-commit prefix (check `git log --oneline -5` for recent style). +- Write the commit message body to `.tmp/commit_msg.txt` and use `git commit -F` (per user's no-heredocs rule). +- Open the PR against `InnerSourceCommons/InnerSourcePatterns` upstream `main` (the user's fork is `origin`). +- Include a `## Test plan` checklist in the PR body — the repo's convention. +- Ask the user before pushing/PRing rather than auto-proceeding. + +## Anti-patterns to avoid + +- Don't use `WebFetch` on YouTube watch pages — it returns only the footer. Use `youtube-transcript-api` and `yt-dlp` instead. +- Don't trust the spoken introduction for the speaker's organization — get it from the video description. +- Don't add a Known Instance entry labeled "Community talk" or similar generic placeholder — the convention is to lead with the speaker's organization. +- Don't propose "Treat docs like code" or similar generic-engineering ideas as new InnerSource patterns. Apply the Step 5 filter. +- Don't bundle multiple PRs into one commit on the same branch — separate concerns deserve separate PRs. +- Don't auto-commit or auto-push without confirmation from the user, even on "high confidence" calls — community library content warrants a human in the loop. +- Don't write the commit message via heredoc — write to `.tmp/commit_msg.txt` and use `git commit -F`. + +## Output format for the user-facing analysis + +Structure the final writeup as: + +``` +## Video summary +<5–10 lines> + +## How it maps to the existing pattern library + +### Strong match — Known Instance candidate +**[Pattern Name](patterns/.../file.md)** + + +### Partial / adjacent match +**[Pattern Name](patterns/.../file.md)** + + +### Candidate new patterns +**Candidate A — ""** + + +## Recommendation + +``` + +Then `AskUserQuestion` to confirm. From 3adb2193aa6ba7eb49a138c9af4ccd4fc5980d40 Mon Sep 17 00:00:00 2001 From: Russ Rutledge Date: Tue, 11 Aug 2026 16:12:09 -0500 Subject: [PATCH 2/6] Accept a transcript directly, and bundle one talk into one PR Two corrections per review: - Step 1 now accepts a transcript handed to it directly (the going-forward case: an automated source pulls a Zoom transcript once a community call finishes, with no YouTube URL involved at all) as well as a YouTube URL to fetch from - the URL-fetch path stays for backlog talks and one-off requests. - Step 8's "one concern per PR" is replaced with "one talk = one PR": bundle everything a single talk's analysis found - Known Instances across multiple patterns, clarifications, new pattern drafts - into one PR, matching how #909 actually added Thales across five patterns in a single PR. Only split PRs across genuinely different source talks. Co-authored-by: Claude Sonnet 5 --- .../skills/analyze-innersource-video/SKILL.md | 16 +++++++++++----- 1 file changed, 11 insertions(+), 5 deletions(-) diff --git a/.claude/skills/analyze-innersource-video/SKILL.md b/.claude/skills/analyze-innersource-video/SKILL.md index 904d3fb94..d2f4f0716 100644 --- a/.claude/skills/analyze-innersource-video/SKILL.md +++ b/.claude/skills/analyze-innersource-video/SKILL.md @@ -1,13 +1,15 @@ --- name: analyze-innersource-video -description: Analyze an InnerSource conference talk or community video on YouTube and relate it to the InnerSourcePatterns library. Identifies which existing patterns the talk instantiates (Known Instance candidates), where it suggests clarifications to an existing pattern, and whether it justifies drafting a new pattern. Use when given a YouTube URL of an InnerSource-related video and asked to relate it to this repo's pattern library. +description: Analyze an InnerSource conference talk or community call — given either a YouTube URL or a transcript directly — and relate it to the InnerSourcePatterns library. Identifies which existing patterns the talk instantiates (Known Instance candidates), where it suggests clarifications to an existing pattern, and whether it justifies drafting a new pattern. Use when given a YouTube URL or a transcript of an InnerSource-related talk and asked to relate it to this repo's pattern library. --- # Analyze InnerSource Video ## When to use -The user provides a YouTube URL of an InnerSource talk and asks you to compare it to the patterns in this repo. Goals: surface known instances, propose surgical clarifications to existing patterns, and identify genuinely new InnerSource pattern candidates. +The user provides either a YouTube URL or an already-fetched transcript of an InnerSource talk and asks you to compare it to the patterns in this repo. **A transcript handed to you directly is the common case going forward** — an automated source (e.g. a Zoom transcript pulled once a community call finishes) supplies the transcript and whatever metadata it has (speaker, org, date) without a YouTube URL ever being in the loop. The YouTube-fetch path stays for backlog talks and one-off requests where only a URL exists. See Step 1 for both. + +Goals: surface known instances, propose surgical clarifications to existing patterns, and identify genuinely new InnerSource pattern candidates. ## Default behavior @@ -15,7 +17,11 @@ The user provides a YouTube URL of an InnerSource talk and asks you to compare i ## Workflow -### Step 1 — Fetch transcript and metadata +### Step 1 — Get transcript and metadata + +**If a transcript was handed to you directly** (the going-forward case — e.g. a Zoom transcript an automated source already pulled), skip the fetch entirely. Take whatever metadata came with it (speaker, org, event, date); if any of it is missing, ask the caller before falling back to a placeholder — same rule as Step 7's Known Instance citation. There is no video to fetch and no YouTube URL required. + +**If you only have a YouTube URL** (backlog talks, one-off requests), fetch both: **Transcript** — use the `youtube-transcript-api` Python library (already available; pip-installable if not). Do *not* try `WebFetch` on YouTube watch pages — it returns only the footer. @@ -132,7 +138,7 @@ Then use `AskUserQuestion` to confirm which actions to take. **Do not edit any f ### Step 8 — Git workflow - **Always branch off `main`**, not whichever branch the user is currently on. Confirm with `git status` and `git branch --show-current` first. -- **One concern per PR** when possible: a Known Instance citation, a pattern clarification, and a new pattern draft are three separate concerns and may deserve separate PRs. +- **One talk = one PR.** Bundle everything the analysis found for a single talk into one PR — Known Instance citations across several patterns, clarifications, a new pattern draft, whatever applies — the way #909 added Thales as a Known Instance across five patterns in one PR. Only split into separate PRs when the changes come from genuinely different source talks, not because they touch different patterns or different candidate types. - Match the repo's commit message style: sentence-case subject, no conventional-commit prefix (check `git log --oneline -5` for recent style). - Write the commit message body to `.tmp/commit_msg.txt` and use `git commit -F` (per user's no-heredocs rule). - Open the PR against `InnerSourceCommons/InnerSourcePatterns` upstream `main` (the user's fork is `origin`). @@ -145,7 +151,7 @@ Then use `AskUserQuestion` to confirm which actions to take. **Do not edit any f - Don't trust the spoken introduction for the speaker's organization — get it from the video description. - Don't add a Known Instance entry labeled "Community talk" or similar generic placeholder — the convention is to lead with the speaker's organization. - Don't propose "Treat docs like code" or similar generic-engineering ideas as new InnerSource patterns. Apply the Step 5 filter. -- Don't bundle multiple PRs into one commit on the same branch — separate concerns deserve separate PRs. +- Don't split one talk's findings across multiple PRs — bundle Known Instances, clarifications, and new pattern drafts from the same talk into one PR (see Step 8). - Don't auto-commit or auto-push without confirmation from the user, even on "high confidence" calls — community library content warrants a human in the loop. - Don't write the commit message via heredoc — write to `.tmp/commit_msg.txt` and use `git commit -F`. From 861e5779d8c44cd82273e5ee8dd5f6802e47c1df Mon Sep 17 00:00:00 2001 From: Russ Rutledge Date: Tue, 11 Aug 2026 21:03:54 -0500 Subject: [PATCH 3/6] Write the whole skill as transcript-first, not YouTube-first Per review: stop framing this as two parallel input paths ("YouTube URL or transcript"). The skill takes a transcript - full stop; where it came from is the caller's concern, not something this document needs to branch on. YouTube-specific fetch mechanics (youtube-transcript-api, yt-dlp) stay as a practical note for when a transcript still needs to be pulled from a video, not as the document's primary framing. Generalizes metadata field descriptions and "cite the source link" away from video-specific phrasing, and retitles the output template's "Video summary" to "Talk summary" to match. Co-authored-by: Claude Sonnet 5 --- .../skills/analyze-innersource-video/SKILL.md | 26 +++++++++---------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/.claude/skills/analyze-innersource-video/SKILL.md b/.claude/skills/analyze-innersource-video/SKILL.md index d2f4f0716..f49af0903 100644 --- a/.claude/skills/analyze-innersource-video/SKILL.md +++ b/.claude/skills/analyze-innersource-video/SKILL.md @@ -1,13 +1,13 @@ --- name: analyze-innersource-video -description: Analyze an InnerSource conference talk or community call — given either a YouTube URL or a transcript directly — and relate it to the InnerSourcePatterns library. Identifies which existing patterns the talk instantiates (Known Instance candidates), where it suggests clarifications to an existing pattern, and whether it justifies drafting a new pattern. Use when given a YouTube URL or a transcript of an InnerSource-related talk and asked to relate it to this repo's pattern library. +description: Analyze an InnerSource conference talk transcript and relate it to the InnerSourcePatterns library. Identifies which existing patterns the talk instantiates (Known Instance candidates), where it suggests clarifications to an existing pattern, and whether it justifies drafting a new pattern. Use when given a transcript of an InnerSource-related talk and asked to relate it to this repo's pattern library. --- # Analyze InnerSource Video ## When to use -The user provides either a YouTube URL or an already-fetched transcript of an InnerSource talk and asks you to compare it to the patterns in this repo. **A transcript handed to you directly is the common case going forward** — an automated source (e.g. a Zoom transcript pulled once a community call finishes) supplies the transcript and whatever metadata it has (speaker, org, date) without a YouTube URL ever being in the loop. The YouTube-fetch path stays for backlog talks and one-off requests where only a URL exists. See Step 1 for both. +The user provides a transcript of an InnerSource talk — plus whatever metadata comes with it (speaker, org, event, date) — and asks you to compare it to the patterns in this repo. Goals: surface known instances, propose surgical clarifications to existing patterns, and identify genuinely new InnerSource pattern candidates. @@ -17,13 +17,11 @@ Goals: surface known instances, propose surgical clarifications to existing patt ## Workflow -### Step 1 — Get transcript and metadata +### Step 1 — Confirm the transcript and metadata -**If a transcript was handed to you directly** (the going-forward case — e.g. a Zoom transcript an automated source already pulled), skip the fetch entirely. Take whatever metadata came with it (speaker, org, event, date); if any of it is missing, ask the caller before falling back to a placeholder — same rule as Step 7's Known Instance citation. There is no video to fetch and no YouTube URL required. +You need the transcript text, plus speaker, organization, event/channel, and date. If any of that's missing, ask the caller for it before guessing — a placeholder in a Known Instance citation is worse than asking (see Step 7). -**If you only have a YouTube URL** (backlog talks, one-off requests), fetch both: - -**Transcript** — use the `youtube-transcript-api` Python library (already available; pip-installable if not). Do *not* try `WebFetch` on YouTube watch pages — it returns only the footer. +**If you still need to pull a transcript from a video**, get it with the `youtube-transcript-api` Python library (already available; pip-installable if not). Do *not* try `WebFetch` on a YouTube watch page — it returns only the footer. Write a script to `.tmp/fetch_transcript.py`: @@ -40,7 +38,7 @@ with open(".tmp/transcript_raw.txt", "w", encoding="utf-8") as f: Then collapse it to a flat readable form in `.tmp/transcript_flat.txt` (strip timestamps, join, normalize whitespace). -**Metadata** — use `yt-dlp` via `python -m yt_dlp` (the `yt-dlp` binary may not be on PATH on Windows even when the package is installed). Write `.tmp/fetch_metadata.py`: +**If speaker/org/date are still missing** and the transcript came from a video, pull them with `yt-dlp` via `python -m yt_dlp` (the `yt-dlp` binary may not be on PATH on Windows even when the package is installed). Write `.tmp/fetch_metadata.py`: ```python import json, yt_dlp @@ -63,10 +61,10 @@ print(out["title"]); print(out["channel"]); print(out["description"]) Produce a brief synthesis covering: - **Title** (from metadata, not from the transcript's spoken title — they often differ) -- **Speaker** — full name from the description; note any nickname the speaker uses in the talk -- **Organization** — from the description -- **Channel / event** — typically the InnerSource Commons channel; the description often names a specific summit or webinar -- **Upload date** — useful for citation +- **Speaker** — full name; note any nickname the speaker uses in the talk +- **Organization** +- **Event** — typically an InnerSource Commons community call; note the specific summit or webinar if named +- **Date** — useful for citation - **Core thesis** in one or two sentences - **Main artifacts / frameworks** the speaker introduces (named structures, checklists, blueprints, mantras) - **Memorable lines** — verbatim quotes can become useful in the pattern's Known Instance description @@ -120,7 +118,7 @@ Then use `AskUserQuestion` to confirm which actions to take. **Do not edit any f - Match the existing style of that pattern's Known Instances section — typically `* **** - ` with the URL inline. - The lead bold should be the speaker's *organization*, not "Community talk" or similar meta-labels — the existing entries are all organizational, so use the same convention. If you cannot find an organization, ask the user before defaulting to a placeholder. -- Quote a memorable line or describe the framework concisely. Cite the YouTube link. +- Quote a memorable line or describe the framework concisely. Cite the source link. **For clarifications:** @@ -160,7 +158,7 @@ Then use `AskUserQuestion` to confirm which actions to take. **Do not edit any f Structure the final writeup as: ``` -## Video summary +## Talk summary <5–10 lines> ## How it maps to the existing pattern library From d99ce64afa8c0f067dd11909a2d9a6daa9de3cde Mon Sep 17 00:00:00 2001 From: Russ Rutledge Date: Wed, 12 Aug 2026 08:26:55 -0500 Subject: [PATCH 4/6] Stop discouraging new-pattern drafts from a single talk The old guidance ("one talk is one data point, not proof a pattern is widely applicable") read as a reason to hold back drafting a genuine new-pattern candidate. But this process only ever sees one talk at a time, so that standard would mean a new pattern candidate never gets drafted at all. Checked meta/contributor-handbook.md: maturity level 1 (Initial) has NO validation requirement - it's explicitly for a single unstructured idea. One instance is what's needed for level 2 (Structured); only 3+ need level 3 (Validated). So the guidance now says to draft at Initial from one talk, which is exactly what that level is for - confirmed against Paired Onboarding Sprint (#926), the first pattern this skill has drafted this way. Co-authored-by: Claude Sonnet 5 --- .claude/skills/analyze-innersource-video/SKILL.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.claude/skills/analyze-innersource-video/SKILL.md b/.claude/skills/analyze-innersource-video/SKILL.md index f49af0903..dd2724aa0 100644 --- a/.claude/skills/analyze-innersource-video/SKILL.md +++ b/.claude/skills/analyze-innersource-video/SKILL.md @@ -131,7 +131,7 @@ Then use `AskUserQuestion` to confirm which actions to take. **Do not edit any f - Use the prompt in `meta/pattern-drafts-with-ai.md` as the basis for drafting. - File name: lowercase, hyphenated, matching the title. Place in `patterns/1-initial/`. - Set Status to `Initial`, Known Instances to the talk itself, Author to TBD, omit Acknowledgments. -- Be honest about what evidence the talk provides — one talk is one data point, not proof a pattern is widely applicable. +- **One talk is enough to draft at Initial — don't hold back.** Per `meta/contributor-handbook.md`, maturity level 1 (Initial) has no validation requirement at all; it's explicitly for a single unstructured idea, even a "donut" with missing sections. One known instance clears the bar for level 2 (Structured); only 3+ instances need level 3 (Validated). So a genuine new-pattern candidate from one talk should be drafted at Initial, not held back for more evidence that this process — one talk at a time — will never accumulate on its own. ### Step 8 — Git workflow From 45ac72e658c5fa74e498bcf2e233261205a105a8 Mon Sep 17 00:00:00 2001 From: Russ Rutledge Date: Wed, 12 Aug 2026 12:44:36 -0500 Subject: [PATCH 5/6] Read README's pattern list instead of extracting patlets Per Sebastian Spier's review: the repo's own README.md already has a "List of Patterns" section with every pattern's title and patlet, kept current as patterns are added (spot-checked against the newest merged pattern - it's there). Reading that one file directly is simpler and more reliable than writing and running a script to walk the patterns/ directory and regex out each Patlet section. Co-authored-by: Claude Sonnet 5 Co-authored-by: Sebastian Spier --- .claude/skills/analyze-innersource-video/SKILL.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/.claude/skills/analyze-innersource-video/SKILL.md b/.claude/skills/analyze-innersource-video/SKILL.md index dd2724aa0..f9abfcc41 100644 --- a/.claude/skills/analyze-innersource-video/SKILL.md +++ b/.claude/skills/analyze-innersource-video/SKILL.md @@ -71,9 +71,9 @@ Produce a brief synthesis covering: ### Step 3 — Survey adjacent patterns -Extract every pattern's title + patlet via a small script (write to `.tmp/extract_patlets.py`). Read the resulting file in full — you want the patlet, not just the title, to judge relevance. +Read the "List of Patterns" section of the repo's own `README.md` — it already has every pattern's title and patlet, grouped by maturity level, kept current as patterns are added. Read it in full; you want the patlet, not just the title, to judge relevance. -Then pick the 3–6 patterns whose patlets sit closest to the talk's theme and read those in full. Don't rely solely on patlets to judge a match: the talk's content may overlap meaningfully with parts of a pattern that the patlet doesn't surface. +Then pick the 3–6 patterns whose patlets sit closest to the talk's theme and read those files in full. Don't rely solely on patlets to judge a match: the talk's content may overlap meaningfully with parts of a pattern that the patlet doesn't surface. ### Step 4 — Categorize the talk's content From f62021c74f15730e81ea043b15f38f9cd234f207 Mon Sep 17 00:00:00 2001 From: Russ Rutledge Date: Wed, 12 Aug 2026 14:29:47 -0500 Subject: [PATCH 6/6] Require checking a pattern's actual Solution before citing a Known Instance Topical keyword overlap (e.g. 'developer environment') isn't enough - the GDK/Internal Developer Platform mismatch on #926 happened because a local dev tool got matched to a pattern about centralized, deployed platforms purely on theme. --- .claude/skills/analyze-innersource-video/SKILL.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/.claude/skills/analyze-innersource-video/SKILL.md b/.claude/skills/analyze-innersource-video/SKILL.md index f9abfcc41..10a279a42 100644 --- a/.claude/skills/analyze-innersource-video/SKILL.md +++ b/.claude/skills/analyze-innersource-video/SKILL.md @@ -81,6 +81,8 @@ For each substantive point in the talk, assign it to one of: **A. Known Instance candidate** — the talk validates, exemplifies, or vividly re-derives an existing pattern's solution. The right action: add a citation under the pattern's `## Known Instances` section. +**Before citing a match, re-read the pattern's `## Problem` and `## Solution` sections, not just its patlet or title.** A talk can share a topic word with a pattern — "developer environment," "onboarding," "platform" — while doing something structurally different from what that pattern actually solves. Internal Developer Platform is a real trap here: it's specifically about a centralized, deployed, org-run self-service system (a portal, CI/CD orchestration, infrastructure provisioning) — not any tool that touches "developer environments." A story about a contributor's local setup (a containerized dev kit they run on their own laptop) is not a Known Instance of it, however similar the vocabulary sounds. The test is whether the talk's example does the same thing the pattern's Solution describes, not whether it shares a theme with the patlet. + **B. Clarification candidate** — the talk surfaces a real gap or vagueness in an existing pattern. The right action: a small, surgical edit that fills the gap without reframing the pattern. Bias toward additions over rewrites; bias toward concrete guidance over editorial framing. **C. New pattern candidate** — the talk presents a problem/solution pair that no existing pattern covers. The right action: propose drafting a new pattern using the AI-assisted prompt in `meta/pattern-drafts-with-ai.md`.