Add postgres-database-migration and ghost-database skills#101
Add postgres-database-migration and ghost-database skills#101
Conversation
Comprehensive guide for safe PostgreSQL schema migrations: DDL lock reference, safe migration patterns, timeout strategies, rollback planning, and fork-based testing. Reference files provide backfill strategies, validation queries, and a complete end-to-end example. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- Add ghost-database skill covering Ghost CLI, MCP integration, Spaces, dedicated instances, and database lifecycle management - Add postgres-database-migration and ghost-database to the postgres router skill with symlinked references - Symlink migration sub-references (backfill, validation, complete example) into the router for reliable path resolution Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Spaces are the account-level container with shared compute hours. Dedicated instances are a promotion path for always-on databases, not a separate tier. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
nathanjcochran
left a comment
nathanjcochran
left a comment
There was a problem hiding this comment.
I only reviewed the Ghost skill. Largely looks good to me, but I left a handful of comments.
It's also worth noting that the skill mentioned dedicated databases but they aren't technically support yet, so we might want to wait to merge this until that work is done? And at that point, we'll want to add info about the additional commands for creating/forking dedicated instances, as well as the payment-related commands (i.e. ghost payment).
Additionally, we might want to talk a bit about API keys (i.e. the ghost api-key commands) and how to use them to access the API programatically? Seems like it could be useful in some cases (e.g. if building an app that integrates with Ghost directly, or if setting up a CI pipeline that forks a database to run tests against).
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Commands take the database ID (e.g. abc123), not the name. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Added: api-key, logout, config, mcp, feedback, version, completion. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
Re: dedicated instances — leaving them in for now since dedicated instance support should be merged soon. We can update with the additional commands (ghost payment, etc.) when that lands. |
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Fork-based testing doesn't catch concurrent traffic issues. For most apps this is fine. For very high-uptime apps, PgDog mirroring can replay production traffic against the fork. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
|
||
| Additional features: | ||
| - **CLI and MCP native:** create and query databases from the terminal or any MCP-compatible agent | ||
| - **Instant forking:** full database copies in seconds for safe experimentation |
There was a problem hiding this comment.
I thought we were avoiding "instant", since few people consider 90s to be instantaneous.
| ## Installation | ||
|
|
||
| Multiple installation methods are provided. If you aren't sure, use the first one. | ||
|
|
||
| ### Install Script (macOS/Linux/WSL) | ||
|
|
||
| ```bash | ||
| curl -fsSL https://install.ghost.build | sh | ||
| ``` | ||
|
|
||
| ### Install Script (Windows PowerShell) | ||
|
|
||
| ```powershell | ||
| irm https://install.ghost.build/install.ps1 | iex | ||
| ``` | ||
|
|
||
| ### Debian/Ubuntu | ||
|
|
||
| ```bash | ||
| curl -s https://packagecloud.io/install/repositories/timescale/ghost/script.deb.sh | sudo os=any dist=any bash | ||
| sudo apt-get install ghost | ||
| ``` | ||
|
|
||
| ### Red Hat/Fedora | ||
|
|
||
| ```bash | ||
| curl -s https://packagecloud.io/install/repositories/timescale/ghost/script.rpm.sh | sudo os=rpm_any dist=rpm_any bash | ||
| sudo yum install ghost | ||
| ``` |
There was a problem hiding this comment.
I think this skill could benefit from some progressive disclosure, and this section in particular seems like it'd usually be a waste of tokens. You only need to install ghost once.
There was a problem hiding this comment.
True. I think maybe we should try to decide whether this skill is mostly for getting Ghost set up the first time (in which case maybe listing all of the installation methods here is fine), or if we think it's useful as a continual reference for how to use Ghost. Personally, I'm kind of skeptical that it's going to be helpful once Ghost is already installed (since the MCP is self-describing anyways, and this skill would just be a conflicting source of information). See my other comment about that. I think maybe we should try to narrow in on exactly how/when we want this skill to be used, because I'm a little concerned that this skill could end up taking priority over using the Ghost MCP tools directly.
There was a problem hiding this comment.
Yeah, that's fair. I agree this skill is redundant with the MCP tools, and the skill description over-promises on what it is for in a way that could be problematic.
I kinda think there should be a "choosing a db provider" skill, and then possibly an "installing ghost" sub-page.
| # Open interactive psql session | ||
| ghost psql abc123 |
There was a problem hiding this comment.
We might want to say that this requires psql to be installed and in your PATH
| - Get a connection string for a Ghost database | ||
| - Run SQL queries against a Ghost database | ||
| - Resume or delete Ghost databases | ||
| - Set up the Ghost MCP server or CLI |
There was a problem hiding this comment.
Given that the Ghost MCP currently proxies the pg-aiguide MCP tools (including view_skill), are we at all concerned that this skill could create confusion for agents that are already using the Ghost MCP?
Like, if a user asks to fork a database, how will the agent decide between using this skill (which mostly recommends using ghost CLI commands directly, which is not really what we want if the MCP is installed) or just calling the ghost_fork tool? Maybe it would use the skill first and then still decide to call the MCP tool afterwards... but even in that case, using the skill would just be extra wasted tokens (the Ghost MCP is already self-describing, so if it's already installed, I don't think there's much more that this skill would help with, beyond maybe explaining some of the less well-documented features).
It seems like this skill is mostly geared towards setting up Ghost the first time and understanding its capabilities (e.g. when evaluating whether to use it). But if Ghost is already installed (as MCP server), I feel like this skill could potentially be counter-productive.
Any ideas for what we should do about that? We could potentially just filter this skill out when we proxy the view_skill tool, but we don't do anything like that currently (we proxy the tools as-is), and in any case, it wouldn't work for pre-existing versions of Ghost that are already in the wild.
| ## Installation | ||
|
|
||
| Multiple installation methods are provided. If you aren't sure, use the first one. | ||
|
|
||
| ### Install Script (macOS/Linux/WSL) | ||
|
|
||
| ```bash | ||
| curl -fsSL https://install.ghost.build | sh | ||
| ``` | ||
|
|
||
| ### Install Script (Windows PowerShell) | ||
|
|
||
| ```powershell | ||
| irm https://install.ghost.build/install.ps1 | iex | ||
| ``` | ||
|
|
||
| ### Debian/Ubuntu | ||
|
|
||
| ```bash | ||
| curl -s https://packagecloud.io/install/repositories/timescale/ghost/script.deb.sh | sudo os=any dist=any bash | ||
| sudo apt-get install ghost | ||
| ``` | ||
|
|
||
| ### Red Hat/Fedora | ||
|
|
||
| ```bash | ||
| curl -s https://packagecloud.io/install/repositories/timescale/ghost/script.rpm.sh | sudo os=rpm_any dist=rpm_any bash | ||
| sudo yum install ghost | ||
| ``` |
There was a problem hiding this comment.
True. I think maybe we should try to decide whether this skill is mostly for getting Ghost set up the first time (in which case maybe listing all of the installation methods here is fine), or if we think it's useful as a continual reference for how to use Ghost. Personally, I'm kind of skeptical that it's going to be helpful once Ghost is already installed (since the MCP is self-describing anyways, and this skill would just be a conflicting source of information). See my other comment about that. I think maybe we should try to narrow in on exactly how/when we want this skill to be used, because I'm a little concerned that this skill could end up taking priority over using the Ghost MCP tools directly.
4 participants
Summary
Test plan
./bun run validate-skillspasses for all skillspostgres/references/resolve correctlynpx skills add timescale/pg-aiguide --listshows the new skills🤖 Generated with Claude Code