Skip to main content
Better prompts mean better results. This guide shows you how to write prompts that Invariant executes reliably.

​
Anatomy of a Good Prompt

Every effective prompt has four parts:
  1. Objective - What you want done
  2. Context - Why or what it’s for
  3. Criteria - How you’ll know it’s complete
  4. Details - Specific requirements or constraints

​
Examples

​
Bug Triage

Weak: 
Check my GitHub issues
Strong: 
Check GitHub issues labeled "bug" opened in the last 7 days.
Categorize by severity (critical, high, medium, low).
For critical bugs, include: file location, error message, and steps to reproduce.
Output as a table I can share with the team.
Why it works:
  • Specific time range (last 7 days)
  • Clear categorization criteria
  • Defines what details to include
  • Specifies output format

​
Daily Standup

Weak: 
Give me a standup
Strong: 
Every weekday at 9am, generate my standup from:
- GitHub commits from yesterday
- Linear issues I moved or completed
- PRs I opened or reviewed

Format as 3 bullets: Yesterday, Today, Blockers.
Keep each bullet under 15 words.
Why it works:
  • Specific schedule (weekday 9am)
  • Lists exact data sources
  • Defines format and length
  • Easy to scan and share

​
Meeting Prep

Weak: 
Prepare me for my meeting with Acme Corp
Strong: 
I have a sales meeting with Acme Corp tomorrow.

Research and prepare:
- Company overview (industry, size, recent funding)
- Key people I'm meeting with (from LinkedIn)
- Their likely pain points based on their industry
- 3 questions I should ask about their workflow challenges

Keep the brief under 1 page.
Why it works:
  • Clear purpose (sales meeting)
  • Specific research areas listed
  • Actionable output (questions)
  • Length constraint

​
Release Notes

Weak: 
Write release notes
Strong: 
Generate release notes from PRs merged since tag v2.3.0.

Group into:
- New Features (PRs with "feature" label)
- Bug Fixes (PRs with "fix" label)
- Improvements (everything else)

For each item: one-line summary from PR title.
Format for our changelog in markdown.
Why it works:
  • Specific starting point (tag v2.3.0)
  • Clear grouping logic
  • Defines summary format
  • Specifies output format

​
Common Mistakes

​
Too vague

Summarize my emails
Better: “Summarize unread emails from today. Categorize as: needs response, FYI, spam.”

​
Missing time range

Show my GitHub activity
Better: “Show my GitHub commits and PRs from this week.”

​
No output format

Research competitor pricing
Better: “Research competitor pricing and output as a comparison table with columns: company, plan, price, key features.”

​
Ambiguous tool reference

Post an update
Better: “Post to #engineering on Slack: ‘Deployed v2.4 - release notes here.’”

​
Scheduling Tips

When scheduling recurring tasks: Be specific about timing: 
Every weekday at 9am EST
Not: “Every morning” Define the window: 
Summarize activity from the last 24 hours
Not: “Summarize recent activity” Handle edge cases: 
If no new issues, say "No new bugs today" instead of sending nothing

​
Best Practices

  1. Start simple, then refine - Run a basic version first, then add criteria
  2. Use specific identifiers - “PR #42” not “my latest PR”
  3. Include tool names - “Post to Slack #engineering” not just “post an update”
  4. Set output expectations - “Keep it under 5 bullets” or “one paragraph”
  5. Test before scheduling - Run manually first to verify results