tomtan/EverOS
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
79b3df4de22dabf2ea53cd9994ac8f3740475466
EverOS/.claude/skills/pr/SKILL.md
Elliot Chen 518b8eca85 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.
2026-06-06 07:33:17 +08:00

1.3 KiB
Raw Blame History

name, description
name description
pr 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: 
    make ci
    Do not open a PR with failing lint/tests.
  3. Push the branch: 
    git push -u origin HEAD
  4. Create the PR, filling the template (.github/PULL_REQUEST_TEMPLATE.md): 
    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.