117 lines
3.0 KiB
Markdown
117 lines
3.0 KiB
Markdown
# Create A Project Profile
|
|
|
|
Use this checklist when adapting the workspace core for a new project.
|
|
|
|
---
|
|
|
|
## 1. Create The Profile
|
|
|
|
Create:
|
|
|
|
```text
|
|
profiles/<project>/profile.md
|
|
profiles/<project>/README.md
|
|
```
|
|
|
|
The profile should declare:
|
|
|
|
- project name
|
|
- workspace purpose
|
|
- primary audience
|
|
- communication sources
|
|
- ticket/work-item system
|
|
- manager or stakeholder mapping
|
|
- active context files
|
|
- enabled commands
|
|
- enabled skills
|
|
|
|
---
|
|
|
|
## 2. Configure Context
|
|
|
|
Create or update:
|
|
|
|
```text
|
|
project-knowledge/00-start/start-here.md
|
|
project-knowledge/01-current/current-work.md
|
|
project-knowledge/01-current/work-items.md
|
|
project-knowledge/02-work-items/
|
|
project-knowledge/03-context/project.md
|
|
project-knowledge/03-context/process/
|
|
project-knowledge/04-people/
|
|
project-knowledge/05-decisions/
|
|
project-knowledge/06-daily/
|
|
project-knowledge/07-maps/
|
|
project-knowledge/08-bases/
|
|
project-knowledge/09-templates/
|
|
```
|
|
|
|
Keep project-specific facts out of `core/`.
|
|
|
|
Treat `workspaces/<profile>/project-knowledge/` as canonical project memory. Keep connector inboxes and generated evidence outside the project knowledge vault.
|
|
|
|
---
|
|
|
|
## 3. Configure Integrations
|
|
|
|
Use generic variables first:
|
|
|
|
```text
|
|
AIW_PROJECT_PROFILE=<project>
|
|
AIW_PROJECT_KNOWLEDGE_DIR=<optional custom project knowledge path>
|
|
AIW_MEMORY_BACKEND=auto
|
|
AIW_CHANNEL_PREFIX=<project-or-team-prefix>
|
|
AIW_MATTERMOST_SYNC_CMD=<optional custom command>
|
|
AIW_SLACK_EXPORT_PATH=<optional archive path>
|
|
```
|
|
|
|
Connector secrets belong in ignored `.env` files, not in profile files.
|
|
|
|
---
|
|
|
|
## 4. Configure Commands And Skills
|
|
|
|
Start with generic commands:
|
|
|
|
- `/workspace-context`
|
|
- `/memory-health`
|
|
- `/memory-create`
|
|
- `/communication-sync`
|
|
- `/archive-import`
|
|
- `/standup`
|
|
- `/manager-update`
|
|
- `/translate`
|
|
- `/ai-prompt`
|
|
|
|
Add project-specific aliases only when they reduce friction.
|
|
|
|
---
|
|
|
|
## 5. Validate
|
|
|
|
Before using the workspace for real work:
|
|
|
|
- confirm `opencode.json` is valid JSON
|
|
- confirm the profile has no secrets
|
|
- run a communication sync with test channels or a dry sample
|
|
- generate one standup from sample context
|
|
- verify that imported evidence and promoted memory stay separate
|
|
- run `bash scripts/memory/memory.sh health`
|
|
|
|
---
|
|
|
|
## 6. Obsidian Vault
|
|
|
|
Open `workspaces/<profile>/project-knowledge/` as the Obsidian vault.
|
|
|
|
Use `scripts/memory/` as the project-agnostic memory interface. Obsidian is the default visual and CLI-backed adapter, but profile logic should not depend on Obsidian.
|
|
|
|
Recommended rules:
|
|
|
|
- keep `workspaces/<profile>/project-knowledge/` as the clean canonical project knowledge
|
|
- keep runtime evidence, scripts, profiles, and generated files outside `workspaces/<profile>/project-knowledge/`
|
|
- version only portable `workspaces/<profile>/project-knowledge/.obsidian` configuration
|
|
- ignore local Obsidian workspace state and plugin runtime files
|
|
- create or update map notes under `workspaces/<profile>/project-knowledge/07-maps/` for human navigation
|
|
- create Bases under `workspaces/<profile>/project-knowledge/08-bases/` using simple `type` properties
|