How the skill recognizes an existing share
After the first upload, the skill writes a small `.instashare.json` sidecar beside the source session. It contains the assigned slug, public URL, and the share-specific delete token. On the next run, the skill uses that information to send an authorized update to the existing slug.
If the remote share was deleted or the sidecar no longer has valid authority, the skill falls back to creating a new share and replaces the sidecar with the new controls.
What an update preserves and replaces
The short identifier and original creation time remain stable. The stored transcript and derived presentation data are refreshed from the current local JSONL. New inline images are extracted and attached to the share as needed.
This is replacement, not version history. A recipient opening the URL sees the latest uploaded state, and InstaShare does not expose earlier revisions of the transcript.
Choose a new link when history matters
A stable link is ideal for a single continuing investigation. If you need immutable checkpoints, separate audiences, or a before-and-after comparison, create separate shares instead of overwriting the first one.