@muskanmeet/invoicing-design-system 0.1.0

package/.local/secondary_skills/podcast-marketing/youtube-processing.md

@@ -0,0 +1,328 @@
+# YouTube Processing
+
+How to extract transcripts, metadata, and audio from YouTube videos for the podcast marketing pipeline.
+
+## Table of Contents
+
+- [URL Handling](#url-handling) — Recognize and normalize YouTube URLs
+- [Caption Extraction](#caption-extraction) — Fetch auto-generated or manual subtitles (preferred, no API key)
+
+- [Audio Download & Transcription](#audio-download--transcription) — Fallback when no captions exist
+- [Metadata Extraction](#metadata-extraction) — Title, channel, description, duration
+
+- [Integration with Content Pipeline](#integration-with-content-pipeline) — How YouTube input feeds into the standard pipeline
+
+## URL Handling
+
+YouTube URLs come in several formats. Normalize to a video ID before processing:
+
+- `https://www.youtube.com/watch?v=VIDEO_ID`
+- `https://youtu.be/VIDEO_ID`
+
+- `https://www.youtube.com/embed/VIDEO_ID`
+- `https://m.youtube.com/watch?v=VIDEO_ID`
+
+- URLs with extra parameters: `&t=120`, `&list=PLxxx`, `&si=xxx`
+
+```python
+
+import re
+
+def extract_video_id(url: str) -> str | None:
+
+patterns = [
+
+r"(?:youtube\\com/watch\\v=|youtu\\be/|youtube\\com/embed/)([a-zA-Z0-9_-]{11})",
+
+]
+
+for pattern in patterns:
+
+match = re.search(pattern, url)
+
+if match:
+
+return match.group(1)
+
+return None
+
+```
+
+## Caption Extraction
+
+The preferred approach — fast, free, and doesn't require downloading the full audio.
+
+### Using youtube-transcript-api
+
+```bash
+
+pip install youtube-transcript-api
+
+```
+
+```python
+
+from youtube_transcript_api import YouTubeTranscriptApi
+
+def get_youtube_transcript(video_id: str, languages: list[str] | None = None) -> dict:
+
+"""Fetch transcript from YouTube's caption system.
+
+Tries manually uploaded captions first, then auto-generated.
+
+Returns a normalized transcript dict compatible with the content pipeline.
+
+Args:
+
+video_id: The 11-character YouTube video ID.
+
+languages: Preferred languages in order. Defaults to ["en"].
+
+Returns:
+
+dict with "text" (full transcript string) and "segments"
+
+(list of {start, end, text} dicts).
+
+Raises:
+
+Exception if no captions are available in any language.
+
+"""
+
+if languages is None:
+
+languages = ["en"]
+
+try:
+
+transcript_list = YouTubeTranscriptApi.list_transcripts(video_id)
+
+transcript = None
+
+try:
+
+transcript = transcript_list.find_manually_created_transcript(languages)
+
+except Exception:
+
+try:
+
+transcript = transcript_list.find_generated_transcript(languages)
+
+except Exception:
+
+pass
+
+if transcript is None:
+
+available = list(transcript_list)
+
+if available:
+
+transcript = available[0]
+
+if transcript.language_code not in languages:
+
+transcript = transcript.translate("en")
+
+if transcript is None:
+
+raise Exception(f"No captions available for video {video_id}")
+
+entries = transcript.fetch()
+
+segments = []
+
+for entry in entries:
+
+segments.append({
+
+"start": entry.start,
+
+"end": entry.start + entry.duration,
+
+"text": entry.text.strip(),
+
+})
+
+full_text = " ".join(seg["text"] for seg in segments)
+
+return {"text": full_text, "segments": segments}
+
+except Exception as e:
+
+raise Exception(f"Failed to get transcript for {video_id}: {e}")
+
+```
+
+### Caption Quality Notes
+
+- **Manually uploaded captions** are highest quality — proper punctuation, speaker labels sometimes included.
+- **Auto-generated captions** are decent for clear speech but may have errors with technical terms, names, and acronyms. The content generation pipeline should handle minor transcription errors gracefully.
+
+- **No captions available** — some videos have captions disabled. Fall back to audio download + Whisper transcription.
+
+## Audio Download & Transcription
+
+Fallback when YouTube captions are unavailable. Uses yt-dlp to download the audio track.
+
+### Setup
+
+```bash
+
+pip install yt-dlp
+
+```
+
+yt-dlp is actively maintained and handles YouTube's frequent changes. Avoid using the deprecated `youtube-dl`.
+
+### Audio Download
+
+```python
+
+import yt_dlp
+
+import os
+
+def download_youtube_audio(video_id: str, output_dir: str = "/tmp") -> str:
+
+"""Download audio from a YouTube video.
+
+Returns the path to the downloaded audio file.
+
+"""
+
+os.makedirs(output_dir, exist_ok=True)
+
+output_path = os.path.join(output_dir, f"{video_id}.mp3")
+
+ydl_opts = {
+
+"format": "bestaudio/best",
+
+"postprocessors": [{
+
+"key": "FFmpegExtractAudio",
+
+"preferredcodec": "mp3",
+
+"preferredquality": "128",
+
+}],
+
+"outtmpl": os.path.join(output_dir, f"{video_id}.%(ext)s"),
+
+"quiet": True,
+
+"no_warnings": True,
+
+}
+
+with yt_dlp.YoutubeDL(ydl_opts) as ydl:
+
+ydl.download([f"https://www.youtube.com/watch?v={video_id}"])
+
+return output_path
+
+```
+
+After downloading, pass the audio file to `whisper_transcribe.transcribe_episode()` from the existing transcription script.
+
+## Metadata Extraction
+
+Extract video metadata without downloading the full video:
+
+```python
+
+import yt_dlp
+
+def get_youtube_metadata(video_id: str) -> dict:
+
+"""Extract metadata from a YouTube video.
+
+Returns title, channel, description, duration, publish date,
+
+and thumbnail URL.
+
+"""
+
+ydl_opts = {
+
+"quiet": True,
+
+"no_warnings": True,
+
+"skip_download": True,
+
+}
+
+with yt_dlp.YoutubeDL(ydl_opts) as ydl:
+
+info = ydl.extract_info(
+
+f"https://www.youtube.com/watch?v={video_id}",
+
+download=False,
+
+)
+
+return {
+
+"title": info.get("title", "Untitled"),
+
+"channel": info.get("channel", info.get("uploader", "Unknown")),
+
+"description": info.get("description", ""),
+
+"duration_seconds": info.get("duration", 0),
+
+"publish_date": info.get("upload_date", ""),
+
+"thumbnail": info.get("thumbnail", ""),
+
+"view_count": info.get("view_count", 0),
+
+"url": f"https://www.youtube.com/watch?v={video_id}",
+
+"tags": info.get("tags", []),
+
+}
+
+```
+
+## Integration with Content Pipeline
+
+When processing a YouTube link, the output maps to the standard pipeline like this:
+
+1. **Episode metadata** comes from YouTube video metadata (title, channel as host/guest, description, publish date).
+2. **Transcript** comes from captions or Whisper transcription — same format as other input modes.
+
+3. **Episode link** in generated content should point to the YouTube video URL instead of a podcast player link.
+4. **Guest name** — try extracting from the video title (common patterns: "Interview with X", "X on Y", "feat. X") or from the video description. Falls back to the channel name.
+
+The content pipeline doesn't need to know the source was YouTube — once you have a transcript and metadata dict, everything works identically.
+
+### Recommended Workflow
+
+```python
+
+from youtube_extractor import extract_video_id, get_youtube_metadata
+
+video_id = extract_video_id(user_provided_url)
+
+metadata = get_youtube_metadata(video_id)
+
+try:
+
+transcript = get_youtube_transcript(video_id)
+
+except Exception:
+
+audio_path = download_youtube_audio(video_id)
+
+transcript = transcribe_episode(audio_path)
+
+# Now pass transcript + metadata to the content generation pipeline
+
+```

package/.local/secondary_skills/product-manager/.fingerprint

@@ -0,0 +1 @@
+dda81d3791b77faf4ab0565bf709c4e4

package/.local/secondary_skills/product-manager/SKILL.md

@@ -0,0 +1,272 @@
+---
+name: product-manager
+description: Create PRDs, product briefs, user stories, and roadmaps with prioritization frameworks.
+---
+
+# Product Manager
+
+Write PRDs, user stories, and roadmaps. Prioritize features. Default to real templates from top product orgs, not textbook generics.
+
+## When to Use
+
+- PRD, spec, or one-pager needed
+- Backlog prioritization
+
+- User stories + acceptance criteria
+- Roadmap planning
+
+## When NOT to Use
+
+- Technical architecture (core agent capabilities)
+- User research / discovery (design-thinker)
+
+## Discovery — Ask Before You Write
+
+Before choosing a PRD format or writing anything, run a lightweight intake to understand context. Ask the user:
+
+1. **Product stage**: New product/feature, iteration on existing, or pivot?
+2. **Team size and culture**: Startup (5 people, move fast) vs. enterprise (cross-functional, needs alignment)?
+
+3. **Decision this document needs to enable**: Exec go/no-go? Eng scoping? Design kickoff?
+4. **Audience**: Who reads this and what do they need to say yes/no to?
+
+5. **Competitive landscape**: Are there direct competitors or alternatives the user is aware of? Reference the `competitive-analysis` secondary skill if the user needs a deeper market scan before writing the PRD.
+
+Use the answers to select the right PRD format below. Do not default to the longest template — match format to context.
+
+## Stakeholder Mapping — DACI Matrix
+
+Before writing the PRD, clarify who is involved. Use a DACI matrix (Atlassian/Intuit standard):
+
+```text
+
+| Role | Who | Responsibility |
+
+|------------|------------------|---------------------------------------------|
+
+| Driver | [name/role] | Owns the document, drives decisions forward |
+
+| Approver | [name/role] | Final sign-off authority (one person only) |
+
+| Contributor| [names/roles] | Provides input, reviews, raises concerns |
+
+| Informed | [names/roles] | Kept in the loop, no active role |
+
+```
+
+**Rules**: Exactly one Approver. Driver is usually the PM. If there are more than 3 Contributors, the scope is probably too broad — split the PRD.
+
+**Best for**: Amazon PR/FAQ (where exec alignment is the goal), any cross-functional project, or when the user says "I need buy-in from multiple teams."
+
+## PRD Formats — Pick by Context
+
+The three most-copied templates in tech. Ask the user their team size and culture, then pick:
+
+### Amazon PR/FAQ ("Working Backwards")
+
+Write the press release *before* building. Used for every Amazon product since 2004 (AWS, Kindle, Prime). Format:
+
+- **Press release (1 page, strict)**: Headline (`[Company] announces [product] to enable [customer] to [benefit]`), sub-headline, dated intro paragraph, problem paragraph (3-4 problems max), solution paragraph, customer quote, how to get started.
+- **Internal FAQ**: Every hard question a VP would ask. "What's the BOM?" "Why won't [competitor] crush this?" "What's the failure mode?"
+
+Why it works: the press-release frame forces customer language and ruthlessly exposes when you can't articulate the benefit. If the PR is boring, the product probably is too.
+
+Source templates: Colin Bryar (ex-Bezos chief of staff) at `coda.io/@colin-bryar/working-backwards`, Ian McAllister's LinkedIn template,`github.com/Green-Software-Foundation/pr-faqs` for a real org using PR/FAQ on GitHub.
+
+**Best for**: Big bets, new product lines, when you need exec alignment before committing eng resources.
+
+### Intercom "Intermission" (1-page hard limit)
+
+Paul Adams (VP Product): "An Intermission must always fit on a printed A4 page. If it does not, you haven't a clear enough view of the problem yet." Sections:
+
+- **Problem**: What's broken, why now, links to customer conversations
+- **Job Stories** (Intercom invented these — replaces user stories): `When [situation], I want to [motivation], so I can [expected outcome]`. Situation > persona. "When I'm on-call at 3am and an alert fires" beats "As a DevOps engineer."
+
+- **Success criteria**: Qualitative + quantitative
+- **NO solution section** — solutions go in Figma, not the PRD
+
+**Best for**: Feature-level work, fast-moving teams, when scope creep is the enemy.
+
+### Linear's Project Spec
+
+Nan Yu (Head of Product at Linear). Short, outcome-focused: Problem → Proposed solution → Success metrics → Non-goals → Open questions. Non-goals are load-bearing — explicitly listing what you're *not* building is the single most effective scope-creep prevention.
+
+**Best for**: Eng-heavy teams already in Linear, projects with clear shape.
+
+Full template collection: `hustlebadger.com/what-do-product-teams-do/prd-template-examples/` (Figma, Asana, Shape Up, Lenny's 1-Pager all compared).
+
+### Competitive / Market Context Section
+
+Every PRD should include a lightweight competitive scan. Add this section after the problem statement in any format:
+
+```text
+
+## Alternatives & Competitive Landscape
+
+| Alternative | How users solve this today | Key weakness we exploit |
+
+|---------------------|---------------------------|-------------------------------|
+
+| [Competitor/workaround] | [description] | [gap or pain point] |
+
+| [Status quo] | [what they do without us] | [cost, time, error rate] |
+
+```
+
+If the user needs a deeper analysis, reference the `competitive-analysis` secondary skill.
+
+### Cross-template patterns (from analysis of 13+ company PRDs)
+
+1. Problem strictly before solution — every high-performing template enforces this
+2. Explicit "Non-goals" section — second most common element
+
+3. Living docs — version + changelog, not write-once
+
+## Scope Estimation
+
+Effort estimates feed into RICE and roadmap sequencing. Use one of these approaches depending on maturity:
+
+### T-shirt sizing (early stage, low confidence)
+
+When detailed estimates are unreliable, use relative sizing:
+
+```text
+
+| Size | Rough meaning | Example |
+
+|------|--------------------------------------|----------------------------------|
+
+| XS | < 1 day, one person | Copy change, config tweak |
+
+| S | 1-3 days, one person | New API endpoint, simple UI page |
+
+| M | 1-2 weeks, 1-2 people | Feature with frontend + backend |
+
+| L | 2-4 weeks, small team | Multi-screen flow, new integration|
+
+| XL | 1+ month, cross-functional | New product area, platform change|
+
+```
+
+### Reference-class estimation (higher confidence)
+
+Compare to similar past work. Ask the user: "What shipped feature is this most similar to? How long did that take?" Adjust from there. This outperforms bottom-up estimation for novel work (Kahneman & Tversky's "planning fallacy" research).
+
+### Rules for estimation
+
+- Always estimate in ranges, not points: "2-4 weeks" not "3 weeks"
+- Include all functions in the estimate (PM + design + eng + QA), not just eng
+
+- Explicitly flag unknowns that could blow up the estimate — these become "Open questions" in the PRD
+
+## Prioritization
+
+**RICE** (Intercom's framework — the de facto standard):
+
+- **Reach**: Users affected per quarter. Use real numbers from analytics, not guesses.
+- **Impact**: 3 = massive, 2 = high, 1 = medium, 0.5 = low, 0.25 = minimal
+
+- **Confidence**: 100% = data-backed, 80% = strong intuition, 50% = guessing. This multiplier is what makes RICE better than ICE — it punishes wishful thinking.
+- **Effort**: Person-months, all functions (PM + design + eng + QA)
+
+- Score = (R × I × C) / E. Build as a spreadsheet — agent can generate CSV.
+
+**When NOT to use RICE**: When effort estimates are garbage (early-stage), when one item is existential (just do it), when the list is >30 items (you have a strategy problem, not a prioritization problem).
+
+**Cost of Delay / WSJF** (SAFe framework): (User value + Time criticality + Risk reduction) / Job size. Better than RICE when timing/sequencing matters (regulatory deadlines, market windows).
+
+**Kano**: Survey users on each feature twice — "how would you feel if we had this?" and "how would you feel if we didn't?" Cross-tab reveals Basic/Performance/Delighter/Indifferent. Reference: `foldingburritos.com/blog/kano-model` for the full method + survey template.
+
+## Roadmap Format
+
+Now / Next / Later (GOV.UK popularized this — intentionally vague on dates to avoid roadmap-as-contract):
+
+```text
+
+## Theme: [one strategic bet this quarter]
+
+## Goal/OKR link: [which company or team OKR does this theme serve?]
+
+### Now (committed, in flight)
+
+| Initiative | Owner | Goal/OKR link | Success metric | Status |
+
+### Next (committed, not started)
+
+| Initiative | Why now | Goal/OKR link | Dependency |
+
+### Later (directional, not committed)
+
+- [bullets only — dates here are lies]
+
+```
+
+Every roadmap item should trace back to a goal or OKR. If an item doesn't link to any goal, it's either a missing goal or a distraction — surface this to the user.
+
+Public roadmap examples to reference: `github.com/github/roadmap` (GitHub's own), Buffer's transparent roadmap, Linear's changelog.
+
+## Acceptance Criteria
+
+Gherkin syntax (Given/When/Then) — directly executable as test cases:
+
+```text
+
+Given [precondition]
+
+When [action]
+
+Then [observable result]
+
+And [additional result]
+
+```
+
+One scenario per acceptance criterion. If you can't write it as Given/When/Then, the requirement is ambiguous.
+
+## Living Document Workflow
+
+PRDs are not write-once artifacts. Include this header in every PRD:
+
+```text
+
+---
+
+Version: [1.0]
+
+Last updated: [date]
+
+Status: [Draft | In Review | Approved | Superseded]
+
+Owner: [Driver from DACI]
+
+---
+
+### Changelog
+
+| Version | Date | Author | Change summary |
+
+|---------|------------|--------|-----------------------------------|
+
+| 1.0 | YYYY-MM-DD | [name] | Initial draft |
+
+| 1.1 | YYYY-MM-DD | [name] | Added success metrics from review |
+
+```
+
+**Review cadence**: Recommend the user revisit the PRD at each major milestone — after design review, after eng scoping, and after launch. Update status and log changes.
+
+## Output Formats
+
+Default output is markdown. Adapt format when it serves the user better:
+
+- **RICE scoring table**: Generate as CSV when the user wants to import into a spreadsheet or share with stakeholders
+- **Roadmap**: Markdown table for docs, CSV for spreadsheet import
+
+- **Connected tools**: Check if the workspace has project management integrations (Linear, Jira, etc.) via the `integrations` skill. If connected, format output to match the tool's conventions (e.g., Linear project spec format for Linear users) and mention that items can be copied into their tool
+
+## Limitations
+
+- Cannot integrate with Jira/Linear/Asana — deliver as markdown for copy-paste
+- Cannot access user analytics — ask user for reach/retention numbers before RICE scoring
+
+- Templates are starting points; teams should adapt

package/.local/secondary_skills/programmatic-seo/.fingerprint

@@ -0,0 +1 @@
+b3f4853dee23b09ca119375d0ca877c0