firefrost-gaming/claude-code-skills-reference
3
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat: Add meeting-minutes-taker skill and sanitization workflow

Browse Source 
New skill: meeting-minutes-taker
- Transform meeting transcripts into structured minutes
- Multi-pass parallel generation with UNION merge
- Evidence-based recording with speaker quotes
- Mermaid diagrams for architecture discussions
- Iterative human-in-the-loop refinement
- Bundled references: template and completeness checklist

skill-creator enhancements:
- Add Step 5: Sanitization Review (Optional)
- New references/sanitization_checklist.md with:
  - 8 categories of content to sanitize
  - Automated grep scan commands
  - 3-phase sanitization process
  - Common pitfalls and completion checklist
- Renumber existing steps 5-8 to 6-9

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
This commit is contained in:
daymade
2026-01-24 18:20:19 +08:00
parent 35872b9e77
commit 1c538567f6
5 changed files with 922 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

474
meeting-minutes-taker/SKILL.md Normal file
View File

@@ -0,0 +1,474 @@
---
name: meeting-minutes-taker
description: |
  Transforms raw meeting transcripts into high-fidelity, structured meeting minutes with iterative review for completeness. This skill should be used when (1) a meeting transcript is provided and meeting minutes, notes, or summaries are requested, (2) multiple versions of meeting minutes need to be merged without losing content, (3) existing minutes need to be reviewed against the original transcript for missing items. Features evidence-based recording with speaker quotes, Mermaid diagrams for architecture discussions, multi-turn parallel generation to avoid content loss, and iterative human-in-the-loop refinement.
---
# Meeting Minutes Taker
Transform raw meeting transcripts into comprehensive, evidence-based meeting minutes through iterative review.
## Quick Start
1. Read the transcript provided by user
2. Load project-specific context file if provided by user (optional)
3. **Multi-turn generation**: Use multiple passes or subagents with isolated context, merge using UNION
4. Self-review using [references/completeness_review_checklist.md](references/completeness_review_checklist.md)
5. Present draft to user for human line-by-line review
6. **Cross-AI comparison** (optional): Human may provide output from other AI tools (e.g., Gemini, ChatGPT) - merge to reduce bias
7. Iterate on feedback until human approves final version
## Core Workflow
Copy this checklist and track progress:
```
Meeting Minutes Progress:
- [ ] Step 1: Read and analyze transcript
- [ ] Step 2: Multi-turn generation (PARALLEL subagents with Task tool)
  - [ ] Create transcript-specific dir: <output_dir>/intermediate/<transcript-name>/
  - [ ] Launch 3 Task subagents IN PARALLEL (single message, 3 Task tool calls)
    - [ ] Subagent 1 → <output_dir>/intermediate/<transcript-name>/version1.md
    - [ ] Subagent 2 → <output_dir>/intermediate/<transcript-name>/version2.md
    - [ ] Subagent 3 → <output_dir>/intermediate/<transcript-name>/version3.md
  - [ ] Merge: UNION all versions, AGGRESSIVELY include ALL diagrams → draft_minutes.md
  - [ ] Final: Compare draft against transcript, add omissions
- [ ] Step 3: Self-review for completeness
- [ ] Step 4: Present draft to user for human review
- [ ] Step 5: Cross-AI comparison (if human provides external AI output)
- [ ] Step 6: Iterate on human feedback (expect multiple rounds)
- [ ] Step 7: Human approves final version
Note: <output_dir> = directory where final meeting minutes will be saved (e.g., project-docs/meeting-minutes/)
Note: <transcript-name> = name derived from transcript file (e.g., 2026-01-15-product-api-design)
```
### Step 1: Read and Analyze Transcript
Analyze the transcript to identify:
- Meeting topic and attendees
- Key decisions with supporting quotes
- Action items with owners
- Deferred items / open questions
### Step 2: Multi-Turn Initial Generation (Critical)
**A single pass will absolutely lose content.** Use multi-turn generation with **redundant complete passes**:
#### Core Principle: Multiple Complete Passes + UNION Merge
Each pass generates **COMPLETE minutes (all sections)** from the full transcript. Multiple passes with isolated context catch different details. UNION merge consolidates all findings.
**❌ WRONG: Narrow-focused passes** (wastes tokens, causes bias)
```
Pass 1: Only extract decisions
Pass 2: Only extract action items
Pass 3: Only extract discussion
```
**✅ CORRECT: Complete passes with isolated context**
```
Pass 1: Generate COMPLETE minutes (all sections) → version1.md
Pass 2: Generate COMPLETE minutes (all sections) with fresh context → version2.md
Pass 3: Generate COMPLETE minutes (all sections) with fresh context → version3.md
Merge: UNION all versions, consolidate duplicates → draft_minutes.md
```
#### Strategy A: Sequential Multi-Pass (Complete Minutes Each Pass)
```
Pass 1: Read transcript → Generate complete minutes → Write to: <output_dir>/intermediate/version1.md
Pass 2: Fresh context → Read transcript → Generate complete minutes → Write to: <output_dir>/intermediate/version2.md
Pass 3: Fresh context → Read transcript → Generate complete minutes → Write to: <output_dir>/intermediate/version3.md
Merge: Read all versions → UNION merge (consolidate duplicates) → Write to: draft_minutes.md
Final: Compare draft against transcript → Add any remaining omissions → final_minutes.md
```
#### Strategy B: Parallel Multi-Agent (Complete Minutes Each Agent) - PREFERRED
**MUST use the Task tool** to spawn multiple subagents with **isolated context**, each generating **complete minutes**:
**Implementation using Task tool:**
```
// Launch ALL 3 subagents in PARALLEL (single message, multiple Task tool calls)
Task(subagent_type="general-purpose", prompt="Generate complete meeting minutes from transcript...", run_in_background=false) → version1.md
Task(subagent_type="general-purpose", prompt="Generate complete meeting minutes from transcript...", run_in_background=false) → version2.md
Task(subagent_type="general-purpose", prompt="Generate complete meeting minutes from transcript...", run_in_background=false) → version3.md
// After all complete:
Main Agent: Read all versions → UNION merge, consolidate duplicates → draft_minutes.md
```
**CRITICAL: Subagent Prompt Must Include:**
1. Full path to transcript file
2. Full path to output file (version1.md, version2.md, version3.md in transcript-specific subdirectory)
3. Context files to load (project-specific context if provided, meeting_minutes_template.md)
4. Reference images/documents if provided by user
5. Output language requirement (match user's language preference, preserve technical terms in English)
6. Quote formatting requirement (see Quote Formatting Requirements section below)
**Why multiple complete passes work:**
- Each pass independently analyzes the SAME content
- Different context states catch different details (no single pass catches everything)
- Pass 1 might catch decision X but miss action item Y
- Pass 2 might catch action item Y but miss decision X
- UNION merge captures both X and Y
**Why isolated context matters:**
- Each pass/agent starts fresh without prior assumptions
- No cross-contamination between passes
- Different "perspectives" emerge naturally from context isolation
#### Progressive Context Offloading (Use File System)
**Critical: Write each pass output to files, not conversation context.**
**Path Convention:** All intermediate files should be created in a **transcript-specific subdirectory** under `<output_dir>/intermediate/` to avoid conflicts between different transcripts being processed.
**CRITICAL: Use transcript-specific subdirectory structure:**
```
<output_dir>/intermediate/<transcript-name>/version1.md
<output_dir>/intermediate/<transcript-name>/version2.md
<output_dir>/intermediate/<transcript-name>/version3.md
```
Example: If final minutes will be `project-docs/meeting-minutes/2026-01-14-api-design.md`, then:
- Intermediate files: `project-docs/meeting-minutes/intermediate/2026-01-14-api-design/version1.md`
- This prevents conflicts when multiple transcripts are processed in the same session
- The `intermediate/` folder should be added to `.gitignore` (temporary working files)
```
// Create transcript-specific subdirectory first
mkdir: <output_dir>/intermediate/<transcript-name>/
// Launch all 3 subagents IN PARALLEL (must be single message with 3 Task tool calls)
Task 1 → Write to: <output_dir>/intermediate/<transcript-name>/version1.md (complete minutes)
Task 2 → Write to: <output_dir>/intermediate/<transcript-name>/version2.md (complete minutes)
Task 3 → Write to: <output_dir>/intermediate/<transcript-name>/version3.md (complete minutes)
Merge Phase:
  Read: <output_dir>/intermediate/<transcript-name>/version1.md
  Read: <output_dir>/intermediate/<transcript-name>/version2.md
  Read: <output_dir>/intermediate/<transcript-name>/version3.md
  → UNION merge, consolidate duplicates, INCLUDE ALL DIAGRAMS → Write to: draft_minutes.md
Final Review:
  Read: draft_minutes.md
  Read: original_transcript.md
  → Compare & add omissions → Write to: final_minutes.md
```
**Benefits of file-based context offloading:**
- Conversation context stays clean (avoids token overflow)
- Intermediate results persist (can be re-read if needed)
- Each pass starts with fresh context window
- Merge phase reads only what it needs
- **Human can inspect intermediate files for review** - Critical for understanding what each pass captured
- Supports very long transcripts that exceed context limits
- **Enables post-hoc debugging** - If final output is missing something, human can trace which pass missed it
**IMPORTANT: Always preserve intermediate versions in transcript-specific subdirectory:**
- `<output_dir>/intermediate/<transcript-name>/version1.md`, `version2.md`, `version3.md` - Each subagent output
- These files help human reviewers understand the merge process
- Do NOT delete intermediate files after merge
- Human may want to compare intermediate versions to understand coverage gaps
- **Add `intermediate/` to `.gitignore`** - These are temporary working files, not final deliverables
- **Transcript-specific subdirectory** prevents conflicts when processing multiple transcripts
#### Output Requirements
- **Chinese output** with English technical terms preserved
- **Evidence-based decisions** - Every significant decision needs a supporting quote
- **Structured sections** - Executive Summary, Key Decisions, Discussion, Action Items, Parking Lot
- **Proper quote formatting** - See Quote Formatting Requirements section below
- **Mermaid diagrams** (STRONGLY ENCOURAGED) - Visual diagrams elevate minutes beyond pure text:
  - **ER diagrams** for database/schema discussions
  - **Sequence diagrams** for data flow and API interactions
  - **Flowcharts** for process/workflow decisions
  - **State diagrams** for state machine discussions
  - Diagrams make minutes significantly easier for humans to review and understand
- **Context-first document structure** - Place all reviewed artifacts (UI mockups, API docs, design images) at the TOP of the document (after metadata, before Executive Summary) to establish context before decisions; copy images to `assets/<meeting-name>/` folder and embed inline using `![description](assets/...)` syntax; include brief descriptions with the visuals - this creates "next level" human-readable minutes where readers understand what was discussed before reading the discussion
- **Speaker attribution** - Correctly attribute decisions to speakers
#### Key Rules
- Never assume - Ask user to confirm if unclear
- Quote controversial decisions verbatim
- Assign action items to specific people, not teams
- Preserve numerical values (ranges, counts, priorities)
- **Always use multiple passes** - Single turn is guaranteed to lose content
- **Normalize equivalent terminology** - Treat trivial variations (e.g., "backend architecture" vs "backend", "API endpoint" vs "endpoint") as equivalent; do NOT point out or highlight such differences between speakers
- **Single source of truth** - Place each piece of information in ONE location only; avoid duplicating tables, lists, or summaries across sections (e.g., API list belongs in Discussion OR Reference, not both)
### Step 3: Self-Review for Completeness
After initial generation, immediately review against transcript:
```
Completeness Checklist:
- [ ] All discussion topics covered?
- [ ] All decisions have supporting quotes?
- [ ] All speakers attributed correctly?
- [ ] All action items have specific owners?
- [ ] Numerical values preserved (ranges, counts)?
- [ ] Entity relationships captured?
- [ ] State machines complete (all states listed)?
```
If gaps found, add missing content silently without mentioning what was missed.
### Step 4: Present to User for Human Review
Present the complete minutes as a **draft for human review**. Emphasize:
- Minutes require careful line-by-line human review
- Domain experts catch terminology conflicts AI may miss
- Final version emerges through iterative refinement
User may:
- Accept as-is (rare for complex meetings)
- Request deeper review for missing content
- Identify terminology issues (e.g., naming conflicts with existing systems)
- Provide another AI's output for cross-comparison
### Step 5: Cross-AI Comparison (Reduces Bias)
**When human provides output from another AI tool** (e.g., Gemini, ChatGPT, etc.):
This step is valuable because:
- **Different AI models have different biases** - Each AI catches different details
- **Cross-validation** - Content appearing in both outputs is likely accurate
- **Gap detection** - Content in one but not the other reveals potential omissions
- **Error correction** - One AI may catch factual errors the other missed (e.g., wrong date, wrong attendee name)
**Comparison Process:**
1. Read the external AI output carefully
2. Identify items present in external output but missing from our draft
3. Verify each item against original transcript before adding (don't blindly copy)
4. Identify items where external AI has errors (wrong facts) - note but don't copy errors
5. UNION merge valid new content into our draft
6. Document any corrections made based on cross-comparison
**Example findings from cross-AI comparison:**
- Missing decision about API authentication method ✓ (add to our draft)
- Missing naming convention specification ✓ (add to our draft)
- Wrong date (2026-01-13 vs actual 2026-01-14) ✗ (don't copy error)
- Wrong attendee name ✗ (don't copy error)
- Missing database performance concern ✓ (add to parking lot)
### Step 6: Iterate on Human Feedback (Critical)
**When user requests deeper review** ("deep review", "check again", "anything missing"):
1. Re-read transcript section by section
2. Compare each section against current minutes
3. Look for: entities, field names, numerical ranges, state transitions, trade-offs, deferred items
4. Add any omitted content
5. Never claim "nothing missing" without thorough section-by-section review
**When user provides another version to merge:**
Merge Principle: **UNION, never remove**
1. Keep ALL content from existing version
2. Add ALL new content from incoming version
3. Consolidate duplicates (don't repeat same info)
4. Preserve more detailed version when depth differs
5. Maintain logical section numbering
### Aggressive Diagram Inclusion (CRITICAL)
**During merge phase, MUST aggressively include ALL diagrams from ALL versions.**
Diagrams are high-value content that took effort to generate. Different subagents may produce different diagrams based on what they focused on. Missing a diagram during merge is a significant loss.
**Merge diagram strategy:**
1. **Inventory ALL diagrams** from each version (v1, v2, v3)
2. **Include ALL unique diagrams** - don't assume a diagram is redundant
3. **If similar diagrams exist**, keep the more detailed/complete one
4. **Check every section** that could contain diagrams: Executive Summary, Discussion, API design, State machines, Data flow, etc.
**Common diagram types to look for:**
- Sequence diagrams (data flow, API interactions)
- ER diagrams (database schema, table relationships)
- State diagrams (state machines, status transitions)
- Flowcharts (decision flows, process workflows)
- Component diagrams (system architecture)
**Example: Missed diagram from v3**
If v3 has a flowchart for "Status Query Mechanism" but v1/v2 don't have it, that flowchart MUST appear in the merged output. Don't assume it's covered by other diagrams.
## Output Language
- **Primary:** Match the language of the transcript (or user's preference if specified)
- **Preserve in English:** Technical terms, entity names, abbreviations (standard practice)
- **Quotes:** Keep original language from transcript
## Reference Files
| File | When to Load |
|------|--------------|
| [meeting_minutes_template.md](references/meeting_minutes_template.md) | First generation - Contains template structure |
| [completeness_review_checklist.md](references/completeness_review_checklist.md) | During review steps - Contains completeness checks |
| Project context file (user-provided) | When user provides project-specific context (team directory, terminology, conventions) |
## Common Patterns
### Architecture Discussions → Mermaid Diagrams (Next-Level Minutes)
**Diagrams elevate meeting minutes beyond pure text.** They make complex discussions immediately understandable for human reviewers. Always look for opportunities to add visual diagrams.
#### When to Use Diagrams:
- **Data flow discussions** → Sequence diagram
- **Database schema discussions** → ER diagram
- **Process/workflow decisions** → Flowchart
- **State machine discussions** → State diagram
- **System architecture** → Component diagram
#### Example: Data Flow (Sequence Diagram)
```mermaid
sequenceDiagram
    participant FE as Frontend
    participant BE as Backend
    participant SVC as External Service
    participant DB as Database
    FE->>BE: Click "Submit Order"
    BE->>SVC: POST /process (send data)
    SVC-->>BE: Return {status}
    BE->>DB: Save result
    BE-->>FE: Return success
```
#### Example: Database Schema (ER Diagram)
```mermaid
erDiagram
    ORDER ||--o{ ORDER_ITEM : "1:N"
    ORDER {
        uuid id PK
        string customer_name
        decimal total_amount
    }
    ORDER_ITEM {
        uuid id PK
        uuid order_id FK
        int quantity
    }
```
#### Example: Version Switching (Workflow Diagram)
```mermaid
sequenceDiagram
    participant User
    participant System
    Note over System: Current: V2 Active
    User->>System: Create V3 (inactive)
    User->>System: Set V2 inactive
    User->>System: Set V3 active
    Note over System: New: V3 Active
```
### Quote Formatting Requirements (CRITICAL)
**Quotes MUST use proper markdown blockquote format on separate lines:**
**❌ WRONG: Inline quote format**
```markdown
* **Quote:** > "This is wrong" - **Speaker**
```
**✅ CORRECT: Blockquote on separate lines**
```markdown
* **Quote:**
  > "This is the correct format" - **Speaker**
```
**✅ CORRECT: Multiple quotes**
```markdown
* **Quote:**
  > "First quote from the discussion" - **Speaker1**
  > "Second quote supporting the same decision" - **Speaker2**
```
**Key formatting rules:**
- `* **Quote:**` on its own line (no quote content on this line)
- Blank line NOT needed after `* **Quote:**`
- Quote content indented with 2 spaces, then `> ` prefix
- Speaker attribution at end of quote line: `- **SpeakerName**`
- Multiple quotes use same indentation, each on its own line
### Technical Decisions → Decision Block
```markdown
### 2.X [Category] Decision Title
* **Decision:** Specific decision made
* **Logic:**
  * Reasoning point 1
  * Reasoning point 2
* **Quote:**
  > "Exact quote from transcript" - **Speaker Name**
```
### Deferred Items → Parking Lot
Items with keywords like "defer to later", "Phase 2", "not in MVP" go to Parking Lot with context.
## Human-in-the-Loop Iteration (Essential)
Meeting minutes are **not one-shot outputs**. High-quality minutes emerge through multiple review cycles:
### Why Human Review is Critical
1. **Terminology conflicts**: Humans know existing system naming (e.g., "Note" already means comments in the existing system)
2. **Domain context**: Humans catch when a term could be confused with another (e.g., "UserProfile" vs "Account")
3. **Organizational knowledge**: Humans know team conventions and prior decisions
4. **Completeness gaps**: Humans can request "deep review" review when something feels missing
### Example Iteration Pattern
```
Round 1: Initial generation
  └─ Human review: "Check original transcript for missing items"
Round 2: Deep transcript review, add omitted content
  └─ Human review: "UserProfile conflicts with existing Account entity naming"
Round 3: Update terminology to use "CustomerProfile" instead
  └─ Human review: "Note field conflicts with existing Comment system"
Round 4: Update to use "Annotation" instead of "Note"
  └─ Human approval: Final version ready
```
### Key Principle
**The AI generates the first draft; humans refine to the final version.** Never assume the first output is complete or uses correct terminology. Always encourage human review and be ready for multiple iteration cycles.
## Anti-Patterns
- ❌ **Single-pass generation** - One turn through transcript will absolutely lose content
- ❌ **Divided sections without overlap** - Each pass must cover FULL transcript, not split by sections
- ❌ **Narrow-focused passes** - Each pass must generate COMPLETE minutes (all sections), not just one section type (wastes tokens, causes bias)
- ❌ Generic summaries without supporting quotes
- ❌ Action items assigned to "team" instead of specific person
- ❌ Missing numerical values (priorities, ranges, state counts)
- ❌ State machines with incomplete states
- ❌ Circular debate transcribed verbatim instead of summarized
- ❌ Removing content during multi-version merge
- ❌ Claiming "nothing missing" without section-by-section review
- ❌ Treating first draft as final without human review
- ❌ Using terminology without checking for conflicts with existing systems
- ❌ Shared context between subagents (causes cross-contamination and missed content)
- ❌ Keeping all intermediate outputs in conversation context (causes token overflow, use file system)
- ❌ **Pure text minutes without diagrams** - Architecture/schema discussions deserve visual representation
- ❌ **Deleting intermediate files after merge** - Preserve for human review and debugging
- ❌ **Blindly copying external AI output** - Always verify against transcript before merging
- ❌ **Ignoring cross-AI comparison opportunity** - Different AI models catch different details
- ❌ **Sequential subagent execution** - MUST launch v1, v2, v3 subagents in PARALLEL using multiple Task tool calls in a single message
- ❌ **Flat intermediate directory** - MUST use transcript-specific subdirectory `intermediate/<transcript-name>/` to avoid conflicts
- ❌ **Inline quote formatting** - Quotes MUST use blockquote format on separate lines, not inline `> "quote"`
- ❌ **Omitting diagrams during merge** - MUST aggressively include ALL diagrams from ALL versions, even if they seem similar
- ❌ **Highlighting trivial terminology variations** - Do NOT point out differences like "backend architecture" vs "backend" or "API" vs "endpoint" between speakers; these are equivalent terms and highlighting such differences is disrespectful
- ❌ **Duplicate content across sections** - Do NOT repeat the same information in multiple sections (e.g., API endpoint table in both "Discussion" and "Reference"); place content in ONE authoritative location and reference it if needed
- ❌ **Creating non-existent links** - Do NOT create markdown links to files that don't exist in the repo (e.g., `[doc.md](reviewed-document)`); use plain text for external/local documents not in the repository
- ❌ **Losing content during consolidation** - When moving or consolidating sections, verify ALL bullet points and details are preserved; never summarize away specific details like "supports batch operations" or "button triggers auto-save"
- ❌ **Appending domain details to role titles** - Use ONLY the Role column from Team Directory for speaker attribution (e.g., "Backend", "Frontend", "TPM"); do NOT append specializations like "Backend, Infrastructure" or "Backend, Business Logic" - all team members with the same role should have identical attribution

100
meeting-minutes-taker/references/completeness_review_checklist.md Normal file
View File

@@ -0,0 +1,100 @@
# Meeting Minutes Review Checklist
## Contents
- Completeness Review Process (4 phases: structural, content depth, quotes, action items)
- Common Omission Patterns (technical, business logic, process items)
- Merge Strategy (multi-version union rules)
- Red Flags (signs of missing content)
## Completeness Review Process
### Phase 1: Structural Check
- [ ] All major discussion topics from transcript are covered
- [ ] Each decision has supporting quote
- [ ] All speakers who made decisions are attributed
- [ ] Action items have specific owners (not generic "team")
- [ ] Priorities assigned to all action items
### Phase 2: Content Depth Check
For each transcript section, verify:
- [ ] **Entities/Data Models**: All mentioned entities captured (tables, fields, relationships)
- [ ] **Numerical Values**: Ranges, priorities, counts preserved (e.g., "0-99", "4 states", "3-4 categories")
- [ ] **State Machines**: All states and transitions documented
- [ ] **Architecture Decisions**: Data flow, dependencies, integration points
- [ ] **Trade-offs**: Rejected alternatives and reasoning
- [ ] **Constraints**: Technical limitations, MVP scope boundaries
### Phase 3: Quote Verification
For significant decisions, ensure:
- [ ] Quote accurately reflects speaker's point
- [ ] Speaker attribution is correct
- [ ] Context around quote is preserved
### Phase 4: Action Items Audit
Cross-reference with transcript for:
- [ ] Explicit task assignments ("Alice will handle...", "Bob, please...")
- [ ] Implicit commitments ("I will design...", "Backend team will...")
- [ ] Deferred items ("Defer to later...", "Not in MVP scope...")
- [ ] Follow-up discussions needed ("Discuss offline...", "Follow up separately...")
## Common Omission Patterns
### Technical Details Often Missed
1. **Entity Hierarchies**: Category → Subcategory → Item → Detail
2. **Field Definitions**: What fields belong to which entity
3. **Calculation Rules**: Priority orders, workflow logic, matching rules
4. **Storage Decisions**: Where data is persisted, what's cached
5. **API Contracts**: Who calls whom, sync vs async
### Business Logic Often Missed
1. **State Transitions**: What triggers state changes
2. **Permission Rules**: Who can do what
3. **Validation Rules**: Required fields, constraints
4. **Display Logic**: What's shown where, sorting rules
5. **Integration Points**: Cross-system data sharing
### Process Items Often Missed
1. **Design Approach**: Joint vs separate design decisions
2. **Dependency Order**: What blocks what
3. **Offline Follow-ups**: Items requiring separate discussion
4. **Scope Deferrals**: What's explicitly pushed to Phase 2
## Merge Strategy (Multi-Version Union)
When merging versions:
1. **Keep ALL content from existing version** - Never remove unless explicitly wrong
2. **Add NEW content from incoming version** - Union, not replace
3. **Resolve conflicts by combining** - Include both perspectives
4. **Preserve more detailed version** - When same topic has different depth
5. **Maintain structure** - Keep section numbering logical
### Merge Checklist
- [ ] All sections from original preserved
- [ ] All sections from new version added (or merged into existing)
- [ ] No duplicate content (consolidate if same info appears twice)
- [ ] Quotes from both versions preserved
- [ ] Action items from both versions merged
- [ ] Numbering remains sequential
## Red Flags (Signs of Missing Content)
- Transcript mentions a topic not in minutes
- Decision recorded without quote
- Action item without clear owner
- Long transcript section summarized in one sentence
- Technical discussion with no entity/field names
- "TBD" items without clear description
- State machine with fewer states than mentioned
- Priority/order system without number ranges

121
meeting-minutes-taker/references/meeting_minutes_template.md Normal file
View File

@@ -0,0 +1,121 @@
# Meeting Minutes Template
## Meeting Metadata
```markdown
---
title: [Meeting Title]
date: [YYYY-MM-DD]
attendees:
- Name (Role)
- Name (Role)
duration: [X hours/minutes]
location: [Virtual/Room Name]
---
```
## Document Structure
### 1. Executive Summary
Brief 2-3 sentence overview of what was discussed and decided.
### 2. Reviewed Materials (Optional)
If the meeting reviewed specific documents, mockups, or artifacts, list them here with brief descriptions. Include images inline if available.
```markdown
![Description of artifact](assets/meeting-name/artifact.png)
```
### 3. Key Decisions
For each major decision:
```markdown
### 3.X [Category] Decision Title
* **Decision:** Specific decision made
* **Logic:**
* Reasoning point 1
* Reasoning point 2
* **Quote:**
> "Exact quote from transcript supporting this decision" - **Speaker Name**
```
Categories: Architecture, API Design, Data Model, Process, Security, etc.
### 4. Discussion Details
Detailed breakdown by topic. Include:
- Context and background
- Options considered
- Trade-offs discussed
- Final direction
Use Mermaid diagrams where applicable:
```mermaid
sequenceDiagram
participant A as Component A
participant B as Component B
A->>B: Action description
B-->>A: Response
```
### 5. Action Items
| # | Task | Owner | Priority | Due Date |
|---|------|-------|----------|----------|
| 1 | Task description | Person Name | P1/P2/P3 | YYYY-MM-DD |
### 6. Parking Lot (Deferred Items)
Items explicitly deferred to future phases or follow-up discussions:
| Item | Reason Deferred | Follow-up |
|------|-----------------|-----------|
| Feature X | Out of MVP scope | Phase 2 |
| Decision Y | Needs more research | Offline discussion |
### 7. Open Questions
Unresolved questions that need follow-up:
- Question 1 - Owner to investigate
- Question 2 - Pending external input
---
## Formatting Guidelines
### Quote Format (CRITICAL)
Always use blockquote on separate line:
```markdown
* **Quote:**
> "This is the correct format" - **Speaker Name**
```
NOT inline:
```markdown
* **Quote:** > "This is wrong" - **Speaker**
```
### Speaker Attribution
Use consistent role-based attribution throughout:
- **Backend**, **Frontend**, **PM**, **TPM**, **Designer**, etc.
### Technical Terms
Preserve in English: API names, entity names, technical terminology, abbreviations
### Diagrams
Use Mermaid for:
- Sequence diagrams (data flow)
- ER diagrams (data models)
- Flowcharts (processes)
- State diagrams (state machines)

60
skill-creator/SKILL.md
View File

@@ -236,7 +236,59 @@ To complete SKILL.md, answer the following questions:
2. When should the skill be used?
3. In practice, how should Claude use the skill? All reusable skill contents developed above should be referenced so that Claude knows how to use them.
### Step 5: Security Review
### Step 5: Sanitization Review (Optional)
**Ask the user before executing this step:** "This skill appears to be extracted from a business project. Would you like me to perform a sanitization review to remove business-specific content before public distribution?"
Skip this step if:
- The skill was created from scratch for public use
- The user explicitly declines sanitization
- The skill is intended for internal/private use only
**When to perform sanitization:**
- Skill was extracted from a business/internal project
- Skill contains domain-specific examples from real systems
- Skill will be distributed publicly or to other teams
**Sanitization process:**
1. **Load the checklist**: Read [references/sanitization_checklist.md](references/sanitization_checklist.md) for detailed guidance
2. **Run automated scans** to identify potential sensitive content:
```bash
# Product/project names, person names, paths
grep -rniE "portal|underwriting|mercury|glean|/Users/|/home/" skill-folder/
# Chinese characters (if skill should be English-only)
grep -rn '[一-龥]' skill-folder/
```
3. **Review and replace** each category:
- Product/project names → generic terms
- Person names → "Alice", "Bob", role-based references
- Entity names → generic entities (ORDER, USER, PRODUCT)
- Folder structures → generic paths
- Internal jargon → industry-standard terms
- Language-specific content → translate or remove
4. **Verify completeness**:
- Re-run all grep patterns (should return no matches)
- Read through skill to ensure coherence
- Confirm skill still functions correctly
**Common replacements:**
| Business-Specific | Generic Replacement |
|-------------------|---------------------|
| "Mercury Prepared" | "the project" |
| "Reviewer Portal" | "the application" |
| "Oliver will handle..." | "Alice will handle..." |
| `REVIEW_RESULT` | `ORDER` |
| `risk_level` | `status` |
| "ultrathink" | "deep review" |
| "后面再说" | "defer to later" |
### Step 6: Security Review
Before packaging or distributing a skill, run the security scanner to detect hardcoded secrets and personal information:
@@ -276,7 +328,7 @@ brew install gitleaks
3. Rotate credentials if previously committed to git
4. Re-run scan to verify fixes before packaging
### Step 6: Packaging a Skill
### Step 7: Packaging a Skill
Once the skill is ready, it should be packaged into a distributable zip file that gets shared with the user. The packaging process automatically validates the skill first to ensure it meets all requirements:
@@ -304,7 +356,7 @@ The packaging script will:
If validation fails, the script will report the errors and exit without creating a package. Fix any validation errors and run the packaging command again.
### Step 7: Update Marketplace
### Step 8: Update Marketplace
After packaging, update the marketplace registry to include the new or updated skill.
@@ -330,7 +382,7 @@ After packaging, update the marketplace registry to include the new or updated s
**Also update** `metadata.version` and `metadata.description` if the overall plugin collection changed significantly.
### Step 8: Iterate
### Step 9: Iterate
After testing the skill, users may request improvements. Often this happens right after using the skill, with fresh context of how the skill performed.

171
skill-creator/references/sanitization_checklist.md Normal file
View File

@@ -0,0 +1,171 @@
# Skill Sanitization Checklist
When extracting a skill from a business project for public distribution, systematically remove all business-specific content to make it generic and reusable.
## Quick Scan Commands
Run these grep patterns to identify potential sensitive content:
```bash
# Business/product names (case-insensitive)
grep -rniE "mercury|portal|underwriting|glean|[company-name]|[product-name]" skill-folder/
# Person names (look for capitalized names)
grep -rniE "\b(Oliver|John|Alice|Bob|建斌|小明)\b" skill-folder/
# Absolute paths and usernames
grep -rniE "/Users/|/home/|/mnt/c/Users|OneDrive|username" skill-folder/
# Chinese characters (if skill should be English-only)
grep -rn '[一-龥]' skill-folder/
# Internal jargon
grep -rniE "ultrathink|internal-only|confidential" skill-folder/
```
## Categories to Sanitize
### 1. Product and Project Names
**What to find:**
- Project codenames (e.g., "Mercury Prepared", "Project Phoenix")
- Internal product names (e.g., "Reviewer Portal", "Admin Dashboard")
- Tool-specific names (e.g., "Glean Gemini" → just "Gemini")
**How to replace:**
- Use generic terms: "the system", "the application", "the service"
- Use placeholder patterns: `<project-name>`, `<product-name>`
- Use generic examples: "e-commerce platform", "user management system"
### 2. Person Names
**What to find:**
- Real employee names in examples: "Oliver will handle...", "建斌你来..."
- Team member references in action items
- Author attributions that reveal identity
**How to replace:**
- Use generic names: "Alice", "Bob", "the developer", "the reviewer"
- Use role-based references: "Backend team", "PM", "Designer"
- Remove author attributions or use placeholders
### 3. Entity and Data Model Names
**What to find:**
- Business-specific entities: `REVIEW_RESULT`, `RISK_MODEL`, `INSPECTION_FACTOR`
- Domain-specific hierarchies: `Section → Area → Item → Evidence`
- Field names revealing business logic: `risk_level`, `underwriting_status`
**How to replace:**
- Use generic entities: `ORDER`, `ORDER_ITEM`, `USER`, `PRODUCT`
- Use generic hierarchies: `Category → Subcategory → Item → Detail`
- Use generic fields: `status`, `quantity`, `customer_name`
### 4. Folder Structures and Paths
**What to find:**
- Team-specific folders: `10-team-collaboration/Meeting Minutes`
- Project-specific paths: `reviewer-portal-api-design`
- Environment-specific paths: `/Users/username/Projects/`
**How to replace:**
- Use generic paths: `project-docs/meeting-minutes`
- Use placeholder paths: `<project-root>/docs/`
- Use relative paths within skill bundle
### 5. Internal Terminology and Jargon
**What to find:**
- Internal slang: "ultrathink", "deep dive session"
- Company-specific processes: "Mercury standup", "Portal review"
- Abbreviations without context: "MP", "RP", "UW"
**How to replace:**
- Use industry-standard terms: "deep review", "thorough analysis"
- Expand or remove unexplained abbreviations
- Use generic process names
### 6. Language-Specific Content
**What to find:**
- Chinese phrases in English skills: "后面再说", "MVP 先不做"
- Mixed language examples that assume bilingual context
- Culture-specific references
**How to replace:**
- Translate to the skill's primary language
- Use language-neutral examples
- Or explicitly support multilingual with clear labels
### 7. Business Logic Examples
**What to find:**
- Domain-specific workflows: "Underwriting system conflicts"
- Business rules: "Inspection Factor vs Risk Factor"
- Industry-specific terminology without explanation
**How to replace:**
- Use generic software examples: "Note field conflicts with Comment system"
- Use universal patterns: "UserProfile vs Account naming conflict"
- Add context if domain terms are necessary
### 8. External Service References
**What to find:**
- Internal APIs: `POST /evaluate (push to Risk Model)`
- Company-specific integrations: "Sync with Underwriting system"
- Internal tool names: "Glean search", "Internal Wiki"
**How to replace:**
- Use generic services: `POST /process (send to External Service)`
- Use placeholder APIs: `<external-api>/endpoint`
- Use generic tool categories: "enterprise search", "knowledge base"
## Sanitization Process
### Phase 1: Automated Scan
```bash
# Run all grep patterns above
# Export results to a file for review
grep -rniE "pattern1|pattern2|pattern3" skill-folder/ > sanitization_report.txt
```
### Phase 2: Manual Review
For each match:
1. Determine if it's truly business-specific or generic
2. Decide on appropriate replacement
3. Check if replacement maintains meaning
4. Verify no broken references
### Phase 3: Verification
After sanitization:
1. Re-run all grep patterns - should return no matches
2. Read through skill to ensure coherence
3. Test skill functionality still works
4. Have someone unfamiliar with the original project review
## Common Pitfalls
| Pitfall | Solution |
|---------|----------|
| Over-sanitizing generic terms | "reviewer" as a role is fine; "Reviewer Portal" is not |
| Breaking examples by removing context | Replace with equivalent generic examples |
| Leaving orphaned references | Check all cross-references after renaming |
| Inconsistent replacements | Use find-and-replace for consistency |
| Sanitizing technical terms | Keep industry-standard terms (API, JSON, MVP) |
## Checklist Before Completion
- [ ] No product/project codenames remain
- [ ] No real person names in examples
- [ ] No business-specific entity names
- [ ] No internal folder structures
- [ ] No unexplained jargon or abbreviations
- [ ] No language-specific content (unless intentional)
- [ ] No internal API or service references
- [ ] All examples are generic and universally understandable
- [ ] Skill still functions correctly after changes
- [ ] Someone unfamiliar with original project can understand it