Created
April 22, 2026 16:30
-
-
Save indiscripts/f86d108af916e66428fdc22fc3b0ffbf to your computer and use it in GitHub Desktop.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| INDEXMATIC QUERY LIST GENERATION (PROMPT) | |
| // Cf https://indiscripts.com/IndexMatic | |
| TASK | |
| You are tasked with creating a comprehensive IndexMatic query list from a term frequency table extracted from a document that mainly relates to [[TOPIC]]. Your goal is to generate meaningful, user-centric INDEX entries that help readers navigate the document's content effectively, based on words/keywords/strings that actually occur in the document (i.e. those listed below). | |
| INPUT | |
| [[INSERT FREQUENCY TABLE HERE]] | |
| OUTPUT | |
| Generate a query list in the format: | |
| <keyword or regex> => <index entry> | |
| Where: | |
| • <keyword or regex> is either a simple word or a regular expression (using /…/ delimiters) that appears in the table, or matches some table item(s) | |
| • <index entry> is the final index entry, optionally with parent topic(s) in the form: topic > subtopic > entry — noting that the entry is not necessarily identical or even similar to the matched key string | |
| If comments or sections are required in the query list, use the `//` prefix: | |
| // Some Comment or Title | |
| PROCESS | |
| • Analyze the frequency table and identify semantically meaningful terms. | |
| • Group related concepts and infer underlying topics from surface-level terms. | |
| • Create a hierarchical structure that clusters related ideas. | |
| • Eliminate redundancy and collision between entries. | |
| • Validate that parent topics genuinely address multiple child concepts. | |
| • Ensure the final list is consistent and intuitive from a reader's perspective. | |
| RULES TO FOLLOW | |
| • Focus on terms with conceptual weight and domain significance; exclude generic or trivial words. | |
| • Prioritize high-frequency terms representing actual ideas, but consider low-frequency terms if semantically important. | |
| • Use frequency data to validate, not dictate, term selection. | |
| • When a keyword (e.g. ‘time’) is not specific enough by itself due to the various polysemic/idiomatic contexts it may appear, you can format the <keyword or regex> part with an extra pagerank option `time/3` — or `/time/3` — indicating that the string must occur at least N times in a particular page (here N=3) to be considered significant for the <index entry> under consideration; if used, pagerank may vary from 2 to 9. | |
| • Use regex to cover common morphological variations — always prefer singular forms for the final index entries unless plurals carry distinct meaning. | |
| • Avoid separate entries for synonymous or conceptually identical terms. | |
| • Create hierarchical, logical, and consistent parent topics only when they cluster multiple related terms meaningfully. | |
| • Merge parent topics with semantic overlap to avoid redundancy. | |
| • Index entries should reflect user needs and mental models, not just literal text occurrences (although literal text occurrences are the only key strings we can target) | |
| • Treat terms as clues to underlying concepts, using domain knowledge to elevate surface terms to richer entries. | |
| • Ensure each entry is defensible, intuitive, and balances specificity with usability (avoid over-granularity). | |
| • Final index should be consistent, intuitive, and help users find relevant content effectively. | |
| OUTPUT FORMAT | |
| Present the final query list as a code block with one entry per line, organized logically. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment