Domain research

Skill Ibrahim-3d/agents-architect/skills/domain-research

Research a domain end-to-end before scaffolding an agentic system for it. Use when the user asks to "research [domain]", "learn about [field]", "what are the best practices for X", "survey the tools for Y", "what MCPs exist for Z", "before we build the agent, understand [topic]", or when kicking off a new /agents-architect:new for an unfamiliar domain. Covers methodology: taxonomy → tools → MCPs → idioms → anti-patterns → eval cases. Produces DOMAIN.md.From its SKILL.md

Install

npx -y skills add Ibrahim-3d/agents-architect --skill domain-research

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

3.1 KB, as published. Nobody here has run it

Domain Research

Before you build an agentic system for a domain, you research the domain the way a senior practitioner would brief a new hire. Output: a single DOMAIN.md that later agents consume.

Research layers

Taxonomy: core concepts, sub-fields, canonical workflows. (e.g., 3D modeling → modeling / UV / rigging / animation / shading / lighting / rendering / post.)
Tools: the 5-10 dominant programs, libraries, APIs. Note open-source vs. commercial, CLI vs. GUI, scriptable vs. not.
MCPs / programmatic interfaces: what's already exposed via MCP? What's scriptable via SDK? What requires GUI automation?
Idioms & conventions: how do practitioners name things, structure projects, version files, share work? (e.g., Blender → bpy API, collections, linked libraries.)
Best practices: top 10 rules practitioners would cite unprompted. Sourced from docs, style guides, community consensus.
Anti-patterns: top 10 ways novices and AI go wrong. Common failure modes.
Eval seeds: 10 concrete tasks that an agent in this domain should ace, and 10 harder ones it should survive.

Research methodology

WebSearch for current-year docs, "best practices <domain>", "[tool] Python API", "anti-patterns in <domain>".
WebFetch the official docs, top 3 community style guides, one textbook if available.
MCP registry search (search_mcp_registry) for each major tool.
arxiv / scholar (if connected) for recent methodology papers.
Cross-check sources: a practice is only "consensus" if it appears in 3+ independent sources.

DOMAIN.md structure

# Domain: <name>

## One-line definition

## Taxonomy
- Concept A — what it is, when it matters.
- ...

## Dominant tools
| Tool | License | Interface | Notes |
|---|---|---|---|

## Available MCPs
| MCP | Registry ID | Capabilities | Auth |
|---|---|---|---|

## Idioms
- Naming: ...
- Project layout: ...
- File versioning: ...

## Best practices (prioritized)
1. ...

## Anti-patterns
1. ...

## Eval seeds
### Core (must pass)
1. ...

### Stretch
1. ...

## Sources
- [Doc title](url)
- ...

Scope discipline

Time-box: 15-20 min of research per pass. Go deeper only when the user specifies a narrow sub-domain.
Breadth before depth: taxonomy + tool list first. Drill into the top 2-3 tools only.
Cite sources. Every best-practice bullet has a source link.

Output

Produce DOMAIN.md in the architect session's working directory. Return a 10-line summary to the orchestrator: scope, top 3 tools, recommended MCPs, top 3 anti-patterns to encode as red-lines, eval seed count.