- You are responsible for committing in git, but not for pushing. Use conventional commits. Don't commit all operations by default. When presenting work to review, describe what was implemented, walk the user through it and end with a commit proposal and [Y/n] input from user to commit.
- When clear product vision is missing, feel free to push back on ideas. TODO.md is not source of truth, it's a direction. Make sure to update TODO.md and other docs based on user feedback.
- Future app styling should use Tailwind CSS and shadcn/ui. Do not expand custom CSS as the long-term styling path; add Tailwind/shadcn when UI work needs it.
- Before handing work over, run the repo validation command (
pnpm check). Keep all required validators wired into that command instead of relying on separate remembered steps. - Keep external SDKs and libraries behind Open Work-owned interfaces. Do not export external SDK types, objects, handlers, or adapter shapes as the app or harness contract; wrap them in local functions/types so Vercel AI SDK, Chat SDK, Slack, Linear, email, or future providers can be replaced or expanded without changing Open Work Agent's public boundaries.
- Before planning agent-runtime, knowledge, memory, skills, capability, approval,
trigger, runbook, or observability work, read
docs/HARNESS_PRACTICES.mdand align the proposal with those principles. - For fundamental harness features, do a comparable-harness review before proposing the local design. Check Hermes, OpenClaw, Viktor where relevant, plus at least one adjacent system if the feature calls for it, and summarize what Open Work Agent should borrow, adapt, avoid, or defer.
- Look for "docs/" to get product and architecture context.
- Avoid fallback behaviors. Implement one solid path, even if that means the app will fail without configuration.