Skip to content

Instantly share code, notes, and snippets.

Show Gist options
  • Select an option

  • Save indiscripts/f86d108af916e66428fdc22fc3b0ffbf to your computer and use it in GitHub Desktop.

Select an option

Save indiscripts/f86d108af916e66428fdc22fc3b0ffbf to your computer and use it in GitHub Desktop.
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