infer-domain-selection-from-code

Infers product domains from scan-index.json signals using canonical domain knowledge base.

3|Updated Jan 25, 2026
One-click install
npx skills add https://github.com/kapilvirenahuja/garura --skill infer-domain-selection-from-code
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: infer-domain-selection-from-code
Source: https://github.com/kapilvirenahuja/garura/tree/main/core/components/skills/infer-domain-selection-from-code
Command: npx skills add https://github.com/kapilvirenahuja/garura --skill infer-domain-selection-from-code

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

It reduces the guesswork of categorizing an existing brownfield repository by inferring which product domains the codebase actually evidences, turning scan signals into a structured proposal for domain taxonomy updates.

Core Features & Use Cases

  • Brownfield domain inference from scan evidence: Cross-walks scan-index signals (framework idioms, dependencies, config files, readme preview, and CI/testing indicators) against Garura’s canonical domain knowledge base.
  • Evidence-backed proposals for new domains: Produces specification/domain-selection.yaml with selected, rejected, and inferred new domains when scan-only domains don’t match the canonical set.
  • Resolution-trace auditability: Writes a resolution trace that records probes and outcomes to support downstream review and governance.

Quick Start

Run the product-keeper codify flow for a brownfield repo and let infer-domain-selection-from-code score canonical domains from scan-index.json, producing specification/domain-selection.yaml under the codify proposals path.

Frequently Asked Questions about infer-domain-selection-from-code

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I infer product domains from a brownfield codebase during modernization?

You can identify product domains by scoring scan-index.json signals—such as framework idioms, dependencies, and CI config—against a canonical domain knowledge base to produce evidence-backed YAML proposals.

What scan signals are used for codebase domain inference and taxonomy mapping?

Domain inference uses scan-index.json signals including framework idioms, dependencies, Docker and CI configuration, readme keywords, and test indicators to cross-walk against the canonical domain knowledge base.

How do I generate evidence-backed proposals for new domains not in my canonical taxonomy?

When scan-only domains do not match the canonical set, the skill produces a specification/domain-selection.yaml file that proposes inferred new domains alongside selected and rejected entries with evidence backing.

Do I need a valid scan-index.json file to bootstrap product codify domain selection?

Yes, you need a valid scan-index.json file and access to the domain knowledge markdown directory to translate repository scan signals into evidence-linked domain selection decisions.

How does resolution-trace logging support domain selection governance and review?

Resolution-trace logging writes a structured decision manifest that records probes and outcomes during domain inference, providing auditability to support downstream review and governance.

What are the limitations of using scan evidence for brownfield domain inference?

A key limitation is that domain inference relies strictly on scan-index.json signals; when scan-only domains do not match the canonical set, it proposes new entries but requires downstream review via the resolution trace.