dotnet stack
These tools load when thedotnet stack is installed. They provide database access, deployment control, log viewing, and production container management for .NET projects.
dev_db
Queries the project’s SQLite database in read-only mode. Omitting query and table lists all tables. Takes no required parameters.
string
default:"dev"
Environment to query. One of
dev (local) or prod (VPS).string
SQL query to execute. Read-only. Omit to list all tables.
string
Shorthand to query a single table (
SELECT * FROM table LIMIT n). Used instead of query for simple table reads.integer
default:"20"
Row limit for
table queries.dev_deploy
Triggers a production deployment after verifying that the git state is clean and pushed. Auto-increments the project version before deploying. Takes no required parameters.
string
default:"patch"
Version bump type. One of
major, minor, patch. Defaults to patch.dev_logs
Views logs from the deployed application instance. Takes no required parameters.
string
default:"dev"
Environment to view logs from. One of
dev (local) or prod (VPS).string
default:"both"
Log source. One of
docker (container stdout/stderr), app (file logs), or both.integer
default:"50"
Number of lines to display.
boolean
default:"false"
When
true, streams logs in real time.array of strings
Filter by log level. Accepted values:
Debug, Information, Warning, Error, Fatal. Omit to show all levels.dev_release
Starts the development environment in Release mode for local production testing. Takes no parameters.
prod_start
Starts the production container on the VPS. If the container is already running, it is stopped first before restarting. Takes no required parameters.
boolean
default:"false"
When
true, pulls the latest image before starting the container.prod_stop
Stops the production container on the VPS. Takes no required parameters.
boolean
default:"false"
When
true, stops the container immediately without a graceful shutdown.start-from-jira workflow
These tools load when thestart-from-jira workflow is installed. They support the research and repository setup phase that happens before implementation begins.
atlassian_download
Downloads attachments from a Jira issue and its child issues, and from any linked Confluence pages. Files are saved to briefing/docs/ with consistent naming. Returns a manifest of downloaded files. Required: jira_key.
string
required
Jira issue key (e.g.
PROJ-1234). The tool also scans child issues and linked Confluence pages.string
Target directory relative to the project root. Defaults to
.bot/workspace/product/briefing/docs.repo_clone
Clones a repository from Azure DevOps, creates an initiative branch, and configures NuGet authentication. Returns the clone path, default branch, and working branch name. Required: project, repo.
string
required
Azure DevOps project name (e.g.
Platform, Services).string
required
Repository name (e.g.
OrderService).repo_list
Lists all cloned repositories in repos/ with their status - clone state, branch information, and analysis state. Takes no parameters.
research_status
Checks research artefact completeness: which briefing files exist, which are missing, and the overall research progress. Takes no parameters.
start-from-pr workflow
These tools load when thestart-from-pr workflow is installed. They provide pull request context before implementation begins.
pr_context
Reads a GitHub or Azure DevOps pull request, including its description, linked issues, and changed files. When pr_url is omitted, dotbot auto-detects the pull request from the current git branch.
string
GitHub or Azure DevOps pull request URL (e.g.
https://github.com/acme/widgets/pull/42). Omit to auto-detect from the current branch.