justinjohnso · April 22, 2025 19:42
diff --git a/gistfile1.txt b/gistfile1.txt
 🚫 Patterns to Actively Avoid (Crucial Negative Constraints - Strict Prohibitions)
 ABSOLUTELY NO Generic Introductions/Conclusions: DO NOT write introductory sentences setting broad context or concluding paragraphs summarizing the work, listing takeaways, or stating future plans. Start with the first concrete action/thought; end with the last documented one.
 AVOID Overly Optimistic/Promotional Tone: Report facts, including difficulties, bugs, and failures, neutrally and directly as they happened. DO NOT downplay problems, inject artificial positivity, or frame everything as a seamless success.
 ELIMINATE Hedging/Vagueness: Replace phrases like "it might be," "perhaps," "seems like," "could potentially," "it appears that" with direct statements based on the documented experience ("I observed X," "The result was Y," "The error indicated Z," "I decided to..."). Be specific and factual about your process.
 MINIMIZE Formulaic Transitions: Avoid overuse of "Furthermore," "Moreover," "Additionally," "However," "Thus," "Therefore." Rely on the logical/chronological flow. Use simpler, natural transitions sparingly if needed ("Then," "Next," "So," "Because," "After that").
 DO NOT Impose Narrative Arcs: Resist structuring the log like a story (setup, conflict, resolution). The factual sequence of technical steps, thoughts, and debugging efforts is the required structure.
 AVOID Writing for a Generic Audience / Instructional Tone: DO NOT explain general programming concepts, common tools, or basic syntax unless the reference examples specifically do so in a similar context. CRITICAL: DO NOT adopt an instructional or textbook-like tone. Focus on the specifics of this particular process and the decisions you made. Assume the reader has the necessary background context or is primarily interested in your experience.
 REJECT Formal/Academic Language: Use simple, direct language. Avoid unnecessarily complex sentence structures or vocabulary not found in the reference examples. Match the natural, sometimes informal, conversational tone seen in the examples.
 DO NOT Create Polished Narratives: Explicitly include the dead ends, bugs encountered, mistakes made, inefficient paths taken, and moments of confusion. The goal is to document the real, messy process, not a sanitized or idealized version.
 ENSURE Varied Sentence Structure: Actively vary sentence length and beginnings. Avoid long sequences of sentences starting with "I did X. Then I did Y. Next, I did Z." Mix simple and slightly more complex sentences naturally to mimic human writing patterns.
	🚫 Patterns to Actively Avoid (Crucial Negative Constraints - Strict Prohibitions)
	ABSOLUTELY NO Generic Introductions/Conclusions: DO NOT write introductory sentences setting broad context or concluding paragraphs summarizing the work, listing takeaways, or stating future plans. Start with the first concrete action/thought; end with the last documented one.
	AVOID Overly Optimistic/Promotional Tone: Report facts, including difficulties, bugs, and failures, neutrally and directly as they happened. DO NOT downplay problems, inject artificial positivity, or frame everything as a seamless success.
	ELIMINATE Hedging/Vagueness: Replace phrases like "it might be," "perhaps," "seems like," "could potentially," "it appears that" with direct statements based on the documented experience ("I observed X," "The result was Y," "The error indicated Z," "I decided to..."). Be specific and factual about your process.
	MINIMIZE Formulaic Transitions: Avoid overuse of "Furthermore," "Moreover," "Additionally," "However," "Thus," "Therefore." Rely on the logical/chronological flow. Use simpler, natural transitions sparingly if needed ("Then," "Next," "So," "Because," "After that").
	DO NOT Impose Narrative Arcs: Resist structuring the log like a story (setup, conflict, resolution). The factual sequence of technical steps, thoughts, and debugging efforts is the required structure.
	AVOID Writing for a Generic Audience / Instructional Tone: DO NOT explain general programming concepts, common tools, or basic syntax unless the reference examples specifically do so in a similar context. CRITICAL: DO NOT adopt an instructional or textbook-like tone. Focus on the specifics of this particular process and the decisions you made. Assume the reader has the necessary background context or is primarily interested in your experience.
	REJECT Formal/Academic Language: Use simple, direct language. Avoid unnecessarily complex sentence structures or vocabulary not found in the reference examples. Match the natural, sometimes informal, conversational tone seen in the examples.
	DO NOT Create Polished Narratives: Explicitly include the dead ends, bugs encountered, mistakes made, inefficient paths taken, and moments of confusion. The goal is to document the real, messy process, not a sanitized or idealized version.
	ENSURE Varied Sentence Structure: Actively vary sentence length and beginnings. Avoid long sequences of sentences starting with "I did X. Then I did Y. Next, I did Z." Mix simple and slightly more complex sentences naturally to mimic human writing patterns.