Skip to content

Latest commit

 

History

History
219 lines (152 loc) · 11.3 KB

project_structure.prompt.md

File metadata and controls

219 lines (152 loc) · 11.3 KB

Description

Develop a Python package for creating structured commit messages. The package should consist of a library to represent commit messages, an interface for building commit messages, and a specific implementation of this interface.

Requirements

Library - CommitMessage

Purpose: Represents a commit message. Features: No methods or fields. Ability to be converted to a string representation.

Interface - CommitMessageBuilder

Purpose: Provides an interface for building commit messages. Methods: init(): Constructor. build(): Should return a CommitMessage object.

Class - AcnCommitMessageBuilder (implements CommitMessageBuilder)

  • Purpose: Specific implementation of CommitMessageBuilder.
  • Public Methods: init(): Constructor. withSummary(summary): Adds a summary to the commit message. withDescription(description): Adds a description. withAuthor(author): Adds an author. withCoAuthors(coAuthors): Adds co-authors. withAuthorAlsoAsCoAuthor(): Includes the author as a co-author. withRisk(risk): Adds a risk level. withIntent(intent): Adds the intent of the changes.
  • Private Methods: _loadRiskCodes(): Loads risk codes. _loadIntentCodes(): Loads intent codes.

Generate build() Method for AcnCommitMessageBuilder Class

Create the build() method within the AcnCommitMessageBuilder class in Python with the following specifications:

  1. Header Construction:

    • Combine the risk, intent, and summary attributes into a header formatted as "{risk}/{intent} - {summary}".

  2. Description Section:

    • Directly use the stored description attribute.

  3. Co-Authors Section:

    • Generate a list of co-authors, each prefixed with "Co-Authored-By:".
    • If the author is included as a co-author, ensure they are listed first.
    • Each co-author should be on a new line.

  4. Message Assembly:

    • Assemble the commit message from the header, description, and co-authors sections.
    • Separate each section with a newline.
    • Exclude any section that is empty or contains only whitespace.

  5. Trailing Newline Handling:

    • If the commit message consists of multiple sections, ensure it ends with a trailing newline.
    • If it's a single line (only the header), do not include a trailing newline.

The method should return the formatted commit message following these guidelines. Focus on string manipulation and conditionals to construct the message according to these rules.

Refined Prompt for withCoAuthors() Method in AcnCommitMessageBuilder

Develop the withCoAuthors() method for the AcnCommitMessageBuilder class in Python. This method should handle two types of inputs: a single string or a list of strings. The method's behavior will depend on the input type:

  1. Input as a List of Strings:

    • Each string in the list represents a user in the format "User Full Name [email protected]".
    • The method should initialize the _co_authors_list attribute with this list.

  2. Input as a Single String:

    • The string could represent:
      • A single user in the format "User Full Name [email protected]".
      • A string joined by "," or "\n" from a list of users.
      • A single-line or multi-line string with each line containing "Co-Authored-By:" followed by the user identifier.
    • The method should process this string to extract user identifiers and convert them into a list of the format "User Full Name [email protected]".
    • After processing, the method should call itself with this list to set the _co_authors_list attribute.

Additional Requirements:

  • Ensure that any "Co-Authored-By:" prefix in the user identifiers is removed before storing in _co_authors_list.
  • The method should be flexible to handle different delimiters (comma, newline) and formats.
  • The method should return self to allow for method chaining.

Use these guidelines to implement withCoAuthors() method, ensuring it can robustly handle different formats of input while correctly populating the _co_authors_list attribute.

Expected Directory Structure

CommitMessageSystem/ ├── init.py ├── commit_message.py ├── commit_message_builder.py └── acn_commit_message_builder.py

Response format

Each .py file should contain the stub implementation of its respective class or interface as per the above specifications.

Each .py file should be displayed in its own code block, with the language set appropriately (e.g. 'python' for *.py files)

Refined prompt

Clarifying Questions

To ensure the request is clear and actionable, I have a few clarifying questions and points for refinement:

  1. Scope and Detail Level:

    • Could you specify which classes, interfaces, and methods you're referring to? Are these the ones previously discussed (e.g., CommitMessage, CommitMessageBuilder, AcnCommitMessageBuilder) or are there additional elements?
    • How detailed should the summary be? Should it include specific method parameters and return types, or just a general overview of each class/interface?

  2. Code Generation Specifics:

    • For generating code, are there any specific Python versions or coding standards (like PEP 8) that should be adhered to?
    • Should the code include comments or documentation strings (docstrings)?

  3. Directory Structure:

    • You mentioned a directory structure. Should the summary include a specific layout for where these classes/interfaces should be located within a project's file system?

  4. Handling Ambiguities:

    • In cases where the requirements might be open to interpretation (e.g., handling edge cases in methods), how would you like those handled? Should I make assumptions based on standard practices, or would you prefer to provide specific guidance?

  5. Format of the Final Output:

    • For the code blocks, are you expecting these to be ready-to-run Python scripts, or more of pseudocode illustrating the structure and key functionalities?

  6. Size and Complexity:

    • Given the potential size of this task (multiple classes and methods), there might be a need to break it down into smaller parts. Would you prefer to handle one class/interface at a time or receive everything in one comprehensive response?

Refining these aspects will greatly help in providing a response that accurately meets your needs.

Clarifying Questions with embedded answers

To ensure the request is clear and actionable, I have a few clarifying questions and points for refinement:

  1. Scope and Detail Level:
    • Could you specify which classes, interfaces, and methods you're referring to? Are these the ones previously discussed (e.g., CommitMessage, CommitMessageBuilder, AcnCommitMessageBuilder) or are there additional elements?
    • How detailed should the summary be? Should it include specific method parameters and return types, or just a general overview of each class/interface?

Answers

  • Yes, I am referencing the classes, interfaces, and methods we previously discussed. There are no additional elements beyond the ones we discussed.
  • The summary should be detailed enough to regenerate the latest version of the code that was listed. If the parameters and return types are obvious enough, do not include them in the summary. But DO generate code with all the detail necessary to implement the full specifications.

  1. Code Generation Specifics:

    • For generating code, are there any specific Python versions or coding standards (like PEP 8) that should be adhered to?
    • Should the code include comments or documentation strings (docstrings)? Answers
    • Adhere to PEP 8 standards.
    • Do not include inline comments
    • Do not include docstrings

  2. Directory Structure:

    • You mentioned a directory structure. Should the summary include a specific layout for where these classes/interfaces should be located within a project's file system?

Answers - Yes. Include specific layout for where these classes/interfaces should be relative to an IntelliJ project directory structure.

  1. Handling Ambiguities:
    • In cases where the requirements might be open to interpretation (e.g., handling edge cases in methods), how would you like those handled? Should I make assumptions based on standard practices, or would you prefer to provide specific guidance?

Answers

  • If requirements are open to interpretation, do not yet generate code. Rather, please ask clarifying questions. Incorporate these answers into the requirements. If there are still ambiguous requirements, state assumptions in the code as comments.
  1. Format of the Final Output:
    • For the code blocks, are you expecting these to be ready-to-run Python scripts, or more of pseudocode illustrating the structure and key functionalities?

Answers

  • Let's do this in 2 passes. As a first pass, I will say "generate pseudocode for all python code". Later, I will say "generate ready-to-run python code".
  1. Size and Complexity:
    • Given the potential size of this task (multiple classes and methods), there might be a need to break it down into smaller parts. Would you prefer to handle one class/interface at a time or receive everything in one comprehensive response?

Answers

  • Please generate everything as a comprehensive response. Remember though, that there will be 2 levels of detail, so I will either say "generate pseudocode for all python code" or "generate ready-to-run python code"

Summar

Certainly! Here's a combined summary of your original request along with your answers to the clarifying questions, and an outline of how we will proceed through the two levels of detail:

Combined Request Summary

Task Overview

  • Develop detailed summaries and code for the previously discussed classes and interfaces (CommitMessage, CommitMessageBuilder, AcnCommitMessageBuilder) in Python.
  • The code and summaries should include all necessary details to regenerate the latest version.

Detailed Requirements

  1. Scope: Focus on the specified classes and interfaces.
  2. Summary Detail:
    • Provide detailed summaries for regeneration of the latest code version.
    • Include parameters and return types where not obvious.
  3. Code Generation Standards:
    • Follow PEP 8 coding standards.
    • Exclude inline comments and docstrings.
  4. Directory Structure:
    • Include a layout that fits an IntelliJ project directory structure.
  5. Handling Ambiguities:
    • Seek clarification on ambiguous requirements.
    • Note ambiguities as comments in the code.

Output Format and Process

  • Two Levels of Detail:

    1. First Pass: Generate pseudocode for all Python code. This will provide an overview of the structure and key functionalities.
    2. Second Pass: Generate ready-to-run Python code based on the pseudocode and any further clarifications.

  • Iterative Approach:

    • The task will be tackled comprehensively, covering all classes and interfaces in one response.
    • In the first pass, pseudocode for each class/interface will be presented in separate sections to maintain clarity.
    • Upon review and any necessary refinements of the pseudocode, the second pass will involve generating the actual Python code.

This approach ensures a systematic and clear development process, allowing for initial conceptualization through pseudocode, followed by the creation of executable Python scripts.

Please confirm if this summary aligns with your expectations and if it's okay to proceed with the first pass of generating pseudocode.