Skip to content

Conversation

@CakekritsananXi
Copy link

@CakekritsananXi CakekritsananXi commented Apr 18, 2025

Important

Adds a new README with gpt-engineer instructions and updates prompts for building an e-commerce site using React and TypeScript.

  • New README:
    • Adds .ipynb_checkpoints/README-checkpoint.md with installation and usage instructions for gpt-engineer.
    • Includes sections on installation, API key setup, creating and improving code, benchmarking, and research.
    • Details features like pre-prompts, vision capabilities, and support for various models.
  • Prompt Updates:
    • Updates projects/example/prompt with detailed prompts for creating an e-commerce website using React, TypeScript, shadcn/ui, and Tailwind CSS.
    • Includes prompts for creating project structure, responsive header, hero section, product and service cards, shopping cart, checkout form, portfolio grid, contact form, routing, state management, and blog structure.
    • Provides specific instructions and expected outcomes for each component.

This description was created by Ellipsis for 434486f. It will automatically update as commits are pushed.

Copy link

@ellipsis-dev ellipsis-dev bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

❌ Changes requested. Reviewed everything up to 434486f in 1 minute and 43 seconds

More details
  • Looked at 286 lines of code in 2 files
  • Skipped 0 files when reviewing.
  • Skipped posting 6 drafted comments based on config settings.
1. .ipynb_checkpoints/README-checkpoint.md:10
  • Draft comment:
    Typo: 'genereation' should be 'generation'.
  • Reason this comment was not posted:
    Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50%
    While this is a valid typo correction, the review rules state we should not make purely informative comments. Typo fixes in documentation, especially README files, are generally considered minor and not critical to code functionality. The typo doesn't impact code behavior or maintainability.
    The typo is in a prominent place (main tagline) and could affect project professionalism. Documentation quality matters for open source projects.
    While documentation quality matters, typo fixes are still minor changes that don't require formal review comments. These can be fixed directly or mentioned informally.
    The comment should be removed as it's a minor documentation issue that doesn't require formal review.
2. projects/example/prompt:144
  • Draft comment:
    Missing newline at end of file; consider adding one for consistency.
  • Reason this comment was not posted:
    Comment did not seem useful. Confidence is useful = 20% <= threshold 50%
    The comment is suggesting a minor style change, which is not critical to the functionality of the code. It doesn't ask for a test or suggest a specific code change that affects the logic or functionality. Therefore, it doesn't align with the rules for useful comments.
3. .ipynb_checkpoints/README-checkpoint.md:10
  • Draft comment:
    Typo: 'genereation' should be 'generation'.
  • Reason this comment was not posted:
    Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50%
    While this is a real typo, our rules state that we should not make purely informative comments that don't require code changes. Spelling fixes in documentation, while helpful, are not critical code issues. Additionally, this appears to be in a .ipynb_checkpoints directory which typically contains temporary/backup files.
    The typo is real and fixing it would improve documentation quality. Documentation clarity is important for user understanding.
    While documentation quality matters, this is a minor spelling issue in what appears to be a checkpoint/backup file, not the main README. The main README would be the proper place to fix this.
    Delete this comment as it's a minor documentation issue in a checkpoint file and doesn't affect code functionality.
4. projects/example/prompt:144
  • Draft comment:
    Add a newline at the end of the file for POSIX compliance and improved readability.
  • Reason this comment was not posted:
    Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50%
    While having a newline at end of file is a common convention and can improve git diffs, this is a very minor issue that would likely be handled automatically by most editors and build tools. The comment doesn't point out a real problem that needs fixing. The file is readable and functional as-is.
    The comment is technically correct - POSIX does recommend ending text files with newlines. But is this really important enough to warrant a PR comment?
    No, this is too minor of an issue. Most modern tools handle this automatically, and it doesn't affect functionality or readability in any meaningful way.
    Delete this comment as it points out an extremely minor formatting issue that doesn't require manual intervention.
5. .ipynb_checkpoints/README-checkpoint.md:10
  • Draft comment:
    Typo: 'genereation' should be corrected to 'generation'.
  • Reason this comment was not posted:
    Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 0% vs. threshold = 50%
    While this is technically about a change since this is a new file, typo corrections in documentation are not critical code changes that require immediate attention. The rules state we should only keep comments that require clear code changes. Documentation typos, while good to fix, don't meet this threshold.
    The typo does affect readability slightly and it's in a prominent place (the tagline). Maybe it's worth fixing for professionalism?
    While presentation matters, the rules explicitly state to only comment on logic issues, not minor text changes. This is a documentation change that doesn't affect functionality.
    The comment should be removed as it addresses a minor documentation typo rather than a substantive code issue.
6. .ipynb_checkpoints/README-checkpoint.md:99
  • Draft comment:
    It appears the flag —-image_directory uses incorrect dash characters. Consider changing it to use two standard hyphens: --image_directory.
  • Reason this comment was not posted:
    Marked as duplicate.

Workflow ID: wflow_etnddi5RRhyaHwAH


Want Ellipsis to fix these issues? Tag @ellipsis-dev in a comment. You can customize Ellipsis with 👍 / 👎 feedback, review rules, user-specific overrides, quiet mode, and more.


### Vision

By default, gpt-engineer expects text input via a `prompt` file. It can also accept image inputs for vision-capable models. This can be useful for adding UX or architecture diagrams as additional context for GPT Engineer. You can do this by specifying an image directory with the `—-image_directory` flag and setting a vision-capable model in the second CLI argument.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Flag syntax: Replace —-image_directory with the standard --image_directory to ensure proper command-line usage.

Suggested change
By default, gpt-engineer expects text input via a `prompt` file. It can also accept image inputs for vision-capable models. This can be useful for adding UX or architecture diagrams as additional context for GPT Engineer. You can do this by specifying an image directory with the `-image_directory` flag and setting a vision-capable model in the second CLI argument.
By default, gpt-engineer expects text input via a `prompt` file. It can also accept image inputs for vision-capable models. This can be useful for adding UX or architecture diagrams as additional context for GPT Engineer. You can do this by specifying an image directory with the `--image_directory` flag and setting a vision-capable model in the second CLI argument.

@CakekritsananXi CakekritsananXi deleted the codespace-reimagined-rotary-phone-v6vg9gqrvjp92xp9 branch April 19, 2025 18:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant