chapterhouse 0.1.1

package/LICENSE

@@ -0,0 +1,23 @@
+NOTICE: Chapterhouse is built on the original Max work by Burke Holland (https://github.com/burkeholland/max).
+
+MIT License
+
+Copyright (c) 2026 Burke Holland
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/README.md

@@ -0,0 +1,363 @@
+# Chapterhouse
+
+Team-level AI orchestrator for engineering teams, powered by [Copilot SDK](https://github.com/github/copilot-sdk) — a daemon you run on your machine, controlled entirely from a web UI in your browser.
+
+## Attribution
+
+Chapterhouse is built on [Max](https://github.com/burkeholland/max) by [Burke Holland](https://github.com/burkeholland). The original Max codebase provided the foundation for this project.
+
+## Highlights
+
+- **Always running** — persistent local daemon with a browser frontend at `http://localhost:7788`.
+- **Builds team memory without leaking personal context** — every Chapterhouse instance keeps a private local wiki at `~/.chapterhouse/wiki/`, while shared team pages live on the authoritative Team Chapterhouse deployment and sync down read-only to personal instances. That gives each engineer a place for personal notes and conversation history without turning OKRs, KPIs, and team docs into conflicting local forks.
+- **Codes while you're away** — spins up real Copilot CLI worker sessions in any directory and reports back when they're done. The Workers tab in the web UI shows what's running.
+- **Learns any skill** — pulls from [skills.sh](https://skills.sh) or builds new skills on demand.
+- **Your Copilot subscription** — works with any model your subscription includes (Claude, GPT, Gemini, …). Auto-routing picks a tier per message.
+
+## Installation
+
+**Requires Node.js 22.5 or later.**
+
+Install globally via npm:
+
+```bash
+npm install -g chapterhouse
+```
+
+After installing, run first-time setup:
+
+```bash
+chapterhouse setup
+```
+
+Setup walks you through:
+
+1. **GitHub token** — Chapterhouse uses the Copilot CLI under the hood. Run `copilot login` (or `gh auth login --scopes copilot`) to authenticate before starting.
+2. **Config file** — Setup writes `~/.chapterhouse/.env`. You can edit it at any time. Key variables:
+
+```bash
+# Required
+COPILOT_MODEL=claude-sonnet-4-5          # default model; overridable per session
+
+# Optional — API token auth (simpler, single-user)
+API_TOKEN=your-secret-token
+
+# Optional — Microsoft Entra ID auth (team deployments)
+ENTRA_AUTH_ENABLED=true
+ENTRA_TENANT_ID=your-tenant-id
+ENTRA_CLIENT_ID=your-client-id
+
+# Optional — Azure DevOps OKR integration
+ADO_ORG=https://dev.azure.com/your-org
+ADO_PROJECT=your-project
+ADO_PAT=your-ado-pat-here
+
+# Optional — Squad (multi-agent team) integration
+ENABLE_SQUAD=1                            # set to 1 to enable squad agent routing
+
+# Optional — periodic decisions→wiki sync (requires ENABLE_SQUAD=1)
+CHAPTERHOUSE_DECISIONS_SYNC_INTERVAL_MS=300000  # default 5 minutes (300 000 ms)
+```
+
+Then start the daemon:
+
+```bash
+chapterhouse start
+```
+
+Open `http://localhost:7788` in your browser.
+
+## Install
+
+### Windows
+
+```powershell
+irm https://raw.githubusercontent.com/bketelsen/chapterhouse/main/install.ps1 | iex
+```
+
+### macOS / Linux
+
+```bash
+curl -fsSL https://raw.githubusercontent.com/bketelsen/chapterhouse/main/install.sh | bash
+```
+
+Or clone and build manually:
+
+```bash
+git clone https://github.com/bketelsen/chapterhouse.git ~/.chapterhouse/src
+cd ~/.chapterhouse/src
+npm install && npm run build && npm link
+```
+
+## Upgrading
+
+If you already have Chapterhouse installed:
+
+```bash
+chapterhouse update
+```
+
+Or manually: `cd ~/.chapterhouse/src && git pull && npm install && npm run build`. Your `~/.chapterhouse/` config carries forward automatically.
+
+## Quick Start
+
+### 1. Run setup (one time)
+
+```bash
+chapterhouse setup
+```
+
+Picks a default model and writes `~/.chapterhouse/.env`. Past versions also configured Telegram — that's gone in v2; the web UI is the only client.
+
+If you plan to use the Azure DevOps OKR integration, also set these in `~/.chapterhouse/.env`:
+
+```bash
+ADO_ORG=https://dev.azure.com/your-org
+ADO_PROJECT=your-project
+ADO_PAT=your-ado-pat-here
+```
+
+`ADO_ORG` and `ADO_PROJECT` are no longer baked into the app and must match your Azure DevOps tenant.
+
+### 2. Make sure Copilot CLI is authenticated
+
+```bash
+copilot login
+```
+
+### 3. Start Chapterhouse
+
+```bash
+chapterhouse start
+```
+
+Or `chapterhouse start --open` to also pop a browser tab.
+
+### 4. Talk to Chapterhouse
+
+Open `http://localhost:7788` in your browser and start typing. Examples:
+
+- "Start working on the auth bug in /full/path/to/myapp"
+- "What sessions are running?"
+- "Check on the api-tests session"
+- "What's the capital of France?"
+
+## Authentication modes
+
+Chapterhouse currently supports two server auth modes:
+
+1. **Legacy API token** — set `API_TOKEN` (or persist a token at `~/.chapterhouse/api-token`). The loopback-only `/api/bootstrap` endpoint hands that token to the local SPA, which then sends it as `Authorization: Bearer ...` on API and SSE requests.
+2. **Microsoft Entra ID** — set `ENTRA_AUTH_ENABLED=true`, `ENTRA_TENANT_ID`, and `ENTRA_CLIENT_ID`. The web UI uses MSAL in the browser, signs the user in with Microsoft, and sends the **ID token** to the backend. The backend verifies that token against the tenant JWKS endpoint and treats the token's `roles` claim as the source of truth for app-role authorization.
+
+Optional Entra settings:
+
+- `ENTRA_REQUIRED_ROLE` — if set, the signed-in user must have this app role in the token's `roles` claim. This replaced the older group-based check.
+- `ENTRA_TEAM_LEAD_ID` — optional for regular engineers, who can omit it entirely. Set it only for the one person who should be treated as `team-lead` for managerial functions such as `/api/team/report` and protected OKR/KPI/team wiki writes. Without it, the signed-in user is treated as `engineer`, which is the correct role for normal team members.
+
+## Docker (Personal)
+
+For a single-user local deployment, use the personal compose file. It binds port `7788`, runs the daemon as the non-root `node` user, and persists state in `CHAPTERHOUSE_HOME` (default: `$HOME/.chapterhouse` on macOS/Linux).
+
+**Authentication is required for Docker deployments.** Set either `API_TOKEN` or a working Entra config in `.env` before starting the container. For Entra, that means `ENTRA_AUTH_ENABLED=true`, `ENTRA_TENANT_ID`, and `ENTRA_CLIENT_ID`; add `ENTRA_REQUIRED_ROLE` if you want app-role gating. `ENTRA_TEAM_LEAD_ID` is optional for regular engineers and should only be set for the one person who needs team-lead/managerial permissions. If it is omitted, the user is treated as `engineer`. The process binds to `0.0.0.0` inside the container so Docker can publish port `7788`, and Chapterhouse refuses to start if neither auth mode is configured.
+
+```bash
+cp .env.example .env  # or create .env with your settings
+docker compose -f docker-compose.personal.yml up --build -d
+```
+
+`docker-compose.personal.yml` mounts `CHAPTERHOUSE_HOME` to `/home/node/.chapterhouse`, `COPILOT_HOME` to `/home/node/.copilot`, `GH_CONFIG_HOME` to `/home/node/.config/gh` (read-only), and loads `.env`, so you can provide `API_HOST`, `API_TOKEN`, any `ENTRA_*` settings, `TEAM_CHAPTERHOUSE_*` sync settings, and optional Copilot token overrides there.
+
+By default, the compose file falls back to `$HOME/.chapterhouse`, `$HOME/.copilot`, and `$HOME/.config/gh`. On Windows, set the host paths explicitly before starting the stack:
+
+```powershell
+$env:CHAPTERHOUSE_HOME = "$env:USERPROFILE\.chapterhouse"
+$env:COPILOT_HOME = "$env:USERPROFILE\.copilot"
+$env:GH_CONFIG_HOME = "$env:USERPROFILE\.config\gh"
+docker compose -f docker-compose.personal.yml up --build -d
+```
+
+You can also put those variables in a local `.env` file next to `docker-compose.personal.yml` if you prefer not to export them in your shell.
+
+### Docker Authentication
+
+Chapterhouse uses the Copilot SDK's default logged-in-user auth flow unless you set an explicit token. In Docker, the recommended setup is:
+
+1. Authenticate on the host with `gh auth login`.
+2. Start the personal compose stack. The container reuses host GitHub CLI auth through the read-only `GH_CONFIG_HOME` mount.
+3. If you prefer an explicit token, set `COPILOT_TOKEN` in `.env` (or `GITHUB_TOKEN` as a fallback). Chapterhouse passes that token to the Copilot SDK directly. Classic `ghp_` personal access tokens are not supported by Copilot.
+
+If auth expires or you want to authenticate from inside the container, run:
+
+```bash
+docker compose -f docker-compose.personal.yml run --rm -it chapterhouse copilot login
+```
+
+That login is persisted in `COPILOT_HOME`, so you only need to repeat it when the Copilot session expires or you want to switch accounts.
+
+## Team Deployment
+
+For an Azure Container Apps deployment with Azure Container Registry, Azure Files-backed wiki storage, Key Vault, and a managed identity, see [deploy/README.md](deploy/README.md).
+
+The deployment assets for the shared instance set Entra auth and `CHAPTERHOUSE_MODE=team`. In team mode, Chapterhouse seeds the shared wiki on first start so the initial OKR, KPI, team, and shared pages exist immediately.
+
+## CLI Commands
+
+| Command                     | Description                                       |
+| --------------------------- | ------------------------------------------------- |
+| `chapterhouse start`        | Start the Chapterhouse daemon (web UI + HTTP API) |
+| `chapterhouse start --open` | Same, plus open the browser                       |
+| `chapterhouse setup`        | Interactive first-run configuration               |
+| `chapterhouse update`       | Check for and install updates                     |
+| `chapterhouse help`         | Show available commands                           |
+
+### Flags
+
+| Flag          | Description                                                                      |
+| ------------- | -------------------------------------------------------------------------------- |
+| `--self-edit` | Allow Chapterhouse to modify its own source code (use with `chapterhouse start`) |
+| `--open`      | Open the web UI in your default browser when the daemon is ready                 |
+
+## Web UI
+
+The browser app at `http://localhost:7788` is split into a few views:
+
+- **Chat** — streaming markdown chat with the orchestrator. Type `/help` to see slash commands (`/cancel`, `/copy`, `/clear`, `/restart`, plus shortcuts to other tabs).
+- **Workers** — list of running and recent agent tasks. Click one to inspect its description, status, and final output.
+- **Wiki** — browse and edit local wiki pages under `~/.chapterhouse/wiki/pages/`. On personal instances, reads of team-scoped paths go through the team wiki sync layer instead of editing the shared source directly.
+- **History** — daily conversation summaries written to your personal wiki under `pages/conversations/`.
+- **Skills** — list of installed skills, broken out by source (bundled / local / global). Local skills can be uninstalled in place.
+- **Settings** — model picker, auto-routing toggle, restart button.
+
+## How it Works
+
+```
+Browser ──HTTP / SSE──► Chapterhouse Daemon
+                            │
+                      Orchestrator Session (Copilot SDK)
+                            │
+                ┌───────────┼───────────┐
+             Worker 1    Worker 2    Worker N
+```
+
+- **Daemon** (`chapterhouse start`) — persistent service running Copilot SDK + HTTP API + SPA static server.
+- **Web UI** — Vite-built React SPA, served by the daemon out of `web/dist/`.
+- **Orchestrator** — long-running Copilot session with custom tools for session management.
+- **Workers** — child Copilot sessions for specific coding tasks.
+
+### Two-Tier Wiki Architecture
+
+Chapterhouse uses two wiki layers on purpose: **personal memory stays local**, while **team knowledge has one authoritative home**. That split is what lets an engineer save private notes and conversation history freely without turning shared planning documents into a pile of unsynchronized copies.
+
+#### Personal Wiki (private, local)
+
+Your personal wiki lives at `~/.chapterhouse/wiki/`.
+
+- It stores your local preferences, conversation history, personal notes, and the cached copies of team pages fetched from the team deployment.
+- It is never shared or synced back to Team Chapterhouse.
+- Your local instance can write to it freely, which makes it the right place for agent memory, scratch knowledge, and anything that should not become team policy just because one assistant session mentioned it.
+
+The personal-memory tools still work against this local wiki:
+
+- **`remember`** — save a fact, preference, project note, or decision into your private wiki
+- **`recall`** / **`wiki_search`** / **`wiki_read`** — search the local wiki index, then open specific pages
+- **`forget`** — remove lines, revise sections, or delete a local page
+- **Index-first context** — Chapterhouse injects a ranked wiki summary into prompts so agents see what they already know without loading the full wiki every turn
+- **Episodic memory** — daily conversation summaries are written asynchronously to `pages/conversations/YYYY-MM-DD.md`
+
+#### Team Wiki (shared, authoritative on Team Chapterhouse)
+
+The team wiki lives on the **Team Chapterhouse** instance and is the authoritative source for shared operating knowledge. Personal instances sync from it read-only so there is one place to manage OKRs, KPIs, team membership, and shared runbooks.
+
+This is why the more sensitive namespaces are restricted: quarterly targets, KPI definitions, and official team roster data should not drift because several personal instances edited different copies at the same time. Shared notes stay collaborative, but the canonical planning data stays controlled.
+
+On Entra-backed deployments, `ENTRA_TEAM_LEAD_ID` is optional for regular engineers. When it is set, Chapterhouse marks the signed-in user as `team-lead` when their token's `oid` matches that value. If it is omitted or the `oid` does not match, the authenticated user is treated as an `engineer`, which is the correct role for normal team members.
+
+**Page namespaces and write permissions:**
+
+| Path | Who can write | Purpose |
+|------|--------------|---------|
+| `pages/okrs/` | Team lead only | OKR definitions and quarterly targets |
+| `pages/kpis/` | Team lead only | Team KPI tracking |
+| `pages/team/` | Team lead only | Team member profiles, onboarding |
+| `pages/shared/` | Any team member | Notes, decisions, runbooks, shared knowledge |
+
+On a fresh team deployment, Chapterhouse seeds the wiki with starter pages for:
+
+- `pages/okrs/2026-Q2.md`
+- `pages/kpis/team.md`
+- `pages/team/index.md`
+- `pages/team/onboarding.md`
+- `pages/shared/README.md`
+
+#### Sync behavior on personal instances
+
+Set `TEAM_CHAPTERHOUSE_URL` on a personal instance to enable team wiki sync. Once enabled:
+
+- Requests to the team instance reuse the current browser session's `Authorization` header automatically; `TEAM_CHAPTERHOUSE_TOKEN` is an optional fallback for non-browser or pre-authenticated flows
+- Team pages are fetched from the Team Chapterhouse API on demand
+- Cached pages are stored locally at `~/.chapterhouse/wiki/.team-cache/`
+- Cache freshness is controlled by `TEAM_WIKI_CACHE_TTL_MINUTES` (default: `60`)
+- If Team Chapterhouse is unreachable, Chapterhouse serves stale cached content instead of failing hard
+- Synced namespaces come from `TEAM_WIKI_PATHS` (default: `pages/team,pages/okrs,pages/kpis,pages/shared`)
+- Listing wiki pages in the personal UI triggers a full sync and indexes the fetched team pages locally so they are discoverable in the wiki browser and prompt context
+
+Relevant personal-instance settings:
+
+```bash
+TEAM_CHAPTERHOUSE_URL=https://your-team-chapterhouse-url.azurecontainerapps.io
+TEAM_CHAPTERHOUSE_TOKEN=
+TEAM_WIKI_CACHE_TTL_MINUTES=60
+TEAM_WIKI_PATHS=pages/team,pages/okrs,pages/kpis,pages/shared
+```
+
+That cache is there for reliability as much as speed: engineers can keep reading the last known team state even when the shared deployment is temporarily unavailable.
+
+#### Team wiki API (Team Chapterhouse)
+
+The shared deployment exposes these wiki endpoints:
+
+- `GET /api/team/wiki` — list all team wiki pages under the configured synced namespaces
+- `GET /api/team/wiki/:path` — read a page (any team member)
+- `PUT /api/team/wiki/:path` — write a page (subject to namespace permissions)
+
+#### Tools available from personal Chapterhouse
+
+Personal instances can work with the team wiki through dedicated tools instead of editing the shared source by hand:
+
+- **`write_team_wiki`** — write shared notes to `pages/shared/` from any personal instance
+- **`get_my_okrs`** — fetch the key results currently owned by the signed-in user from the team wiki
+
+## Development
+
+```bash
+# Clone and install
+git clone https://github.com/bketelsen/chapterhouse.git
+cd chapterhouse
+npm install
+npm --prefix web install
+
+# Watch mode (server)
+npm run dev
+
+# Watch mode (web UI, in a second terminal — proxies to the daemon on 7788)
+npm run dev:web
+
+# Build everything
+npm run build
+```
+
+The web UI lives in `web/`. Production builds emit to `web/dist/`, which the Express server serves out of in `src/api/server.ts`.
+
+### Releasing a new version
+
+The release flow is: bump version → commit → tag → push (tag triggers npm publish via CI).
+
+```bash
+# 1. Bump the version in package.json
+npm version patch   # or minor / major
+
+# 2. Push the commit and the tag
+git push origin main --follow-tags
+```
+
+`npm version` handles the commit and tag automatically. `prepublishOnly` runs `npm run build` before publish so the tarball always contains a fresh build. If you don't have CI set up, publish manually with `npm publish` after the tag push.

package/agents/chapterhouse.agent.md

@@ -0,0 +1,40 @@
+---
+name: Chapterhouse
+description: Orchestrator — routes tasks to specialist agents and handles direct conversation
+model: claude-sonnet-4.6
+---
+
+You are Chapterhouse, a team-level AI assistant for engineering teams running 24/7 on the user's machine. You are the engineering team's always-on assistant.
+
+## Your Role
+
+You are the orchestrator. You receive all user messages and decide how to handle them:
+
+- **Direct answer**: For simple questions, general knowledge, status checks, math, quick lookups — answer directly. No tool calls needed.
+- **Delegate to a specialist**: For tasks that need coding, design, or deep work — use `delegate_to_agent` to hand the task to the right agent.
+- **Use a skill**: If you have a skill for what the user asks (email, browser, etc.), use it.
+
+## Your Agents
+
+You manage a team of specialist agents. Each has their own persistent session, model, and expertise:
+
+{agent_roster}
+
+## Delegation Rules
+
+1. **You are the dispatcher, not the laborer.** If a task requires running commands, editing files, writing code, debugging, or any execution — delegate it.
+2. **Pick the right specialist.** Design/UI work → @designer. Coding/debugging → @coder. Everything else → @general-purpose.
+3. **One tool call, one brief response.** Call `delegate_to_agent` and respond with a short acknowledgment. Don't chain tool calls before delegating.
+4. **Announce what you're doing.** Tell the user who you're delegating to and what the task is.
+5. **When results come back**, summarize the key points. Don't relay entire output verbatim.
+6. **You can delegate multiple tasks simultaneously.** Different agents can work in parallel.
+7. **For @general-purpose**, specify a model_override based on complexity: use "gpt-4.1" for simple tasks, "claude-sonnet-4.6" for moderate tasks, "claude-opus-4.6" for complex tasks.
+
+## Background Delegation
+
+`delegate_to_agent` is **non-blocking**. It dispatches the task and returns immediately:
+
+1. When you delegate, acknowledge right away: "On it — I've asked @coder to handle that."
+2. You do NOT wait for the agent to finish.
+3. When the agent completes, you'll receive a `[Agent task completed]` message with the results.
+4. Summarize and relay the results to the user.

package/agents/coder.agent.md

@@ -0,0 +1,38 @@
+---
+name: Coder
+description: Software engineering specialist — implementation, debugging, refactoring, deployment
+model: gpt-5.4
+---
+
+You are Coder, a software engineering specialist agent within Chapterhouse. You handle all coding tasks with precision and expertise.
+
+## Your Expertise
+
+- Writing new features and implementations
+- Bug fixing and debugging
+- Code refactoring and optimization
+- Test writing and test-driven development
+- Build systems and deployment
+- Database design and queries
+- API design and implementation
+- Performance optimization
+
+## How You Work
+
+You receive tasks from @chapterhouse (the orchestrator) or directly from the user via @coder mentions. When you receive a task:
+
+1. Understand the requirements and context
+2. Explore the relevant codebase
+3. Plan your approach
+4. Implement the solution
+5. Verify it works (run tests, builds, etc.)
+
+## Guidelines
+
+- Read existing code before writing new code
+- Follow the project's existing patterns and conventions
+- Write tests when the project has a test framework
+- Make precise, surgical changes — don't modify unrelated code
+- Run builds and tests after making changes
+- Use descriptive commit messages when committing
+- Explain your approach when making non-obvious decisions

package/agents/designer.agent.md

@@ -0,0 +1,43 @@
+---
+name: Designer
+description: UI/UX design specialist — mockups, components, styling, visual work
+model: claude-opus-4.6
+skills:
+  - frontend-design
+---
+
+You are Designer, a UI/UX design specialist agent within Chapterhouse. You create beautiful, production-grade frontend interfaces.
+
+## Critical Rule
+
+**Always use the `frontend-design` skill for every task.** Invoke it before doing any design or implementation work. The skill contains your design philosophy and aesthetic guidelines — never skip it.
+
+## Your Expertise
+
+- Visual design and layout
+- Component architecture
+- CSS/Tailwind styling
+- Responsive design
+- Accessibility
+- Design systems
+- Mockups and wireframes
+- Color theory and typography
+
+## How You Work
+
+You receive tasks from @chapterhouse (the orchestrator) or directly from the user via @designer mentions. When you receive a task:
+
+1. **Invoke the `frontend-design` skill first** — it will guide your aesthetic choices
+2. Analyze the design requirements
+3. Consider the existing codebase patterns and design system
+4. Create or modify the implementation
+5. Explain your design decisions
+
+## Guidelines
+
+- Prefer modern CSS and Tailwind when appropriate
+- Create accessible designs (ARIA labels, semantic HTML, keyboard navigation)
+- Consider mobile-first responsive design
+- Use the project's existing design patterns when they exist
+- Write clean, maintainable component code
+- Explain your design rationale when making aesthetic choices

package/agents/general-purpose.agent.md

@@ -0,0 +1,30 @@
+---
+name: General Purpose
+description: Versatile agent for tasks that don't fit a specialist — model chosen per task
+model: auto
+---
+
+You are a versatile AI assistant agent within Chapterhouse. You handle a wide variety of tasks that don't require a dedicated specialist.
+
+## Your Role
+
+You're the catch-all agent. When a task doesn't clearly fit @designer or @coder, you handle it. This includes:
+
+- Research and analysis
+- Documentation writing
+- Data processing and transformation
+- System administration tasks
+- File organization
+- General problem-solving
+
+## How You Work
+
+You receive tasks from @chapterhouse (the orchestrator) or directly from the user via @general-purpose mentions. Handle each task thoroughly and report results clearly.
+
+## Guidelines
+
+- Be thorough but efficient
+- Explain your reasoning when making decisions
+- If a task would be better handled by @designer or @coder, say so
+- Use the wiki to store and retrieve relevant knowledge
+- Follow the project's existing conventions