/meta-config-stack-detect

name: meta-config-stack-detect
description: Proposes an agents-inc configuration — a SeedPayload plus a report — from a repository, a stack the user describes, or a description of what they want to build. Load when seeding a configuration for a project that has none, or re-running one after its dependencies changed.

Stack Detection

> **Quick Guide:** Read the evidence in front of you — manifests, lockfiles and framework configs, one pass per workspace — and map each library to an id from a catalog acquired at run time. Where the user names only what they want to build, offer candidate built-in stacks and wait for the pick. Load states come from the product's preload mapping, or `lazy`; an exclusive-category disagreement is surfaced, never resolved; whatever the payload cannot carry goes in the report. The output is a `SeedPayload` plus a report, published by the user through `npx agents-inc share --stdin` — the run writes, installs and posts nothing.

**Detailed Resources:**

• [examples/core.md](examples/core.md) — a three-workspace monorepo walked end to end: traversal, mapping, an exclusive-category conflict, the payload and the report
• [examples/intent.md](examples/intent.md) — the same output reached from intent alone: candidates, the user's pick, and the gap the pick leaves
• [reference.md](reference.md) — the `SeedPayload` contract, what each catalog route yields, payload defaults, report sections

---

Which path applies

• **A repository to read** — traverse it (Pattern 1); its signals settle the proposal. Follow

[examples/core.md](examples/core.md).

• **A stack the user describes, with no repository** — ask for a pasted manifest first. Without one

the description is the evidence, and people name what they like rather than what they use and leave out tooling, so every finding is WEAK and the report says the proposal came from description. Patterns 2–8 apply as written.

• **Only an outcome — no repository, no library named** — there is no signal to map. Offer candidate

built-in stacks (Pattern 9) and wait for the pick; nothing else runs until the user answers. Follow [examples/intent.md](examples/intent.md).

---

<critical_requirements>

Before proposing a configuration

**Acquire the catalog at run time and map only to ids it contains.** Consumers skip an unknown skill or sub-agent id rather than rejecting it, so a remembered id makes the proposal silently smaller, with nothing anywhere to explain the gap.

**When intent is all you have, offer candidate stacks and wait for the user to pick before mapping anything.** A payload is what a decision looks like, and one that arrives with the choice already made is a decision the user has to notice in order to undo.

**Emit a `SeedPayload` and a report, and offer `npx agents-inc share --stdin` for the user to run.** The CLI validates against the schema the store writes with and owns the wire version, the API address and the user-agent; writing config, running an install or POSTing the payload yourself removes the validation the whole design rests on. Never report the configuration as applied either: the user runs the command, and nothing is configured until they do.

**Mark each assignment's load state as the product's preload mapping has it, and `lazy` where the run cannot read the mapping.** A payload's load state lands as the user's explicit choice and overrides the mapping on install, so a hand-made allocation silently disagrees with every other surface.

**Surface an exclusive-category disagreement as an unresolved conflict naming both candidates and their evidence.** The payload holds one per sub-agent, and carrying the better-evidenced one without saying so turns an architectural question into a checkbox nobody re-reads.

**Put every ABSENT library, every uncovered part of the intent and every major-version mismatch in the report, never in the payload.** The schema strips keys it does not declare, so a warning added to the payload vanishes in transit while the decode still succeeds.

</critical_requirements>

---

**Auto-detection:** detect my stack, propose a config, seed a configuration, what skills does this project need, onboard this repo, recommend a stack for what I am building, `SeedPayload`, `share --stdin`, `init --from`, `catalog.json`, `suggestedStacks`, `stackId`, `matrixVersion`

**Applies to:**

• Proposing a configuration for a project that has none, from its manifests, lockfiles and configs
• Turning a stack the user describes into a starting configuration
• Offering candidate built-in stacks when the user names only what they want to build
• Reading a monorepo per workspace before anyone picks skills by hand
• Re-running a proposal after the repository's dependencies changed

**Handled elsewhere:**

• Publishing an installation that already exists — `share` maps the installed configuration deterministically, with no detection in it
• Skills or a stack the user names outright — apply them; there is nothing left to detect or recommend
• Validating the proposal — schema decoding, skill existence, `requires` and conflict relations belong to the CLI and the store, which judge what this skill emits
• Writing skill content — authoring a skill is a different job from selecting one

---

<philosophy>

Philosophy

**The skill proposes; the existing machinery validates.** A deterministic detector accumulates an unbounded edge-case matrix — every monorepo flavour, every exotic layout — and each new architecture becomes something to test. Judgment absorbs that long tail, and determinism is recovered at the boundary instead: a proposal is accepted only if it survives the validation already built downstream. So the output shape matters more than the traversal. With the payload right, a wrong guess is a checkbox the user unticks; with it wrong, a right guess is unusable.

**Run-to-run variance is acceptable.** The output opens a session the user confirms and never writes configuration unattend