/meta-config-stack-detect

name: meta-config-stack-detect
description: Inspect a codebase, a stack the user describes, or a description of what they want to build; map what is there to agents-inc catalog skills — or intent to candidate built-in stacks the user picks from — and emit a SeedPayload plus a human-readable proposal report. Use when seeding a configuration for a project that has none.

Stack Detection

> **Quick Guide:** Traverse what is in front of you — manifests, lockfiles, framework configs, one pass per workspace — or, where the user names nothing but the thing they want to build, offer candidate built-in stacks and wait for them to pick. Acquire the catalog and the stacks at run time, map signals to catalog skill ids, mark how each assignment loads per the product's preload mapping, surface exclusive-category conflicts instead of resolving them, and emit a `SeedPayload` plus a proposal report. The skill proposes. The machinery downstream validates. Nothing is written unattended.

---

**Detailed Resources:**

• [examples/core.md](examples/core.md) - A three-workspace monorepo walked end to end: traversal, mapping, an exclusive-category near-miss, the complete `SeedPayload`, and the proposal report — then the same output reached the other way, from intent alone: candidates, the user's pick, and the gap the pick leaves

---

<critical_requirements>

CRITICAL: Before Proposing Anything

> **All output must follow project conventions in CLAUDE.md**

**(You MUST acquire the catalog at run time and map only to ids it contains — never propose a skill id from memory, and never inline a copy of the catalog into your reasoning as if it were current)**

**(You MUST acquire the built-in stacks the same way when intent is all the user has given you, offer candidates with the reason each is one, and wait for the USER to pick before any mapping runs — recommending is still proposing, never deciding)**

**(You MUST emit the proposal as a `SeedPayload` and OFFER the command that publishes it — `agents-inc share --stdin` — for the user to run; never write config files, never run install commands, never POST the payload yourself, never report a configuration as applied)**

**(You MUST mark each assignment's load state as the product's preload mapping has it, and `lazy` where you cannot read the mapping — never allocate slots, count preloads, or hold a budget of your own)**

**(You MUST surface exclusive-category disagreement as an unresolved conflict naming both candidates and their evidence — never resolve one silently)**

**(You MUST report every detected library that has no catalog skill, every part of the intent no candidate stack covers, and every major-version mismatch, in the human-readable report — the `SeedPayload` stays schema-pure and carries none of them)**

</critical_requirements>

---

**Auto-detection:** stack detection, propose a config, seed a configuration, what skills does this project need, detect my stack, onboard this repo, what stack should I use, recommend a stack for what I am building, SeedPayload proposal

**When to use:**

• A project has no configuration yet and the user wants one proposed from the code
• A user describes their stack in conversation and wants a starting configuration
• A user describes only what they want to build, names no libraries, and needs candidate stacks to choose between
• A monorepo needs a per-workspace read before anyone picks skills by hand
• An existing proposal needs re-running after the repo's dependencies changed

**Key patterns covered:**

• Traversal: which signals settle a question and which only corroborate
• Catalog acquisition in priority order, with verification rather than assumption
• Intent to candidate built-in stacks, offered for the user to pick between
• Mapping judgment, including the audited-vs-absent distinction
• Workspace to domain and sub-agent mapping
• Load state, deferred to the product's preload mapping
• Conflict surfacing for exclusive categories
• Version awareness (configure-and-warn)
• Output assembly: `SeedPayload` plus proposal report

**When NOT to use:**

• The project already has a configuration — that is a deterministic mapping from existing config, not detection
• The user names the skills they want — take them at their word and skip detection
• The user names the built-in stack they want — apply it; there is nothing left to recommend
• The task is authoring skill content rather than selecting skills

---

<philosophy>

Philosophy

**The skill proposes; the existing machinery validates.** Detection is deliberately judgment-shaped. A deterministic detector accumulates an unbounded edge-case matrix — every monorepo flavor, every module-federation layout, every exotic directory convention — and each new architecture becomes something to test. Judgment absorbs that long tail instead. Determinism is recovered at the boundary rather than in the detector: a proposal is only accepted if it survives the validation that already exists downstream — schema decoding, skill-existence checks, `requires` relations, conflict relations, and one-selection-per-exclusive-category. Nothing anywhere tests "does detection handle this build system"; the only guarantee that has to hold is that an invalid configuration cannot get through, and that guarantee is already built and already tested.

This is why there is no deterministic detector to imitate, and why the output shape matters more than the traversal. Get the payload right and a wrong guess is a checkbox the user unticks. Get the payload wrong and a right guess is unusable.

**Three ways in, one concern.** Files on disk, a stack the user names, and a description of what they want to build are three qualities of evidence for the same question — which skills should this configuration carry. The third is the weakest by a wide margin: intent names no library, so answering it means choosing among the stacks the product already ships, and choosing is the user's to do. Offer the