concept-extractor

Name: concept-extractor
Author: AdamBien

40stars10forks

How to install concept-extractor?

adambien/airails/concept-extractor

$npx -y skills add AdamBien/airails --skill concept-extractor

Installs into the current project.

Summary

Mine candidate domain concepts and their vocabulary from every naming source of a legacy system — database schema, UI labels, REST/URL paths, configuration, code identifiers, documentation. Produces a regenerable CONCEPTS.md (aliases, evidence, frequency, co-occurrence) and seeds

Files · 1

View on GitHub

SKILL.md

1	# Concept Extractor
2
3	Recover the domain language buried in a legacy system's names. The technical structure of overengineered systems lies about the domain — packages reflect patterns, not business capabilities. Names are where the original domain knowledge survived. Produce candidates for human review, never verdicts.
4
5	## Workflow
6
7	1. Inventory which naming sources exist in the system (see ranking below).
8	2. Mine every source. Tokenize compound names: `CustomerContractValidationServiceFactoryImpl` → Customer, Contract, Validation.
9	3. Strip pattern noise using [references/noise-words.md](references/noise-words.md). Keep the discards for the noise report.
10	4. Cluster aliases into one concept per meaning (Customer / Client / Kunde / `CUST`). Expand abbreviations from surrounding context — column names, labels, Javadoc.
11	5. Record co-occurrence: two concepts co-occur when they share a class, table, URL path, or UI view.
12	6. Write `migration/CONCEPTS.md` in the analyzed project — all pipeline artifacts live in this folder, never at the legacy project's root.
13	7. Seed `migration/GLOSSARY.md` if absent. If present, append proposals under `## Proposed` — never modify existing entries.
14
15	## Naming Sources — Ranked by Trustworthiness
16
17	Mine all that exist. When sources conflict, trust the higher-ranked one:
18
19	1. Database schema — tables, columns, constraints. Survived every refactoring fashion; usually the most honest source.
20	2. UI labels — JSP/JSF/HTML text, i18n bundles, report headers. Closest to the language the business actually speaks.
21	3. External contracts — REST/URL paths, queue and topic names, WSDL, exchanged file names.
22	4. Configuration keys, enum values, exception names.
23	5. Code identifiers — packages, classes, methods, fields. Most numerous, least reliable.
24	6. Comments, Javadoc, test names, documentation.
25
26	## CONCEPTS.md Format
27
28	Regenerable, evidence-oriented, diffable. Use this structure:
29
30	```markdown
31	# Concepts: <system name>
32
33	## Concepts
34	### <Concept>
35	- Aliases: <all forms found, incl. abbreviations>
36	- Sources: DB / UI / contracts / code — with concrete pointers (table, file, path)
37	- Frequency: <n> \| Confidence: high \| medium \| low
38	- Co-occurs with: <Concept> (<count>), ...
39
40	## Co-occurrence
41	<table or Mermaid graph of concept pairs with counts>
42
43	## Noise Report
44	<stripped words with counts — makes the extraction auditable>
45
46	## Open Questions
47	### Q<n> — <one-line question>
48	<evidence pointers; candidate answers when enumerable — suspected synonyms
49	across sources, homonyms in different contexts (often the first hint of a
50	BC boundary), unexpandable abbreviations>
51	```
52
53	Q-ids are stable across re-runs: never renumber, new questions get new ids. They are the contract `concept-clarifier` resolves against.
54
55	Confidence: high = present in several source kinds, medium = one kind with many occurrences, low = single source or unresolved abbreviation. Order concepts by frequency — the reader reviews the top entries carefully and skims the tail.
56
57	## GLOSSARY.md Format
58
59	Human-owned, durable — the ubiquitous language of the future system. Seed one entry per high- and medium-confidence concept:
60
61	```markdown
62	### <Concept>
63	Definition (inferred): <one sentence>. (hypothesis — derived from <evidence>; confirm with domain expert)
64	Canonical term: <term> — supersedes: <aliases>
65	Related: [[<Concept>]], [[<Concept>]]
66	```
67
68	Every definition is inferred from usage, not knowledge — mark it as a hypothesis until a human removes the marker. The canonical term is a naming decision for the generated code (entities, boundaries, REST paths, BC names); for mixed-language systems, pick one language and state it at the top of the glossary.
69
70	The glossary outlives `migration/`: its canonical terms feed the new system's sbce system doc and BC naming. It is authored here but meant to be promoted into the new system — the folder is disposable, the glossary is cargo. State this in the glossary header.
71
72	## Rules
73
74	- Every claim carries an evidence pointer — review must be spot-checkable, not trust-based.
75	- All output goes to `migration/` — a well-known path is the contract downstream skills read from, and one folder keeps the legacy repo clean (one `.gitignore` line

People who liked this also viewed

6 picks

Type

concept-extractor

40stars10forks

View on GitHub

How to install concept-extractor?

adambien/airails/concept-extractor

$npx -y skills add AdamBien/airails --skill concept-extractor

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Concept Extractor
2
3	Recover the domain language buried in a legacy system's names. The technical structure of overengineered systems lies about the domain — packages reflect patterns, not business capabilities. Names are where the original domain knowledge survived. Produce candidates for human review, never verdicts.
4
5	## Workflow
6
7	1. Inventory which naming sources exist in the system (see ranking below).
8	2. Mine every source. Tokenize compound names: `CustomerContractValidationServiceFactoryImpl` → Customer, Contract, Validation.
9	3. Strip pattern noise using [references/noise-words.md](references/noise-words.md). Keep the discards for the noise report.
10	4. Cluster aliases into one concept per meaning (Customer / Client / Kunde / `CUST`). Expand abbreviations from surrounding context — column names, labels, Javadoc.
11	5. Record co-occurrence: two concepts co-occur when they share a class, table, URL path, or UI view.
12	6. Write `migration/CONCEPTS.md` in the analyzed project — all pipeline artifacts live in this folder, never at the legacy project's root.
13	7. Seed `migration/GLOSSARY.md` if absent. If present, append proposals under `## Proposed` — never modify existing entries.
14
15	## Naming Sources — Ranked by Trustworthiness
16
17	Mine all that exist. When sources conflict, trust the higher-ranked one:
18
19	1. Database schema — tables, columns, constraints. Survived every refactoring fashion; usually the most honest source.
20	2. UI labels — JSP/JSF/HTML text, i18n bundles, report headers. Closest to the language the business actually speaks.
21	3. External contracts — REST/URL paths, queue and topic names, WSDL, exchanged file names.
22	4. Configuration keys, enum values, exception names.
23	5. Code identifiers — packages, classes, methods, fields. Most numerous, least reliable.
24	6. Comments, Javadoc, test names, documentation.
25
26	## CONCEPTS.md Format
27
28	Regenerable, evidence-oriented, diffable. Use this structure:
29
30	```markdown
31	# Concepts: <system name>
32
33	## Concepts
34	### <Concept>
35	- Aliases: <all forms found, incl. abbreviations>
36	- Sources: DB / UI / contracts / code — with concrete pointers (table, file, path)
37	- Frequency: <n> \| Confidence: high \| medium \| low
38	- Co-occurs with: <Concept> (<count>), ...
39
40	## Co-occurrence
41	<table or Mermaid graph of concept pairs with counts>
42
43	## Noise Report
44	<stripped words with counts — makes the extraction auditable>
45
46	## Open Questions
47	### Q<n> — <one-line question>
48	<evidence pointers; candidate answers when enumerable — suspected synonyms
49	across sources, homonyms in different contexts (often the first hint of a
50	BC boundary), unexpandable abbreviations>
51	```
52
53	Q-ids are stable across re-runs: never renumber, new questions get new ids. They are the contract `concept-clarifier` resolves against.
54
55	Confidence: high = present in several source kinds, medium = one kind with many occurrences, low = single source or unresolved abbreviation. Order concepts by frequency — the reader reviews the top entries carefully and skims the tail.
56
57	## GLOSSARY.md Format
58
59	Human-owned, durable — the ubiquitous language of the future system. Seed one entry per high- and medium-confidence concept:
60
61	```markdown
62	### <Concept>
63	Definition (inferred): <one sentence>. (hypothesis — derived from <evidence>; confirm with domain expert)
64	Canonical term: <term> — supersedes: <aliases>
65	Related: [[<Concept>]], [[<Concept>]]
66	```
67
68	Every definition is inferred from usage, not knowledge — mark it as a hypothesis until a human removes the marker. The canonical term is a naming decision for the generated code (entities, boundaries, REST paths, BC names); for mixed-language systems, pick one language and state it at the top of the glossary.
69
70	The glossary outlives `migration/`: its canonical terms feed the new system's sbce system doc and BC naming. It is authored here but meant to be promoted into the new system — the folder is disposable, the glossary is cargo. State this in the glossary header.
71
72	## Rules
73
74	- Every claim carries an evidence pointer — review must be spot-checkable, not trust-based.
75	- All output goes to `migration/` — a well-known path is the contract downstream skills read from, and one folder keeps the legacy repo clean (one `.gitignore` line

People who liked this also viewed

6 picks

Type