chore: initialize EverOS 1.0.0

md-first memory extraction framework for AI agents.

Markdown is the single source of truth; SQLite holds state and LanceDB
provides the rebuildable vector + BM25 + scalar index. The codebase follows
a single-direction DDD layering (entrypoints -> service -> memory -> infra,
with component / core / config cross-cutting) enforced by import-linter.

Engineering surface:
- Coding conventions in .claude/rules/ (path-scoped) and workflows in
  .claude/skills/ (/commit, /new-branch, /pr).
- GitHub Actions CI runs make lint + test + integration; pre-commit mirrors
  the gates locally (ruff, hygiene hooks, gitlint commit-msg).
- Commit messages follow Conventional Commits, enforced by gitlint.
- make lint also enforces datetime two-zone discipline and OpenAPI drift.

.claude/skills/commit/SKILL.md

@@ -0,0 +1,54 @@
+---
+name: commit
+description: Stage and create a Conventional Commits message for the current change
+---
+
+# /commit
+
+Create a well-formed commit following the [Conventional Commits](https://www.conventionalcommits.org)
+standard. The format is enforced by `gitlint` in the `commit-msg` hook.
+
+## Steps
+
+1. Run `git status` and `git diff` (and `git diff --staged`) to see what changed.
+2. Review recent history for style: `git log --oneline -10`.
+3. Group the change into a single focused commit. If the working tree mixes
+   unrelated changes, stage selectively (`git add -p` / specific paths) rather
+   than committing everything at once.
+4. Write the message in **Conventional Commits** form:
+
+   ```
+   <type>[(scope)][!]: <imperative summary, ≤72 chars>
+
+   <optional body: what & why, wrapped at 72>
+
+   <optional footer: BREAKING CHANGE: …, Refs: #123>
+   ```
+
+5. Never use `--no-verify`. If pre-commit hooks fail, fix the cause and re-commit.
+6. Do not commit secrets, generated artifacts, or work-in-progress to a
+   protected branch (`main` / `dev` / `master`).
+
+## Types
+
+| Type | Use for |
+|---|---|
+| `feat` | new feature |
+| `fix` | bug fix |
+| `refactor` | behavior-preserving restructure |
+| `test` | add / update tests |
+| `docs` | documentation |
+| `style` | formatting only |
+| `perf` | performance |
+| `chore` | config / build / tooling |
+| `build` | build system or dependencies |
+| `ci` | CI configuration |
+| `revert` | revert a previous commit |
+
+## Notes
+
+- No emoji — the title must start with the `type`.
+- One logical change per commit; keep the history bisectable.
+- The summary is imperative mood: "add", not "added" / "adds".
+- `scope` is optional: `fix(search): …`. A `!` before the colon (or a
+  `BREAKING CHANGE:` footer) marks a breaking change.

.claude/skills/new-branch/SKILL.md

@@ -0,0 +1,43 @@
+---
+name: new-branch
+description: Create a branch following the project's GitFlow Lite model
+---
+
+# /new-branch
+
+Cut a new branch under the GitFlow Lite model.
+
+## Branch model
+
+```
+master  = released / stable (tagged on release; protected)
+dev     = integration branch (protected)
+feat/*  = cut from dev  → PR → merge into dev
+fix/*   = cut from dev  → PR → merge into dev
+hotfix/* = cut from master → merge into master AND synced into dev (double merge)
+release  = dev → master + tag on master (no separate release branch)
+```
+
+## Steps
+
+1. Ask (or infer) the change type: `feat`, `fix`, or `hotfix`.
+2. Pick the parent:
+   - `feat/*`, `fix/*` → branch from **`dev`**.
+   - `hotfix/*` → branch from **`master`**.
+3. Update the parent first:
+   ```bash
+   git checkout <parent>
+   git pull --ff-only
+   ```
+4. Create the branch with a kebab-case slug:
+   ```bash
+   git checkout -b feat/<short-slug>
+   ```
+5. For a `hotfix`, remember it must later merge into **both** `master` and `dev`.
+
+## Naming
+
+- `feat/add-agentic-rerank`, `fix/empty-profile-crash`, `hotfix/lancedb-conn-leak`.
+- Lowercase, hyphen-separated, no spaces, concise.
+
+Never commit directly to `master` or `dev` — always via a branch + PR.

.claude/skills/pr/SKILL.md

@@ -0,0 +1,41 @@
+---
+name: pr
+description: Open a GitHub PR targeting the correct branch with the project template
+---
+
+# /pr
+
+Open a pull request on GitHub using the `gh` CLI and the repo's PR template.
+
+## Steps
+
+1. Confirm the branch and target:
+   - `feat/*`, `fix/*` → base **`dev`**.
+   - `hotfix/*` → base **`master`** (then a follow-up PR/sync into `dev`).
+2. Ensure local checks pass first:
+   ```bash
+   make ci
+   ```
+   Do not open a PR with failing lint/tests.
+3. Push the branch:
+   ```bash
+   git push -u origin HEAD
+   ```
+4. Create the PR, filling the template
+   ([.github/PULL_REQUEST_TEMPLATE.md](../../../.github/PULL_REQUEST_TEMPLATE.md)):
+   ```bash
+   gh pr create --base dev --fill-first
+   ```
+   Then edit the body to complete each section:
+   - **Summary** — what changed and why.
+   - **Area** — tick the relevant box (architecture / benchmark / use case /
+     docs / DX / CI-build-release).
+   - **Verification** — paste the commands you ran (`make ci`, manual checks).
+   - **Checklist** — tick honestly; don't tick boxes you didn't satisfy.
+   - **Notes for Reviewers** — anything subtle.
+
+## Notes
+
+- Keep the PR scoped to one area. Split unrelated changes.
+- If `make ci` was not fully run, say so in Verification rather than implying it passed.
+- A `hotfix` is not done until it has landed on **both** `master` and `dev`.