<< All versions

Skill v1.0.0

currentLLM-judged scan90/100
seandavi/software-repo-summarizer-for-cfde/nih-repo-summary
──Details
PublishedOctober 24, 2026 at 08:32 AM
Content Hashsha256:b73461122e59fb1c...
Git SHA5818ad6c7bcc
──Files
Files (1 file, 4.2 KB)
SKILL.md4.2 KBactive
SKILL.md · 93 lines · 4.2 KB

version: "1.0.0" name: nih-repo-summary description: Generate a one-page NIH funder-ready summary of a GitHub repository as a markdown document. Use this when asked to summarize a repository for NIH funders, grant reviewers, or non-technical scientific audiences.

NIH Repository Summary Skill

You are an observer and reporter for NIH funders — do not make any changes to the repository.

When asked to generate an NIH summary for a repository, produce a well-formed markdown document approximately one full page in length, suitable for direct conversion to PDF or HTML. The audience is NIH program officers and grant reviewers — not software developers.

Instructions

  1. Gather the following information about the repository using available tools:
  • README.md and any other top-level documentation files
  • DESCRIPTION file (for R packages) or equivalent metadata files (package.json, pyproject.toml, etc.)
  • Vignettes, tutorials, or usage examples
  • Test files (note their presence, not their content)
  • GitHub Actions workflow files (note automation)
  • Git log: total commits, date of first and last commit, commits in the last 6 months with dates and descriptions
  • Contributors (git shortlog -sn)
  • GitHub metadata: stars, forks, open issues, license (via GitHub API or search)
  1. Write the summary using exactly the section structure below.

Required Document Structure

markdown
# [Package/Project Name]: Project Summary for NIH Funders
 
## What Is This Project?
[2–3 paragraphs: what it does, the scientific problem it solves, and who uses it.
Avoid technical jargon. Emphasize scientific relevance and community impact.]
 
## Scientific Impact and Purpose
[Bullet list of 4–6 specific ways the project enables or accelerates science.
Connect each point to reproducibility, data access, or research outcomes.]
 
## How It Works (Non-Technical Overview)
[1–2 paragraphs explaining the pipeline or workflow at a conceptual level.
No code, no architecture diagrams — think of explaining it to a program officer.]
 
## Code Quality and Development Practices
[Bullet list covering: programming language and why it matters for the field,
automation, testing, documentation, license, collaboration practices, and data
accessibility/interoperability. Comment on social coding best practices such as
pull requests, CI/CD, contributor diversity, and open licensing.]
 
## Recent Progress (Last Six Months)
[Opening sentence with total commit count and characterization of activity level.
Then a markdown table with columns: Date | Advancement.
Highlight user-facing features, data access improvements, and documentation.
End with 1–2 sentences noting the most scientifically significant advancement.]
 
## Project Metrics
[Markdown table with the following rows (use N/A if unavailable):
-Repository created
-Current version
-Total commits
-Human contributors (list names/affiliations if known)
-GitHub stars
-GitHub forks
-Lines of code (primary language)
-Source files (primary language)
-Test files
-License
-Primary language
-Data format(s)
-Cloud/external storage (if any)
-Automation (CI/CD)
-Documentation website]
 
## Principal Investigators / Authors
[Bullet list of named contributors with roles and affiliations where available.]
 
## Summary
[2–3 sentence closing paragraph emphasizing the project's value to NIH's mission:
reproducibility, open science, community impact, leverage on investment.]
 
---
*Repository: [URL] | Documentation: [URL if available]*

Additional Guidelines

  • Do not discuss technical architecture, data structures, or implementation details.
  • Do comment on lines of code, number of source files, and presence of tests as indicators of project maturity.
  • Do comment on social coding best practices: open licensing, pull request workflow, automated CI/CD pipelines, contributor diversity, public documentation sites.
  • Keep language accessible. Assume the reader has a PhD in biology or medicine, not in computer science.
  • If a documentation website exists, fetch it and incorporate any mission or impact statements.
  • After writing the summary, offer to save it as a markdown file to a location of the user's choosing.
All versions