feat: Add meeting-minutes-taker skill and sanitization workflow
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
@@ -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
171
skill-creator/references/sanitization_checklist.md
Normal 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
|
||||
Reference in New Issue
Block a user