---
name: tow-send-vault
description: >-
  Use when sending selected project content to the connected Obsidian vault as a new note.
  Triggers: "send this to my vault", "save this in my second brain", "put this in my vault",
  and after project-document organization to offer "shall I also put this in the vault?".
---

# tow-send-vault

Bring selected project content into the connected vault as a new note. Read the [conventions](../../docs/methodology.md) and, for a vault using the TOW schema, the [TOW recipe](../../docs/recipe.md) (§3 tags, §4 frontmatter). Run `tow config` to resolve the effective `tagDictionary`/`categoryDictionary` paths, and read the vault's `tow/tags.md` and `tow/categories.md` manuals when present before drafting. Only `tow send` writes to the vault; it never overwrites an existing note. Use the paths from `tow config`.

## Workflow

1. **Select source and scope.** Use the exact Markdown file or excerpt the user selects, whether tracked or not. For a project document set, use `tow project files`; list untracked and ignored files by name before reading content, and include those only when selected. Do not send a whole file when the user selected only an excerpt. Preserve the exact selected bytes; create any scratch source copy only after approval. If the user finishes project-document organization, offer, “Shall I also put this in the vault?”
2. **Resolve the destination.** Read `tow config` and applicable vault manuals/rules. Propose a vault-relative path inside one configured note folder: project-specific content → `<projects>/<project>/`; reusable domain knowledge → `<resources>/<domain>/`; life-area content → `<areas>/<area>/`; unclear destination → configured `<inbox>/`. Keep the destination under a configured note folder and choose a filename appropriate to the selected content; never overwrite. `tow send` accepts only the folders that `projects`, `areas`, `resources` and `inbox` name in `tow config`, also with `"scope": "vault"`. When the user's destination is another folder, say so and offer the config change through `tow-setup` (set one of those keys to that folder); do not substitute a different folder or write the note with file tools. If the vault or its destination cannot be accessed, print the host permission hint from `tow-query` and stop.
3. **Draft metadata and tags.** Preserve the selected content verbatim as the note body; fit the vault by choosing the filename and adding only necessary metadata. If the selected source has frontmatter, offer its keys as metadata to merge into the new note's frontmatter and ask which keys the user approves; never copy source frontmatter into the body. Follow the vault's adopted schema and existing metadata conventions; don't introduce a schema the vault hasn't adopted. Record provenance in `source:` using the repository URL or name, source path and commit when available. Recommend concept tags from the selected content and the configured tag dictionary. Pre-select existing dictionary concepts, and list new concepts separately; attach new concepts only when the user selects them. New categories, if needed, are listed as new concepts separately and registered through `tow-classify` only if selected and approved.
4. **Present one batch proposal.** Show one table for all selected content with source, destination, proposed filename/frontmatter/tags and any new concepts. Get one approval for the whole batch. Do not create the note or scratch files before approval. This approval covers the listed table; a preview does not authorize changed destinations or metadata.
5. **Send the approved draft.** For the approved batch, write the proposed note to a scratch file and keep the selected original content in a separate source file. Run `tow send <draft> <vault-relative-dest> --source <source>` as a read-only preview, then use the same command with `--apply` under that same approval if the preview matches the table. If it differs, stop and obtain approval for the changed plan. The helper verifies the body bytes match the selected source and creates a new file exclusively. If the user explicitly requests a summary, rewrite, restructuring or other transformation, follow the post-curation contract and pass `--transformed`; otherwise never summarize or rewrite the body.
6. **Verify and report.** Read back the new vault note and verify metadata, provenance, destination and exact body preservation. Report the created path and selected source. Leave the project source unchanged. If the host denies vault access, print its permission hint and stop; do not retry through shell or another tool. TOW's checks are not an OS-level access boundary.