# Spark Ecosystem Product

> Make Spark Intelligence product decisions with deep awareness of Spark Researcher, Spark Swarm, domain chips, specialization paths, autoloop flywheels, and the wider Spark ecosystem. Use when defining product scope, modular architecture, ecosystem integration, persistent agent behavior, or self-evolving collective-intelligence systems.

- Skill: `vibeforge1111/spark-ecosystem-product` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add vibeforge1111/spark-ecosystem-product`
- Raw SKILL.md: https://api.skillmd.com/api/skills/vibeforge1111/spark-ecosystem-product/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: vibeforge1111 (https://skillmd.com/u/vibeforge1111)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/vibeforge1111/spark-ecosystem-product

---


# Spark Ecosystem Product

Use this skill when work touches:

- product scope
- modular architecture
- ecosystem integration
- domain chip usage
- specialization path design
- autoloop and self-improvement loops
- persistent agent product decisions

## Read First

- `docs/PRD_SPARK_INTELLIGENCE_V1.md`
- `docs/ARCHITECTURE_SPARK_INTELLIGENCE_V1.md`
- `docs/CODING_RULESET_V1.md`
- `docs/SPARK_INTELLIGENCE_PROMPT_BIBLE.md`

Then read:

- `references/system-map.md`

## Core Doctrine

Spark Intelligence should be:

- one persistent agent identity
- powered by Spark Researcher
- deepened by Spark Swarm when needed
- specialized by domain chips
- evolved by specialization paths
- improved by autoloop flywheels

The product should feel like one coherent machine made of lego pieces, not one bloated repo that tries to own everything itself.

## Product Lens

Ask these questions on every decision:

1. Does this deepen the wedge or widen the surface?
2. Should this live in Spark Intelligence, Spark Researcher, Spark Swarm, a domain chip, or a specialization path?
3. Does this make the agent feel more coherent or more fragmented?
4. Does this improve retention or only improve the demo?
5. Is this modular in the right way, or just split apart cosmetically?

## Workflow

1. Define the user-facing behavior.
2. Assign the correct subsystem owner.
3. Keep Spark Intelligence as the runtime shell, not the owner of all intelligence.
4. Use chips and paths as modular attachments.
5. Preserve one persistent agent identity across channels.
6. Distinguish governing-loop work from scheduled harness work.
7. Check whether the proposal improves collective intelligence and moddability without increasing chaos.

If ownership is unclear, use the system ownership map in `references/system-map.md` before recommending any new module or feature.

## Required Outputs

Return these explicitly:

- user-facing value
- subsystem owner
- ecosystem dependencies
- whether this belongs in Spark Intelligence or elsewhere
- impact on modularity
- impact on self-evolution and collective intelligence

## Spark-Specific Rules

- Keep the runtime core in Spark Researcher.
- Keep deep delegation in Spark Swarm.
- Keep specialization in chips and paths.
- Keep memory ownership with the memory chip.
- Keep Spark Intelligence lightweight enough to stay maintainable.
- Do not cron-shape ecosystem evolution when the behavior belongs in Spark's governing loop.

## Default Deliverable

The result should usually include:

- what the user gets
- who owns the feature
- why it belongs there
- what stays out of this repo