View all documentations

Commands Documentation

This document describes all available public commands that can be executed via GitHub issue or pull request comments using the @holdex bot.

Command Format

All commands follow the pattern:

@holdex <object> <action> [arguments...]

Arguments can be provided as:

  • Flags: --key=value or --key="value with spaces"
  • Positional arguments: Some commands accept positional arguments (values without flags)

Available Commands

1. Goal Create Spec

Creates docs/specs/<name>.md on main and links it under Spec. Only when Spec has no URL yet.

The file name is derived from the Goal title (e.g. Goal: Spec workflowspec-workflow.md); if taken, -2, -3, … are used. The Spec link stays the same if the Goal title changes later.

If main is protected, Wizard retries after granting itself access when it can; for org-level rules, follow the comment on the Goal to add Wizard as a bypass, then run this command again.

See Spec workflow for full details.

Location: Goal & draft goal issue comments only

Command:

@holdex goal create-spec

Example:

@holdex goal create-spec

2. Goal Create Google Doc

Creates a Google Doc under Stakeholders Interview section for current Goal.

Location: Goal & draft goal issue comments only

Command:

@holdex goal create-google-doc

Example:

@holdex goal create-google-doc

3. Goal Attach Google Doc

Attaches a Google Doc to current Goal under Stakeholders Interview section.

Location: Goal & draft goal issue comments only

Command:

@holdex goal attach-google-doc <doc> | --doc=<doc>

Args Schema

Arguments:

Property Type
doc (*) string (min length: 1)

(*) Required.

Example:

@holdex goal attach-google-doc https://docs.google.com/document/d/1234567890

4. Goal Set Eta

Updates the ETA of the current Goal and syncs it to the Oracle Board. Updates the ETA: line in Deadline section.

Location: Goal & draft goal issue comments only

Command:

@holdex goal set-eta <eta> | --eta=<eta>

Args Schema

Arguments:

Property Description Type
eta (*) Estimated completion date in DD-MMM-YYYY format (e.g., 01-Jan-2026) or relative days from today (e.g., +5d) string (min length: 1)

(*) Required.

Example:

@holdex goal set-eta 01-Jan-2026
@holdex goal set-eta +5d

5. Bug Set Eta

Updates the ETA of the current Bug and syncs it to the Oracle Board.

Location: Bug issue comments only

Command:

@holdex bug set-eta <eta> | --eta=<eta>

Args Schema

Arguments:

Property Description Type
eta (*) Estimated completion date in DD-MMM-YYYY format (e.g., 01-Jan-2026) or relative days from today (e.g., +5d) string (min length: 1)

(*) Required.

Example:

@holdex bug set-eta 01-Jan-2026
@holdex bug set-eta +5d

6. Pr Submit Time

Submits or updates the total time spent on a pull request. Use this to set your total time, or to correct a previous submission. Accepted while the PR is open. After merge, must be submitted within 24 hours. Rejected if the PR was closed without merging.

Location: Pull request comments only

Command:

@holdex pr submit-time <time> | --time=<time>

Args Schema

Arguments:

Property Description Type
time (*) Time spent on the PR in format like 15m, 1h, 2h30m, or 1.5h string (min length: 1)

(*) Required.

Example:

@holdex pr submit-time 2h30m

7. Pr Add Time

Adds time on top of any previously submitted time for a pull request. Accepted while the PR is open. After merge, must be submitted within 24 hours. Rejected if the PR was closed without merging.

Location: Pull request comments only

Command:

@holdex pr add-time <time> | --time=<time>

Args Schema

Arguments:

Property Description Type
time (*) Time to add on top of any previous submission, e.g. 15m, 1h, 2h30m, or 1.5h string (min length: 1)

(*) Required.

Example:

@holdex pr add-time 1h15m

8. Calendar Reserve

Reserves up to 10 candidate meeting slots for an external contact (identified by their Attio People record id) by placing a tentative hold for each on the creator's calendar and any teammates named with --with. Replies with a copy-ready, dual-timezone message and a pick-link the creator shares themselves — Wizard never sends it. --with names must already have connected Google Calendar with write consent.

Location: Issue comments only (not in pull requests)

Command:

@holdex calendar reserve <attioPersonId> | --attioPersonId=<attioPersonId> [--with=<with>] [--days=<days>] [--per_day=<per_day>] [--extra=<extra>] [--length=<length>] [--order=<order>] [--guest_tz=<guest_tz>] [--buffer=<buffer>]

Args Schema

Arguments:

Property Type
attioPersonId (*) string (min length: 1)
with string
days number (int, >0)
per_day number (int, >0)
extra number (int, ≥0) (nullable)
length number (int, >0)
order 'spread' | 'earliest' | 'latest'
guest_tz string
buffer number (int, ≥0) (nullable)

(*) Required.

Example:

@holdex calendar reserve 018f2c3a-... --with=teammate1,teammate2 --days=3 --per_day=3 --length=30 --order=spread --guest_tz=Australia/Sydney --buffer=15

9. Calendar Cancel

Cancels the pending calendar reservation opened by @holdex calendar reserve in this same issue thread — releases every held slot without booking any. Only the reservation's own creator can cancel it.

Location: Issue comments only (not in pull requests)

Command:

@holdex calendar cancel

Args Schema

Arguments:

Property Type

All properties are optional.

Example:

@holdex calendar cancel

Special Commands

These commands use different event handling patterns and are processed separately from the standard command pipeline. It may use a different command pattern than the standard commands.

1. Bug Report

Report the commit and author that introduced a bug. Use this when fixing a bug to attribute it to the original source. Only the topmost bug report comment on the PR is recognized. Before merge, edit or delete that comment to change the report. The commit URL must be a valid GitHub commit link. See Bug Submission Notice for the full workflow.

Command Pattern:

@holdex bug commit <commit-url> && bug author @<username>

Example:

@holdex bug commit https://github.com/holdex/my-repo/commit/1234567890 && bug author @johndoe

2. Fix Pr Dispute

Dispute a previous bug report after the PR has been merged. Use this to correct an incorrect bug attribution. After merge, editing or deleting the original report no longer works — use dispute instead. See Bug Submission Notice for the full workflow.

Command Pattern:

@holdex bug dispute <commit-url> && bug author @<username>

Example:

@holdex bug dispute https://github.com/holdex/my-repo/commit/1234567890 && bug author @johndoe

3. Guideline Violation

Report a guideline violation by referencing its ID (e.g., G123). Use this to flag code that violates project guidelines.

Command Pattern:

@holdex G<number>

Example:

@holdex G123

Usage Notes

  1. Command Execution Location: Each command has specific location restrictions (see individual command documentation above). Commands can be restricted to:

    • Issue comments only: Cannot be executed in pull request comments
    • Goal & draft goal issue comments only: Must be executed in a goal or draft goal issue (not a regular issue or pull request)
    • Bug issue comments only: Must be executed in a bug issue (not a regular issue or pull request)
    • Client card issue comments only: Must be executed on a Client card (issue title starts with Client:)
    • Pull request comments only: Can only be executed in pull request comments
    • Issue and pull request comments: Can be executed in both issue and pull request comments All commands require an organization context (they must be run in a repository that belongs to an organization).
  2. Command Pattern: Commands must follow the exact pattern @holdex <object> <action> [arguments...]. The object and action are case-insensitive and will be normalized to lowercase.

  3. Error Handling: If a command fails, the bot will post a comment with error details, including the specific error message to help with troubleshooting.

  4. Success Indication: Successful commands will add a reaction to your comment:

    • 👀 (eyes) reaction indicates the command was successfully parsed and triggered
    • 🚀 (rocket) reaction indicates the command task completed successfully
  5. Asynchronous Execution: Commands are executed asynchronously. After parsing and validation, the command is triggered and runs in the background. The initial reaction (👀) indicates the command was accepted, while the final reaction (🚀) indicates completion.

  6. Positional Arguments: Some commands support positional arguments as a convenience - they can be used instead of flags for common parameters. Positional arguments are captured for arguments that don't start with --.

  7. Default Values: Some optional parameters have default values. Check individual command documentation above for details. If a parameter is not provided and has no default, it will be omitted.

  8. Value Formatting:

    • Use quotes for values with spaces: --key="value with spaces" or --key='value with spaces'
    • Values without spaces don't need quotes: --key=value
    • Single or double quotes are supported
    • Values are parsed exactly as provided (case-sensitive for values)
  9. Code Fences: Commands inside fenced code blocks (```...```) are excluded and will not be executed. This prevents accidental execution when showing command examples in documentation or comments.