When assisting with the mk3y.com project:

  1. Thoroughly review the codebase:
    • Understand the current Jekyll implementation and structure.
    • Use repopack-output.txt for context on file organization and content.
  2. Identify the specific problem or task:
    • Pinpoint the exact issue or area for improvement.
    • Consider potential impacts on other parts of the site.
  3. Analyze similar implementations:
    • Look for patterns in how similar functionalities are handled within the Jekyll project.
    • Consider best practices for Jekyll and static site generators.
  4. Look for inconsistencies:
    • Detect any mismatches or incorrect usage of Jekyll features or Liquid templating.
    • Identify areas where the project deviates from Jekyll conventions.
  5. Aim for simplicity and efficiency:
    • Prioritize solutions that align with Jekyll’s philosophy and existing project patterns.
    • Consider performance implications, especially for static site generation.
  6. Avoid unnecessary complexity:
    • Refrain from introducing new plugins or dependencies unless absolutely necessary.
    • Utilize Jekyll’s built-in features and Liquid templating where possible.
  7. Validate assumptions:
    • Test assumptions about how Jekyll processes and generates content.
    • Consider edge cases in content rendering and site structure.
  8. Consider the broader impact:
    • Assess how changes might affect the overall site structure, performance, and maintainability.
    • Think about future migration possibilities (e.g., to another static site generator).
  9. Refer to documentation and best practices:
    • Consult Jekyll documentation and community resources for optimal solutions.
    • Consider SEO best practices for static sites.
  10. Document thought process:
    • Use tags to explain reasoning and decisions.
    • Discuss alternatives considered and trade-offs made.
  11. Provide clear, actionable solutions:
    • Present solutions with specific file paths and code snippets.
    • Use markdown code blocks for syntax highlighting.
    • Explain how to implement the solution within the Jekyll project structure.
  12. Consider migration path:
    • When suggesting solutions, keep in mind potential future migration from Jekyll.
    • Prefer approaches that are common across static site generators when possible.
  13. Focus on key areas:
    • Pay special attention to _layouts, _includes, and _posts directories.
    • Consider optimizations for the build process and generated static files.

When presenting solutions:

  1. Start with a brief summary of the problem and proposed solution.
  2. Provide step-by-step instructions for implementation.
  3. Include relevant code snippets with explanations.
  4. Explain the rationale behind the chosen approach.
  5. Mention any potential side effects or considerations.
  6. Suggest testing procedures to validate the solution.

Example format for presenting a solution:

Problem: [Brief description of the issue]

Proposed Solution: [Concise summary of the approach]

[Explanation of reasoning, alternatives considered, and decision-making process]

Implementation Steps:

  1. [Step-by-step instructions]

Code Changes:

# File: [path/to/file]
[Code snippet with changes highlighted or explained]

Rationale: [Explanation of why this solution is appropriate for the Jekyll project]

Considerations:

Testing: [Suggestions for how to test and validate the solution]