PowerOn/gateway
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

deleted unnecessary prompts

Browse source
This commit is contained in:
idittrich-valueon 2026-03-22 18:21:08 +01:00
parent f808d63c25
commit e1ed0ee63c
27 changed files with 0 additions and 1492 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

119
prompts/20260322-165228-001-chapter_structure_generation_prompt.txt
View file

@ -1,119 +0,0 @@
# TASK: Plan Document Structure (Documents + Chapters)
This is a STRUCTURE PLANNING task. You define which documents to create and which chapters each document will have.
Chapter CONTENT will be generated in a later step - here you only plan the STRUCTURE and assign content references.
Return EXACTLY ONE complete JSON object. Do not generate multiple JSON objects, alternatives, or variations. Do not use separators like "---" between JSON objects.
## USER REQUEST (for context)
```
formulier eine passende email zur eingehenden email
```
## AVAILABLE CONTENT PARTS
(No content parts available)
## CONTENT ASSIGNMENT RULE
CRITICAL: Every chapter MUST have contentParts assigned if it relates to documents/images/data from the user request.
If the user request mentions documents/images/data, then EVERY chapter that generates content related to those references MUST assign the relevant ContentParts explicitly.
Assignment logic:
- If chapter DISPLAYS a document/image → assign "object" format ContentPart with "caption"
- If chapter generates text content ABOUT a document/image/data → assign ContentPart with "instruction":
- Prefer "extracted" format if available (contains analyzed/extracted content)
- If only "object" format is available, use "object" format with "instruction" (to write ABOUT the image/document)
- If chapter's generationHint or purpose relates to a document/image/data mentioned in user request → it MUST have ContentParts assigned
- Multiple chapters might assign the same ContentPart (e.g., one chapter displays image, another writes about it)
- Use ContentPart IDs exactly as listed in AVAILABLE CONTENT PARTS above
- Empty contentParts are only allowed if chapter generates content WITHOUT referencing any documents/images/data from the user request
CRITICAL RULE: If the user request mentions BOTH:
a) Documents/images/data (listed in AVAILABLE CONTENT PARTS above), AND
b) Generic content types (article text, main content, body text, etc.)
Then chapters that generate those generic content types MUST assign the relevant ContentParts, because the content should relate to or be based on the provided documents/images/data.
## CONTENT EFFICIENCY PRINCIPLES
- Generate COMPACT content: Focus on essential information only
- AVOID verbose, lengthy, or repetitive text - be concise and direct
- Prioritize FACTS over filler text - no introductions like "In this chapter..."
- Minimize system resources: shorter content = faster processing
- Quality over quantity: precise, meaningful content rather than padding
## CHAPTER STRUCTURE REQUIREMENTS
- Generate chapters based on USER REQUEST - analyze what structure the user wants
- Create ONLY the minimum chapters needed to cover the user's request - avoid over-structuring
- HARD LIMIT: Maximum 7 chapters per document. If the topic can be covered in fewer, prefer fewer. Combine related topics into single chapters rather than creating many small ones.
- IMPORTANT: Each chapter MUST have ALL these fields:
- id: Unique identifier (e.g., "chapter_1")
- level: Heading level (1, 2, 3, etc.)
- title: Chapter title
- contentParts: Object mapping ContentPart IDs to usage instructions (MUST assign if chapter relates to documents/data from user request)
- generationHint: Description of what content to generate (including formatting/styling requirements)
- sections: Empty array [] (REQUIRED - sections are generated in next phase)
- contentParts: {"partId": {"instruction": "..."} or {"caption": "..."} or both} - Assign ContentParts as required by CONTENT ASSIGNMENT RULE above
- The "instruction" field for each ContentPart MUST contain ALL relevant details from the USER REQUEST that apply to content extraction for this specific chapter. Include all formatting rules, data requirements, constraints, and specifications mentioned in the user request that are relevant for processing this ContentPart in this chapter.
- generationHint: Keep CONCISE but include relevant details from the USER REQUEST. Focus on WHAT to generate, not HOW to phrase it verbosely.
- The number of chapters depends on the user request - create only what is requested. Do NOT create chapters for topics without available data.
CRITICAL: Only create chapters for CONTENT sections, not for formatting/styling requirements. Formatting/styling requirements to be included in each generationHint if needed.
## DOCUMENT STRUCTURE
For each document, determine:
- outputFormat: From USER REQUEST (explicit mention or infer from purpose/content type). Default: "txt". Multiple documents can have different formats.
- language: From USER REQUEST (map to ISO 639-1: de, en, fr, it...). Default: "de". Multiple documents can have different languages.
- chapters: Structure appropriately for the format (e.g., pptx=slides, docx=sections, xlsx=worksheets). Match format capabilities and constraints.
Required JSON fields:
- metadata: {"title": "...", "language": "..."}
- documents: Array with id, title, filename, outputFormat, language, chapters[]
- chapters: Array with id, level, title, contentParts, generationHint, sections[]
EXAMPLE STRUCTURE (for reference only - adapt to user request):
{
"metadata": {
"title": "Document Title",
"language": "de"
},
"documents": [{
"id": "doc_1",
"title": "Document Title",
"filename": "document.txt",
"outputFormat": "txt",
"language": "de",
"chapters": [
{
"id": "chapter_1",
"level": 1,
"title": "Chapter Title",
"contentParts": {
"extracted_part_id": {
"instruction": "Use extracted content with ALL relevant details from user request"
}
},
"generationHint": "Detailed description including ALL relevant details from user request for this chapter",
"sections": []
}
]
}]
}
CRITICAL INSTRUCTIONS:
- Generate chapters based on USER REQUEST, NOT based on the example above
- The example shows the JSON structure format, NOT the required chapters
- Create only the chapters that match the user's request
- Adapt chapter titles and structure to match the user's specific request
- Determine outputFormat and language for each document by analyzing the USER REQUEST above
- The example shows placeholders "txt" and "de" - YOU MUST REPLACE THESE with actual values determined from the USER REQUEST
MANDATORY CONTENT ASSIGNMENT CHECK:
For each chapter, verify:
1. Does the user request mention documents/images/data? (e.g., "photo", "image", "document", "data", "based on", "about")
2. Does this chapter's generationHint, title, or purpose relate to those documents/images/data mentioned in step 1?
- Examples: "article about the photo", "text describing the image", "analysis of the document", "content based on the data"
- Even if chapter doesn't explicitly say "about the image", if user request mentions both the image AND this chapter's content type → relate them
3. If YES to both → chapter MUST have contentParts assigned (cannot be empty {})
4. If ContentPart is "object" format and chapter needs to write ABOUT it → assign with "instruction" field, not just "caption"
OUTPUT FORMAT: Start with { and end with }. Do NOT use markdown code fences (```json). Do NOT add explanatory text before or after the JSON. Return ONLY the JSON object itself.

41
prompts/20260322-165232-002-chapter_structure_generation_response.txt
View file

@ -1,41 +0,0 @@
{
"metadata": {
"title": "Email Response",
"language": "de"
},
"documents": [
{
"id": "doc_1",
"title": "Email Response",
"filename": "email_response.txt",
"outputFormat": "txt",
"language": "de",
"chapters": [
{
"id": "chapter_1",
"level": 1,
"title": "Introduction",
"contentParts": {},
"generationHint": "Write an introductory paragraph for the email response, setting the tone and context.",
"sections": []
},
{
"id": "chapter_2",
"level": 1,
"title": "Main Content",
"contentParts": {},
"generationHint": "Develop the main body of the email, addressing the points raised in the incoming email.",
"sections": []
},
{
"id": "chapter_3",
"level": 1,
"title": "Conclusion",
"contentParts": {},
"generationHint": "Conclude the email with a polite closing statement and any necessary follow-up actions.",
"sections": []
}
]
}
]
}

41
prompts/20260322-165232-003-chapter_structure_generation_final_result.txt
View file

@ -1,41 +0,0 @@
{
"metadata": {
"title": "Email Response",
"language": "de"
},
"documents": [
{
"id": "doc_1",
"title": "Email Response",
"filename": "email_response.txt",
"outputFormat": "txt",
"language": "de",
"chapters": [
{
"id": "chapter_1",
"level": 1,
"title": "Introduction",
"contentParts": {},
"generationHint": "Write an introductory paragraph for the email response, setting the tone and context.",
"sections": []
},
{
"id": "chapter_2",
"level": 1,
"title": "Main Content",
"contentParts": {},
"generationHint": "Develop the main body of the email, addressing the points raised in the incoming email.",
"sections": []
},
{
"id": "chapter_3",
"level": 1,
"title": "Conclusion",
"contentParts": {},
"generationHint": "Conclude the email with a polite closing statement and any necessary follow-up actions.",
"sections": []
}
]
}
]
}

119
prompts/20260322-165824-004-chapter_structure_generation_prompt.txt
View file

@ -1,119 +0,0 @@
# TASK: Plan Document Structure (Documents + Chapters)
This is a STRUCTURE PLANNING task. You define which documents to create and which chapters each document will have.
Chapter CONTENT will be generated in a later step - here you only plan the STRUCTURE and assign content references.
Return EXACTLY ONE complete JSON object. Do not generate multiple JSON objects, alternatives, or variations. Do not use separators like "---" between JSON objects.
## USER REQUEST (for context)
```
formulier eine passende email zur eingehenden email
```
## AVAILABLE CONTENT PARTS
(No content parts available)
## CONTENT ASSIGNMENT RULE
CRITICAL: Every chapter MUST have contentParts assigned if it relates to documents/images/data from the user request.
If the user request mentions documents/images/data, then EVERY chapter that generates content related to those references MUST assign the relevant ContentParts explicitly.
Assignment logic:
- If chapter DISPLAYS a document/image → assign "object" format ContentPart with "caption"
- If chapter generates text content ABOUT a document/image/data → assign ContentPart with "instruction":
- Prefer "extracted" format if available (contains analyzed/extracted content)
- If only "object" format is available, use "object" format with "instruction" (to write ABOUT the image/document)
- If chapter's generationHint or purpose relates to a document/image/data mentioned in user request → it MUST have ContentParts assigned
- Multiple chapters might assign the same ContentPart (e.g., one chapter displays image, another writes about it)
- Use ContentPart IDs exactly as listed in AVAILABLE CONTENT PARTS above
- Empty contentParts are only allowed if chapter generates content WITHOUT referencing any documents/images/data from the user request
CRITICAL RULE: If the user request mentions BOTH:
a) Documents/images/data (listed in AVAILABLE CONTENT PARTS above), AND
b) Generic content types (article text, main content, body text, etc.)
Then chapters that generate those generic content types MUST assign the relevant ContentParts, because the content should relate to or be based on the provided documents/images/data.
## CONTENT EFFICIENCY PRINCIPLES
- Generate COMPACT content: Focus on essential information only
- AVOID verbose, lengthy, or repetitive text - be concise and direct
- Prioritize FACTS over filler text - no introductions like "In this chapter..."
- Minimize system resources: shorter content = faster processing
- Quality over quantity: precise, meaningful content rather than padding
## CHAPTER STRUCTURE REQUIREMENTS
- Generate chapters based on USER REQUEST - analyze what structure the user wants
- Create ONLY the minimum chapters needed to cover the user's request - avoid over-structuring
- HARD LIMIT: Maximum 7 chapters per document. If the topic can be covered in fewer, prefer fewer. Combine related topics into single chapters rather than creating many small ones.
- IMPORTANT: Each chapter MUST have ALL these fields:
- id: Unique identifier (e.g., "chapter_1")
- level: Heading level (1, 2, 3, etc.)
- title: Chapter title
- contentParts: Object mapping ContentPart IDs to usage instructions (MUST assign if chapter relates to documents/data from user request)
- generationHint: Description of what content to generate (including formatting/styling requirements)
- sections: Empty array [] (REQUIRED - sections are generated in next phase)
- contentParts: {"partId": {"instruction": "..."} or {"caption": "..."} or both} - Assign ContentParts as required by CONTENT ASSIGNMENT RULE above
- The "instruction" field for each ContentPart MUST contain ALL relevant details from the USER REQUEST that apply to content extraction for this specific chapter. Include all formatting rules, data requirements, constraints, and specifications mentioned in the user request that are relevant for processing this ContentPart in this chapter.
- generationHint: Keep CONCISE but include relevant details from the USER REQUEST. Focus on WHAT to generate, not HOW to phrase it verbosely.
- The number of chapters depends on the user request - create only what is requested. Do NOT create chapters for topics without available data.
CRITICAL: Only create chapters for CONTENT sections, not for formatting/styling requirements. Formatting/styling requirements to be included in each generationHint if needed.
## DOCUMENT STRUCTURE
For each document, determine:
- outputFormat: From USER REQUEST (explicit mention or infer from purpose/content type). Default: "txt". Multiple documents can have different formats.
- language: From USER REQUEST (map to ISO 639-1: de, en, fr, it...). Default: "de". Multiple documents can have different languages.
- chapters: Structure appropriately for the format (e.g., pptx=slides, docx=sections, xlsx=worksheets). Match format capabilities and constraints.
Required JSON fields:
- metadata: {"title": "...", "language": "..."}
- documents: Array with id, title, filename, outputFormat, language, chapters[]
- chapters: Array with id, level, title, contentParts, generationHint, sections[]
EXAMPLE STRUCTURE (for reference only - adapt to user request):
{
"metadata": {
"title": "Document Title",
"language": "de"
},
"documents": [{
"id": "doc_1",
"title": "Document Title",
"filename": "document.txt",
"outputFormat": "txt",
"language": "de",
"chapters": [
{
"id": "chapter_1",
"level": 1,
"title": "Chapter Title",
"contentParts": {
"extracted_part_id": {
"instruction": "Use extracted content with ALL relevant details from user request"
}
},
"generationHint": "Detailed description including ALL relevant details from user request for this chapter",
"sections": []
}
]
}]
}
CRITICAL INSTRUCTIONS:
- Generate chapters based on USER REQUEST, NOT based on the example above
- The example shows the JSON structure format, NOT the required chapters
- Create only the chapters that match the user's request
- Adapt chapter titles and structure to match the user's specific request
- Determine outputFormat and language for each document by analyzing the USER REQUEST above
- The example shows placeholders "txt" and "de" - YOU MUST REPLACE THESE with actual values determined from the USER REQUEST
MANDATORY CONTENT ASSIGNMENT CHECK:
For each chapter, verify:
1. Does the user request mention documents/images/data? (e.g., "photo", "image", "document", "data", "based on", "about")
2. Does this chapter's generationHint, title, or purpose relate to those documents/images/data mentioned in step 1?
- Examples: "article about the photo", "text describing the image", "analysis of the document", "content based on the data"
- Even if chapter doesn't explicitly say "about the image", if user request mentions both the image AND this chapter's content type → relate them
3. If YES to both → chapter MUST have contentParts assigned (cannot be empty {})
4. If ContentPart is "object" format and chapter needs to write ABOUT it → assign with "instruction" field, not just "caption"
OUTPUT FORMAT: Start with { and end with }. Do NOT use markdown code fences (```json). Do NOT add explanatory text before or after the JSON. Return ONLY the JSON object itself.

39
prompts/20260322-165827-005-chapter_structure_generation_response.txt
View file

@ -1,39 +0,0 @@
{
"metadata": {
"title": "Email Response",
"language": "de"
},
"documents": [{
"id": "doc_1",
"title": "Email Response",
"filename": "email_response.txt",
"outputFormat": "txt",
"language": "de",
"chapters": [
{
"id": "chapter_1",
"level": 1,
"title": "Introduction",
"contentParts": {},
"generationHint": "Generate a brief introduction for the email response.",
"sections": []
},
{
"id": "chapter_2",
"level": 1,
"title": "Main Content",
"contentParts": {},
"generationHint": "Generate the main body of the email response, addressing the points mentioned in the incoming email.",
"sections": []
},
{
"id": "chapter_3",
"level": 1,
"title": "Conclusion",
"contentParts": {},
"generationHint": "Generate a concise conclusion for the email response.",
"sections": []
}
]
}]
}

41
prompts/20260322-165827-006-chapter_structure_generation_final_result.txt
View file

@ -1,41 +0,0 @@
{
"metadata": {
"title": "Email Response",
"language": "de"
},
"documents": [
{
"id": "doc_1",
"title": "Email Response",
"filename": "email_response.txt",
"outputFormat": "txt",
"language": "de",
"chapters": [
{
"id": "chapter_1",
"level": 1,
"title": "Introduction",
"contentParts": {},
"generationHint": "Generate a brief introduction for the email response.",
"sections": []
},
{
"id": "chapter_2",
"level": 1,
"title": "Main Content",
"contentParts": {},
"generationHint": "Generate the main body of the email response, addressing the points mentioned in the incoming email.",
"sections": []
},
{
"id": "chapter_3",
"level": 1,
"title": "Conclusion",
"contentParts": {},
"generationHint": "Generate a concise conclusion for the email response.",
"sections": []
}
]
}
]
}

22
prompts/20260322-165827-007-email_composition_prompt.txt
View file

@ -1,22 +0,0 @@
Compose an email based on this context:
-------
Reply to the following email(s):\n\nFrom: ida-dittrich@proton.me\nSubject: test\nContent:\nYou don't often get email from ida-dittrich@proton.me. Learn why this is important\r\n\r\n\r\ndies ist eine testmail.\r\n\r\n\r\nSent from Proton Mail for iOS.
-------
Recipients: (not specified - this is a draft)
Style: business
Max length: 1000 characters
Available_Document_References:
- (no documents)
Based on the context, decide which documents to attach.
CRITICAL: Use EXACT document references from Available_Document_References above. For individual documents: ALWAYS use docItem:<documentId>:<filename> format (include filename)
Return JSON:
{
"subject": "subject line",
"body": "email body (HTML allowed)",
"attachments": ["docItem:<documentId>:<filename>"]
}

7
prompts/20260322-165829-008-email_composition_response.txt
View file

@ -1,7 +0,0 @@
```json
{
"subject": "Re: Test",
"body": "Sehr geehrte Frau Dittrich,<br><br>vielen Dank für Ihre Testmail. Bitte lassen Sie mich wissen, wenn es noch etwas gibt, bei dem ich Ihnen behilflich sein kann.<br><br>Mit freundlichen Grüßen,<br>[Ihr Name]",
"attachments": []
}
```

119
prompts/20260322-170224-009-chapter_structure_generation_prompt.txt
View file

@ -1,119 +0,0 @@
# TASK: Plan Document Structure (Documents + Chapters)
This is a STRUCTURE PLANNING task. You define which documents to create and which chapters each document will have.
Chapter CONTENT will be generated in a later step - here you only plan the STRUCTURE and assign content references.
Return EXACTLY ONE complete JSON object. Do not generate multiple JSON objects, alternatives, or variations. Do not use separators like "---" between JSON objects.
## USER REQUEST (for context)
```
formulier eine passende email zur eingehenden email
```
## AVAILABLE CONTENT PARTS
(No content parts available)
## CONTENT ASSIGNMENT RULE
CRITICAL: Every chapter MUST have contentParts assigned if it relates to documents/images/data from the user request.
If the user request mentions documents/images/data, then EVERY chapter that generates content related to those references MUST assign the relevant ContentParts explicitly.
Assignment logic:
- If chapter DISPLAYS a document/image → assign "object" format ContentPart with "caption"
- If chapter generates text content ABOUT a document/image/data → assign ContentPart with "instruction":
- Prefer "extracted" format if available (contains analyzed/extracted content)
- If only "object" format is available, use "object" format with "instruction" (to write ABOUT the image/document)
- If chapter's generationHint or purpose relates to a document/image/data mentioned in user request → it MUST have ContentParts assigned
- Multiple chapters might assign the same ContentPart (e.g., one chapter displays image, another writes about it)
- Use ContentPart IDs exactly as listed in AVAILABLE CONTENT PARTS above
- Empty contentParts are only allowed if chapter generates content WITHOUT referencing any documents/images/data from the user request
CRITICAL RULE: If the user request mentions BOTH:
a) Documents/images/data (listed in AVAILABLE CONTENT PARTS above), AND
b) Generic content types (article text, main content, body text, etc.)
Then chapters that generate those generic content types MUST assign the relevant ContentParts, because the content should relate to or be based on the provided documents/images/data.
## CONTENT EFFICIENCY PRINCIPLES
- Generate COMPACT content: Focus on essential information only
- AVOID verbose, lengthy, or repetitive text - be concise and direct
- Prioritize FACTS over filler text - no introductions like "In this chapter..."
- Minimize system resources: shorter content = faster processing
- Quality over quantity: precise, meaningful content rather than padding
## CHAPTER STRUCTURE REQUIREMENTS
- Generate chapters based on USER REQUEST - analyze what structure the user wants
- Create ONLY the minimum chapters needed to cover the user's request - avoid over-structuring
- HARD LIMIT: Maximum 7 chapters per document. If the topic can be covered in fewer, prefer fewer. Combine related topics into single chapters rather than creating many small ones.
- IMPORTANT: Each chapter MUST have ALL these fields:
- id: Unique identifier (e.g., "chapter_1")
- level: Heading level (1, 2, 3, etc.)
- title: Chapter title
- contentParts: Object mapping ContentPart IDs to usage instructions (MUST assign if chapter relates to documents/data from user request)
- generationHint: Description of what content to generate (including formatting/styling requirements)
- sections: Empty array [] (REQUIRED - sections are generated in next phase)
- contentParts: {"partId": {"instruction": "..."} or {"caption": "..."} or both} - Assign ContentParts as required by CONTENT ASSIGNMENT RULE above
- The "instruction" field for each ContentPart MUST contain ALL relevant details from the USER REQUEST that apply to content extraction for this specific chapter. Include all formatting rules, data requirements, constraints, and specifications mentioned in the user request that are relevant for processing this ContentPart in this chapter.
- generationHint: Keep CONCISE but include relevant details from the USER REQUEST. Focus on WHAT to generate, not HOW to phrase it verbosely.
- The number of chapters depends on the user request - create only what is requested. Do NOT create chapters for topics without available data.
CRITICAL: Only create chapters for CONTENT sections, not for formatting/styling requirements. Formatting/styling requirements to be included in each generationHint if needed.
## DOCUMENT STRUCTURE
For each document, determine:
- outputFormat: From USER REQUEST (explicit mention or infer from purpose/content type). Default: "txt". Multiple documents can have different formats.
- language: From USER REQUEST (map to ISO 639-1: de, en, fr, it...). Default: "de". Multiple documents can have different languages.
- chapters: Structure appropriately for the format (e.g., pptx=slides, docx=sections, xlsx=worksheets). Match format capabilities and constraints.
Required JSON fields:
- metadata: {"title": "...", "language": "..."}
- documents: Array with id, title, filename, outputFormat, language, chapters[]
- chapters: Array with id, level, title, contentParts, generationHint, sections[]
EXAMPLE STRUCTURE (for reference only - adapt to user request):
{
"metadata": {
"title": "Document Title",
"language": "de"
},
"documents": [{
"id": "doc_1",
"title": "Document Title",
"filename": "document.txt",
"outputFormat": "txt",
"language": "de",
"chapters": [
{
"id": "chapter_1",
"level": 1,
"title": "Chapter Title",
"contentParts": {
"extracted_part_id": {
"instruction": "Use extracted content with ALL relevant details from user request"
}
},
"generationHint": "Detailed description including ALL relevant details from user request for this chapter",
"sections": []
}
]
}]
}
CRITICAL INSTRUCTIONS:
- Generate chapters based on USER REQUEST, NOT based on the example above
- The example shows the JSON structure format, NOT the required chapters
- Create only the chapters that match the user's request
- Adapt chapter titles and structure to match the user's specific request
- Determine outputFormat and language for each document by analyzing the USER REQUEST above
- The example shows placeholders "txt" and "de" - YOU MUST REPLACE THESE with actual values determined from the USER REQUEST
MANDATORY CONTENT ASSIGNMENT CHECK:
For each chapter, verify:
1. Does the user request mention documents/images/data? (e.g., "photo", "image", "document", "data", "based on", "about")
2. Does this chapter's generationHint, title, or purpose relate to those documents/images/data mentioned in step 1?
- Examples: "article about the photo", "text describing the image", "analysis of the document", "content based on the data"
- Even if chapter doesn't explicitly say "about the image", if user request mentions both the image AND this chapter's content type → relate them
3. If YES to both → chapter MUST have contentParts assigned (cannot be empty {})
4. If ContentPart is "object" format and chapter needs to write ABOUT it → assign with "instruction" field, not just "caption"
OUTPUT FORMAT: Start with { and end with }. Do NOT use markdown code fences (```json). Do NOT add explanatory text before or after the JSON. Return ONLY the JSON object itself.

41
prompts/20260322-170228-010-chapter_structure_generation_response.txt
View file

@ -1,41 +0,0 @@
{
"metadata": {
"title": "Email Response",
"language": "de"
},
"documents": [
{
"id": "doc_1",
"title": "Email Response",
"filename": "email_response.txt",
"outputFormat": "txt",
"language": "de",
"chapters": [
{
"id": "chapter_1",
"level": 1,
"title": "Einleitung",
"contentParts": {},
"generationHint": "Generate an introductory paragraph for the email response, setting the tone and context.",
"sections": []
},
{
"id": "chapter_2",
"level": 1,
"title": "Hauptteil",
"contentParts": {},
"generationHint": "Develop the main body of the email, addressing the key points from the incoming email and providing necessary information or responses.",
"sections": []
},
{
"id": "chapter_3",
"level": 1,
"title": "Schluss",
"contentParts": {},
"generationHint": "Conclude the email with a closing statement, including any follow-up actions or expressions of gratitude.",
"sections": []
}
]
}
]
}

41
prompts/20260322-170228-011-chapter_structure_generation_final_result.txt
View file

@ -1,41 +0,0 @@
{
"metadata": {
"title": "Email Response",
"language": "de"
},
"documents": [
{
"id": "doc_1",
"title": "Email Response",
"filename": "email_response.txt",
"outputFormat": "txt",
"language": "de",
"chapters": [
{
"id": "chapter_1",
"level": 1,
"title": "Einleitung",
"contentParts": {},
"generationHint": "Generate an introductory paragraph for the email response, setting the tone and context.",
"sections": []
},
{
"id": "chapter_2",
"level": 1,
"title": "Hauptteil",
"contentParts": {},
"generationHint": "Develop the main body of the email, addressing the key points from the incoming email and providing necessary information or responses.",
"sections": []
},
{
"id": "chapter_3",
"level": 1,
"title": "Schluss",
"contentParts": {},
"generationHint": "Conclude the email with a closing statement, including any follow-up actions or expressions of gratitude.",
"sections": []
}
]
}
]
}

119
prompts/20260322-171026-012-chapter_structure_generation_prompt.txt
View file

@ -1,119 +0,0 @@
# TASK: Plan Document Structure (Documents + Chapters)
This is a STRUCTURE PLANNING task. You define which documents to create and which chapters each document will have.
Chapter CONTENT will be generated in a later step - here you only plan the STRUCTURE and assign content references.
Return EXACTLY ONE complete JSON object. Do not generate multiple JSON objects, alternatives, or variations. Do not use separators like "---" between JSON objects.
## USER REQUEST (for context)
```
formulier eine passende email zur eingehenden email
```
## AVAILABLE CONTENT PARTS
(No content parts available)
## CONTENT ASSIGNMENT RULE
CRITICAL: Every chapter MUST have contentParts assigned if it relates to documents/images/data from the user request.
If the user request mentions documents/images/data, then EVERY chapter that generates content related to those references MUST assign the relevant ContentParts explicitly.
Assignment logic:
- If chapter DISPLAYS a document/image → assign "object" format ContentPart with "caption"
- If chapter generates text content ABOUT a document/image/data → assign ContentPart with "instruction":
- Prefer "extracted" format if available (contains analyzed/extracted content)
- If only "object" format is available, use "object" format with "instruction" (to write ABOUT the image/document)
- If chapter's generationHint or purpose relates to a document/image/data mentioned in user request → it MUST have ContentParts assigned
- Multiple chapters might assign the same ContentPart (e.g., one chapter displays image, another writes about it)
- Use ContentPart IDs exactly as listed in AVAILABLE CONTENT PARTS above
- Empty contentParts are only allowed if chapter generates content WITHOUT referencing any documents/images/data from the user request
CRITICAL RULE: If the user request mentions BOTH:
a) Documents/images/data (listed in AVAILABLE CONTENT PARTS above), AND
b) Generic content types (article text, main content, body text, etc.)
Then chapters that generate those generic content types MUST assign the relevant ContentParts, because the content should relate to or be based on the provided documents/images/data.
## CONTENT EFFICIENCY PRINCIPLES
- Generate COMPACT content: Focus on essential information only
- AVOID verbose, lengthy, or repetitive text - be concise and direct
- Prioritize FACTS over filler text - no introductions like "In this chapter..."
- Minimize system resources: shorter content = faster processing
- Quality over quantity: precise, meaningful content rather than padding
## CHAPTER STRUCTURE REQUIREMENTS
- Generate chapters based on USER REQUEST - analyze what structure the user wants
- Create ONLY the minimum chapters needed to cover the user's request - avoid over-structuring
- HARD LIMIT: Maximum 7 chapters per document. If the topic can be covered in fewer, prefer fewer. Combine related topics into single chapters rather than creating many small ones.
- IMPORTANT: Each chapter MUST have ALL these fields:
- id: Unique identifier (e.g., "chapter_1")
- level: Heading level (1, 2, 3, etc.)
- title: Chapter title
- contentParts: Object mapping ContentPart IDs to usage instructions (MUST assign if chapter relates to documents/data from user request)
- generationHint: Description of what content to generate (including formatting/styling requirements)
- sections: Empty array [] (REQUIRED - sections are generated in next phase)
- contentParts: {"partId": {"instruction": "..."} or {"caption": "..."} or both} - Assign ContentParts as required by CONTENT ASSIGNMENT RULE above
- The "instruction" field for each ContentPart MUST contain ALL relevant details from the USER REQUEST that apply to content extraction for this specific chapter. Include all formatting rules, data requirements, constraints, and specifications mentioned in the user request that are relevant for processing this ContentPart in this chapter.
- generationHint: Keep CONCISE but include relevant details from the USER REQUEST. Focus on WHAT to generate, not HOW to phrase it verbosely.
- The number of chapters depends on the user request - create only what is requested. Do NOT create chapters for topics without available data.
CRITICAL: Only create chapters for CONTENT sections, not for formatting/styling requirements. Formatting/styling requirements to be included in each generationHint if needed.
## DOCUMENT STRUCTURE
For each document, determine:
- outputFormat: From USER REQUEST (explicit mention or infer from purpose/content type). Default: "txt". Multiple documents can have different formats.
- language: From USER REQUEST (map to ISO 639-1: de, en, fr, it...). Default: "de". Multiple documents can have different languages.
- chapters: Structure appropriately for the format (e.g., pptx=slides, docx=sections, xlsx=worksheets). Match format capabilities and constraints.
Required JSON fields:
- metadata: {"title": "...", "language": "..."}
- documents: Array with id, title, filename, outputFormat, language, chapters[]
- chapters: Array with id, level, title, contentParts, generationHint, sections[]
EXAMPLE STRUCTURE (for reference only - adapt to user request):
{
"metadata": {
"title": "Document Title",
"language": "de"
},
"documents": [{
"id": "doc_1",
"title": "Document Title",
"filename": "document.txt",
"outputFormat": "txt",
"language": "de",
"chapters": [
{
"id": "chapter_1",
"level": 1,
"title": "Chapter Title",
"contentParts": {
"extracted_part_id": {
"instruction": "Use extracted content with ALL relevant details from user request"
}
},
"generationHint": "Detailed description including ALL relevant details from user request for this chapter",
"sections": []
}
]
}]
}
CRITICAL INSTRUCTIONS:
- Generate chapters based on USER REQUEST, NOT based on the example above
- The example shows the JSON structure format, NOT the required chapters
- Create only the chapters that match the user's request
- Adapt chapter titles and structure to match the user's specific request
- Determine outputFormat and language for each document by analyzing the USER REQUEST above
- The example shows placeholders "txt" and "de" - YOU MUST REPLACE THESE with actual values determined from the USER REQUEST
MANDATORY CONTENT ASSIGNMENT CHECK:
For each chapter, verify:
1. Does the user request mention documents/images/data? (e.g., "photo", "image", "document", "data", "based on", "about")
2. Does this chapter's generationHint, title, or purpose relate to those documents/images/data mentioned in step 1?
- Examples: "article about the photo", "text describing the image", "analysis of the document", "content based on the data"
- Even if chapter doesn't explicitly say "about the image", if user request mentions both the image AND this chapter's content type → relate them
3. If YES to both → chapter MUST have contentParts assigned (cannot be empty {})
4. If ContentPart is "object" format and chapter needs to write ABOUT it → assign with "instruction" field, not just "caption"
OUTPUT FORMAT: Start with { and end with }. Do NOT use markdown code fences (```json). Do NOT add explanatory text before or after the JSON. Return ONLY the JSON object itself.

41
prompts/20260322-171030-013-chapter_structure_generation_response.txt
View file

@ -1,41 +0,0 @@
{
"metadata": {
"title": "Email Response",
"language": "de"
},
"documents": [
{
"id": "doc_1",
"title": "Email Response",
"filename": "email_response.txt",
"outputFormat": "txt",
"language": "de",
"chapters": [
{
"id": "chapter_1",
"level": 1,
"title": "Introduction",
"contentParts": {},
"generationHint": "Generate an introductory paragraph for the email response, setting the tone and context.",
"sections": []
},
{
"id": "chapter_2",
"level": 1,
"title": "Main Content",
"contentParts": {},
"generationHint": "Develop the main body of the email, addressing the points mentioned in the incoming email.",
"sections": []
},
{
"id": "chapter_3",
"level": 1,
"title": "Conclusion",
"contentParts": {},
"generationHint": "Conclude the email with a polite closing statement and any necessary follow-up actions.",
"sections": []
}
]
}
]
}

41
prompts/20260322-171030-014-chapter_structure_generation_final_result.txt
View file

@ -1,41 +0,0 @@
{
"metadata": {
"title": "Email Response",
"language": "de"
},
"documents": [
{
"id": "doc_1",
"title": "Email Response",
"filename": "email_response.txt",
"outputFormat": "txt",
"language": "de",
"chapters": [
{
"id": "chapter_1",
"level": 1,
"title": "Introduction",
"contentParts": {},
"generationHint": "Generate an introductory paragraph for the email response, setting the tone and context.",
"sections": []
},
{
"id": "chapter_2",
"level": 1,
"title": "Main Content",
"contentParts": {},
"generationHint": "Develop the main body of the email, addressing the points mentioned in the incoming email.",
"sections": []
},
{
"id": "chapter_3",
"level": 1,
"title": "Conclusion",
"contentParts": {},
"generationHint": "Conclude the email with a polite closing statement and any necessary follow-up actions.",
"sections": []
}
]
}
]
}

119
prompts/20260322-171117-015-chapter_structure_generation_prompt.txt
View file

@ -1,119 +0,0 @@
# TASK: Plan Document Structure (Documents + Chapters)
This is a STRUCTURE PLANNING task. You define which documents to create and which chapters each document will have.
Chapter CONTENT will be generated in a later step - here you only plan the STRUCTURE and assign content references.
Return EXACTLY ONE complete JSON object. Do not generate multiple JSON objects, alternatives, or variations. Do not use separators like "---" between JSON objects.
## USER REQUEST (for context)
```
formulier eine passende email zur eingehenden email
```
## AVAILABLE CONTENT PARTS
(No content parts available)
## CONTENT ASSIGNMENT RULE
CRITICAL: Every chapter MUST have contentParts assigned if it relates to documents/images/data from the user request.
If the user request mentions documents/images/data, then EVERY chapter that generates content related to those references MUST assign the relevant ContentParts explicitly.
Assignment logic:
- If chapter DISPLAYS a document/image → assign "object" format ContentPart with "caption"
- If chapter generates text content ABOUT a document/image/data → assign ContentPart with "instruction":
- Prefer "extracted" format if available (contains analyzed/extracted content)
- If only "object" format is available, use "object" format with "instruction" (to write ABOUT the image/document)
- If chapter's generationHint or purpose relates to a document/image/data mentioned in user request → it MUST have ContentParts assigned
- Multiple chapters might assign the same ContentPart (e.g., one chapter displays image, another writes about it)
- Use ContentPart IDs exactly as listed in AVAILABLE CONTENT PARTS above
- Empty contentParts are only allowed if chapter generates content WITHOUT referencing any documents/images/data from the user request
CRITICAL RULE: If the user request mentions BOTH:
a) Documents/images/data (listed in AVAILABLE CONTENT PARTS above), AND
b) Generic content types (article text, main content, body text, etc.)
Then chapters that generate those generic content types MUST assign the relevant ContentParts, because the content should relate to or be based on the provided documents/images/data.
## CONTENT EFFICIENCY PRINCIPLES
- Generate COMPACT content: Focus on essential information only
- AVOID verbose, lengthy, or repetitive text - be concise and direct
- Prioritize FACTS over filler text - no introductions like "In this chapter..."
- Minimize system resources: shorter content = faster processing
- Quality over quantity: precise, meaningful content rather than padding
## CHAPTER STRUCTURE REQUIREMENTS
- Generate chapters based on USER REQUEST - analyze what structure the user wants
- Create ONLY the minimum chapters needed to cover the user's request - avoid over-structuring
- HARD LIMIT: Maximum 7 chapters per document. If the topic can be covered in fewer, prefer fewer. Combine related topics into single chapters rather than creating many small ones.
- IMPORTANT: Each chapter MUST have ALL these fields:
- id: Unique identifier (e.g., "chapter_1")
- level: Heading level (1, 2, 3, etc.)
- title: Chapter title
- contentParts: Object mapping ContentPart IDs to usage instructions (MUST assign if chapter relates to documents/data from user request)
- generationHint: Description of what content to generate (including formatting/styling requirements)
- sections: Empty array [] (REQUIRED - sections are generated in next phase)
- contentParts: {"partId": {"instruction": "..."} or {"caption": "..."} or both} - Assign ContentParts as required by CONTENT ASSIGNMENT RULE above
- The "instruction" field for each ContentPart MUST contain ALL relevant details from the USER REQUEST that apply to content extraction for this specific chapter. Include all formatting rules, data requirements, constraints, and specifications mentioned in the user request that are relevant for processing this ContentPart in this chapter.
- generationHint: Keep CONCISE but include relevant details from the USER REQUEST. Focus on WHAT to generate, not HOW to phrase it verbosely.
- The number of chapters depends on the user request - create only what is requested. Do NOT create chapters for topics without available data.
CRITICAL: Only create chapters for CONTENT sections, not for formatting/styling requirements. Formatting/styling requirements to be included in each generationHint if needed.
## DOCUMENT STRUCTURE
For each document, determine:
- outputFormat: From USER REQUEST (explicit mention or infer from purpose/content type). Default: "txt". Multiple documents can have different formats.
- language: From USER REQUEST (map to ISO 639-1: de, en, fr, it...). Default: "de". Multiple documents can have different languages.
- chapters: Structure appropriately for the format (e.g., pptx=slides, docx=sections, xlsx=worksheets). Match format capabilities and constraints.
Required JSON fields:
- metadata: {"title": "...", "language": "..."}
- documents: Array with id, title, filename, outputFormat, language, chapters[]
- chapters: Array with id, level, title, contentParts, generationHint, sections[]
EXAMPLE STRUCTURE (for reference only - adapt to user request):
{
"metadata": {
"title": "Document Title",
"language": "de"
},
"documents": [{
"id": "doc_1",
"title": "Document Title",
"filename": "document.txt",
"outputFormat": "txt",
"language": "de",
"chapters": [
{
"id": "chapter_1",
"level": 1,
"title": "Chapter Title",
"contentParts": {
"extracted_part_id": {
"instruction": "Use extracted content with ALL relevant details from user request"
}
},
"generationHint": "Detailed description including ALL relevant details from user request for this chapter",
"sections": []
}
]
}]
}
CRITICAL INSTRUCTIONS:
- Generate chapters based on USER REQUEST, NOT based on the example above
- The example shows the JSON structure format, NOT the required chapters
- Create only the chapters that match the user's request
- Adapt chapter titles and structure to match the user's specific request
- Determine outputFormat and language for each document by analyzing the USER REQUEST above
- The example shows placeholders "txt" and "de" - YOU MUST REPLACE THESE with actual values determined from the USER REQUEST
MANDATORY CONTENT ASSIGNMENT CHECK:
For each chapter, verify:
1. Does the user request mention documents/images/data? (e.g., "photo", "image", "document", "data", "based on", "about")
2. Does this chapter's generationHint, title, or purpose relate to those documents/images/data mentioned in step 1?
- Examples: "article about the photo", "text describing the image", "analysis of the document", "content based on the data"
- Even if chapter doesn't explicitly say "about the image", if user request mentions both the image AND this chapter's content type → relate them
3. If YES to both → chapter MUST have contentParts assigned (cannot be empty {})
4. If ContentPart is "object" format and chapter needs to write ABOUT it → assign with "instruction" field, not just "caption"
OUTPUT FORMAT: Start with { and end with }. Do NOT use markdown code fences (```json). Do NOT add explanatory text before or after the JSON. Return ONLY the JSON object itself.

41
prompts/20260322-171121-016-chapter_structure_generation_response.txt
View file

@ -1,41 +0,0 @@
{
"metadata": {
"title": "Email Response",
"language": "de"
},
"documents": [
{
"id": "doc_1",
"title": "Email Response",
"filename": "email_response.txt",
"outputFormat": "txt",
"language": "de",
"chapters": [
{
"id": "chapter_1",
"level": 1,
"title": "Einleitung",
"contentParts": {},
"generationHint": "Generate an introductory paragraph for the email response, setting the tone and context.",
"sections": []
},
{
"id": "chapter_2",
"level": 1,
"title": "Hauptteil",
"contentParts": {},
"generationHint": "Create the main body of the email, addressing the key points from the incoming email.",
"sections": []
},
{
"id": "chapter_3",
"level": 1,
"title": "Schluss",
"contentParts": {},
"generationHint": "Conclude the email with a closing statement and any necessary follow-up actions.",
"sections": []
}
]
}
]
}

41
prompts/20260322-171121-017-chapter_structure_generation_final_result.txt
View file

@ -1,41 +0,0 @@
{
"metadata": {
"title": "Email Response",
"language": "de"
},
"documents": [
{
"id": "doc_1",
"title": "Email Response",
"filename": "email_response.txt",
"outputFormat": "txt",
"language": "de",
"chapters": [
{
"id": "chapter_1",
"level": 1,
"title": "Einleitung",
"contentParts": {},
"generationHint": "Generate an introductory paragraph for the email response, setting the tone and context.",
"sections": []
},
{
"id": "chapter_2",
"level": 1,
"title": "Hauptteil",
"contentParts": {},
"generationHint": "Create the main body of the email, addressing the key points from the incoming email.",
"sections": []
},
{
"id": "chapter_3",
"level": 1,
"title": "Schluss",
"contentParts": {},
"generationHint": "Conclude the email with a closing statement and any necessary follow-up actions.",
"sections": []
}
]
}
]
}

119
prompts/20260322-171530-018-chapter_structure_generation_prompt.txt
View file

@ -1,119 +0,0 @@
# TASK: Plan Document Structure (Documents + Chapters)
This is a STRUCTURE PLANNING task. You define which documents to create and which chapters each document will have.
Chapter CONTENT will be generated in a later step - here you only plan the STRUCTURE and assign content references.
Return EXACTLY ONE complete JSON object. Do not generate multiple JSON objects, alternatives, or variations. Do not use separators like "---" between JSON objects.
## USER REQUEST (for context)
```
formulier eine passende email zur eingehenden email
```
## AVAILABLE CONTENT PARTS
(No content parts available)
## CONTENT ASSIGNMENT RULE
CRITICAL: Every chapter MUST have contentParts assigned if it relates to documents/images/data from the user request.
If the user request mentions documents/images/data, then EVERY chapter that generates content related to those references MUST assign the relevant ContentParts explicitly.
Assignment logic:
- If chapter DISPLAYS a document/image → assign "object" format ContentPart with "caption"
- If chapter generates text content ABOUT a document/image/data → assign ContentPart with "instruction":
- Prefer "extracted" format if available (contains analyzed/extracted content)
- If only "object" format is available, use "object" format with "instruction" (to write ABOUT the image/document)
- If chapter's generationHint or purpose relates to a document/image/data mentioned in user request → it MUST have ContentParts assigned
- Multiple chapters might assign the same ContentPart (e.g., one chapter displays image, another writes about it)
- Use ContentPart IDs exactly as listed in AVAILABLE CONTENT PARTS above
- Empty contentParts are only allowed if chapter generates content WITHOUT referencing any documents/images/data from the user request
CRITICAL RULE: If the user request mentions BOTH:
a) Documents/images/data (listed in AVAILABLE CONTENT PARTS above), AND
b) Generic content types (article text, main content, body text, etc.)
Then chapters that generate those generic content types MUST assign the relevant ContentParts, because the content should relate to or be based on the provided documents/images/data.
## CONTENT EFFICIENCY PRINCIPLES
- Generate COMPACT content: Focus on essential information only
- AVOID verbose, lengthy, or repetitive text - be concise and direct
- Prioritize FACTS over filler text - no introductions like "In this chapter..."
- Minimize system resources: shorter content = faster processing
- Quality over quantity: precise, meaningful content rather than padding
## CHAPTER STRUCTURE REQUIREMENTS
- Generate chapters based on USER REQUEST - analyze what structure the user wants
- Create ONLY the minimum chapters needed to cover the user's request - avoid over-structuring
- HARD LIMIT: Maximum 7 chapters per document. If the topic can be covered in fewer, prefer fewer. Combine related topics into single chapters rather than creating many small ones.
- IMPORTANT: Each chapter MUST have ALL these fields:
- id: Unique identifier (e.g., "chapter_1")
- level: Heading level (1, 2, 3, etc.)
- title: Chapter title
- contentParts: Object mapping ContentPart IDs to usage instructions (MUST assign if chapter relates to documents/data from user request)
- generationHint: Description of what content to generate (including formatting/styling requirements)
- sections: Empty array [] (REQUIRED - sections are generated in next phase)
- contentParts: {"partId": {"instruction": "..."} or {"caption": "..."} or both} - Assign ContentParts as required by CONTENT ASSIGNMENT RULE above
- The "instruction" field for each ContentPart MUST contain ALL relevant details from the USER REQUEST that apply to content extraction for this specific chapter. Include all formatting rules, data requirements, constraints, and specifications mentioned in the user request that are relevant for processing this ContentPart in this chapter.
- generationHint: Keep CONCISE but include relevant details from the USER REQUEST. Focus on WHAT to generate, not HOW to phrase it verbosely.
- The number of chapters depends on the user request - create only what is requested. Do NOT create chapters for topics without available data.
CRITICAL: Only create chapters for CONTENT sections, not for formatting/styling requirements. Formatting/styling requirements to be included in each generationHint if needed.
## DOCUMENT STRUCTURE
For each document, determine:
- outputFormat: From USER REQUEST (explicit mention or infer from purpose/content type). Default: "txt". Multiple documents can have different formats.
- language: From USER REQUEST (map to ISO 639-1: de, en, fr, it...). Default: "de". Multiple documents can have different languages.
- chapters: Structure appropriately for the format (e.g., pptx=slides, docx=sections, xlsx=worksheets). Match format capabilities and constraints.
Required JSON fields:
- metadata: {"title": "...", "language": "..."}
- documents: Array with id, title, filename, outputFormat, language, chapters[]
- chapters: Array with id, level, title, contentParts, generationHint, sections[]
EXAMPLE STRUCTURE (for reference only - adapt to user request):
{
"metadata": {
"title": "Document Title",
"language": "de"
},
"documents": [{
"id": "doc_1",
"title": "Document Title",
"filename": "document.txt",
"outputFormat": "txt",
"language": "de",
"chapters": [
{
"id": "chapter_1",
"level": 1,
"title": "Chapter Title",
"contentParts": {
"extracted_part_id": {
"instruction": "Use extracted content with ALL relevant details from user request"
}
},
"generationHint": "Detailed description including ALL relevant details from user request for this chapter",
"sections": []
}
]
}]
}
CRITICAL INSTRUCTIONS:
- Generate chapters based on USER REQUEST, NOT based on the example above
- The example shows the JSON structure format, NOT the required chapters
- Create only the chapters that match the user's request
- Adapt chapter titles and structure to match the user's specific request
- Determine outputFormat and language for each document by analyzing the USER REQUEST above
- The example shows placeholders "txt" and "de" - YOU MUST REPLACE THESE with actual values determined from the USER REQUEST
MANDATORY CONTENT ASSIGNMENT CHECK:
For each chapter, verify:
1. Does the user request mention documents/images/data? (e.g., "photo", "image", "document", "data", "based on", "about")
2. Does this chapter's generationHint, title, or purpose relate to those documents/images/data mentioned in step 1?
- Examples: "article about the photo", "text describing the image", "analysis of the document", "content based on the data"
- Even if chapter doesn't explicitly say "about the image", if user request mentions both the image AND this chapter's content type → relate them
3. If YES to both → chapter MUST have contentParts assigned (cannot be empty {})
4. If ContentPart is "object" format and chapter needs to write ABOUT it → assign with "instruction" field, not just "caption"
OUTPUT FORMAT: Start with { and end with }. Do NOT use markdown code fences (```json). Do NOT add explanatory text before or after the JSON. Return ONLY the JSON object itself.

41
prompts/20260322-171533-019-chapter_structure_generation_response.txt
View file

@ -1,41 +0,0 @@
{
"metadata": {
"title": "Email Response Plan",
"language": "de"
},
"documents": [
{
"id": "doc_1",
"title": "Email Response",
"filename": "email_response.txt",
"outputFormat": "txt",
"language": "de",
"chapters": [
{
"id": "chapter_1",
"level": 1,
"title": "Einleitung",
"contentParts": {},
"generationHint": "Formulate an introductory paragraph for the email response, setting the context for the reply.",
"sections": []
},
{
"id": "chapter_2",
"level": 1,
"title": "Hauptteil",
"contentParts": {},
"generationHint": "Develop the main body of the email response, addressing the key points from the incoming email.",
"sections": []
},
{
"id": "chapter_3",
"level": 1,
"title": "Schlussfolgerung",
"contentParts": {},
"generationHint": "Conclude the email with a summary or closing remarks, ensuring a polite and professional tone.",
"sections": []
}
]
}
]
}

41
prompts/20260322-171533-020-chapter_structure_generation_final_result.txt
View file

@ -1,41 +0,0 @@
{
"metadata": {
"title": "Email Response Plan",
"language": "de"
},
"documents": [
{
"id": "doc_1",
"title": "Email Response",
"filename": "email_response.txt",
"outputFormat": "txt",
"language": "de",
"chapters": [
{
"id": "chapter_1",
"level": 1,
"title": "Einleitung",
"contentParts": {},
"generationHint": "Formulate an introductory paragraph for the email response, setting the context for the reply.",
"sections": []
},
{
"id": "chapter_2",
"level": 1,
"title": "Hauptteil",
"contentParts": {},
"generationHint": "Develop the main body of the email response, addressing the key points from the incoming email.",
"sections": []
},
{
"id": "chapter_3",
"level": 1,
"title": "Schlussfolgerung",
"contentParts": {},
"generationHint": "Conclude the email with a summary or closing remarks, ensuring a polite and professional tone.",
"sections": []
}
]
}
]
}

22
prompts/20260322-171534-021-email_composition_prompt.txt
View file

@ -1,22 +0,0 @@
Compose an email based on this context:
-------
Reply to the following email(s):\n\nRecipient (reply to this address): ida-dittrich@proton.me\n\nFrom: ida-dittrich@proton.me\nSubject: test\nContent:\nYou don't often get email from ida-dittrich@proton.me. Learn why this is important\r\n\r\ndies ist eine testmail.\r\n\r\n\r\n\r\nSent from Proton Mail for iOS.\n\nFrom: p.motsch@valueon.ch\nSubject: FW: KI@SV Abgleich - Bericht Test Session\nContent:\nHallo Ida\r\n\r\nHier noch Futter für den Bericht nach der Session BEDAG von morgen.\r\nDies muss in unseren Bericht rein als Grundlage für die Entscheidungen auf Stufe Gesamtprojekt:\r\n\r\nFokus der Tests\r\n\r\n * Test auf «STA Sandbox» 19.03.2026, mit Cobra orgi\n\nFrom: notify@mail.notion.so\nSubject: Stephan Schellworth hat dich in Bedag Testschritt 3: Benchmark-Tests mit Cursor CLI erwähnt\nContent:\nStephan Schellworth hat dich in Bedag Testschritt 3: Benchmark-Tests mit Cursor CLI erwähnt\r\n17. März 2026, 08:15\r\n·PowerOn Startseite/05_Prozesse & Operations/Sprint Set Up/Tickets\r\nOwner\r\nI\r\nIda\r\nGehe zur Seite\r\nBenachrichtigungseinstellungen für diese \n\nFrom: notify@mail.notion.so\nSubject: Stephan Schellworth hat dich in Bedag Testschritt 4: Automatische Testfall-Ableitung erwähnt\nContent:\nStephan Schellworth hat dich in Bedag Testschritt 4: Automatische Testfall-Ableitung erwähnt\r\n17. März 2026, 08:15\r\n·PowerOn Startseite/05_Prozesse & Operations/Sprint Set Up/Tickets\r\nOwner\r\nI\r\nIda\r\nGehe zur Seite\r\nBenachrichtigungseinstellungen für diese\n\nFrom: notify@mail.notion.so\nSubject: Stephan Schellworth hat dich in Bedag Testschritt 2: Neutralisierten Code Dokumentieren erwähnt\nContent:\nStephan Schellworth hat dich in Bedag Testschritt 2: Neutralisierten Code Dokumentieren erwähnt\r\n17. März 2026, 08:15\r\n·PowerOn Startseite/05_Prozesse & Operations/Sprint Set Up/Tickets\r\nOwner\r\nI\r\nIda\r\nGehe zur Seite\r\nBenachrichtigungseinstellungen für di
-------
Recipients: ['ida-dittrich@proton.me']
Style: business
Max length: 1000 characters
Available_Document_References:
- (no documents)
Based on the context, decide which documents to attach.
CRITICAL: Use EXACT document references from Available_Document_References above. For individual documents: ALWAYS use docItem:<documentId>:<filename> format (include filename)
Return JSON:
{
"subject": "subject line",
"body": "email body (HTML allowed)",
"attachments": ["docItem:<documentId>:<filename>"]
}

7
prompts/20260322-171536-022-email_composition_response.txt
View file

@ -1,7 +0,0 @@
```json
{
"subject": "Re: Test Email",
"body": "Hallo Ida,<br><br>Vielen Dank für Ihre Testmail. Ich habe die Informationen aus der letzten Sitzung erhalten und werde sicherstellen, dass diese in unseren Bericht aufgenommen werden. Bitte lassen Sie mich wissen, wenn es noch weitere Details gibt, die berücksichtigt werden sollten.<br><br>Mit freundlichen Grüßen,<br><br>P. Motsch",
"attachments": []
}
```

119
prompts/20260322-171858-023-chapter_structure_generation_prompt.txt
View file

@ -1,119 +0,0 @@
# TASK: Plan Document Structure (Documents + Chapters)
This is a STRUCTURE PLANNING task. You define which documents to create and which chapters each document will have.
Chapter CONTENT will be generated in a later step - here you only plan the STRUCTURE and assign content references.
Return EXACTLY ONE complete JSON object. Do not generate multiple JSON objects, alternatives, or variations. Do not use separators like "---" between JSON objects.
## USER REQUEST (for context)
```
formulier eine passende email zur eingehenden email
```
## AVAILABLE CONTENT PARTS
(No content parts available)
## CONTENT ASSIGNMENT RULE
CRITICAL: Every chapter MUST have contentParts assigned if it relates to documents/images/data from the user request.
If the user request mentions documents/images/data, then EVERY chapter that generates content related to those references MUST assign the relevant ContentParts explicitly.
Assignment logic:
- If chapter DISPLAYS a document/image → assign "object" format ContentPart with "caption"
- If chapter generates text content ABOUT a document/image/data → assign ContentPart with "instruction":
- Prefer "extracted" format if available (contains analyzed/extracted content)
- If only "object" format is available, use "object" format with "instruction" (to write ABOUT the image/document)
- If chapter's generationHint or purpose relates to a document/image/data mentioned in user request → it MUST have ContentParts assigned
- Multiple chapters might assign the same ContentPart (e.g., one chapter displays image, another writes about it)
- Use ContentPart IDs exactly as listed in AVAILABLE CONTENT PARTS above
- Empty contentParts are only allowed if chapter generates content WITHOUT referencing any documents/images/data from the user request
CRITICAL RULE: If the user request mentions BOTH:
a) Documents/images/data (listed in AVAILABLE CONTENT PARTS above), AND
b) Generic content types (article text, main content, body text, etc.)
Then chapters that generate those generic content types MUST assign the relevant ContentParts, because the content should relate to or be based on the provided documents/images/data.
## CONTENT EFFICIENCY PRINCIPLES
- Generate COMPACT content: Focus on essential information only
- AVOID verbose, lengthy, or repetitive text - be concise and direct
- Prioritize FACTS over filler text - no introductions like "In this chapter..."
- Minimize system resources: shorter content = faster processing
- Quality over quantity: precise, meaningful content rather than padding
## CHAPTER STRUCTURE REQUIREMENTS
- Generate chapters based on USER REQUEST - analyze what structure the user wants
- Create ONLY the minimum chapters needed to cover the user's request - avoid over-structuring
- HARD LIMIT: Maximum 7 chapters per document. If the topic can be covered in fewer, prefer fewer. Combine related topics into single chapters rather than creating many small ones.
- IMPORTANT: Each chapter MUST have ALL these fields:
- id: Unique identifier (e.g., "chapter_1")
- level: Heading level (1, 2, 3, etc.)
- title: Chapter title
- contentParts: Object mapping ContentPart IDs to usage instructions (MUST assign if chapter relates to documents/data from user request)
- generationHint: Description of what content to generate (including formatting/styling requirements)
- sections: Empty array [] (REQUIRED - sections are generated in next phase)
- contentParts: {"partId": {"instruction": "..."} or {"caption": "..."} or both} - Assign ContentParts as required by CONTENT ASSIGNMENT RULE above
- The "instruction" field for each ContentPart MUST contain ALL relevant details from the USER REQUEST that apply to content extraction for this specific chapter. Include all formatting rules, data requirements, constraints, and specifications mentioned in the user request that are relevant for processing this ContentPart in this chapter.
- generationHint: Keep CONCISE but include relevant details from the USER REQUEST. Focus on WHAT to generate, not HOW to phrase it verbosely.
- The number of chapters depends on the user request - create only what is requested. Do NOT create chapters for topics without available data.
CRITICAL: Only create chapters for CONTENT sections, not for formatting/styling requirements. Formatting/styling requirements to be included in each generationHint if needed.
## DOCUMENT STRUCTURE
For each document, determine:
- outputFormat: From USER REQUEST (explicit mention or infer from purpose/content type). Default: "txt". Multiple documents can have different formats.
- language: From USER REQUEST (map to ISO 639-1: de, en, fr, it...). Default: "de". Multiple documents can have different languages.
- chapters: Structure appropriately for the format (e.g., pptx=slides, docx=sections, xlsx=worksheets). Match format capabilities and constraints.
Required JSON fields:
- metadata: {"title": "...", "language": "..."}
- documents: Array with id, title, filename, outputFormat, language, chapters[]
- chapters: Array with id, level, title, contentParts, generationHint, sections[]
EXAMPLE STRUCTURE (for reference only - adapt to user request):
{
"metadata": {
"title": "Document Title",
"language": "de"
},
"documents": [{
"id": "doc_1",
"title": "Document Title",
"filename": "document.txt",
"outputFormat": "txt",
"language": "de",
"chapters": [
{
"id": "chapter_1",
"level": 1,
"title": "Chapter Title",
"contentParts": {
"extracted_part_id": {
"instruction": "Use extracted content with ALL relevant details from user request"
}
},
"generationHint": "Detailed description including ALL relevant details from user request for this chapter",
"sections": []
}
]
}]
}
CRITICAL INSTRUCTIONS:
- Generate chapters based on USER REQUEST, NOT based on the example above
- The example shows the JSON structure format, NOT the required chapters
- Create only the chapters that match the user's request
- Adapt chapter titles and structure to match the user's specific request
- Determine outputFormat and language for each document by analyzing the USER REQUEST above
- The example shows placeholders "txt" and "de" - YOU MUST REPLACE THESE with actual values determined from the USER REQUEST
MANDATORY CONTENT ASSIGNMENT CHECK:
For each chapter, verify:
1. Does the user request mention documents/images/data? (e.g., "photo", "image", "document", "data", "based on", "about")
2. Does this chapter's generationHint, title, or purpose relate to those documents/images/data mentioned in step 1?
- Examples: "article about the photo", "text describing the image", "analysis of the document", "content based on the data"
- Even if chapter doesn't explicitly say "about the image", if user request mentions both the image AND this chapter's content type → relate them
3. If YES to both → chapter MUST have contentParts assigned (cannot be empty {})
4. If ContentPart is "object" format and chapter needs to write ABOUT it → assign with "instruction" field, not just "caption"
OUTPUT FORMAT: Start with { and end with }. Do NOT use markdown code fences (```json). Do NOT add explanatory text before or after the JSON. Return ONLY the JSON object itself.

41
prompts/20260322-171901-024-chapter_structure_generation_response.txt
View file

@ -1,41 +0,0 @@
{
"metadata": {
"title": "Email Response",
"language": "de"
},
"documents": [
{
"id": "doc_1",
"title": "Email Response",
"filename": "email_response.txt",
"outputFormat": "txt",
"language": "de",
"chapters": [
{
"id": "chapter_1",
"level": 1,
"title": "Einleitung",
"contentParts": {},
"generationHint": "Formulate a suitable introduction for the email response.",
"sections": []
},
{
"id": "chapter_2",
"level": 1,
"title": "Hauptteil",
"contentParts": {},
"generationHint": "Develop the main content of the email response, addressing the points from the incoming email.",
"sections": []
},
{
"id": "chapter_3",
"level": 1,
"title": "Schlussfolgerung",
"contentParts": {},
"generationHint": "Conclude the email with a polite closing statement.",
"sections": []
}
]
}
]
}

41
prompts/20260322-171901-025-chapter_structure_generation_final_result.txt
View file

@ -1,41 +0,0 @@
{
"metadata": {
"title": "Email Response",
"language": "de"
},
"documents": [
{
"id": "doc_1",
"title": "Email Response",
"filename": "email_response.txt",
"outputFormat": "txt",
"language": "de",
"chapters": [
{
"id": "chapter_1",
"level": 1,
"title": "Einleitung",
"contentParts": {},
"generationHint": "Formulate a suitable introduction for the email response.",
"sections": []
},
{
"id": "chapter_2",
"level": 1,
"title": "Hauptteil",
"contentParts": {},
"generationHint": "Develop the main content of the email response, addressing the points from the incoming email.",
"sections": []
},
{
"id": "chapter_3",
"level": 1,
"title": "Schlussfolgerung",
"contentParts": {},
"generationHint": "Conclude the email with a polite closing statement.",
"sections": []
}
]
}
]
}

22
prompts/20260322-171901-026-email_composition_prompt.txt
View file

@ -1,22 +0,0 @@
Compose an email based on this context:
-------
Reply to the following email(s):\n\nRecipient (reply to this address): ida-dittrich@proton.me\n\nFrom: ida-dittrich@proton.me\nSubject: test\nContent:\nYou don't often get email from ida-dittrich@proton.me. Learn why this is important\r\n\r\ndies ist eine testmail.\r\n\r\n\r\n\r\nSent from Proton Mail for iOS.
-------
Recipients: ['ida-dittrich@proton.me']
Style: business
Max length: 1000 characters
Available_Document_References:
- (no documents)
Based on the context, decide which documents to attach.
CRITICAL: Use EXACT document references from Available_Document_References above. For individual documents: ALWAYS use docItem:<documentId>:<filename> format (include filename)
Return JSON:
{
"subject": "subject line",
"body": "email body (HTML allowed)",
"attachments": ["docItem:<documentId>:<filename>"]
}

7
prompts/20260322-171904-027-email_composition_response.txt
View file

@ -1,7 +0,0 @@
```json
{
"subject": "Re: test",
"body": "Sehr geehrte Frau Dittrich,<br><br>vielen Dank für Ihre Nachricht. Ich habe Ihre Testmail erhalten und stehe Ihnen gerne für weitere Fragen oder Anliegen zur Verfügung.<br><br>Mit freundlichen Grüßen,<br><br>[Ihr Name]",
"attachments": []
}
```