Store Adoption
Fetch updates from all 4 plugin stores, inventory their contents, and generate a ranked list of adoption candidates matched against the fleet's needs.
When to Use
- Monthly cadence: run as part of the Brain Retraining Cadence
- When a new heir is added to the fleet (new needs to match)
- When a store gets a significant update (new category of plugins)
- On demand via
/scan-stores
Inputs
- Fleet profile (
fleet/fleet-profile.json) — each heir's domain, stack, and needs
- Portfolio intelligence (refreshed daily by AlexFleetPortfolio):
AlexFleetPortfolio/repos/repo-analysis.json — descriptions, languages, topics for all 69 reposAlexFleetPortfolio/repos/repo-classification.json — AI-classified categories (9 categories, tiers)AlexFleetPortfolio/repos/traffic-latest.json — view/clone activity (signals active repos)
- 4 plugin stores (local clones at
C:\Development\):
.github-private (production, 37 plugins)copilot-plugins (official GitHub)awesome-copilot (community)playground (staging, 800+)
Process
Step 1 — Fetch and inventory (mechanical)
node scripts/store-sync.cjs
This does three things:
- Pulls AlexFleetPortfolio — gets the latest daily-refreshed repo data (descriptions, topics, languages, classifications, traffic)
- Pulls all 4 plugin stores — gets latest plugin additions
- Writes outputs:
fleet/store-inventory.json + fleet/STORE-INVENTORY.md — plugin tablesfleet/portfolio-snapshot.json — repo-analysis + repo-classification snapshot from AlexFleetPortfolio
Use --skip-fetch to inventory without pulling (offline mode).
Step 2 — Semantic matching (AI)
Read fleet/STORE-INVENTORY.md and fleet/fleet-profile.json. For each store (production first, then official, community, playground):
- Scan the plugin descriptions in the inventory table
- For each plugin, assess: does this plugin's purpose match any heir's domain, mission, or stated needs?
- Weight by relevance: a healthcare plugin is relevant to the
health heir, not to job
- Filter out Microsoft-internal tools that require internal infrastructure (ICM, ADX clusters, CloudMine, etc.)
- Flag plugins that serve multiple heirs (cross-cutting capabilities)
Present the top candidates as:
| Plugin | Store | Why | Heirs served | Components |
| --- | --- | --- | --- | --- |
| deep-review | production | Adversarial code review — all heirs benefit | all | 1 skill, 3 agents |
Step 3 — Triage candidates
Apply the same judgment as Mall store-evaluation:
| Signal |
Action |
| Production store + matches 3+ heirs |
Strong candidate — evaluate for Mall promotion |
| Official store + matches domain need |
Good candidate — install to specific heirs |
| Community + high star count |
Worth reviewing — quality varies |
| Playground + niche domain |
Only if specific heir needs it urgently |
Step 4 — Route approved candidates
| Destination |
When |
Mall (Alex_Skill_Mall) |
Skill is domain-general, would serve multiple heirs |
| Heir local/ |
Plugin serves one specific heir's niche |
| Edition baseline |
Plugin is universally useful (rare — must pass skill-review gates) |
| Defer |
Not needed now, log in decisions/curation-log.md |
Step 5 — Update fleet profile
After installing candidates, update fleet-profile.json:
- Remove satisfied needs from heir entries
- Add newly discovered needs surfaced during review
Outputs
| File |
Content |
fleet/store-inventory.json |
Structured plugin inventory (names, counts, README excerpts) |
fleet/STORE-INVENTORY.md |
Markdown tables for AI semantic search |
fleet/fleet-profile.json |
Updated after triage (manual step) |
Keeping the Profile Current
The fleet profile is the matching input. Keep it accurate:
- When a new heir is registered, add its entry with domain, stack, needs
- When an heir installs Mall skills, remove those needs
- When the fleet's mission shifts (new project domain), update domain_summary
- Run
node scripts/store-sync.cjs monthly to refresh candidates
Anti-Patterns
| Anti-pattern |
Fix |
| Installing every candidate |
Apply the selection filter — most candidates are noise |
| Skipping production store |
Production has the highest quality bar — check it first |
| Updating profile after install but not after retirement |
Dead heirs inflate the needs signal |
| Running without fetching |
Stale stores produce stale candidates — always fetch first |
1---2name: store-adoption3description: Fetch plugin store updates, inventory contents, match against fleet profile, and generate adoption candidates report4---5
6# Store Adoption
7
8Fetch updates from all 4 plugin stores, inventory their contents, and generate a ranked list of adoption candidates matched against the fleet's needs.
9
10## When to Use
11
12- Monthly cadence: run as part of the Brain Retraining Cadence
13- When a new heir is added to the fleet (new needs to match)
14- When a store gets a significant update (new category of plugins)
15- On demand via `/scan-stores`
16
17## Inputs
18
19- **Fleet profile** (`fleet/fleet-profile.json`) — each heir's domain, stack, and needs
20- **Portfolio intelligence** (refreshed daily by AlexFleetPortfolio):
21 - `AlexFleetPortfolio/repos/repo-analysis.json` — descriptions, languages, topics for all 69 repos
22 - `AlexFleetPortfolio/repos/repo-classification.json` — AI-classified categories (9 categories, tiers)
23 - `AlexFleetPortfolio/repos/traffic-latest.json` — view/clone activity (signals active repos)
24- **4 plugin stores** (local clones at `C:\Development\`):
25 - `.github-private` (production, 37 plugins)
26 - `copilot-plugins` (official GitHub)
27 - `awesome-copilot` (community)
28 - `playground` (staging, 800+)
29
30## Process
31
32### Step 1 — Fetch and inventory (mechanical)
33
34```bash
35node scripts/store-sync.cjs
36```
37
38This does three things:
391. **Pulls AlexFleetPortfolio** — gets the latest daily-refreshed repo data (descriptions, topics, languages, classifications, traffic)
402. **Pulls all 4 plugin stores** — gets latest plugin additions
413. **Writes outputs**:
42 - `fleet/store-inventory.json` + `fleet/STORE-INVENTORY.md` — plugin tables
43 - `fleet/portfolio-snapshot.json` — repo-analysis + repo-classification snapshot from AlexFleetPortfolio
44
45Use `--skip-fetch` to inventory without pulling (offline mode).
46
47### Step 2 — Semantic matching (AI)
48
49Read `fleet/STORE-INVENTORY.md` and `fleet/fleet-profile.json`. For each store (production first, then official, community, playground):
50
511. Scan the plugin descriptions in the inventory table
522. For each plugin, assess: **does this plugin's purpose match any heir's domain, mission, or stated needs?**
533. Weight by relevance: a healthcare plugin is relevant to the `health` heir, not to `job`
544. Filter out Microsoft-internal tools that require internal infrastructure (ICM, ADX clusters, CloudMine, etc.)
555. Flag plugins that serve multiple heirs (cross-cutting capabilities)
56
57Present the top candidates as:
58
59```markdown
60| Plugin | Store | Why | Heirs served | Components |
61| --- | --- | --- | --- | --- |
62| deep-review | production | Adversarial code review — all heirs benefit | all | 1 skill, 3 agents |
63```
64
65### Step 3 — Triage candidates
66
67Apply the same judgment as Mall store-evaluation:
68
69| Signal | Action |
70| --- | --- |
71| Production store + matches 3+ heirs | Strong candidate — evaluate for Mall promotion |
72| Official store + matches domain need | Good candidate — install to specific heirs |
73| Community + high star count | Worth reviewing — quality varies |
74| Playground + niche domain | Only if specific heir needs it urgently |
75
76### Step 4 — Route approved candidates
77
78| Destination | When |
79| --- | --- |
80| **Mall** (`Alex_Skill_Mall`) | Skill is domain-general, would serve multiple heirs |
81| **Heir local/** | Plugin serves one specific heir's niche |
82| **Edition baseline** | Plugin is universally useful (rare — must pass skill-review gates) |
83| **Defer** | Not needed now, log in `decisions/curation-log.md` |
84
85### Step 5 — Update fleet profile
86
87After installing candidates, update `fleet-profile.json`:
88- Remove satisfied needs from heir entries
89- Add newly discovered needs surfaced during review
90
91## Outputs
92
93| File | Content |
94| --- | --- |
95| `fleet/store-inventory.json` | Structured plugin inventory (names, counts, README excerpts) |
96| `fleet/STORE-INVENTORY.md` | Markdown tables for AI semantic search |
97| `fleet/fleet-profile.json` | Updated after triage (manual step) |
98
99## Keeping the Profile Current
100
101The fleet profile is the matching input. Keep it accurate:
102
103- When a new heir is registered, add its entry with domain, stack, needs
104- When an heir installs Mall skills, remove those needs
105- When the fleet's mission shifts (new project domain), update domain_summary
106- Run `node scripts/store-sync.cjs` monthly to refresh candidates
107
108## Anti-Patterns
109
110| Anti-pattern | Fix |
111| --- | --- |
112| Installing every candidate | Apply the selection filter — most candidates are noise |
113| Skipping production store | Production has the highest quality bar — check it first |
114| Updating profile after install but not after retirement | Dead heirs inflate the needs signal |
115| Running without fetching | Stale stores produce stale candidates — always fetch first |
gabrielmoreira