API tools faq
paste
Advertisement
andrejsstepanovs

project_help

andrejsstepanovs
May 4th, 2025
300
0
Never
Add comment
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
YAML 21.98 KB | None | 0 0
raw download clone embed print report
  1. llm_models:
  2.     - name: "normal"
  3.       temperature: 0.2
  4.       model: "google-gemini-2.0-flash"
  5.       provider: custom
  6.       base_url: "http://localhost:4000/v1/chat/completions"
  7.       api_key: "sk-_fi-7AJGJXnetgRdFTIfIw"
  8.  
  9.     - name: "large"
  10.       temperature: 0.2
  11.       model: "google-gemini-2.5-flash"
  12.       provider: custom
  13.       base_url: "http://localhost:4000/v1/chat/completions"
  14.       api_key: "sk-_fi-7AJGJXnetgRdFTIfIw"
  15.       commands:
  16.        - summarize-task
  17.  
  18.     - name: "genius"
  19.       temperature: 0.2
  20.       model: "google-gemini-2.5-pro-preview"
  21.       provider: custom
  22.       base_url: "http://localhost:4000/v1/chat/completions"
  23.       api_key: "sk-_fi-7AJGJXnetgRdFTIfIw"
  24.       commands:
  25.        - create-issues
  26.  
  27.     # gpt-4.1, gpt-o3-mini, groq-deepseek-r1-distill-llama-70b, groq-llama-3.3-70b, deepseek-reasoner, deepseek-chat, google-gemini-2.5-flash, google-gemini-2.5-pro-preview
  28.  
  29. redmine:
  30.   db: redmine:redmine@tcp(localhost:3306)/redmine # things from docker-compose
  31.   url: "http://localhost:8080"
  32.   api_key: "2159cef2fb6c82c4f66981f199798781e161c694"
  33.   repositories: "/var/repositories/"
  34.  
  35. coding_agents:
  36.   aider:
  37.     timeout: "180m"
  38.     config: "/home/andrejs/www/aiwork/local/.andai.aider.yaml"
  39.     model_metadata_file: "/home/andrejs/aiwork/local/.andai.aider.model.json"
  40.     map_tokens: 512 #1024
  41.  
  42. projects:
  43.   - identifier: "andai"
  44.     name: "Andai"
  45.     description: "Golang project"
  46.     git_path: "/andai/.git"
  47.     git_local_dir: "/home/andrejs/www/andai/.git"
  48.     final_branch: "main"
  49.     commands: &golang_commands
  50.       - name: "test"
  51.         command: ["make", "test"]
  52.         ignore_err: True
  53.         ignore_stdout_if_no_stderr: True
  54.       - name: "lint"
  55.         command: ["make", "run-lint"]
  56.         ignore_err: True
  57.         success_if_no_output: True
  58.       - name: "reformat"
  59.         command: ["gofmt", "-s", "-w", "."]
  60.         ignore_err: True
  61.         success_if_no_output: True
  62.     wiki: |
  63.      # Coding assistant
  64.       Andai is coding assistant that is working together with ticketing system and github.
  65.      
  66.       ## Coding Best Practices
  67.       - Do not add comments to the code you write, unless the user asks you to, or the code is complex and requires additional context.
  68.       - When making changes to files, first understand the file's code conventions. Mimic code style, use existing libraries and utilities, and follow existing patterns.
  69.       - NEVER assume that a given library is available, even if it is well known. Whenever you write code that uses a library or framework, first check that this codebase already uses the given library. For example, you might look at neighboring files, or check the package.json (or cargo.toml, and so on depending on the language).
  70.       - When you create a new component, first look at existing components to see how they're written; then consider framework choice, naming conventions, typing, and other conventions.
  71.       - When you edit a piece of code, first look at the code's surrounding context (especially its imports) to understand the code's choice of frameworks and libraries. Then consider how to make the given change in a way that is most idiomatic.
  72.  
  73.       ## Coding Best Practices
  74.       - Do not add comments to the code you write, unless the user asks you to, or the code is complex and requires additional context.
  75.       - When making changes to files, first understand the file's code conventions. Mimic code style, use existing libraries and utilities, and follow existing patterns.
  76.       - NEVER assume that a given library is available, even if it is well known. Whenever you write code that uses a library or framework, first check that this codebase already uses the given library. For example, you might look at neighboring files, or check the package.json (or cargo.toml, and so on depending on the language).
  77.       - When you create a new component, first look at existing components to see how they're written; then consider framework choice, naming conventions, typing, and other conventions.
  78.       - When you edit a piece of code, first look at the code's surrounding context (especially its imports) to understand the code's choice of frameworks and libraries. Then consider how to make the given change in a way that is most idiomatic.
  79.       - Default working language: **English**
  80.  
  81.   - identifier: "go-llm-client"
  82.     name: "LLM Client"
  83.     description: "LLM Client is golang project that is interacting with LLM models."
  84.     git_path: "/go-llm-client/.git"
  85.     git_local_dir: "/home/andrejs/www/go-llm-client/.git"
  86.     final_branch: "main"
  87.     commands: &golang_commands
  88.       - name: "test"
  89.         command: ["make", "test"]
  90.         ignore_err: True
  91.         ignore_stdout_if_no_stderr: True
  92.       - name: "lint"
  93.         command: ["make", "run-lint"]
  94.         ignore_err: True
  95.         success_if_no_output: True
  96.       - name: "reformat"
  97.         command: ["gofmt", "-s", "-w", "."]
  98.         ignore_err: True
  99.         success_if_no_output: True
  100.     wiki: |
  101.      # Coding assistant
  102.       LLM Client is golang project that is interacting with LLM models.
  103.      
  104.       ## Coding Best Practices
  105.       - Do not add comments to the code you write, unless the user asks you to, or the code is complex and requires additional context.
  106.       - When making changes to files, first understand the file's code conventions. Mimic code style, use existing libraries and utilities, and follow existing patterns.
  107.       - NEVER assume that a given library is available, even if it is well known. Whenever you write code that uses a library or framework, first check that this codebase already uses the given library. For example, you might look at neighboring files, or check the package.json (or cargo.toml, and so on depending on the language).
  108.       - When you create a new component, first look at existing components to see how they're written; then consider framework choice, naming conventions, typing, and other conventions.
  109.       - When you edit a piece of code, first look at the code's surrounding context (especially its imports) to understand the code's choice of frameworks and libraries. Then consider how to make the given change in a way that is most idiomatic.
  110.  
  111.       # Internal package imports and usage
  112.       - When importing packages from project use full path like so:
  113.       ```go
  114.       import (
  115.         "github.com/andrejsstepanovs/go-llm-client/internal/models"
  116.       )
  117.       ```
  118.  
  119.       ## Coding Best Practices
  120.       - Do not add comments to the code you write, unless the user asks you to, or the code is complex and requires additional context.
  121.       - When making changes to files, first understand the file's code conventions. Mimic code style, use existing libraries and utilities, and follow existing patterns.
  122.       - NEVER assume that a given library is available, even if it is well known. Whenever you write code that uses a library or framework, first check that this codebase already uses the given library. For example, you might look at neighboring files, or check the package.json (or cargo.toml, and so on depending on the language).
  123.       - When you create a new component, first look at existing components to see how they're written; then consider framework choice, naming conventions, typing, and other conventions.
  124.       - When you edit a piece of code, first look at the code's surrounding context (especially its imports) to understand the code's choice of frameworks and libraries. Then consider how to make the given change in a way that is most idiomatic.
  125.       - Default working language: **English**
  126.  
  127. workflow:
  128.   states:
  129.     Init:
  130.       ai: ["Task", "Grooming"]
  131.       is_default: True
  132.       is_first: True
  133.     Backlog:
  134.       ai: ["Story", "Task", "Grooming"]
  135.       description: Issue is ready to be worked on.
  136.     Think:
  137.       ai: ["Story", "Task", "Grooming"]
  138.       description: Analyze Issue and plan how to work on it.
  139.     Work:
  140.       ai: ["Story", "Task", "Grooming"]
  141.       description: Analyze Issue and plan how to work on it.
  142.     Test:
  143.       ai: ["Story", "Task", "Grooming"]
  144.       description: |
  145.        Check current state of the story code.
  146.         If everything is fine, move to Done.
  147.         If not, move to Work where new Tasks will try to fix discovered issues.
  148.     Fixing:
  149.       ai: ["Story", "Task"]
  150.       description: |
  151.        Resolving issues identified during the Testing phase. If all is OK, will move to QA.
  152.         If fail to fix then will move task to Help where user will take it on.
  153.     Help:
  154.       ai: ["Story"]
  155.       description: |
  156.        Human in the middle bugfixing state for Grooming tasks.
  157.     QA:
  158.       ai: ["Task", "Grooming"]
  159.       description: Human Test to check Story code.
  160.     Deploy:
  161.       ai: ["Story", "Task", "Grooming"]
  162.       description: Merge code into to parent Issue branch.
  163.     Done:
  164.       description: Issue is completed.
  165.       ai: []
  166.       is_closed: True
  167.  
  168.   transitions:
  169.     - source: Init
  170.       target: Backlog
  171.  
  172.     - source: Backlog
  173.       target: Think
  174.     - source: Think
  175.       target: Work
  176.  
  177.     - source: Work
  178.       target: Test
  179.  
  180.     - source: Test
  181.       success: true
  182.       target: QA
  183.     - source: Test
  184.       fail: true
  185.       target: Fixing
  186.  
  187.     - source: Fixing
  188.       success: true
  189.       target: QA
  190.     - source: Fixing
  191.       fail: true
  192.       target: Help
  193.  
  194.     - source: Help
  195.       target: QA
  196.  
  197.     - source: QA
  198.       success: true
  199.       target: Deploy
  200.  
  201.     - source: QA
  202.       fail: true
  203.       target: Think
  204.  
  205.     - source: Deploy
  206.       target: Done
  207.  
  208.   issue_types:
  209.     Story:
  210.       description: |
  211.        Represents a significant feature or component that requires multiple Tasks to implement.
  212.         Scope: Entire feature or major component, potentially spanning multiple files and modules.
  213.       jobs:
  214.         Backlog:
  215.           steps:
  216.             - command: next
  217.         Think:
  218.           steps:
  219.             - command: context-files
  220.               context: ["wiki", "ticket", "comments"]
  221.               remember: True
  222.             - command: ai
  223.               context: ["project", "wiki", "ticket", "comments"]
  224.               comment: True
  225.               prompt: |
  226.                 You are an experienced Project Manager with expertise in translating business requirements into actionable technical specifications. Your task is to:
  228.                 1. Analyze the provided information about this ticket/issue thoroughly
  229.                 2. Identify and describe all necessary features from a business perspective
  230.                 3. Explain the user experience requirements and expected outcomes
  231.                 4. Prioritize components based on business value and dependencies
  232.                 5. Highlight potential edge cases and considerations
  233.                 6. Structure your response as a comprehensive ticket comment for the engineering team
  234.  
  235.                 Important: Do not invent or add new requirements that weren't mentioned in the original ticket.
  236.                 Your role is strictly to clarify, organize, and enhance the existing information, not to create new features or expand the scope.
  237.                 Avoid feature creep.
  238.  
  239.                 Your response should:
  240.                - Begin with a brief summary of the overall objective (1-2 sentences)
  241.                 - Include detailed descriptions of each functional requirement with clear acceptance criteria
  242.                 - Specify any business rules, constraints, or regulatory requirements
  243.                 - Avoid technical implementation details (the "how") - focus on the "what" and "why"
  244.                 - Use precise, specific language that leaves no room for misinterpretation
  245.  
  246.                 The engineering team will use your analysis to decompose this issue into smaller, manageable tasks.
  247.                 Be thorough, specific, and ensure that all business requirements are clearly articulated.
  248.             - command: summarize-task
  249.               comment: True
  250.               context: ["issue_types", "project", "wiki", "ticket", "comments", "children"]
  251.               prompt: |
  252.                Based on comments figure out if task was already worked on
  253.                 and if this time it is required to adjust something instead of creating issue to implement the story.
  254.                 If this is the case (issue was already worked on) this means that issue failed Test and we need to
  255.                 create new issues that addresses Test findings.
  256.                 Understand that based on current issue comments and their time.
  257.                 If there are no comments or existing comments don't show that issue was already worked on,
  258.                 then create new issues that are needed for this story issue.
  259.                 Summary: Break down the current Story issue into Task issues based on pre-planned ideas from comments,
  260.                 ensuring detailed descriptions for each task. QA existing comments to clarify requirements,
  261.                 check if the task was previously worked on, and determine if adjustments are needed.
  262.                 If adjustments are needed then it means that the task failed Test,
  263.                 create new issues to address Test findings. If there’s no evidence of prior work,
  264.                 create new tasks to implement the Story.
  265.                 Use comment timestamps and context to guide decisions,
  266.                 ensuring alignment with Test requirements.
  267.                 Now using what you know, analyze current_issue and comments carefully.
  268.                 Suggest how to split current Story issue into smaller scope Task issues (make sure to stick with Task issue scope and create as many Task issues as necessary).
  269.                 Dont forget to mention scope of the Task issues you create.
  270.                 Make sure each Task issue is small enough to be implemented in a single code file or even better - one part of a single code file.
  271.         Work:
  272.           steps:
  273.             - command: create-issues
  274.               action: Task
  275.               prompt: |
  276.                Based on last comments and context that you are presented with,
  277.                 split current Story issue into Task issues using pre-planned idea mentioned in comments.
  278.                 Write a detailed description of what needs to be done.
  279.                 Comply to clarification comments if exists.
  280.                 Make the new issues detailed, clear and concise. Dont forget to mention scope of the files that need to be worked on.
  281.                 Keep in mind that Task issue are small enough to be implemented in a single code file or even better - one part of a single code file.
  282.               context: ["issue_types", "project", "wiki", "ticket", "last-5-comments", "children"]
  283.         Test:
  284.           steps:
  285.             - command: next
  286.         Fixing:
  287.           steps:
  288.             - command: next
  289.         Help:
  290.           steps:
  291.             - command: next
  292.         Deploy:
  293.           steps:
  294.             - command: merge-into-parent
  295.     Task:
  296.       description: |
  297.        Task issues are building blocks for single Story issue.
  298.         Scope: Single method or specific part of a file.
  299.         Represents the smallest unit of work that must be implemented independently
  300.         in a single mid size or small git commit for one part of the code file.
  301.       jobs:
  302.         Init:
  303.           steps:
  304.             - command: next
  305.         Backlog:
  306.           steps:
  307.             - command: next
  308.         Think:
  309.           steps:
  310.             - command: context-files
  311.               context: ["wiki", "parents", "ticket", "comments"]
  312.               remember: True
  313.             - command: summarize-task
  314.               context: ["project", "wiki", "ticket", "last-5-comments"]
  315.               comment: True
  316.               prompt: |
  317.                Locate code files that are relevant for current Task issue.
  318.                 Provide ideas how to resolve the given Task issue.
  319.                 Focus only on the code relevant to the current issue (issue_type: Task).
  320.                 Ensure that the changes do not affect anything else beyond what is asked in the current Task issue.
  321.                 implement (code) given Task issue based on ticket description, last comments and your reasoning.
  322.         Work:
  323.           steps:
  324.             - command: context-files
  325.               context: ["ticket", "last-3-comments"]
  326.               remember: True
  327.             - command: aider
  328.               action: architect-code
  329.               context: ["project", "wiki", "ticket", "last-5-comments"]
  330.               prompt: Implement (code) current Task issue based on available information.
  331.             - command: project-cmd
  332.               action: reformat
  333.             - command: commit
  334.               prompt: linter changes
  335.         Test:
  336.           steps:
  337.             - command: project-cmd
  338.               action: lint
  339.               remember: True
  340.             - command: project-cmd
  341.               action: test
  342.               remember: True
  343.             - command: ai
  344.               prompt: |
  345.                If there are any linter errors then pinpoint exact files and place in file (using linter output) that is at fault.
  346.                 Answer with clear and concise explanation of the sources for these linter errors.
  347.                 If there are any testing errors then pinpoint exact files and test cases that are faulty (using tests output).
  348.                 Keep the answer straight to the point of what was test cases are broken and in what file and where.
  349.                 If there are no linter and testing errors then answer with "Linter and tests are OK".
  350.               remember: True
  351.             - command: create-issues
  352.               action: Grooming
  353.               context: ["issue_types", "ticket", "last-3-comments"]
  354.               prompt: |
  355.                Create Grooming issues that are focusing on fixing all found linter and test errors.
  356.                
  357.                 Instructions:
  358.                 - Create one Grooming issue per error.
  359.                 - If there are no linter or tests failures present then do nothing (do not create any new Grooming issues).
  360.                
  361.                 In new Grooming issue description carefully define:
  362.                 - What test or linter check needs fixing.
  363.                 - Where are affected files located.
  364.             - command: evaluate
  365.               context: [ "ticket", "comments" ]
  366.         Fixing:
  367.           steps:
  368.             - command: project-cmd
  369.               action: lint
  370.               remember: True
  371.             - command: project-cmd
  372.               action: test
  373.               remember: True
  374.             # - command: ai
  375.             #   prompt: |
  376.            #     If there are any linter errors then pinpoint exact files and place in file (using linter output) that is at fault.
  377.             #     Answer with clear and concise explanation of the sources for these linter errors.
  378.             #     If there are any testing errors then pinpoint exact files and test cases that are faulty (using tests output).
  379.             #     Keep the answer straight to the point of what was test cases are broken and in what file and where.
  380.             #     If there are no linter and testing errors then answer with "Linter and tests are OK".
  381.             #   remember: True
  382.             - command: evaluate
  383.               context: [ "ticket", "comments" ]
  384.         Help:
  385.           steps:
  386.             - command: next
  387.         QA:
  388.           steps:
  389.             - command: next
  390.         Deploy:
  391.           steps:
  392.             - command: merge-into-parent
  393.  
  394.     Grooming:
  395.       description: |
  396.        A unit of work focused on fixing test failures and linter issues.
  397.         Scope: Specific fixes for test failures and linter failures that was spotted during parent Task issue Testing phase.
  398.       jobs:
  399.         Init:
  400.           steps:
  401.             - command: next
  402.         Backlog:
  403.           steps:
  404.             - command: next
  405.         Think:
  406.           steps:
  407.             - command: next
  408.         Work:
  409.           steps:
  410.             - command: context-files
  411.               context: [ "ticket", "comments" ]
  412.               remember: True
  413.             - command: aider
  414.               action: code
  415.               comment: False
  416.               context: [ "project", "wiki", "ticket", "last-comment" ]
  417.               prompt: |
  418.                Implement (code) given Grooming issue based on ticket description and last comments.
  419.                 It is not allowed to create new files or run any commands!
  420.             - command: project-cmd
  421.               action: reformat
  422.             - command: commit
  423.               prompt: linter changes
  424.         Test:
  425.           steps:
  426.             - command: next
  427.         QA:
  428.           steps:
  429.             - command: next
  430.         Deploy:
  431.           steps:
  432.             - command: merge-into-parent
  433.  
  434.   priorities:
  435.     - type: Grooming
  436.       state: Deploy
  437.     - type: Grooming
  438.       state: Fixing
  439.     - type: Grooming
  440.       state: Help
  441.     - type: Grooming
  442.       state: QA
  443.     - type: Grooming
  444.       state: Test
  445.     - type: Grooming
  446.       state: Work
  447.     - type: Grooming
  448.       state: Think
  449.     - type: Grooming
  450.       state: Backlog
  451.     - type: Grooming
  452.       state: Init
  453.  
  454.     - type: Task
  455.       state: Deploy
  456.     - type: Task
  457.       state: Fixing
  458.     - type: Task
  459.       state: Help
  460.     - type: Task
  461.       state: QA
  462.     - type: Task
  463.       state: Test
  464.     - type: Task
  465.       state: Work
  466.     - type: Task
  467.       state: Think
  468.     - type: Task
  469.       state: Backlog
  470.     - type: Task
  471.       state: Init
  472.  
  473.     - type: Story
  474.       state: Deploy
  475.     - type: Story
  476.       state: Fixing
  477.     - type: Story
  478.       state: Help
  479.     - type: Story
  480.       state: QA
  481.     - type: Story
  482.       state: Test
  483.     - type: Story
  484.       state: Work
  485.     - type: Story
  486.       state: Think
  487.     - type: Story
  488.       state: Backlog
  489.  
  490.   triggers:
  491.     - issue_type: Task
  492.       if:
  493.         - moved_to: Done
  494.           all_siblings_status: Done
  495.           transition:
  496.             who: parent
  497.             to: QA
  498.     # - issue_type: Grooming
  499.     #   if:
  500.     #     - moved_to: Done
  501.     #       all_siblings_status: Done
  502.     #       transition:
  503.     #         who: parent
  504.     #         to: QA
  505.  
Tags: andai
Advertisement
Add Comment
Please, Sign In to add comment
Advertisement
Public Pastes
Advertisement
We use cookies for various purposes including analytics. By continuing to use Pastebin, you agree to our use of cookies as described in the Cookies Policy.  OK, I Understand
Not a member of Pastebin yet?
Sign Up, it unlocks many cool features!