القائمة
Use when extracting patterns from any external repo or tool. Read source level, not description level. Classify, extract and integrate what serves the ecosystem.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Use when running the weekly intelligence review. The AI briefs each engagement from live ecosystem data, the Sovereign speaks freely across 3 this-week and 2 next-week engagements, and the session closes with a Sovereign Command update.
Use when starting a session to initialize the AI interface with continuity checks, a live ecosystem orientation and approval-gated support sweep before any session work begins.
Use when archiving several ecosystem artifacts at once with per-artifact approval gates before any vault move executes.
Use when checking for published updates from the Sovereign Ecosystem GitHub repo and selectively applying only what you explicitly approve.
Use when a long-form manuscript (book chapter, ebook, multi-chapter playbook, long-form digital product) needs an editing pass to identify and remove AI writing tells against the Anti-AI Writing Patterns Codex. Triggered by the Sovereign after draft completion, by a Pending Plan handover map naming this skill at the edit phase, or by any post-draft state where AI-assisted prose needs the anti-pattern sweep before final review.
Use when updating a Pending Plan mid-arc with breadcrumbs, applicability changes, partial implementation notes and reconciliation-ready context.
| name | source-harvest |
| description | Use when extracting patterns from any external repo or tool. Read source level, not description level. Classify, extract and integrate what serves the ecosystem. |
| status | active |
| version | 1 |
Purpose: Extract actionable patterns from any external repo, plugin, or resource by reading the actual source, skills, hooks, commands, protocols, configs. Not the README. The nuance is in the implementation. Classify each component against ecosystem equivalents and execute approved integrations with governance applied. Trigger: Sovereign identifies a new repo, plugin, or tool of interest. Also used as the first-pass when adding any new repo to the Sovereign Tech Watch Protocol Watched Repos table, the first review should always be a Source Harvest, not a description scan. Inputs: Repo URL, tool reference, or inbox item. Outputs: Structured harvest report (classified component by component) + approved ecosystem file edits + deferred items filed + optional Pending Plans for larger scope + optional Sovereign Tech Watch entry. Status: active Related Protocols/Codices: [[Council Chamber/Protocols/Governance/Sovereign Tech Watch Protocol]], [[Council Chamber/Tools/Support Files/sovereign-deferred-items.md]], [[Council Chamber/Protocols/Governance/Ambassador Doctrine]]
Every component is classified as one of four dispositions:
| Disposition | Meaning | Action |
|---|---|---|
| Adopt | Genuinely new capability not covered by ecosystem | Build as an ecosystem skill or protocol, adapted to ecosystem vernacular and governance |
| Enrich | Strengthens an existing ecosystem skill or protocol | Identify the exact change and target file; execute with approval |
| Defer | Useful but no immediate gap; worth watching | File in sovereign-deferred-items.md with a promotion signal |
| Ignore | Fully covered by existing ecosystem capabilities, or not relevant | No action; note briefly why |
Identify the source and confirm it is publicly accessible. Common paths:
gh api repos/[owner]/[repo]/contents/ to list top-level structureWebFetchWebFetch and WebSearch to extract feature sets and technical documentation. When source code is unavailable, the harvest operates at the capability and pattern level. The classification framework still applies.If authentication is required or the source is private, halt: "Source requires authentication or is private. Sovereign must provide access or assess via available documentation."
Do not proceed using only the README or description as primary evidence. For non-repo sources where no code exists, capability documentation and API references serve as the evidence base.
Fetch and list all components. Typical targets:
.md or scripted skill definitions)Present the inventory to the Sovereign: "Found [N] components: [brief list by category]." Confirm before proceeding to classification.
Read each component file. Do not classify from filenames or descriptions alone. The content is the evidence.
For large repos (20+ components), group by category and read the most relevant ones first. Flag anything skipped and why.
For each component, assign a disposition (Adopt / Enrich / Defer / Ignore) and write one to three lines of rationale:
Compile the full classification into a harvest report:
SOURCE HARVEST: [repo name], [date]
--------------------------------------
Adopt: [count], [names]
Enrich: [count], [names + target ecosystem file]
Defer: [count], [names]
Ignore: [count]
[Per-component breakdown]
For each Enrich: specify the exact change to the target file (what to add, where, why). For each Adopt: draft the ecosystem-adapted version in outline or propose a Pending Plan if scope requires more than one session.
Present the harvest report to the Sovereign. No changes execute without approval.
Ask: "Approve all, approve subset, or revise?" Wait for explicit response.
If the Sovereign approves a subset, note which items are deferred for a future run.
For each approved Enrich: edit the target ecosystem file. For each approved Adopt: create the new SKILL.md or protocol file at the canonical path.
Log each change as it completes.
Ecosystem governance applies to all adoptions:
For every new skill or protocol created in Step 7, run this housekeeping block before proceeding to Step 9:
a. Register the skill. New skills are only discoverable by your runtime after registration. The exact mechanism depends on your environment:
.claude/skills/), create a link or copy from that directory to Council Chamber/Skills/[Skill Name]. On Mac/Linux: ln -s; on Windows: mklink /J (run as administrator).Confirm the path resolves correctly after creation.
b. Update the Skills Index. Edit Council Chamber/Skills/Skills Index.md:
c. Note if a new skill requires a CLAUDE.md update. If the skill introduces a standing behavior (a new trigger phrase, a new mandatory gate, a new integration), check whether CLAUDE.md needs a standing instruction. If yes, flag it as a recommendation before Step 10.
This housekeeping block is not optional for Adopt items. A skill that exists in the canonical path but has no symlink and no index entry is a ghost. Discoverable only by accident.
For each Defer and any unapproved Adopt: add an entry to Council Chamber/Tools/Support Files/sovereign-deferred-items.md.
Each entry must include:
Update entry_count in the frontmatter.
If ongoing monitoring of this source is warranted (active development, high relevance, good signal-to-noise), add a row to the Watched Repos table in Council Chamber/Protocols/Governance/Sovereign Tech Watch Protocol.md.
Note what was adopted or enriched from this first harvest so future changelog reviews have context.
If the source arrived via the ecosystem Inbox (Inbox/), note the disposition in the file or confirm with the Sovereign whether to archive it.
Output a final summary:
Source Harvest complete: [repo name], [date]
Adopted: [N skills/protocols created]
Enriched: [N existing files updated]
Deferred: [N items filed]
Ignored: [N]
Watch entry: [added / not added]
When creating a new skill that operates externally, declare the allowed tools in the command frontmatter using the allowed-tools key. This scopes the permission surface to the minimum required for that skill's job.
Example:
---
allowed-tools: Bash(gh issue view:*), Bash(gh pr comment:*), Bash(gh pr diff:*)
---
This is a Vigraha boundary at the command level. It prevents a skill from reaching tools it has no business touching. Apply it to any skill that uses external CLIs or operates with scoped permissions.
Not all ecosystems can use this pattern in every execution environment. Flag it in new skill design as the intended permission boundary even if the runtime does not enforce it yet.
Status is active. Execution authorized. Steps 1-5 are research only. Step 6 is the approval gate. Steps 7-12 execute after approval.
[!info] Ambassador Doctrine Active This skill operates under the [[Council Chamber/Protocols/Governance/Ambassador Doctrine]]. Primary strategy: Āsana: observe and classify before acting. The harvest is intelligence gathering first, integration second. Secondary: Vigraha: ecosystem governance standards are a boundary assertion, not a formality. External patterns are adopted on ecosystem terms. The approval gate at Step 6 is the Āsana-to-Yāna transition: information collected, decision made, action authorized.
Date-stamped entries for harvest decisions and calibration findings that emerge in practice.
Template note: As you run Source Harvests, log your decisions here. The refinements section becomes a precedent record, what you adopted and why, what you rejected, what surprised you. Future harvests reference this section to avoid re-evaluating patterns that have already been classified.
Also installs standalone from https://www.infinitegameos.io/skills/source-harvest (dual-distribution: this copy lives in your vault, the public plugin updates independently).