gptools
You can find the Github repository for this project at kiwiscanfly/gptools.
gptools
is a a straightforward command-line utility designed for interacting with ChatGPT or Ollama models in smart new ways. This is super nerdy, so you’ll need to be comfortable using the various command line tools to follow these instructions and to use the thing. It allows for the execution of ChatGPT or Ollama prompts from your command line, combining input text with your collection of prompts. This tool can take input via standard input, enabling prompt chaining for more complex operations. Additionally, the utility offers PDF support with the --input
flag.
A distinct feature of gptools
is its storage system. It lets users store prompts in a specified directory, facilitating creating and curating a personal prompts repository. These can then be leveraged in other projects, enhancing reusability and efficiency.
Let’s set up the tool, create a prompt, and explore how it can be used.
Setting Up gptools
Command Installation
Navigate to the place you keep your code with cd ~/my-code-folder
.
Clone the Repository: Start by cloning the repository with git clone https://github.com/kiwiscanfly/gptools.git
.
Navigate to the code folder with cd gptools
.
Install the tool globally using the command npm install -g
.
Configuration
Create a .gptools config file in your home directory with necessary settings such as your OpenAI API key, the maximum token count, and preferred models. Run nano ~/.gptools
or use your preferred text editor. You’ll need a OpenAI Developer account, go there and get an API key for this, add the API key and adjust the following settings to your liking, paste them into the file:
MODEL="openai"
OPENAI_API_KEY="<your api key>"
OPENAI_MAX_TOKENS=2000
OPENAI_MODEL="gpt-4-turbo-preview"
GPTOOLS_PROMPTS_DIR="~/prompts"
OLLAMA_MODEL="llama3"
Prompt creation
Initialise a directory named prompts to house your command files with mkdir ~/prompts
. You may want to create a Git repo for these to be under source control.
Inside your prompts directory, you can create markdown files for each command with placeholders for dynamic content input. The name of the file will determine the command you run to execute it. Run the following commands
Run nano ~/prompts/paragraph.md
and add the following:
Can you provide a one paragraph summary of the given text? The summary should cover the key points and main ideas presented in the original text, while also condensing the information into a concise and easy-to-understand format.
<!-- INPUT -->
Run nano ~/prompts/bullet-points.md
and add the following:
Please read the following text and provide an extensive list of all that is stated in the form of bullet points.
<!-- INPUT -->
Running the command
Assuming you are still in the code directory, you can run the command like so to get a summary of the readme file cat README.md | gptools paragraph
. To show the benefits of chaining you can run the command cat README.md | gptools paragraph | gptools bullet-points
, which will extract a summary of the readme file and then convert that summary into bullet points.
Ollama provides the ability to run large language models locally. Once you have it installed you can run a command like ollama pull llama3
to download a model. To use this model with gptools
you must specify it in the OLLAMA_MODEL
entry in your ~/.gptools
file and then pass the --ollama
argument to the command. The chaining example would look like this: cat README.md | gptools paragraph --ollama | gptools bullet-points --ollama
, this is fantastic for comparing and contrasting large language models.
Additional use-cases
Here are some examples demonstrating the versatility of gptools
:
Daniel Miessler has several excellet prompts for his Fabric project, I’d highly recommend creating your own adaptation of the prompt and then running gptools
against PDFs using a command like gptools wisdom --pdf complex-paper.pdf
.
Another useful use case if your a programmer is reviewing code differences with using git with a command like git diff | gptools diff
and a prompt like the following:
Your role is to meticulously examine a pull request or commit as if you are a seasoned code reviewer. This involves a detailed analysis of the proposed changes, with a focus on logic, runtime efficiency, and overall readiness for merge. Approach this task methodically, breaking it down into manageable steps for thorough evaluation.
### Revised Instructions
- Begin with examining the `git diff` output for the pull request to understand the modifications.
- **Changes**: Provide a concise summary of the modifications introduced in the pull request.
- **Style Suggestions**: Offer recommendations to improve the code's readability and adherence to best practices in coding standards.
- **Security Considerations**: Assess the code for potential security vulnerabilities, emphasizing secure coding practices.
- **Potential Issues**: Identify any logical errors, runtime inefficiencies, or other concerns that could impact the code's functionality or performance.
- **Suggested Improvements**: Propose actionable improvements to enhance the code's quality, maintainability, or security posture.
- Format your feedback as a markdown document to ensure clarity and readability.
- In your review, specifically address the following points from the code review checklist provided:
### Code Review Checklist
- Scrutinize the pull request for any superfluous files, folders, or code modules that should be omitted.
- Confirm compliance with the Single Responsibility Principle (SRP) and the Don't Repeat Yourself (DRY) principle to promote clean code practices.
- Ensure comprehensive coverage of all potential error scenarios within the code.
- Evaluate the clarity and usefulness of error messages to aid in debugging and user guidance.
- Assess the code for elegant and robust error handling mechanisms.
- Examine how sensitive data and credentials are stored, ensuring they are securely managed.
- Check if external libraries and dependencies are current and securely configured.
- Protect against common security threats, such as SQL injections and Cross-Site Scripting (XSS), by verifying the implementation of adequate safeguards.
Or if you have a small enough project or enough tokens you can run a command like find . -path ./node_modules -prune -false -o -name "*.js" -exec sh -c 'echo "File: $1"; cat "$1"; echo ""' sh {} \; | gptools code-review
to send it all your code files.