| name | oss-analyze |
| description | This skill should be used when the user asks to "analyze an open source project", "generate a feature matrix", "extract features from a repo", "analyze a GitHub repo for pre-sales", "update the feature matrix", or provides a GitHub URL with intent to understand the project's capabilities for RFP response or solution design. Supports incremental updates on new major versions. |
| version | 0.2.0 |
OSS Analyze
Overview
Analyze an open source project from its GitHub repository and produce a structured feature matrix (knowledge/oss-feature-matrix.md) consumable by downstream RFP response, solution design, and demo building skills. Treat the feature matrix as version-controlled documentation (Docs-as-Code pattern).
When to Use
- First run: when onboarding a new OSS project as the base platform for customer engagements
- Incremental update: when the OSS project releases a new major version — re-run to diff and update
- This is a Phase 0 prerequisite before
/case-import or /rfp-response
Workflow
Step 0: Check for existing matrix
If knowledge/oss-feature-matrix.md already exists:
- Read it to understand the previous analysis baseline
- Note the previous version and date
- Check
CHANGELOG.md, release notes, or git tag diff between previous and current versions to identify what changed
- After generating the new analysis, highlight changes from the previous version in a
## Changes from v<prev> section
What to diff:
| Area | What changed | Impact on RFP responses |
|---|
| New features | Additions since last version | New capabilities to cite |
| Deprecated/removed | Features dropped or renamed | Stop promising these |
| API changes | Breaking changes, new endpoints | Update integration answers |
| Config changes | New/deprecated settings | Update deployment answers |
| Module restructuring | Moved or renamed components | Update architecture references |
Step 1: Acquire the repository
Preferred: gitmcp.io MCP. gitmcp.io provides a hosted MCP server for GitHub repos. Configure it as an MCP server in Claude Code, then use the available tools to explore the repo:
- Use the MCP server's
get_file_tree or equivalent to list the repo structure
- Use
get_file_content or equivalent to read specific files
- The MCP server URL follows the pattern
https://gitmcp.io/{owner}/{repo}
Fallback chain (if gitmcp.io MCP is not configured):
gh repo clone <repo> to a temporary directorycurl raw.githubusercontent.com files- Direct
git clone as a last resort
Error handling: If the repo is inaccessible (404, auth required, rate limited), report the specific error and stop. If docs/ directory is missing, note the gap in the output and proceed with source-only analysis. If the repo is empty or has no recognizable structure, mark the output as status: blocked with an explanation.
Step 2: Build project overview
Read the following in order, recording findings:
- README.md — what the project does, core value proposition, quick start
- docs/ directory index — identify key documentation files
- Root directory structure — identify modules, subprojects, monorepo layout
- Dependency declarations —
go.mod, package.json, Cargo.toml, pom.xml, requirements.txt etc., to understand tech stack and key dependencies
Step 3: Extract feature matrix
Extract the following dimensions from documentation and source code:
| Dimension | Source | Notes |
|---|
| Core features | README, docs/ | Product-level feature descriptions |
| Modules/components | Source directory structure | Code organization, each module's responsibility |
| APIs/interfaces | API definitions, proto files, OpenAPI specs | Programmable interfaces |
| Extension points | Plugin/extension documentation in docs/ | Customization entry points |
| Configuration | Config files, environment variable docs | Deployment and runtime configuration |
| Deployment | docker-compose, k8s YAML, helm charts | Deployment architecture |
| Version info | CHANGELOG, git tags | Current version and history |
Step 4: Generate the feature matrix
Output knowledge/oss-feature-matrix.md with the following structure:
---
skill: oss-analyze
date: <YYYY-MM-DD>
inputs: <github-url>
status: draft
---
# <Project Name> Feature Matrix
## Project Overview
- **Repository**: <url>
- **Current Version**: <version>
- **Tech Stack**: <language/framework>
- **License**: <license>
- **Core Value**: <one sentence>
## Feature Catalog
### <Category 1>
| Feature | Description | Since | Confidence |
|---------|-------------|-------|------------|
| ... | ... | ... | confirmed |
### <Category 2>
...
## Module Architecture
<project-name>/
├── module-a/ — <responsibility>
├── module-b/ — <responsibility>
└── ...
## APIs & Extension Points
| Interface | Type | Description | Source |
|-----------|------|-------------|--------|
| ... | REST/gRPC/SDK | ... | <file> |
## Deployment & Operations
| Dimension | Detail |
|-----------|--------|
| Deployment method | ... |
| Service dependencies | ... |
| Resource requirements | ... |
## Known Limitations
- ...
## Changes from <previous version>
> Only present when updating an existing matrix
| Dimension | Previous | Current | Impact |
|-----------|----------|---------|--------|
| New features | — | ... | ... |
| Deprecated | ... | — | ... |
| API changes | ... | ... | ... |
Step 5: Validate and guide
After generating the output:
- Verify the feature catalog covers the dimensions needed for RFP response (features, APIs, deployment, limitations)
- Annotate coverage gaps with
<!-- GAP: <missing dimension> — needs supplementary source -->
- If this is an update, call out specific changes that affect RFP responses (new capabilities to leverage, deprecated features to avoid)
- Prompt the next step:
/case-import to add past project cases, or /rfp-response to consume this matrix
Quality Checklist
