Writing Custom Prompts for Remocode Standup Reports

Why Customize the Standup Prompt?

Remocode's default standup prompt instructs the AI to act like a scrum master, producing structured reports with status, progress, and issues for each pane. This works well for most teams, but different roles and projects benefit from different report styles.

A CTO reviewing five projects needs a different report than a developer debugging one feature. A security-conscious team needs different emphasis than a team focused on shipping speed. Custom prompts let you shape the AI's analysis to match your needs.

Anatomy of a Good Report Prompt

An effective standup prompt should specify:

• ●Role — who the AI should emulate (scrum master, tech lead, QA engineer)
• ●Focus — what aspects of terminal output to prioritize
• ●Format — how the output should be structured
• ●Verbosity — how detailed or concise the report should be

The default prompt handles all four: it emulates a scrum master, focuses on progress and blockers, uses the PaneName/Status/Progress/Issues format, and targets moderate verbosity. Your custom prompt can adjust any of these dimensions.

Prompt Templates for Different Roles

For Team Leads: Executive Summary

Provide a brief executive summary of all terminals. For each pane,
give one sentence covering current status and any action items.
Group by project if pane names include project identifiers. End
with a summary line counting total Active, Blocked, and Error states.

This produces a scannable overview that a team lead can read in 30 seconds. Details are sacrificed for speed.

For Developers: Technical Detail

For each terminal, report the current file being modified, the most
recent command output (success or failure), any error messages with
line numbers, and test results if visible. Include specific function
or class names when they appear in the output.

This gives developers actionable technical detail — they can read the report and know exactly where to look in the code.

For QA Engineers: Testing Focus

Focus on test-related activity across all terminals. Report test
suite status (passing/failing counts), any new test failures since
the last report, and any terminals where tests are not being run.
Flag any terminal where error output suggests untested code paths.

This highlights testing health across the project, making it ideal for QA team members who need to track test coverage.

For Security Reviews: Vulnerability Focus

Analyze terminal output for any security-relevant activity. Flag
files related to authentication, authorization, input handling,
or data storage. Note any terminals where environment variables,
API keys, or credentials appear in the output. Report any new
dependencies being installed.

This turns the standup into a lightweight security scan, complementing the dedicated audit command with ongoing awareness.

Controlling Verbosity

Verbosity is one of the most useful things to customize. Here are examples at different levels:

Minimal (1-2 lines per pane)

One line per pane: status emoji and key fact. Skip Idle panes.

Standard (3-5 lines per pane)

This is approximately what the default prompt produces. Each pane gets a status, progress summary, and issues list.

Verbose (detailed paragraph per pane)

For each pane, provide a detailed paragraph covering all visible
activity since the last report. Include file names, command outputs,
error messages, and test results. Do not summarize — be comprehensive.

Match verbosity to your check-in frequency. If you get reports every 10 minutes, minimal is best. If you get one report per day, verbose captures more useful context.

Conditional Reporting

Advanced prompts can include conditions:

Report all panes, but apply different detail levels based on status.
For Active panes: one sentence summary. For Blocked panes: full
detail including what the blocker appears to be and suggested
resolution. For Error panes: include the complete error message
and stack trace if visible. Skip Idle panes entirely.

This focuses attention on problems while keeping normal progress reports brief. Blocked and Error states get the detail needed for action; Active states just confirm things are working.

Testing Your Custom Prompt

After setting a custom prompt, wait for the next scheduled standup report and review the output. Ask yourself:

• ●Does it provide the information I actually need?
• ●Is it the right length for how often I receive reports?
• ●Does it highlight the issues I care about?
• ●Would a teammate understand this report without additional context?

Iterate on the prompt until the reports match your needs. Small wording changes can significantly affect output quality — be specific about what you want the AI to focus on and how to format it.

Sharing Prompts Across the Team

If your team agrees on a reporting format, share the custom prompt so everyone's reports are consistent. This is especially valuable when reports land in a shared Telegram channel — uniform formatting makes it easy to scan multiple developers' reports quickly.