Sharing Your Work

Pick by what you're sharing and who it's for

HQ has four ways to share, and they map to four different questions:

• "Look at this thing I made" → /deploy, turns an artifact into a live web link.
• "You need access to these files" → /hq-share, grants access to files in the company vault.
• "Hey, heads up" → /dm, sends a teammate a direct message from HQ.
• "This project is yours now" → /delegate, hands a whole project to a teammate or a bot.

/deploy, turn an artifact into a live link#

When HQ builds you something viewable, a report, a dashboard, a landing page, a deck, /deploy publishes it to the web and hands you a URL:

/deploy

Run it from the project you built (or just ask "deploy this"). HQ builds the artifact, shows you a local preview first, runs safety checks, uploads, and returns a link like https://your-app.indigo-hq.com. Anything sensitive-looking (customer data, financials) is automatically gated rather than left open.

Every deployed link has exactly one access level:

Just say what you want: "deploy this, company-only" or "deploy this so only alice@client.com can see it." Re-deploying the same project updates the same link. To add someone to a private link later, ask HQ to share the deploy with their email.

Want feedback right on the page? Turn on comments when you deploy ("deploy this with comments"). See Getting Feedback with Comments on Your Deploys. Building a full app with its own server code? See Deploying Full-Stack Apps.

Two notes on passwords: they're announced once and saved locally (HQ won't re-print a password into chat, it tells you how to retrieve it), and if you forget one, the retrieval command is in the deploy confirmation.

/hq-share, share files from the vault#

The vault is your company's shared cloud file storage, the cloud side of HQ that sync keeps up to date with your machine. /hq-share grants access to a vault path in one of two modes, chosen automatically:

Single-use link (no recipient named):

/hq-share reports/q3/

HQ mints an encrypted, single-use link and opens a share page in your browser where you pick recipients, teammates, groups, or the whole company, and set read or write per person. The link expires in 15 minutes and dies after one use. That's a security feature: the link is only the doorway to granting access; the access itself is durable. If a link expires before it's used, just run the command again, fresh links are free.

Direct grant (recipient named with --with):

/hq-share reports/q3/ --with alice@acme.com --permission read

No browser, no link. HQ writes the access grant directly and confirms it. The recipient must be a real email address, a group ID, or @all (everyone in the company). If you skip --permission, it defaults to read; HQ will always confirm with you before granting write, since that's a bigger deal. Add --company acme when you belong to more than one company.

One subtlety worth knowing: a direct grant to someone who has never signed into HQ sits dormant until they do, it doesn't notify them. If you want them to receive something right now, use the single-use link (they can open it immediately) or pair the grant with a /dm.

/dm, message a teammate from HQ#

/dm alice@acme.com "Q3 report is live, link in the vault under reports/q3/"

The message arrives in the recipient's HQ app under Direct messages, with a notification. You can DM anyone you share an active company with, including yourself, which makes a handy reminder system. You can use a first name ("dm alice ...") and HQ confirms exactly who it resolved to before sending.

Two extras make /dm more than a chat message:

• Attach a prompt: add --prompt "..." and the recipient gets a one-click Copy prompt button, ready-made instructions they can paste into their own HQ session. This is how you hand work to a teammate's HQ, not just to the teammate. There's also --details for a longer write-up they can open.
• Schedule delivery: --in 2h or --at 2026-07-09T09:00:00Z delivers later, even if you're offline at that moment.

/dm me@acme.com "Send the client follow-up" --in 3h
/dm alice@acme.com "Can your bot pick this up?" --prompt "Deploy the pricing-calculator project and verify the live link works."

Never put secrets or credentials in a DM, messages are stored server-side. For credentials, use /hq-secrets.

/delegate, hand a project to someone#

When a whole project needs to move to someone else, /delegate does the handoff in one step. It works for teammates and for cloud bots (AI teammates with their own HQ account).

/delegate alice

Run it from inside the project, or name the project: /delegate alice pricing-calculator. HQ then:

1. Confirms exactly who "alice" is. If more than one person matches, it asks you to pick.
2. Gives them access to the project's files and any passwords or keys the project needs.
3. Checks the access actually landed.
4. Makes them the project's owner.
5. Sends them a direct message with a summary of the project and how to pick it up.

Keeping ownership? Add --share. The other person gets the same access and the same summary message, but the project stays yours. Use this when you're bringing someone in to help, not handing it over.

/delegate alice --share

Add --dry-run to see exactly what HQ would do without changing anything.

A project needs a project spec (a PRD, the plan HQ writes for bigger projects) before you can delegate it, since that's what tells the other person what they're taking on. If HQ says there isn't one, ask it to write one first.

Decision guide: which one when?#

Rule of thumb: /deploy shares a view, /hq-share shares access, /dm shares a message, and /delegate hands over a project.

Common questions#

If you get stuck#

Most sharing failures are sign-in problems, run /hq-whoami to check your session and /hq-login to refresh it. If a deploy or share still fails, see The "I'm stuck" guide or file /hq-bug.