Skip to main content

Build a Team PTO Tracker

Describe your tool and Devin builds, tests, and verifies it end-to-end.
AuthorCognition
CategoryFeature Development
1

(Optional) Scope the codebase with Ask Devin

If you already have internal tools in your app, use Ask Devin to understand the existing patterns before writing your spec. This is especially useful if you want the new tool to match the architecture of what’s already there:Use the answers to fill in your spec with specific file references, component names, and patterns so Devin builds something consistent with your existing tools. You can also start a Devin session directly from Ask Devin, and it will carry over everything it learned as context.
2

Write a detailed spec

Internal tools — PTO trackers, admin panels, data scripts, CLI utilities — are essential but rarely prioritized. They’re ideal for Devin because the requirements are well-defined, the audience is your team, and “works correctly” matters more than pixel-perfect design.Be specific about what the tool does, what data it stores, and what services it connects to. The more detail you include, the closer the first version matches what you need.You can also iterate on your spec using Ask Devin — paste a rough draft and ask it to identify gaps or suggest improvements based on your codebase.
3

Add credentials

Pass any API keys or tokens Devin needs via Secrets — in this case, the Slack webhook URL.The simplest approach is to store them as organization secrets before starting the session:
  1. Go to Settings > Secrets and add SLACK_WEBHOOK_URL
  2. Devin accesses secrets as environment variables, so they never end up hardcoded in your source code.
Organization secrets must be added before starting the session — they’re injected at session start. Alternatively, you can provide secrets during the session using the chat, and Devin will also proactively ask you for any credentials it needs when it encounters missing environment variables.
4

Guide the session with slash commands

Once the session starts, you can use slash commands to steer Devin’s workflow:
  • /plan — Ask Devin to create a thorough implementation plan before writing any code. Review the plan and suggest changes before it starts building.
  • /test — Tell Devin to run all tests and verify its work. Use this after each major milestone to catch issues early.
  • /review — Ask Devin to review its own code for bugs, edge cases, and style issues before opening the PR.
These commands work at any point during the session — use /plan at the start, /test after each feature is built, and /review before the final PR.
5

Devin builds it and verifies it works

Devin treats internal tools like any production feature — it writes the code, adds tests, and then opens the app in its built-in browser to verify the UI works end-to-end.
  1. Investigates your codebase — Finds your DataTable and Calendar components, reads your Prisma schema, and studies the existing /internal/ page layout
  2. Creates the database migration — Adds pto_requests and pto_balances tables via Prisma
  3. Builds the pages — Request submission form, manager approval queue, calendar view, and balance dashboard under /internal/pto
  4. Integrates Slack — Sends webhook notifications when requests are submitted and when they’re approved or denied
  5. Writes tests — Unit tests for PTO balance calculations and date-overlap detection, API tests for the request endpoints, integration tests for the approval workflow
  6. Opens the app in its browser — Navigates to every page, submits a test PTO request, approves it from the manager view, verifies the calendar updates, checks the dashboard numbers, and tests edge cases like overlapping dates and exceeding balances
  7. Opens a PR — Delivers everything: migration, seed script, application code, tests, and a README section explaining how to use the tool
Browser verification catches issues that automated tests miss — broken form layouts, a calendar that renders but doesn’t respond to clicks, or a submit button that doesn’t clear the form after success.
6

Extend your tool

Once the base tool works, add features in follow-up sessions:
7

Review the PR with Devin Review

Once Devin opens the PR, use Devin Review to review the changes. Devin Review has full context of your codebase and can catch bugs, security issues, and style inconsistencies across the diff.