Customer Workspace

Set up or operate customer workspaces without confusing setup artifacts with live records.

When to Use

• Creating a per-customer workspace.
• Operating an existing workspace: inbox updates, meeting notes, questions, actions, workstreams, or handoffs.
• Adding customer-information routing or meeting-note workflows.
• Reviewing the current owner, next action, and source records before a handoff.

Choose a Mode First

Inspect the workspace before choosing an action. Treat it as existing when it contains any managed record such as .github/copilot-instructions.md, .github/prompts/, workspace-summary.md, _customer/profile.md, _inbox/, or workstreams/. An aggregate operations workspace may contain a lightweight Customers/{id}/ profile, task list, inbox, and meetings. Do not initialize a full customer workspace over those records; ask for a separate target if dedicated customer management is needed.

• Do not rerun the initializer or use -Force in an existing workspace unless overwriting generated assets is explicitly requested.
• Existing records are authoritative. Add only explicitly requested missing assets; never replace live notes, tasks, or workstream records with templates.

Setup a New Workspace

# Basic
.\scripts\Initialize-CustomerWorkspace.ps1 -CustomerName "Contoso Inc"

# Full options
.\scripts\Initialize-CustomerWorkspace.ps1 `
  -CustomerName "Contoso Inc" `
  -ContractType "Ongoing support" `
  -ContractPeriod "2025/04 - 2028/03" `
  -KeyContacts "John Doe (Infra Lead)"

If PowerShell is unavailable, manually create the same folders and copy only the required prompt and template files from assets/.

Use setup only when the managed structure is absent. The initializer stops by default when managed assets exist; use -Force only for an explicitly approved replacement of generated prompts and templates.

Setup Intake

Capture only routing facts: workspace scope, sharing boundary, own-team aliases, key roles, meeting cadence, and primary inputs. Leave detailed technical inventory to later inbox and meeting records.

Canonical Records

Initialize-CustomerWorkspace.ps1 creates the managed scaffold and its templates. Create workstream folders, meeting notes, next actions, project threads, and material folders only when the operating workflow requires them. Leave cross-customer activity reports and global task indexes in the owning operations workspace; link to them when needed instead of copying them into a customer record.

Research Reports

Use research-reports/ for generated Markdown deliverables; keep the workspace root for entry files and controls. Detailed placement and sanitization rules are in Knowledge Ledger Rules.

Knowledge Ledger

Use _knowledge/ only for compact, reusable learnings when the user explicitly requests extraction or generalization. Apply Knowledge Ledger Rules before writing.

Optional Material Folders

Separate immutable originals, internal edits and shareable copies; use _received/, _working/ and _provided/ unless the user specifies another destination. Import accessible originals before relying on summaries. Renaming is not anonymization; restricted source content must stay out of recipient files, including hidden slides and notes. Apply Customer Material Lifecycle before moving or renaming files.

Operate an Existing Workspace

Keep source records authoritative: summaries and workstreams link to meeting notes and inbox entries instead of duplicating them.

Track Work

• A workstream README owns its current status, owner, actions, and timeline; the portfolio is its index. Create a workstream only after its name and scope are confirmed.
• When a customer follow-up continues an existing question or delivered answer, keep the original exchange visible and append the follow-up chronologically in the owning deliverable or thread. If later evidence resolves an existing 要確認, append the resolution and evidence to that owning entry instead of creating a parallel source record. For month-bound _questions ledgers, append to the current month and reference the original entry instead of rewriting the prior month.
• Put customer-agreed homework, self-initiated proposals, and supplementary research in separate next-actions/ folders. Task headers link back to their meeting source, while customer-shareable meeting tables exclude local task paths.
• Use only candidate, not-started, in-progress, blocked, done, or dropped. Before assigning not-started or done, inspect task-linked external work locations; workspace absence does not prove a deliverable is missing. When external progress and artifacts confirm completion, update the canonical action record and indexes in the same operation. Do not copy external artifacts unless the material lifecycle requires it. A blocked record names the current owner and its transition condition.
• Create pj_{topic}/ only when the topic spans multiple meetings and meets the detailed project-thread split conditions.

Meeting Notes Quality Gate

Before calling meeting notes done:

• Mark uncertain names, times, product names, prices, and support boundaries as 要確認; record the available transcript range and keep uncorroborated AI follow-ups provisional rather than assigning confirmed owners, deadlines, or deliverables.
• Omit credentials and token-bearing image URLs from saved source text. After saving, ask for a Teams meeting/recap/recording URL if absent; record supplied links without asking again, and distinguish link capture from full-content verification.
• Extract open questions and work needing follow-up into _questions/{YYYY-MM}.md and next-actions/ in the same operation.
• Keep local paths, internal links, internal speculation, and commercial terms out of customer-shareable content.
• Default to one working meeting note. Do not create *_internal.md solely for unverified technical details; separate only on explicit request or when sensitive material cannot remain in a clearly marked internal section.
• Customer highlights contain only confirmed items and split cross-side coordination into one 双方 (両者で調整) bucket. Apply Meeting Minutes Rules for details.

Done Criteria

• Setup: the managed scaffold exists and routing facts are captured.
• Operate: the canonical record, related question/action ledger, and relevant index reflect the input without duplicate source content.
• Review / Handoff: the report identifies authoritative sources, current owner, next action, and unresolved questions.

Key References

• Inbox Rules
• Meeting Minutes Rules
• Workspace Summary Rules
• Workstream Portfolio Rules
• Knowledge Ledger Rules
• Customer Material Lifecycle
• Project Thread Rules

Assets

Note: assets/ 配下の prompt / instruction / template は、新しい顧客ワークスペースを初期化するときの コピー元 として使う scaffolding 用ファイル。ホスト workspace の .github/prompts/ や .github/copilot-instructions.md とは独立に進化させてよい（同期は必須ではない）。ホスト側で機能追加した場合に scaffolding にも反映したいときは、明示的にこのフォルダへ back-port する。

• assets/_templates/: next-actions, knowledge ledger, attachments, and workspace templates
• assets/*.prompt.md: inbox, meeting-note conversion, and question extraction prompts. Prompt files load only in the VS Code Local agent (not Agent Host sessions), so the routing rules in copilot-instructions.md must work without them.
• assets/copilot-instructions.md: generated workspace auto-routing rules
• scripts/Test-ReceivedMaterialPlacement.ps1 - Read-only root audit for unclassified received-material candidates