Your First Session

Now that you’re all set up, kick off your first Devin session!

Start with tasks that are smaller in scope and tell Devin where and how to verify it’s on the right track. We’ve seen users work with Devin on everything from fixing small bugs to automated version upgrades to large scale migrations.

Start a run with Devin

Log into your Devin account and set Devin to work on your project with your first prompt! You can come up with your own task, select from one of Devin’s project-specific suggestions, or use and repurpose our first-time prompts below.

First-time Prompt Ideas

Try in Devin

Clone the repository from https://github.com/onblog/SnowJena, specifically the snowjena-ticket-server application, and set it up locally. 
First, ensure the snowjena-ticket-server application builds and runs successfully with the current setup. You don’t need to worry about other applications in the repository. 
Next, upgrade the Spring Boot version to 3.3.2 in the snowjena-ticket-server application, making only the necessary changes related to this version upgrade. 
After the upgrade, test the snowjena-ticket-server application to confirm it still builds and runs correctly. 
You don't need to push code. Instead, share a zipped folder. 
Also share a screenshot of the application running successfully in your browser.

Try in Devin

## Overview
Given a link to a github repository, use Gource to visualise the git history.

## What’s Needed From User
- Provide a link to a github repository

## Procedure
1. Install dependencies
- Install Gource on your machine using `sudo apt install gource`
- Install `ffmpeg` and `xvfb` on the machine.
- Set up `xvfb` using `ps aux | grep Xvfb`
2. Clone the git repository locally on your machine.
- Navigate to the root directory of the Git repository.
3. Get the total days of commits -
- Get the start date of the first commit using :
 `git log --pretty='format:%cd' --date='format:%Y-%m-%d' | tail -1`
- Get the end date of the latest commit using :
 `git log --pretty='format:%cd' --date='format:%Y-%m-%d' | head -1`
- Calculate the total number of days
4. Choose the right parameters -
- Considering the default duration to be 60 seconds, calculate the speedup factor using - 60/(total number of days).
- Set the parameter `--seconds-per-day` and `--auto-skip-seconds` to the calculated speedup factor.
- Hide elements using `--hide dirnames,filenames`
- Set `<filename>` to the name of the git repository.
- Set the parameter `--output-ppm-stream` to `<filename>.ppm`
5. Run gource with all the parameters.
- Use xvfb to run gource
  `xvfb-run --auto-servernum --server-num=1 gource ...`
6. Generate a .webm file -
- Run the following command
  `ffmpeg -y -r 60 -f image2pipe -vcodec ppm -i <filename>.ppm -vcodec libvpx -b 10000K <filename>.webm`
7. Output:
- Send the video file as an attachment using the messaging interface to the browser.

## Advice and Pointers
1. Adjust the frame rate and resolution to balance video quality and file size.
2. There is no need to authenticate the GitHub CLI on the machine.
3. Make sure the .ppm file is properly generated for all the commits.

Try in Devin

## Overview
The task is to make a quick pull request to a repository.
Since this is a 'quick' PR, you will not need to run any code or test anything; simply make a PR and the user will handle the testing. Your only responsibility is reading and writing code.

## What's Needed From User
- The repository to create a pull request to

## Procedure
### Prepare your workspace
1. Navigate to the relevant repository on your machine (clarify with the user if you can't figure it out).
    - Check out the main branch and note down the name of the main branch.
    - Checkout to a new branch since you'll be making a pull request. The name of the branch has to be of the format `devin/<your-branch-name>/X` where X is a random number. For example `devin/fix-popup/3234`. Run `git remote -v && git pull && git checkout -b devin/{branch-name}/$RANDOM` and replace `{branch-name}` with the name of the branch you want to create.
2. Study the request, codebase, and plan out the changes
    - Review the most relevant files and code sections, identifying relevant snippets.
    - Inform the user of your plan
### Work on the PR itself
3. Make the code changes
    - Don't change anything that wasn't specifically requested by the user
4. Make the PR
    - Commit and push the changes and tell the user.
    - See advice section for the exact command to make the PR
    - Make a pull request & review the pr to make sure it looks OK.
    - Ensure all GitHub actions pass successfully & make necessary changes until they do
    - Send the PR link to the user and summarize what you changed.
5. Address any feedback from the review; send the PR link again every time you make any changes
    - If you need to make updates, just push more commits to the same branch; don't create a new one


## Task Specification
- PR link is included in your messages to the user
- PR was reviewed after creation
- PR does not include any stray changes
- PR does not change anything that wasn't specifically requested by the user
- PR description should include a summary of the changes, formatted as a checklist
- PR description should mention that the code was written without testing, and include - [ ] Test the changes as an item
- PR description should include the following footer: "This PR was written by [Devin](https://devin.ai/) :angel:"
- PR description should include any metadata that the user has provided (e.g. linear ticket tags in the appropriate syntax)
- PR description should not be malformatted (use --body-file instead of --body if the newlines are garbled!)

## Forbidden Actions
- Do NOT try to access github.com through the browser, you will not be authenticated.
- NEVER force push on branches! Prefer merging over rebasing so that you don't lose any work.
- Do NOT push directly to the main branch.

## Advice and Pointers
- Double check the name of the main branch (which could be `main` or `master`) using `git branch`.
- For repos with CI/CD on github actions, you can check build logs using the gh cli. if you're asked to fix a build/fix lint, you should start by looking at recent build logs
- Check `git status` before committing or adding files.
- Use `git diff` to see what changes you have made before committing.
- If you're updating an existing repo, use `gh cli` to make pull requests.
- Send the PR link to the user every time you update & ask them to re-review so that it's convenient for them
- You should already be authorized to access any repositories the user tells you about. If not, ask the user for access.

Try in Devin

## Overview    
This playbook guides you through the process of creating an architectural diagram of a public GitHub repository or any source code using [C4-PlantUML](https://github.com/plantuml-stdlib/C4-PlantUML)

## What’s Needed From User
1. Provide link to your desired public github repository or a zip file containing your source code
2. Provide instructions if you want the architecture diagram to be customized

## Procedure
1. Install dependencies
    - Ensure that Java runtime is installed in your system
    - Install Graphviz using `sudo apt install graphviz`
2. Download PlantUML from the browser
    - Navigate to [https://plantuml.com/download](https://plantuml.com/download) in your browser and download [PlantUML](https://github.com/plantuml/plantuml/releases/download/v1.2024.5/plantuml-1.2024.5.jar)
    - Ensure that it is included in your PATH
3. Extract the source code (if zip file is provided)
- Download the zip file provided by the user directly to the current working directory
- Extract the source code from the zip file using `unzip <file_name.zip>` 
4. Setup the GitHub repository (if provided)
    - Clone the GitHub repository provided by the user
    - Navigate to the correct directory
5. Analyze the functionality of different components in the app carefully
    - Analyze the app directory
    - Understand the functionality of each component in the app very carefully
6. Generate the `.puml` file
    - Keep `Person` element outside `System_Boundary`
    - Make sure to add all the essential components and their relevant details in the diagram
    - Refer to [https://github.com/plantuml-stdlib/C4-PlantUML/blob/master/README.md](https://github.com/plantuml-stdlib/C4-PlantUML/blob/master/README.md) for detailed instructions
    - Include the following in the `.puml` file after `@startuml`:
    !include  https://raw.githubusercontent.com/plantuml-stdlib/C4-PlantUML/master/C4_Container.puml
    !include https://raw.githubusercontent.com/plantuml-stdlib/C4-PlantUML/master/C4_Component.puml
7. Generate the architecture diagram
    - Generate the architecture diagram from the `.puml` file
    - Make sure that the command is run without errors
8. Share the final deliverables
    - Share the architecture diagram with the user as an attachment

## Deliverables
1. The architecture diagram of the GitHub repository or the source code

## Advice and Pointers
1. Ensure that the diagram is clear and easy to understand

The first time you use Devin, we would recommend sitting and watching how Devin works for a few minutes using the Follow Devin tab or in our example session video below. In general, you don’t need to monitor Devin like this all the time, but it is a great starting point for understanding Devin’s capabilities.

Note: This video was sped up for demonstration purposes.

If you’d like to dig in to some more detailed examples of what Devin can do (and how), check out our introductory tutorials below.

Code Coverage

Devin can analyze your codebase’s test suite and write additional tests to increase code coverage for your team.

API Integration

Devin can integrate, configure, and test third party APIs in your applications.

Containerization

In this tutorial, we’ll show you how Devin can configure a Docker container to standardize your team’s dev environment.

Managing Frontend Components

Devin can work with frontend libraries and share visuals with you during its sessions.

Work With Your Existing Tools

You can invite Devin to work in many of the tools or applications you work in - it’s as simple as giving Devin the necessary credentials, API keys or tokens so it can work within those services through the Secrets Manager or when prompted to securely share the credential in the chat.

Here are some common tools Devin has used with our early users:

For more details on Devin’s integrations check out our GitHub and Slack integration guides:

GitHub

Connect your GitHub account to allow Devin to access, create pull requests and contribute to your existing repositories.

Slack

Connect Devin to your company Slack and kick off runs directly via Slack by tagging @Devin.

For automated workflows and integrations with your existing tools, you can also leverage our External API to programmatically create sessions and retrieve structured results.

Get Started

Tutorials

Prompt and Use Case Library

Working With Devin

Working with Teams

Integrations

API Reference

Other

Troubleshooting

Start a run with Devin

First-time Prompt Ideas

Code Coverage

API Integration

Containerization

Managing Frontend Components

Work With Your Existing Tools

GitHub

Slack

Get Started

Tutorials

Prompt and Use Case Library

Working With Devin

Working with Teams

Integrations

API Reference

Other

Troubleshooting

​Start a run with Devin

​First-time Prompt Ideas

Code Coverage

API Integration

Containerization

Managing Frontend Components

​Work With Your Existing Tools

GitHub

Slack

Start a run with Devin

First-time Prompt Ideas

Work With Your Existing Tools