Add Apache License 2.0 to all life science skill directories

[daniellechou-anthropic]

Added LICENSE.txt files to:

• single-cell-rna-qc @jwei-ant
• clinical-trial-protocol-skill @max petruzzi
• instrument-data-to-allotrope
• nextflow-development @jwei-ant
• scientific-problem-selection @jwei-ant
• scvi-tools @jwei-ant

Followed pattern from the public skill repo: https://github.com/anthropics/skills/blob/main/skills/canvas-design/LICENSE.txt

[claude]

Instrument Data to Allotrope Converter - License Addition Review

✅ Review Status: Approved

This PR adds the Apache License 2.0 to the instrument-data-to-allotrope skill directory.

Review Summary

Change: Addition of LICENSE.txt file only - no skill functionality changes.

License File: The Apache License 2.0 text is complete and properly formatted.

Observations

This is a straightforward license addition with no impact on skill functionality, documentation, or structure. The change aligns with standardizing licensing across skill directories in the repository.

No action required - the change is appropriate and complete.

[claude]

Single-Cell RNA-seq Quality Control Skill Review

Summary

This PR adds Apache License 2.0 to the single-cell-rna-qc skill. The license addition is appropriate and consistent with the repository's licensing approach.

Review of PR Changes

✅ LICENSE.txt added - Standard Apache 2.0 license file added to skill directory

General Skill Quality Assessment

Since this is a license-only PR, I also reviewed the existing skill structure:

✅ Well-structured skill - The skill follows best practices with clear YAML frontmatter, organized documentation, and proper use of bundled resources

✅ Good progressive disclosure - SKILL.md (176 lines) is concise and under the 500-line guideline, with detailed methodology properly separated into references/scverse_qc_guidelines.md

✅ Appropriate use of scripts - Three Python scripts provide deterministic QC functionality:

• qc_analysis.py - Complete pipeline script
• qc_core.py - Modular utility functions
• qc_plotting.py - Visualization utilities

✅ Clear workflow guidance - Two distinct approaches (complete pipeline vs. modular building blocks) with clear selection criteria

✅ Strong description - Frontmatter description clearly specifies what the skill does and when to use it

Recommendation

Approve - The license addition is appropriate. The existing skill is well-designed and follows skill creation best practices.

[claude]

scvi-tools Skill Review

Summary

This PR adds an Apache License 2.0 to the scvi-tools skill. The change is appropriate and brings the skill into alignment with licensing requirements.

Review of Changes

✅ LICENSE Addition

Status: Approved

The addition of LICENSE.txt with Apache License 2.0 is appropriate and aligns with the licensing standards for the skills repository. This is the only change in this PR.

Overall Skill Quality Assessment

Since this is a review of an existing skill with only a license addition, I've also assessed the overall skill quality:

Strengths

1. Excellent Progressive Disclosure: The skill makes excellent use of the three-level loading system:

   • Clear, comprehensive frontmatter description with specific triggers
   • Concise SKILL.md body (~156 lines) with navigation
   • 12 reference files for detailed workflows loaded only when needed
   • 8 modular scripts for reusable functionality

2. Strong Description: The frontmatter description is comprehensive and covers all use cases:

   • Lists all 8 major use cases clearly
   • Includes specific model names (scVI, scANVI, totalVI, etc.)
   • Contains relevant technical terms (VAE, batch correction, CITE-seq)
   • Provides clear triggering keywords

3. Well-Organized Navigation: The skill provides clear decision trees and tables:

   • Model Selection Guide table
   • Workflow Reference Files table
   • CLI Scripts table with usage examples
   • Quick Decision Tree for workflow selection

4. Appropriate Resource Organization:

   • References directory with 12 workflow-specific guides
   • Scripts directory with 7 CLI tools + 1 utilities module
   • Clear separation between procedural knowledge (SKILL.md) and detailed steps (references)

5. Reusable Components: The scripts/model_utils.py provides importable functions, and CLI scripts are modular and chainable.

Minor Observations

1. "When to Use This Skill" Section: Lines 18-25 contain a "When to Use This Skill" section in the SKILL.md body. According to skill-creator best practices, all triggering information should be in the frontmatter description, not the body (since the body is only loaded after triggering). This information appears redundant with the frontmatter.

2. External URLs: The skill includes external documentation links (lines 152-155). While helpful, these could potentially go stale. Consider whether these are essential or if the references files contain sufficient information.

Suggestions for Future Iterations

1. Remove Redundant "When to Use" Section: Consider removing lines 18-25 since this information is already comprehensively covered in the frontmatter description.

2. Reference File Size: Verify that reference files are well-structured with tables of contents if they exceed 100 lines (as recommended in skill-creator best practices).

Recommendation

Approve and merge. The LICENSE addition is appropriate and the skill demonstrates excellent design patterns overall. The minor observations above are opportunities for future refinement but don't block this PR.

[claude]

Nextflow Development Skill Review

Summary

This PR adds an Apache License 2.0 file to the existing nextflow-development skill. The change is approved as a licensing addition.

Review of the Change

What Changed

• Added: LICENSE.txt (Apache License 2.0, 201 lines)
• Modified: Nothing else

Assessment

✅ Approved - This is a standard licensing file addition with no impact on skill functionality.

Context

The nextflow-development skill (previously named nf-core) provides guidance for running nf-core bioinformatics pipelines (rnaseq, sarek, atacseq) on sequencing data. This licensing addition aligns with the repository's licensing standards.

---

General Skill Quality Assessment

While reviewing this PR, I also examined the overall skill quality. Here are observations about the existing skill:

✅ Strengths

1. Excellent Progressive Disclosure

   • Well-structured with clear workflow checklist (Steps 0-6)
   • Effective use of reference files for detailed docs
   • SKILL.md stays focused on core workflow (~290 lines)

2. Strong Description (Frontmatter)

   • Comprehensive triggers: "nf-core, Nextflow, FASTQ analysis, variant calling, gene expression, differential expression, GEO reanalysis, GSE/GSM/SRR accessions, or samplesheet creation"
   • Clearly defines when to use the skill

3. Good Script Organization

   • 5 main scripts + utils package
   • Scripts handle deterministic tasks (environment checks, samplesheet generation, data fetching)

4. Effective Decision Points

   • Clear "DECISION POINT" markers for user confirmation
   • Examples: pipeline selection, genome choice, parameter configuration

5. Well-Organized References

   • Domain-specific: pipelines/rnaseq.md, pipelines/sarek.md, pipelines/atacseq.md
   • Functional: troubleshooting.md, installation.md, geo-sra-acquisition.md

🔍 Minor Observations

1. Writing Style

   • Some sections use declarative mood ("This skill is provided...") instead of imperative
   • Frontmatter follows guidelines correctly

2. Directory Structure

   • No assets/ directory (appropriate - this skill doesn't need output templates)
   • Scripts could benefit from brief inline documentation

3. Disclaimer Section

   • The disclaimer at the end is appropriate given the bioinformatics domain
   • Attribution and licensing sections are helpful additions

---

Recommendation

Approve and merge. The LICENSE.txt addition is standard practice and has no functional impact on the skill.

The existing skill demonstrates strong adherence to skill-creator principles:

• Concise SKILL.md focusing on workflow
• Effective progressive disclosure with references
• Appropriate degree of freedom (scripts for fragile operations, text guidance for flexible decisions)
• Clear triggering conditions in description

---

Reviewed using: skill-creator guidelines from the Anthropic Agent Skills repository

[claude]

Scientific Problem Selection - Skill Review

Summary of Changes

This PR adds an Apache License 2.0 (LICENSE.txt) to the existing scientific-problem-selection skill. No changes were made to the skill content itself.

Overall Assessment

The license addition is appropriate, but this review also evaluates the existing skill quality since it's in the life-sciences repository.

---

Strengths

1. Excellent Progressive Disclosure Design

• SKILL.md (270 lines) serves as a clear navigation hub
• Nine reference files organize detailed content by topic
• Clear search patterns provided for each reference file (lines 229-239)
• Good balance: core workflow in SKILL.md, details in references

2. Strong Conversational Entry Points

• Three clear starting points meet users where they are (lines 10-20)
• Each option has appropriate initial prompts and follow-up workflows
• Response approaches demonstrate understanding before diving deeper

3. Well-Structured Workflow

• Clear 9-skill progression with purpose, output, and timeframe for each
• Flexible application (skills work independently, sequentially, or iteratively)
• Visual workflow diagram helps users understand the sequence

4. Comprehensive Domain Knowledge

• Based on published framework (Fischbach & Walsh, Cell 2024)
• Includes key principles (Risk Paradox, Parameter Paradox, Adversity Principle)
• Appropriate for target audiences (grad students, postdocs, PIs, founders)

---

Issues and Recommendations

1. LICENSE.txt Should Not Be in Skill Directory

• Issue: According to skill-creator guidance, skills should "only contain essential files that directly support its functionality" and explicitly states "Do NOT create extraneous documentation or auxiliary files"
• Impact: LICENSE.txt is repository-level infrastructure, not skill functionality
• Recommendation: Move LICENSE.txt to repository root or create a standard licensing approach for all skills
• File: scientific-problem-selection/LICENSE.txt

2. Description Could Be More Concise

• Issue: The description in frontmatter is 5 lines and includes both what it does AND multiple trigger examples. While comprehensive, it's token-heavy for metadata that's always in context.
• Current: "This skill should be used when scientists need help with research problem selection, project ideation, troubleshooting stuck projects, or strategic scientific decisions. Use this skill when users ask to pitch a new research idea, work through a project problem, evaluate project risks, plan research strategy, navigate decision trees, or get help choosing what scientific problem to work on. Typical requests include 'I have an idea for a project', 'I'm stuck on my research', 'help me evaluate this project', 'what should I work on', or 'I need strategic advice about my research'."
• Suggested: "Framework for systematic scientific problem selection, project evaluation, and research strategy. Use when scientists need help choosing research problems, evaluating project ideas, troubleshooting stuck projects, planning research strategy, or making strategic scientific decisions."
• File: SKILL.md:2-3

3. Time Estimates Throughout

• Issue: Skill-creator guidance explicitly states "Never give time estimates or predictions for how long tasks will take"
• Locations:
  • Table at lines 142-152 includes time estimates for each skill
  • "Who Should Use These Skills" section includes timeline guidance (lines 206, 211, 216, 221)
  • Expected Outcomes section uses time-based headers (lines 245, 253, 257)
• Recommendation: Remove time estimates or replace with complexity indicators (simple/moderate/complex)
• File: SKILL.md:142-152, 206-221, 245-261

4. Missing Table of Contents in Longer Reference Files

• Issue: Skill-creator guidance recommends "For files longer than 100 lines, include a table of contents at the top so Claude can see the full scope when previewing"
• Impact: Without previewing the reference files, I cannot verify if they include TOCs, but given the comprehensive nature of the skill, this is worth checking
• Recommendation: Ensure all reference files >100 lines have TOCs
• Files: references/*.md (all 9 files)

5. "Concrete Outputs" Design Principle Conflicts with Skill-Creator Guidance

• Issue: Line 194 states "Every skill produces tangible 1-2 page documents" but skill-creator doesn't emphasize document creation
• Observation: This may be appropriate for this specific domain (scientific research planning) where deliverables matter, but it's worth considering if Claude should generate these documents or guide users through the thinking
• File: SKILL.md:194

---

Questions for Author

1. Licensing Strategy: Should LICENSE.txt be at the repository root instead? Are all skills in life-sciences under Apache 2.0?

2. Reference File Structure: Do the reference files in references/ include tables of contents? (Recommended for files >100 lines)

3. Document Generation: Should Claude generate the "1-2 page documents" mentioned in the skill, or guide users through the thinking? The current approach seems to emphasize document creation.

---

Validation Checklist

Based on skill-creator requirements:

• ✅ SKILL.md with required YAML frontmatter (name, description)
• ✅ Progressive disclosure design (SKILL.md + references)
• ✅ Clear reference file organization by domain (9 skills)
• ✅ Search patterns provided for reference files
• ⚠️ No extraneous files (LICENSE.txt shouldn't be here)
• ⚠️ Time estimates present (should be removed)
• ❓ Table of contents in reference files (needs verification)
• ✅ Concise SKILL.md under 500 lines (270 lines)
• ✅ Clear when-to-use guidance in description
• ✅ Appropriate degree of freedom (conversational, high freedom)

---

Recommendation

Approve with modifications:

1. Move LICENSE.txt to repository root (blocking)
2. Remove time estimates throughout (recommended)
3. Condense description in frontmatter (optional)
4. Verify reference files >100 lines have TOCs (recommended)

The skill itself is well-designed with excellent progressive disclosure and strong domain knowledge. The license addition is appropriate but should be handled at the repository level rather than within the skill directory.

[claude]

Skill Review: Clinical Trial Protocol Skill

Executive Summary

The clinical-trial-protocol-skill is a comprehensive, well-architected skill for generating clinical trial protocols for medical devices and drugs. The skill demonstrates strong technical design with its waypoint-based architecture, modular subskill system, and progressive disclosure approach. However, there are several areas for improvement related to skill design principles, particularly around context efficiency, documentation structure, and adherence to skill creator guidelines.

Overall Assessment: Solid foundation with room for optimization

---

Strengths

1. Strong Architecture

• Waypoint-based design effectively separates concerns and enables resumability
• Modular subskill structure follows progressive disclosure principles well
• Clear execution control with explicit orchestration logic

2. Domain Expertise

• Comprehensive understanding of FDA regulatory pathways (IND, IDE, 510(k), PMA)
• Appropriate disclaimers and professional consultation requirements
• Validated sample size calculator script with statistical rigor

3. User Experience

• Research-only mode provides valuable flexibility
• Resume capability from any step
• Clear progress indicators and menu-driven interactions

4. Technical Implementation

• Well-structured Python script for sample size calculations
• JSON waypoints for structured data, markdown for human-readable content
• MCP server integration for ClinicalTrials.gov access

---

Areas for Improvement

Critical Issues

1. README.md Should Not Exist

Issue: The skill includes a `README.md` file

Guideline violated: "What to Not Include in a Skill" section states:

"A skill should only contain essential files that directly support its functionality. Do NOT create extraneous documentation or auxiliary files, including: README.md"

Impact: Adds unnecessary clutter and confusion about which file is authoritative

Recommendation:

• Delete `README.md` entirely
• Move any essential information from README into SKILL.md frontmatter description
• The description field in YAML frontmatter is the primary triggering mechanism and should be comprehensive

---

2. SKILL.md Body is Too Long (509 lines)

Issue: SKILL.md body is 509 lines, exceeding the recommended 500-line limit

Guideline:

"Keep SKILL.md body to the essentials and under 500 lines to minimize context bloat. Split content into separate files when approaching this limit."

Impact: Excessive context window consumption for every invocation

Specific sections that could be moved to references:

1. Detailed error handling (lines 419-436) → `references/error-handling.md`
2. Technical waypoint file formats (lines 383-408) → `references/waypoint-formats.md`
3. Full execution flow details (lines 154-380) could be condensed to high-level logic, with detailed pseudocode moved to references

Recommendation:
```
clinical-trial-protocol-skill/
├── SKILL.md (condensed to <400 lines)
└── references/
├── 00-initialize-intervention.md (existing)
├── 01-research-protocols.md (existing)
├── ... (other existing files)
├── execution-guide.md (detailed execution flow)
├── waypoint-formats.md (technical specifications)
└── error-handling.md (comprehensive error scenarios)
```

Then in SKILL.md, add:
```markdown

Detailed Documentation

For implementation details:

• Execution Flow Details: See references/execution-guide.md
• Waypoint File Formats: See references/waypoint-formats.md
• Error Handling: See references/error-handling.md
  ```

---

3. Description Field Missing "When to Use" Details

Issue: The YAML frontmatter description is brief (SKILL.md:3)

Current description:
```yaml
description: Generate clinical trial protocols for medical devices or drugs. This skill should be used when users say "Create a clinical trial protocol", "Generate protocol for [device/drug]", "Help me design a clinical study", "Research similar trials for [intervention]", or when developing FDA submission documentation for investigational products.
```

Guideline:

"Include both what the Skill does and specific triggers/contexts for when to use it. Include all 'when to use' information here - Not in the body. The body is only loaded after triggering, so 'When to Use This Skill' sections in the body are not helpful to Claude."

What's missing:

• Research-only mode capability (major feature!)
• Protocol revision/iteration use cases
• Specific regulatory submission contexts (IDE, IND, Pre-Sub)
• Resume capability for interrupted workflows

Recommendation:
```yaml
description: Generate clinical trial protocols for medical devices (IDE pathway) or drugs (IND pathway) with comprehensive regulatory research and statistical calculations. Use when: (1) Creating new clinical trial protocols from scratch, (2) Researching similar trials and FDA guidance without full protocol generation (research-only mode), (3) Generating specific protocol sections (foundation, intervention, operations), (4) Preparing FDA Pre-Submission documentation, (5) Calculating sample sizes with statistical justification, (6) Resuming interrupted protocol development. Triggers include: "Create a clinical trial protocol", "Research similar trials for [intervention]", "Generate protocol for [device/drug]", "Help me design a clinical study", "Calculate sample size for trial", "Find FDA guidance for [intervention]", "Resume protocol development", or when developing investigational device exemption (IDE) or investigational new drug (IND) submission documentation.
```

---

Moderate Issues

4. Redundant "Overview" and "What This Skill Does" Sections

Issue: SKILL.md has overlapping introductory sections (lines 22-41)

Impact: Wastes ~150 tokens on repeated information

Recommendation: Consolidate into a single "Overview" section:
```markdown

Overview

Generate clinical trial protocols for medical devices or drugs using a modular, waypoint-based architecture.

Two Modes:

• Research Only (Steps 0-1): Clinical research, FDA guidance, similar trials → .md artifact
• Full Protocol (Steps 0-5): Complete NIH-format protocol document

Resume Capability: Automatically resumes from last completed step if interrupted.
```

---

5. Execution Control Instructions Could Be More Concise

Issue: The "⚠️ EXECUTION CONTROL - READ THIS FIRST" section (lines 8-20) uses dramatic formatting and repetitive warnings

Current approach:
```markdown
CRITICAL: This orchestrator follows a SIMPLE START approach:

1. Display the welcome message FIRST
2. Ask user to confirm they're ready to proceed
3. Jump directly into Full Workflow Logic
4. Do NOT pre-read subskill files

Why this matters:

• Pre-reading all subskills wastes context and memory
  ```

Issue: Overuse of emphasis (bold, all-caps) and redundant explanations

Recommendation: Simplify to direct instructions:
```markdown

Execution Protocol

1. Display welcome message with mode selection
2. Wait for user choice (Research Only / Full Protocol / Exit)
3. Execute workflow sequentially, loading subskills on-demand only when their step runs
4. Never pre-read subskill files - load them at execution time

Rationale: Lazy loading conserves context window for actual protocol development.
```

---

6. Time Estimates Violate Guidelines

Issue: SKILL.md line 328 includes: "show estimated remaining time"

Guideline violated:

"Never give time estimates or predictions for how long tasks will take"

Recommendation: Remove this instruction. Replace with progress indicators only:
```markdown
4. Display progress: "Progress: [X/6] steps complete"
```

---

Minor Issues

7. Asset Template Could Be Referenced More Clearly

Issue: SKILL.md mentions "Any `.md` files in the `assets/` directory" (line 119) but doesn't explicitly name the existing template

Current:
```markdown
Template Files: Any `.md` files in the `assets/` directory
```

Recommendation:
```markdown
Default Template: `assets/FDA-Clinical-Protocol-Template.md` (NIH format)
Custom Templates: Any additional `.md` files in `assets/` directory
```

---

8. Disclaimers Appear Twice

Issue: Disclaimers appear in both SKILL.md (lines 437-457) and README.md (lines 19-34)

Recommendation: Keep disclaimers only in SKILL.md (and remove README.md entirely per Issue #1)

---

9. Prerequisites Section Could Use Progressive Disclosure

Issue: Prerequisites section (lines 85-134) is detailed but all front-loaded

Current structure: All prerequisites explained in SKILL.md

Recommendation: Keep high-level requirements in SKILL.md, move detailed setup to references:
```markdown

Prerequisites

1. ClinicalTrials.gov MCP Server (Required) - Setup Guide
2. Python Dependencies (Required for Step 4) - Run: `pip install -r requirements.txt`
3. FDA Database Access (Built-in via WebSearch)
4. Protocol Template (Included: `assets/FDA-Clinical-Protocol-Template.md`)

Step 1 automatically verifies MCP connectivity at startup.
```

Then create `references/mcp-setup.md` with full installation details.

---

Recommendations Summary

Immediate Actions (High Priority)

1. Delete README.md - Move essential info to SKILL.md description
2. Condense SKILL.md to <400 lines - Move technical details to references
3. Enhance description field - Add research-only mode, resume capability, specific triggers
4. Remove time estimates - Line 328 violates guidelines

Short-term Improvements (Medium Priority)

5. Consolidate overview sections - Eliminate redundancy
6. Simplify execution control - Remove excessive emphasis
7. Create references for details:
   • `references/execution-guide.md` (detailed workflow logic)
   • `references/waypoint-formats.md` (technical specs)
   • `references/error-handling.md` (comprehensive error scenarios)
   • `references/mcp-setup.md` (installation details)

Nice-to-Have (Low Priority)

8. Clarify asset template naming - Explicitly reference FDA-Clinical-Protocol-Template.md

---

Positive Patterns to Maintain

1. Waypoint architecture - Excellent separation of concerns
2. On-demand subskill loading - Follows progressive disclosure perfectly
3. Research-only mode - Great flexibility for users
4. Statistical validation - sample_size_calculator.py is well-implemented
5. Clear step boundaries - Each subskill is self-contained
6. Error handling at orchestration level - Appropriate retry logic
7. User-provided template support - Good customization option

---

Compliance Checklist

Guideline	Status	Notes
SKILL.md required	✅ Pass	Present and well-structured
YAML frontmatter (name, description)	✅ Pass	Present, but description could be enhanced
No README.md	❌ Fail	README.md should be deleted
SKILL.md under 500 lines	❌ Fail	509 lines - needs trimming
Progressive disclosure	✅ Pass	Excellent waypoint and subskill system
Scripts for deterministic tasks	✅ Pass	sample_size_calculator.py appropriate
References for documentation	⚠️ Partial	Good use of subskill references, but some details should move from SKILL.md
Assets for output resources	✅ Pass	FDA template appropriately placed
No time estimates	❌ Fail	Line 328 includes time estimate instruction
Concise is key	⚠️ Partial	Some verbosity in execution control and overview sections

Overall Compliance: 6/10 Pass, 2/10 Partial, 2/10 Fail

---

Conclusion

The clinical-trial-protocol-skill demonstrates strong domain expertise and thoughtful technical architecture. The waypoint-based system and modular subskills are exemplary implementations of progressive disclosure. With focused improvements to reduce SKILL.md length, remove extraneous documentation (README.md), and enhance the description field, this skill will fully align with best practices.

The core functionality is solid and provides real value for clinical researchers. The recommended changes are primarily about optimizing context efficiency and adhering to skill creator conventions rather than fixing fundamental issues.

Recommendation: Approve with requested revisions (delete README.md, condense SKILL.md, enhance description, remove time estimates)