Skip to main content

🌊 Workflow catalogue

See here for a list of default workflows that you can use in your own repositories.

generate_readme_summaries​

The generate_readme_summaries workflow:

  • crawls the repository's folders,
  • summarizes each file and folder,
  • generates a README.md file with the summaries in each folder.

The following parameters are available:

  • FILE_SUMMARY_PROMPT: the prompt to use when asking for a summary of a file,
  • FILE_SUMMARY_INSTRUCTIONS: the instructions to use when asking for a summary of a file,
  • FOLDER_SUMMARY_PROMPT: the prompt to use when asking for a summary of a folder,
  • FOLDER_SUMMARY_INSTRUCTIONS: the instructions to use when asking for a summary of a folder,
  • IGNORE_FILES: a list of files to ignore when crawling the repository,
  • EMPTY_FILE_SUMMARY: the summary to use when a file is empty.

You can invoke it by using the following trigger:

triggers:
  - branch_name: main
    run:
      workflow: generate_readme_summaries
      parameters:
        FILE_SUMMARY_PROMPT: "Write an executive summary of this file, intended for someone seeing it for the first time. Write 3-6 bullet points, prefixed with emojis."
        FILE_SUMMARY_INSTRUCTIONS: "Respond in 3-6 bullet points, using plenty of emojis."
        FOLDER_SUMMARY_PROMPT: "Write an executive summary of this folder, intended for someone seeing it for the first time. Respond in 3-5 sentences."
        FOLDER_SUMMARY_INSTRUCTIONS: "Respond in simple sentences, using plenty of emojis."
        IGNORE_FILES:
          - docs
        EMPTY_FILE_SUMMARY: "This file is empty."

The above trigger will run the workflow whenever the main branch is updated.

publish_todo_issues​

publish_todo_issues manages code annotations by:

  • Scanning the repository for all occurrences of TODOs and FIXMEs,
  • Leveraging LLM to obtain suggestions for solving them and assessing their difficulty,
  • Posting them as issues in the repository.

The following parameters are available:

  • ISSUE_LABEL_CHOICES: the choices to use when asking for the difficulty of a task,
  • ISSUE_LABEL_PROMPT: the prompt to use when asking for the difficulty of a task,
  • ISSUE_DESCRIPTION_PROMPT: the prompt to use when asking for a resolution of a TODO,
  • ISSUE_DESCRIPTION_INSTRUCTIONS: the instructions to use when asking for a resolution of a TODO.

You can invoke it by using the following trigger:

triggers:
  - branch_name: main
    run:
      workflow: publish_todo_issues
      parameters:
        ISSUE_LABEL_CHOICES:
          - "easy"
          - "medium"
          - "hard"
        ISSUE_LABEL_PROMPT: |
          How hard is this task?
        ISSUE_DESCRIPTION_PROMPT: |
          What tips can you give to someone that's resolving this TODO?
        ISSUE_DESCRIPTION_INSTRUCTIONS: |
          Respond in 1-3 sentences.

api_git_history​

The api_git_history workflow creates a history of selected API GET requests payloads by:

  • fetching an API GET request,
  • saving the response payload to a file,
  • committing the file to the repository.

The following inputs are available:

  • endpoint_url: the URL of the API endpoint to fetch
  • headers: the headers to use when fetching the API endpoint
  • filepath: the path of the file to save the response payload to

You can invoke it by using Cron Trigger:

triggers:
  - cron_schedule: "0 0 * * *"
    run: 
      workflow: api_git_history
      inputs: 
        endpoint_url: 
          const: "https://jsonplaceholder.typicode.com/todos"
        headers: 
          const: {"Content-type": "application/json; charset=UTF-8"}
        filepath:
          const: "todos.json"

summarize_pr​

The summarize_pr workflow summarizes a pull request by:

  • getting the diff of the pull request,
  • generating a summary of the diff,
  • posting a comment with the summary.

You can invoke it by using the following trigger:

triggers:
  - type: label
    label_substring: summarize
    on_pull_request: true
    workflow: summarize_pr

And adding a summarize label to a pull request.