# Source Harvest

> Systematic pattern extraction from any external repo or tool at source level. Classify, extract, integrate.

**Skill · v1.0 · Updated 2026-04-29**

Source Harvest is a skill for extracting patterns from external repositories at source level rather than description level. It reads the actual implementation, classifies each component as Adopt, Enrich, Defer or Ignore, and executes approved integrations under governance. The README is not the nuance.

## Install

### Claude Code (CLI / WSL / Git Bash)

```
/plugin marketplace add https://www.infinitegameos.io/marketplace.json
/plugin install source-harvest@igos-library
```

### Claude Code (VS Code)

[Install in VS Code](vscode://anthropic.claude-code/install-plugin?plugin=source-harvest&marketplace=https%3A%2F%2Fwww.infinitegameos.io%2Fmarketplace.json)

Opens the Claude Code plugins dialog with the marketplace and skill prefilled. Requires the Claude Code VS Code extension installed and signed in. Or paste the snippet below into `.claude/settings.json` for VS Code, JetBrains or any setup that prefers manual config:

```json
{
  "extraKnownMarketplaces": {
    "igos-library": {
      "source": {
        "source": "url",
        "url": "https://www.infinitegameos.io/marketplace.json"
      }
    }
  },
  "enabledPlugins": {
    "source-harvest@igos-library": true
  }
}
```

### Direct markdown URL

```
curl https://www.infinitegameos.io/markdown/skills/source-harvest
```

Or send `Accept: text/markdown` to https://www.infinitegameos.io/skills/source-harvest

### Cursor

```
curl -O https://www.infinitegameos.io/install/cursor/source-harvest.mdc
```

### Aider, Cline, any agent with --read

```
curl -O https://www.infinitegameos.io/markdown/skills/source-harvest
aider --read source-harvest.md
```

## Definition

Source Harvest is a skill for extracting patterns from external repositories, plugins and tools at the source level rather than the description level. It reads the actual implementation. It classifies each component against your existing tooling. It executes approved integrations under governance. The README is not the nuance. The descriptions on a homepage are not the patterns. The patterns live in the skill files, the hook scripts, the command definitions, the configurations and the protocol documents that ship inside a repo. Source Harvest treats those as the evidence base. Every component receives one of four dispositions: Adopt, Enrich, Defer or Ignore. Adoptions are conscious, governed and adapted to your system's voice and conventions. Nothing installs wholesale. The result is a body of work that grows by intentional integration, not by accumulation.

## The four dispositions

Every component reviewed in a harvest receives exactly one disposition. Adopt means a genuinely new capability not covered by your existing system. The component becomes a new internal skill or protocol, adapted to your voice and conventions. Enrich means the component strengthens something you already have. The harvest names the exact change and the target file, then executes the edit under approval. Defer means the pattern is interesting but no immediate gap warrants integration. The component is filed in a deferred inventory with a promotion signal: the specific trigger that should pull it back off the shelf later. Ignore means the pattern is fully covered by current capability or not relevant. The harvest documents the reason briefly and moves on.

The four dispositions are the spine of the discipline. They make sure every component lands somewhere. Nothing drifts. Nothing accumulates by accident. The harvest report becomes a record of conscious decisions rather than an inventory of stored ideas.

## How a harvest runs

A harvest opens by confirming access to the source. Public repos are read directly. Closed platforms substitute capability documentation and API references for the source code. The classification framework still applies. After access, the harvest inventories every component: skills, hooks, commands, configurations, protocols, scripts. The list is presented to the operator before classification proceeds.

Each component is then read in full. Filenames and one-line descriptions do not classify. Source content is the evidence. Once read, each component receives its disposition with one to three lines of rationale. The compiled harvest report is presented at the approval gate. No changes execute without explicit approval. Approved items execute step by step. Adopted skills are written to canonical paths with proper frontmatter and discoverability registration. Enriched files receive their precise edits. Deferred items are logged with promotion signals. The harvest closes with a summary report.

The approval gate is the discipline. It is the moment intelligence-gathering becomes integration. Without that gate, harvests drift toward wholesale install. With it, every adoption is a conscious choice on your terms.

## Use Cases

**Open-source plugin source review**

When someone publishes a Claude Code plugin, the description rarely surfaces the load-bearing patterns. Source Harvest reads the hooks, commands and skills directly, surfacing patterns like four-phase debug gates, dual confidence scoring rubrics or per-phase verification disciplines that descriptions skip. Each pattern receives a disposition before any code is integrated.

**Closed SaaS platform capability inventory**

Closed-source platforms cannot be source-read, but feature documentation and API references serve as the evidence base. A capability-level harvest classifies each feature against existing internal systems. Patterns adopt. Disconnected internal tools sometimes reveal a synthesis that none of them named alone, like a workflow architecture connecting three previously separate systems.

**Multi-source comparative harvest**

Three related skills run as a simultaneous harvest produce more signal than any one alone. When all three independently flag the same anti-pattern, that convergence is itself the finding. The output becomes a synthesized codex rather than three parallel skill clones, plus targeted enrichments to existing internal protocols where the convergence pulled them.

**First-pass review for a tech watchlist**

Adding a new repo to an ongoing tech-watch list begins with a Source Harvest, not a description scan. The first review establishes whether the repo offers anything genuinely novel or whether it duplicates current capability. The disposition becomes the entry's classification record for future changelog reviews and pulls forward the patterns worth watching.

**Backend-dependent plugin extraction**

A plugin that requires a worker service or local backend gets classified at the source level even though most of its skills are not adoption candidates. The patterns inside, like phase-zero documentation discovery or smart token-economics tables, often integrate cleanly into existing protocols even when the full plugin does not. The infrastructure is deferred. The patterns travel.

## FAQ

**Why read the source instead of the README?**

Descriptions summarize intent. Source carries the load-bearing patterns. A four-phase debug gate, a dual confidence scoring rubric or a per-phase verification discipline is invisible from a homepage. The patterns live in the skill files, the hook scripts and the configs. Source Harvest treats those as the evidence base.

**What does each disposition mean in practice?**

Adopt creates a new internal skill, adapted to your conventions. Enrich edits an existing skill or protocol with a precise change. Defer files the pattern in an inventory with a promotion signal. Ignore is documented and dismissed because your system already covers it. Every component lands somewhere.

**Can Source Harvest classify closed-source or SaaS platforms?**

Yes. When source code is unavailable, capability documentation and API references become the evidence base. The four dispositions still apply. The harvest operates at the pattern level rather than the implementation level. Feature inventories run against existing internal systems the same way.

**What happens at the approval gate?**

Step 6 is a hard pause. The harvest report is presented to the operator with every component classified. Nothing installs without explicit approval. The operator can approve all, approve a subset or revise. Approved items execute. Rejected items either get filed or dismissed.

**How does Source Harvest scale to large repos?**

Group by category. Read the highest-relevance components first. Flag anything skipped and document why. A repo with forty components rarely needs each one read in full. Five Adopt candidates, ten Enrich candidates and the rest Ignore is a normal harvest shape.

## Related

- [Plan Challenger](https://www.infinitegameos.io/skills/plan-challenger)
- [Systematic Debugging](https://www.infinitegameos.io/skills/systematic-debugging)
- [Pending Plan Implementation](https://www.infinitegameos.io/skills/pending-plan-implementation)
- [Skill Creator](https://www.infinitegameos.io/skills/skill-creator)
- [Researcher](https://www.infinitegameos.io/skills/researcher)

---

Source Harvest is one entry point. The full system it lives inside is The Sovereign Life Playbook. The Playbook gives you the design frame for which patterns are worth extracting in the first place.

[See the Sovereign Life Playbook](https://sidequesthq.co/products/sovereign-life-playbook)

---
*[Infinite Game OS](https://www.infinitegameos.io) · [Skills](https://www.infinitegameos.io/skills) · [Source Harvest](https://www.infinitegameos.io/skills/source-harvest)*