git:20260911.a823e04 to git:20261002.4768f11

---

name: shared-space

description: Record and use a team knowledge base that lives outside the vault - a network drive, Google Drive, OneDrive or SharePoint folder. Survey mode reads the place and writes down how it is organised into projects/NNNN-<slug>/shared/; place mode says where a vault note belongs in it. Use when the user wants to register a team share for a project, refresh what is recorded about one, or work out where to file something.

argument-hint: "survey <project> <location> | place <note>"

---

# shared-space — the team knowledge bases outside the vault

A vault project's notes are for the owner and their agents. A team keeps its

own material somewhere else — a network drive, a Google Drive or SharePoint

folder — organised by conventions nobody wrote down anywhere the vault can see.

This skill records those places against a project, and uses what it recorded to

say where something belongs. It has two modes.

| Mode | What it does |

|---|---|

| `survey <project> <location>` | Read the place, work out how it is organised, and write `projects/NNNN-<slug>/shared/<name>.md` |

| `place <note>` | Say where a vault note belongs in the project's shared spaces, and prepare the copy |

The app's **Projects** tab lists what `shared/` holds and offers a prompt that

launches survey mode; nothing about these notes is written by the app itself.

## What is worth recording

**The rules, not the folder tree.** Naming conventions, which kind of document

goes where, who owns what, what the review or approval step is. A listing of

every folder is stale within weeks and nobody reads it; keep the structure to

the parts that orient a reader.

A place with no rules to record is just a link, and belongs in the project's

`links.md` instead. Do not create a shared-space note for one.

## The note

`projects/NNNN-<slug>/shared/<name>.md`. One file is one place; the folder is the

registry, so nothing lists these notes in `_index.md`. `<name>` is English

kebab-case, like every other folder name in the vault.

```markdown

---

type: shared-space

title: Design team share

kind: network-drive # network-drive | google-drive | onedrive | sharepoint | other

location: //fileserver/design/projectX

access: mapped to Z:, needs VPN

direction: read-only # read-only | export-ok

surveyed: 2026-09-05

---

## Structure

- `01_仕様/` — specifications, one folder per release

- `02_議事録/` — meeting minutes, `YYYY-MM-DD_<topic>.md`

- `99_archive/` — anything superseded

## Rules

- A file name starts with the date in `YYYYMMDD` (stated: `運用ルール.md`)

- Specifications are Word, minutes are Markdown (inferred)

- The release folder is created by the PM, not by contributors (stated)

## Placement

- Task deliverables about the UI → `01_仕様/<release>/`

- Meeting notes → `02_議事録/`

## Memo

The owner's own notes. Neither the app nor this skill rewrites this section.

```

`direction` is the safety valve, and it is the field to get right:

- `read-only` — never write anything into the place. This is the default, and

what a missing or unrecognised value means.

- `export-ok` — the owner has said material may be filed into it.

## Survey mode

1. **Resolve the project.** The first argument is a project slug

(`projects/NNNN-<slug>/`) or part of a project's title. Vault resolution follows

`task-start`: `WORKHUB_VAULT` → the current directory when it is a vault

(it has `tasks/` and `_ai/`) → `vault_path` in

`%APPDATA%\workhub\config.json`. Ask when nothing matches or several do.

2. **Check you can actually read the location.** This is the step that decides

whether the rest is worth anything.

- A UNC path, a mapped drive, or a local sync folder (Google Drive for

desktop, OneDrive, Dropbox) can be listed and read directly.

- A bare `https://drive.google.com/...` or SharePoint URL **cannot**. Ask

for the local sync path instead, or for an export of the folder listing.

- If neither is available, stop and say so. Do not write a note. A file of

plausible invented conventions is worse than no file: the next reader

cannot tell it apart from one that was checked.

3. **Read the place.** Bound the walk — a few levels, enough to see the shape.

What to look for, in order:

- A document that states the rules: `README`, `運用ルール`, `命名規則`,

`フォルダ構成`, a wiki page, an onboarding deck. This is the jackpot; when

it exists, most of `## Rules` comes from it.

- The existing file and folder names. Conventions are visible in them —

date prefixes, numbered folders, a per-release or per-customer split.

- Which folders are alive and which are dead. A folder last touched three

years ago is history, not structure.

4. **Write the note.** Mark every rule `(stated)` when a document in the place

says so, and `(inferred)` when you read it off the file names. Never present

a guess as a rule — the distinction is what makes the note trustworthy later.

Set `surveyed:` to today. Ask the owner for `direction:` rather than

deciding it; when they have not answered, write `read-only`.

5. **Link it.** Add a line to the project's `README.md` where it lists what the

project holds, and run `/kb-index` so `_index.md` matches the folder.

6. **Report** what you recorded, and — separately — what you could not see and

what you inferred rather than read. The gaps are the part the owner has to

judge.

### Re-surveying

Surveying a place that already has a note is an **update**, not a new file.

Read the existing note first, change what has actually changed, and set

`surveyed:` to today. Leave `## Memo` exactly as it is. When a rule you had

recorded no longer holds, say so in the report rather than deleting it

silently — a convention that changed is news.

## Place mode

Given a vault note, say where it belongs in the project's shared spaces.

1. Read every note in the project's `shared/`.

2. Match the note against each place's `## Placement` and `## Rules`, and name

the destination folder plus the file name the conventions imply.

3. **Check `direction` before offering to copy anything.** A `read-only` place

is not a destination: say where the material *would* go and stop there.

4. For an `export-ok` place, show the source, the destination path and the file

name, and ask the owner to confirm before copying. Copying a file into a

team's shared drive is outward-facing — it is seen by other people and is

awkward to take back.

5. After a copy, note it in the deliverable's own note (what was filed, where,

when). That record is what makes it possible to tell later whether the two

copies have diverged.

## What this skill does not do

- **It does not sync.** Filing something into a shared space is one-way,

explicit and per-occasion. Two-way mirroring of a folder a team also edits

produces conflicts and stale duplicates, and neither is worth the

convenience.

- **It does not write into a place while surveying it**, whatever the

`direction` says. A survey reads.

- **It does not delete or reorganise anything** in a shared space. The team

owns it.