| <%# 1. THE GOAL %>Your goal is to thoroughly analyze the provided context and files in order to deliver high-quality, production-ready | |
| code for a specific instruction described below regarding a Ruby on Rails project. You will be attentive to details in existing models, controllers, | |
| views, and any business logic implied by the project’s context. You will also write or update RSpec specs | |
| following best practices to ensure that your solutions are thoroughly tested and maintainable. | |
| You will find the **instruction** in the format below at **the end of this prompt**, which describes the feature or requirement to be implemented: | |
| ``` | |
| <instruction>As a user, I want to be able to comment articles</instruction> | |
| ``` | |
| Please **carefully analyze** the project context. It contains an overview of the company or product, its primary features, | |
| its target audience, the value propositions, and the main pain points addressed by the product. You will use this | |
| information to guide your decision-making, ensuring that any code you produce aligns with the business objectives and user needs. | |
| You will find the **project context** in the formal below **the end of this prompt** | |
| ``` | |
| <abstract> | |
| Short summary describing the company or product. | |
| </abstract> | |
| <coreFeatures> | |
| <feature>Feature 1</feature> | |
| <feature>Feature 2</feature> | |
| <feature>Feature 3</feature> | |
| </coreFeatures> | |
| <targetAudience> | |
| <audience>Audience 1</audience> | |
| <audience>Audience 2</audience> | |
| <audience>Audience 3</audience> | |
| </targetAudience> | |
| <valueProposition> | |
| <value>Value proposition 1</value> | |
| <value>Value proposition 2</value> | |
| <value>Value proposition 3</value> | |
| </valueProposition> | |
| <painPointsAddressed> | |
| <pain>Pain point 1</pain> | |
| <pain>Pain point 2</pain> | |
| <pain>Pain point 3</pain> | |
| </painPointsAddressed> | |
| ``` | |
| I will provide you a lot of files from the project, in order to help you make iterations/decisions. | |
| Some of them are not relevant, you have to figured it out by yourself. | |
| I will give you at least the `routes.rb`, the `schema.rb`, and all the models files. | |
| Here is an example format for a file provided at the end of the prompt: | |
| ``` | |
| <file name="user.rb" type="model" path="app/models/user.rb"> | |
| class User < ActiveRecord::Base | |
| validates :email, presence: true | |
| def full_name | |
| "#{last_name} #{first_name}" | |
| end | |
| end | |
| </file> | |
| ``` | |
| <%# 2. RETURN FORMAT %>The final output returned by the LLM must strictly follow this structure: | |
| 1. A **global explanation** of what did you change, like a summary of the global changes, something that | |
| can be including in a pull request initial comment. | |
| 2. **Abstract** describing changes, in the following order: | |
| 1. Models changes, including migrations: every changes on the model should be really simple | |
| and translate the database schema, complex logic will be in the step 2. | |
| For example, don't update data within models, don't use callbacks, make it simple. | |
| 2. Services/organizers/interactors changes: everything unrelated to models/controllers/views | |
| 3. Controllers: it should call only one method on an object by action. | |
| For example, if you have to manipulate an object multiple times, please use a service or an organizer. | |
| It should be as simple as this: | |
| ``` | |
| def create | |
| @object = Service.new(object_params) # or Organizer.call(organizer_params) | |
| if @object.success? | |
| render_success | |
| else | |
| render_failuer | |
| end | |
| end | |
| ``` | |
| 4. Views | |
| 3. **Each file** that has been updated or newly created, including: | |
| - Explanation of the changes (before the snippet). | |
| - The updated code (or new file code if it’s a new file), without `<file>` tags | |
| - A snippet with only the change, without `<file>` tags | |
| 4. One or more **final capybara test** for the whole feature, regarding all the potential | |
| users affected. | |
| 5. **Warnings** to be mindful of any potential issues. | |
| For 3., if it's not a controller, you have to produce a test file with the same instructions as described | |
| for the files within the step 3. | |
| Additionally: | |
| - Group each PORO file with its test. | |
| - The codebase should have tiny models, tiny controllers | |
| - If business logic is more complex than 5 lines or spans multiple objects, it must be moved to organizers and interactors. | |
| - If logic manipulates multiple models, use multiple interactors orchestrated by an organizer. | |
| - The same logic applies to callbacks or webhooks: they should be organized into interactors and organizers. | |
| - Provide straightforward explanations so a junior developer can understand your reasoning. | |
| <%# 3. WARNINGS %>Before responding, you must double-check: | |
| - Every files should follow Single Responsability Principle (known as SRP): if a file has multiple | |
| responsability, split them in multiple files. It's better to have multiple small files than a big one. | |
| In this case, please use an organizer to orchestrate them. There is an example: | |
| ``` | |
| class MainOrganizer < ApplicationOrganizer | |
| organize Task1, | |
| Task2 | |
| end | |
| class Task1 < ApplicationInteractor | |
| def call | |
| # some logic | |
| end | |
| end | |
| class Task2 < ApplicationInteractor | |
| def call | |
| # some another logic | |
| end | |
| end | |
| ``` | |
| - Every method should be tested: if a method is not tested, write a test for it. | |
| - Every method should be private unless it's used by another class: if a method is public and not used by | |
| another class, make it private. | |
| - Every method should be short: if a method is longer than 10 lines, refactor it. | |
| - That new files are placed in the correct folder (e.g., `app/models/` for a model, `spec/models/` for its test). | |
| - That no comments are left inside the files (comments are irrelevant in the final code). | |
| - That no modifications are necessary to apply the patches (they must be copy-paste ready). | |
| If you have doubts or need clarification, you have to to ask simple questions to clarify before rendering your plan. | |
| <%# 4. EXAMPLES %> | |
| Here is a full (but simple) example of a final output for the instruction | |
| `Add first name and last name validation to the User model` | |
| (code blocks within this snippet adds backslash to backticks, | |
| final output should use backticks without backslash) | |
| ``` | |
| # 1. Models changes | |
| * We add a `validates :first_name, :last_name, presence: true` to `User` model | |
| # 2. Services/organizers/interactors changes | |
| No changes needed | |
| # 3. Controllers | |
| No changes needed | |
| # 4. Views | |
| No changes needed | |
| --- | |
| # Files | |
| ## Updated code in `app/models/user.rb` | |
| *Explanation*: We add a `presence: true` validation to fields `first_name`, `last_name` for `User | |
| \`\`\`ruby | |
| class User < ActiveRecord::Base | |
| validates :email, :first_name, :last_name, presence: true | |
| def full_name | |
| "#{last_name} #{first_name}" | |
| end | |
| end | |
| \`\`\` | |
| The relevant changes: | |
| \`\`\` | |
| diff --git a/app/models/user.rb b/app/models/user.rb | |
| index b56d75c4..f951a837 100644 | |
| --- a/user.rb | |
| +++ b/user.rb | |
| @@ -1,4 +1,4 @@ | |
| class User < ApplicationRecord | |
| - validates :email, presence: true | |
| + validates :email, :first_name, :last_name, presence: true | |
| def full_name | |
| \`\`\` | |
| The snippet to copy: | |
| \`\`\`ruby | |
| validates :email, :first_name, :last_name, presence: true | |
| \`\`\` | |
| --- | |
| # Warnings | |
| * You should check controllers/service which creates users in order to be sure there is a `first_name` and `last_name` | |
| ``` | |
| <%# 5. CONTEXT DUMP %>Here is all the relevant context and files, followed by the instruction you must implement: | |
| <%= project_context %> | |
| <% files.each do |file| %> | |
| <file name="<%= file[:name] %>" type="<%= file[:type] %>" path="<%= file[:path] %>"> | |
| <%= file[:contents].strip %> | |
| </file> | |
| <% end %> | |
| <instruction> | |
| <%= instruction %> | |
| </instruction> |
| #!/usr/bin/env ruby | |
| # frozen_string_literal: true | |
| require 'erb' | |
| require 'byebug' | |
| require 'optparse' | |
| options = { template: './prompt.txt.erb' } | |
| OptionParser.new do |opts| | |
| opts.banner = "Usage: #{$PROGRAM_NAME} [options] [input_file]" | |
| opts.on('--template TEMPLATE', 'Specify custom template file (default: ./prompt.txt.erb)') do |template| | |
| options[:template] = template | |
| end | |
| end.parse! | |
| if File.exist?('./llm-feature.txt') | |
| instruction, patterns = File.read('./llm-feature.txt').split("\n\n\n") | |
| patterns = patterns.split("\n") | |
| elsif !ARGV[0].nil? | |
| instruction, patterns = File.read(ARGV[0]).split("\n\n\n") | |
| patterns = patterns.split("\n") | |
| else | |
| print "Enter your final instruction (multi-line).\n" | |
| print "Press ENTER on an empty line to finish.\n" | |
| instruction_lines = [] | |
| while (line = $stdin.gets) | |
| break if line.strip.empty? | |
| instruction_lines << line.chomp | |
| end | |
| instruction = instruction_lines.join("\n") | |
| print "Enter one or more file patterns (glob), each on its own line.\n" | |
| print "Press ENTER on an empty line to finish.\n" | |
| patterns = [] | |
| while (line = $stdin.gets) | |
| break if line.strip.empty? | |
| patterns << line.chomp | |
| end | |
| end | |
| def extract_type(file_path) | |
| if file_path.start_with?('app') | |
| file_path.split('/')[1] | |
| elsif file_path.start_with?('spec/features') | |
| 'spec_feature' | |
| elsif file_path.start_with?('spec/factories') | |
| 'spec_factory' | |
| else | |
| 'unknown' | |
| end | |
| end | |
| files = patterns.flat_map { |pattern| Dir.glob(pattern) }.uniq | |
| files_data = files.map do |file| | |
| { | |
| name: File.basename(file), | |
| path: file, | |
| type: extract_type(file), | |
| contents: File.read(file) | |
| } | |
| end << { | |
| name: 'schema.rb', | |
| path: 'db/schema.rb', | |
| type: 'schema', | |
| contents: File.read('db/schema.rb') | |
| } << { | |
| name: 'routes.rb', | |
| path: 'config/routes.rb', | |
| type: 'routes', | |
| contents: File.read('config/routes.rb') | |
| } | |
| files_data.uniq! | |
| print "Files to be included:\n" | |
| files_data.each do |file_data| | |
| print "#{file_data[:path]}\n" | |
| end | |
| renderer = ERB.new(File.read(options[:template])) | |
| result = renderer.result_with_hash( | |
| files: files_data, | |
| instruction: instruction, | |
| project_context: File.read('./project-context.xml') | |
| ) | |
| File.write('final-prompt.txt', result) | |
| # vim: ft=ruby |
| An explanation of the feature | |
| app/organizer/whatever.rb | |
| spec/organizer/whatever_spec.rb | |
| app/interactors/whatever/**/*.rb | |
| spec/interactors/whatever/**/*.rb |
| <%# 1. THE GOAL %> | |
| Your goal is to analyze the provided context and files in detail. Instead of producing code snippets, you will deliver a **step-by-step product requirement document** describing all necessary changes for the feature or requirement specified below in the `<instruction>` block. This includes identifying relevant files, explaining the changes to be made, why they’re required, potential edge cases, and any important insights or verifications needed. These instructions will then be passed to another LLM agent that will implement, test, and finalize the changes directly. | |
| The **instruction** describing the feature or requirement to be implemented will be found at the end of this prompt, in this format: | |
| ``` | |
| <instruction>As a user, I want to be able to comment articles</instruction> | |
| ``` | |
| You also have access to a **project context** (company or product overview, features, audience, etc.) and a series of **files** from the Ruby on Rails codebase (e.g. models, controllers, views, etc.). Some may be irrelevant; focus only on those needed. | |
| Each file is presented like this: | |
| ``` | |
| <file name="user.rb" type="model" path="app/models/user.rb"> | |
| class User < ActiveRecord::Base | |
| validates :email, presence: true | |
| def full_name | |
| "#{last_name} #{first_name}" | |
| end | |
| end | |
| </file> | |
| ``` | |
| Your task is **not to provide code snippets** but to provide a thorough, line-by-line (or section-by-section) **requirements document** of what should be changed or created, including file paths, the reason for each modification, and any dependencies or testing considerations. | |
| <%# 2. RETURN FORMAT %> | |
| The final output returned by the LLM must strictly follow this structure: | |
| 1. **Global Explanation** | |
| - A concise overview (like a PR description) explaining the major change and its purpose. | |
| 2. **Abstract of Changes** (in this order) | |
| 1. **Models changes** (including migrations): | |
| - Clearly outline any new attributes, validations, or relationships needed. | |
| - Keep these changes minimal and focused on essential attributes. Complex business logic must go elsewhere. | |
| 2. **Services / Organizers / Interactors changes**: | |
| - Detail any logic that involves multiple steps or objects. | |
| - If the logic is more than a few lines or requires multiple steps, break it down into separate interactors, orchestrated by an organizer. | |
| 3. **Controllers**: | |
| - Specify controller actions that must be updated or added. | |
| - Each action should do one simple thing: instantiate an object or call a service/organizer, check success, and render results. | |
| 4. **Views**: | |
| - Summarize new or updated views (if any). | |
| - Indicate form fields, partials, or display changes that must be implemented. | |
| 3. **File-by-File Requirements** | |
| - For each file that needs modification (or creation), give a clear explanation of **what** must change and **why**, referencing specific lines or methods. | |
| - If a file doesn’t currently exist, specify where it should be created and what it should contain at a high level. | |
| - **Do not provide code snippets**. Instead, describe the requirements and logic to be implemented or updated. | |
| 4. **Capybara Test Scenarios** | |
| - Provide one or more high-level user-focused test scenarios covering this feature. | |
| - For each scenario, specify the typical user flow (e.g., “User visits the article page, clicks ‘Add Comment’, fills out the text, submits...”), edge cases, and expected outcomes. | |
| 5. **Warnings / Potential Issues** | |
| - List any important considerations or pitfalls to watch out for (e.g., performance concerns, security implications, or data consistency). | |
| <%# 3. WARNINGS %> | |
| Before finalizing your response, verify: | |
| - **Single Responsibility Principle (SRP)**: If a file has multiple responsibilities, suggest splitting it into smaller files (e.g., an organizer orchestrating multiple interactors). | |
| - **Test Coverage**: Each method or service introduced/modified should be tested in the relevant spec file. Include references to the new tests in your plan (e.g., “Add specs for the new validation in `spec/models/user_spec.rb`”). | |
| - **Visibility of Methods**: If a method is not used externally, recommend making it private. | |
| - **Method Length**: If a method is longer than ~10 lines, propose refactoring or moving logic to a dedicated service/interactor. | |
| - **File Placement**: Ensure new files are placed in the correct directory (`app/models/`, `spec/models/`, etc.). | |
| - **No Inline Comments**: The final code must not have leftover comments or debugging statements. | |
| - **Copy-Paste Ready**: The changes you describe should be easily implementable by another agent without guesswork. | |
| If you need clarification at any point, ask targeted questions to ensure you have all details before outlining the requirements. | |
| <%# 4. EXAMPLES %> | |
| Below is an **updated** simplified example of a final output for the instruction: | |
| `Add first name and last name validation to the User model.` | |
| Notice this example **does not** include code snippets but rather a **step-by-step requirement**: | |
| ``` | |
| 1. Global Explanation | |
| We need to ensure all Users have `first_name` and `last_name` present when created or updated. This aligns with the business requirement of properly identifying users across the platform. | |
| 2. Abstract of Changes | |
| - Models: | |
| * User model: Add presence validations for `first_name` and `last_name`. | |
| - Services/Organizers/Interactors: | |
| * No changes needed. | |
| - Controllers: | |
| * No changes needed. | |
| - Views: | |
| * No changes needed. | |
| 3. File-by-File Requirements | |
| - `app/models/user.rb`: | |
| - Add `validates :first_name, :last_name, presence: true`. | |
| - Make sure the file does not contain unused public methods. If there are any that are not externally used, make them private. | |
| - Verify `full_name` method still behaves correctly and is tested. | |
| 4. Capybara Test Scenarios | |
| - **Scenario**: Creating a new user | |
| 1. Visit the sign-up page. | |
| 2. Fill in the email, but leave out `first_name` or `last_name`. | |
| 3. Submit the form. | |
| 4. Expect to see a validation error for missing fields. | |
| - **Scenario**: Editing an existing user | |
| 1. Visit the edit user page. | |
| 2. Remove `first_name` or `last_name`. | |
| 3. Submit. | |
| 4. Expect an error indicating the fields cannot be empty. | |
| 5. Warnings / Potential Issues | |
| - Ensure that any existing user records in the database without `first_name` or `last_name` are handled, if relevant. | |
| - Confirm that forms and controllers handle strong parameters for `first_name` and `last_name`. | |
| ``` | |
| <%# 5. CONTEXT DUMP %> | |
| Here is all the relevant context and files, followed by the instruction you must implement: | |
| <%= project_context %> | |
| <% files.each do |file| %> | |
| <file name="<%= file[:name] %>" type="<%= file[:type] %>" path="<%= file[:path] %>"> | |
| <%= file[:contents].strip %> | |
| </file> | |
| <% end %> | |
| <instruction> | |
| <%= instruction %> | |
| </instruction> |
| <name>Superdocu</name> | |
| <url>https://superdocu.com/</url> | |
| <abstract> | |
| Superdocu is a platform designed to simplify and automate the collection and management of documents from external stakeholders—such as customers, suppliers, and partners—ultimately ensuring better compliance, faster onboarding, and streamlined operations. | |
| </abstract> | |
| <coreFeatures> | |
| <feature>Automated Document Collection: Enables businesses to request and receive KYC, AML, and various compliance documents without endless email chains or manual follow-ups.</feature> | |
| <feature>Customizable Onboarding Workflows: Allows the creation of tailor-made forms, checklists, and requirements based on the specific needs of each department or client segment.</feature> | |
| <feature>Intuitive Interface and Dashboards: Provides real-time visibility into who has submitted required documents, which requests are outstanding, and any missing items needing attention.</feature> | |
| <feature>Secure Data Management: Encrypts sensitive documents, supports GDPR compliance, and ensures secure file storage and controlled user access.</feature> | |
| <feature>Automated Reminders and Notifications: Sends scheduled reminders to external stakeholders, reducing the time spent on manually chasing documents.</feature> | |
| <feature>Integration and API Support: Offers the ability to connect Superdocu with other internal systems (CRM, ERP, etc.) to synchronize customer or partner data in real time.</feature> | |
| </coreFeatures> | |
| <targetAudience> | |
| <audience>Compliance & Risk Management Teams: Those responsible for maintaining regulatory compliance who need an efficient, automated way to collect and verify documentation.</audience> | |
| <audience>Operations & HR Departments: Professionals who handle employee onboarding, supplier setup, or administrative tasks requiring seamless collection of necessary paperwork.</audience> | |
| <audience>Finance & Accounting Teams: Teams that must collect and review financial documents from partners, vendors, or customers to maintain auditable records.</audience> | |
| <audience>Sales & Onboarding Specialists: Individuals seeking to accelerate the client onboarding process by reducing friction and manual data gathering.</audience> | |
| </targetAudience> | |
| <valueProposition> | |
| <value>Streamlined Compliance and KYC: By automating document requests and validations, Superdocu helps prevent compliance violations and reduces risk exposure.</value> | |
| <value>Time and Cost Efficiency: Cuts down on labor-intensive email follow-ups and manual tracking, allowing teams to focus on higher-value tasks.</value> | |
| <value>Improved User Experience: Offers an intuitive interface for both internal teams and external stakeholders, making document submission and verification quick and hassle-free.</value> | |
| <value>Centralized Document Management: Consolidates files in a single repository, ensuring easy retrieval, version control, and consistent documentation across all departments.</value> | |
| <value>Enhanced Visibility and Control: Real-time dashboards and detailed logs provide managers with full transparency into onboarding progress and compliance status.</value> | |
| </valueProposition> | |
| <painPointsAddressed> | |
| <pain>Excessive Manual Effort: Traditional document collection involves repetitive data entry and chasing individuals via emails, which Superdocu automates.</pain> | |
| <pain>High Risk of Non-Compliance: Relying on scattered document management processes can lead to missing or outdated paperwork, which Superdocu mitigates through automated workflows.</pain> | |
| <pain>Lack of Transparency in Onboarding: Without real-time tracking, stakeholders often remain uncertain about the status of required documents—Superdocu provides live dashboards and notifications.</pain> | |
| <pain>Fragmented Data Storage: Documents can be lost or siloed in multiple systems; Superdocu centralizes everything in one secure platform.</pain> | |
| <pain>Time-Consuming Follow-Ups and Reminders: Superdocu automates reminders, so teams spend less time on administrative tasks and more on strategic activities.</pain> | |
| </painPointsAddressed> |