domain-discovery

Name: domain-discovery
Author: TanStack

314stars19forks

How to install domain-discovery?

tanstack/intent/domain-discovery

$npx -y skills add TanStack/intent --skill domain-discovery

Installs into the current project.

Summary

Analyze library documentation and source code, then interview maintainers to discover capability domains and task-focused skills for AI coding agents. Activate when creating skills for a new library, organizing existing documentation into skill categories, or when a maintainer wa

Files · 1

View on GitHub

SKILL.md

1	# Domain Discovery & Maintainer Interview
2
3	You are extracting domain knowledge for a library to produce a structured
4	domain map. Your job is not to summarize documentation — it is to build a
5	deep understanding of the library first, then use that understanding to
6	surface the implicit knowledge that maintainers carry but docs miss.
7
8	The output is a set of task-focused skills — each one matching a
9	specific developer moment ("implement a proxy", "set up auth", "audit
10	before launch"). Domains are an intermediate conceptual grouping you use
11	during analysis; the final skills emerge from the intersection of domains
12	and developer tasks.
13
14	There are five phases. Always run them in order — unless the lightweight
15	path applies (see below).
16
17	1. Quick scan — orient yourself (autonomous)
18	2. High-level interview — extract the maintainer's task map
19	3. Deep read — fill in failure modes and detail (autonomous)
20	4. Detail interview — gap-targeted questions, AI-agent failures
21	5. Finalize artifacts
22
23	### Lightweight path (small libraries)
24
25	After Phase 1, decide whether the library warrants the full five-phase
26	flow or the compressed flow below. This is a judgment call — lean toward
27	full discovery unless the library is obviously small (single-purpose
28	utility, 2–3 distinct developer tasks max). Use a compressed flow when
29	the skill surface is small enough that two interview rounds would be
30	redundant:
31
32	1. Phase 1 — Quick scan (same as full flow)
33	2. Phase 2+4 combined — Single interview round. Combine the
34	high-level task map questions (Phase 2) with gap-targeted and
35	AI-agent-specific questions (Phase 4) into one interview session
36	of 4–8 questions total. Skip the draft-review step since the skill
37	set is small enough to confirm in one pass.
38	3. Phase 3 — Deep read (same as full flow, but scope is smaller)
39	4. Phase 5 — Finalize artifacts (same as full flow)
40
41	The lightweight path produces identical output artifacts (domain_map.yaml
42	and skill_spec.md). It just avoids two separate interview rounds when the
43	library is small enough that one round covers everything.
44
45	### Hard rules — interview phases are mandatory and interactive
46
47	These rules override any other reasoning. No exceptions.
48
49	1. **Phases 2 and 4 are interactive interviews conducted with the
50	maintainer.** You must ask the questions specified in each sub-section
51	and wait for the maintainer's response before continuing. Documentation,
52	source code, and other automated analysis are NOT substitutes for the
53	maintainer's answers.
54	2. **Every question in Phases 2 and 4 must be asked as an open-ended
55	question and sent as a message to the maintainer.** You must then
56	STOP and WAIT for their reply. Do not answer your own questions. Do
57	not infer answers from documentation. Do not skip questions because
58	you believe you already know the answer.
59	3. **Never ask factual questions you can answer by searching the
60	codebase.** Before asking any question, determine whether the answer
61	is a deterministic fact (how many X exist, what versions are
62	supported, which files implement Y) or a judgment call (which ones
63	matter, what should we prioritize, what do developers struggle with).
64	Factual questions must be answered by searching the code — grep,
65	glob, read files. Only ask the maintainer for priorities, opinions,
66	trade-offs, and implicit knowledge that cannot be found in code or
67	docs. Asking the maintainer a question whose answer is sitting in
68	the codebase wastes their time and erodes trust in the process.
69	4. **Do not convert open-ended questions into multiple-choice,
70	yes/no, or confirmation prompts.** The question templates in each
71	sub-section are open-ended by design. Present them as open-ended
72	questions. The maintainer's unprompted answers surface knowledge that
73	pre-structured options suppress.
74	5. Minimum question counts are enforced. Each sub-section specifies
75	a question count range (e.g. "2–4 questions"). You must ask at least
76	the minimum number. Asking zero questions in any sub-section is a
77	protocol violation.
78	6. STOP gates are mandatory. At the boundaries marked `── STOP ──`
79	below, you must halt execution and wait for the maintainer's response
80	or acknowledgment before proceeding. Do

People who liked this also viewed

6 picks

Type

domain-discovery

314stars19forks

View on GitHub

How to install domain-discovery?

tanstack/intent/domain-discovery

$npx -y skills add TanStack/intent --skill domain-discovery

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Domain Discovery & Maintainer Interview
2
3	You are extracting domain knowledge for a library to produce a structured
4	domain map. Your job is not to summarize documentation — it is to build a
5	deep understanding of the library first, then use that understanding to
6	surface the implicit knowledge that maintainers carry but docs miss.
7
8	The output is a set of task-focused skills — each one matching a
9	specific developer moment ("implement a proxy", "set up auth", "audit
10	before launch"). Domains are an intermediate conceptual grouping you use
11	during analysis; the final skills emerge from the intersection of domains
12	and developer tasks.
13
14	There are five phases. Always run them in order — unless the lightweight
15	path applies (see below).
16
17	1. Quick scan — orient yourself (autonomous)
18	2. High-level interview — extract the maintainer's task map
19	3. Deep read — fill in failure modes and detail (autonomous)
20	4. Detail interview — gap-targeted questions, AI-agent failures
21	5. Finalize artifacts
22
23	### Lightweight path (small libraries)
24
25	After Phase 1, decide whether the library warrants the full five-phase
26	flow or the compressed flow below. This is a judgment call — lean toward
27	full discovery unless the library is obviously small (single-purpose
28	utility, 2–3 distinct developer tasks max). Use a compressed flow when
29	the skill surface is small enough that two interview rounds would be
30	redundant:
31
32	1. Phase 1 — Quick scan (same as full flow)
33	2. Phase 2+4 combined — Single interview round. Combine the
34	high-level task map questions (Phase 2) with gap-targeted and
35	AI-agent-specific questions (Phase 4) into one interview session
36	of 4–8 questions total. Skip the draft-review step since the skill
37	set is small enough to confirm in one pass.
38	3. Phase 3 — Deep read (same as full flow, but scope is smaller)
39	4. Phase 5 — Finalize artifacts (same as full flow)
40
41	The lightweight path produces identical output artifacts (domain_map.yaml
42	and skill_spec.md). It just avoids two separate interview rounds when the
43	library is small enough that one round covers everything.
44
45	### Hard rules — interview phases are mandatory and interactive
46
47	These rules override any other reasoning. No exceptions.
48
49	1. **Phases 2 and 4 are interactive interviews conducted with the
50	maintainer.** You must ask the questions specified in each sub-section
51	and wait for the maintainer's response before continuing. Documentation,
52	source code, and other automated analysis are NOT substitutes for the
53	maintainer's answers.
54	2. **Every question in Phases 2 and 4 must be asked as an open-ended
55	question and sent as a message to the maintainer.** You must then
56	STOP and WAIT for their reply. Do not answer your own questions. Do
57	not infer answers from documentation. Do not skip questions because
58	you believe you already know the answer.
59	3. **Never ask factual questions you can answer by searching the
60	codebase.** Before asking any question, determine whether the answer
61	is a deterministic fact (how many X exist, what versions are
62	supported, which files implement Y) or a judgment call (which ones
63	matter, what should we prioritize, what do developers struggle with).
64	Factual questions must be answered by searching the code — grep,
65	glob, read files. Only ask the maintainer for priorities, opinions,
66	trade-offs, and implicit knowledge that cannot be found in code or
67	docs. Asking the maintainer a question whose answer is sitting in
68	the codebase wastes their time and erodes trust in the process.
69	4. **Do not convert open-ended questions into multiple-choice,
70	yes/no, or confirmation prompts.** The question templates in each
71	sub-section are open-ended by design. Present them as open-ended
72	questions. The maintainer's unprompted answers surface knowledge that
73	pre-structured options suppress.
74	5. Minimum question counts are enforced. Each sub-section specifies
75	a question count range (e.g. "2–4 questions"). You must ask at least
76	the minimum number. Asking zero questions in any sub-section is a
77	protocol violation.
78	6. STOP gates are mandatory. At the boundaries marked `── STOP ──`
79	below, you must halt execution and wait for the maintainer's response
80	or acknowledgment before proceeding. Do

People who liked this also viewed

6 picks

Type