Skip to main content

add-focus-mode

Create or update OpenMates user-facing focus modes using the existing SKILL.md, app.yml, i18n, docs, and test patterns

跳到安装

来源信息

仓库
glowingkitty/OpenMates
最近来源活动
2026年9月11日 12:04
检测到的 SKILL.md 语言
英语
星标
46
分支
3

安装方式

默认使用会先检查来源的 Prompt;你也可以切换为直接命令,或下载本地副本。

检查来源文件

决定是否安装前,请先阅读 SKILL.md,以及 SkillsMP 当前展示的配套文件。

正在显示 SKILL.md

SKILL.md
来源说明 · 只读预览
name
add-focus-mode
description
Create or update OpenMates user-facing focus modes using the existing SKILL.md, app.yml, i18n, docs, and test patterns
user-invocable
true
argument-hint
<appId?> <focusId?>
## Purpose Use this skill when the user wants to create or update an OpenMates focus mode. OpenMates focus modes are user-facing chat modes that temporarily change how a mate thinks and responds for a specific goal. They are not Codex modes, editor modes, OS notification modes, or backend app skills. ## Arguments Parse `$ARGUMENTS` as optional hints: - `appId` — parent OpenMates app directory, such as `web`, `code`, `jobs`, or `study` - `focusId` — runtime focus mode id, snake_case preferred, such as `career_insights` If either value is missing, infer it during discovery or ask during the clarifying rounds. Do not invent a final app or ID without user confirmation. ## Workflow Follow this structure closely. The user expects a deliberate plan-before-build flow with two clarification blocks and a draft review gate. Every clarifying question must include `Recommendation:` with the evidence-based preferred answer and rationale plus `Examples:` with task-specific options or outcomes. If uncertain, recommend the safest reversible default and state the uncertainty. ### Step 1: Check Existing Focus Modes First inspect how focus modes already exist and how the target app is structured. Read or search these paths as relevant: - `docs/architecture/apps/focus-modes.md` - `docs/architecture/apps/focus-modes-implementation.md` - `docs/user-guide/apps/focus-modes.md` - `backend/apps/*/focus_modes/*/SKILL.md` - `backend/apps/{appId}/focus_modes/*/SKILL.md` - `backend/apps/{appId}/app.yml` - `frontend/packages/ui/src/i18n/sources/focus_modes/` - `frontend/packages/ui/src/i18n/sources/app_focus_modes/` - `frontend/apps/web_app/tests/focus-mode-*.spec.ts` - `frontend/packages/ui/scripts/generate-apps-metadata.js` Identify whether the request is: - creating a new focus mode - updating an existing focus mode - migrating a legacy focus mode - changing prompt behavior only - changing activation/routing behavior ### Step 2: Ask 3 Clarifying Rounds Ask exactly one clear question per round and wait for the user's answer before continuing. Stop early only if the user explicitly says to skip clarification. Use these topics unless the repo context reveals more urgent blockers: - Round 1: What user goal should this focus mode solve? - Round 2: Which app/category should own it, and should it be new or update an existing mode? - Round 3: When should it activate, and what should be explicitly out of scope? ### Step 3: Search Internal Context Based on the answers, search internal sources for relevant connected information and ideas. Check: - existing focus modes with similar goals or prompts - the owning app's `app.yml`, skills, settings/memories, providers, and icons - GitHub issues for related product ideas, bugs, or prior decisions - architecture docs and user-guide docs for the affected app/domain - tests that cover focus mode settings, activation, rejection, mention, or app behavior Use GitHub Issues by default for tracker searches. Do not create or update an issue unless the user asks. ### Step 4: Search External Context Search externally for ideas and best practices relevant to the requested focus mode. Use: - GitHub search for similar AI assistant modes, prompt packages, agent skills, Claude skills, or domain-specific assistant workflows - web search for best practices in the requested domain - official or authoritative sources when the mode touches health, finance, legal, safety, education, jobs, security, privacy, or other high-risk topics Keep this research practical. Extract patterns that improve the OpenMates focus mode contract; do not copy prompts wholesale. ### Step 5: Ask 3 More Clarifying Rounds Ask exactly one clear question per round and wait for the user's answer before continuing. These questions must be informed by the internal and external research. Use them to resolve: - domain-specific constraints or safety boundaries - privacy or data-use limits - success criteria for what a good answer in this mode looks like - allowed skills/apps and whether the mode should ask before using external data - how proactive, cautious, structured, or conversational the mate should be ### Step 6: Suggest a Draft Present a concise draft and ask for feedback before editing product files. The draft must include: - display name - parent app - runtime focus ID and directory name - default-enabled behavior, including `default_enabled: false` only when the mode intentionally ships off - one-line description - activation/preprocessor hint - process bullets shown in settings - 2-3 “How to use” examples with highlighted trigger words - system prompt outline or full proposed system prompt - skills/apps it may rely on - non-goals - safety, privacy, and data-use rules For updates, show a focused diff-style summary of what will change. ### Step 7: Ask for Feedback Wait for the user's feedback. Do not implement before this gate unless the user explicitly says to proceed without draft approval. ### Step 8: Finalize the Draft Incorporate feedback and show the final version briefly. Confirm any remaining tradeoffs, such as activation breadth, default-enabled behavior, or safety wording. ### Step 8b: Define Phase Gates Before implementation, record the phase gate in the draft, inline contract, or full spec: 1. Implement and test focus-mode behavior through real OpenMates CLI chats against the dev server first. Mocked OpenMates API calls, mocked SDK clients, stubbed servers, direct function calls, and fixture replay do not satisfy this gate. 2. Implement and test npm SDK and pip SDK parity locally against the dev server when focus-mode activation or memory/settings behavior is exposed programmatically. After local CLI and SDK evidence is green, reproduce or wire the same coverage into GitHub Actions for CI/daily tests. 3. Implement web settings, examples, or Playwright coverage only after CLI and required SDK evidence are green. 4. Run deployed Playwright visual smoke for larger web/UI surfaces in both laptop and mobile viewports, fixing and redeploying any objective rendering, error, loading, or responsiveness issue, then ask the user to confirm the deployed dev web behavior works and looks correct before starting Apple parity. Use Firecrawl only as a recorded fallback when Playwright is impractical or blocked. `*.spec.ts` evidence alone is not enough. 5. Start Apple parity only after CLI, SDK, web, and user-confirmation evidence are complete, or after an explicit waiver/blocker is recorded. ### Step 9: Implement the Focus Mode Use the current OpenMates implementation reality, not only the future target architecture. Primary authoring target: - `backend/apps/{appId}/focus_modes/{focus-dir}/SKILL.md` Current compatibility targets that may also need updates: - `backend/apps/{appId}/app.yml` - `frontend/packages/ui/src/i18n/sources/focus_modes/{appId}_{focusId}.yml` - `frontend/packages/ui/src/i18n/sources/app_focus_modes/{appId}.yml` Rules: - Runtime `id` in `SKILL.md` is snake_case and must match OpenMates metadata. - Focus mode directory names are kebab-case for portability. - Keep `SKILL.md`, `app.yml`, and i18n keys aligned while the migration is incomplete. - Do not add `stage`; focus modes are enabled by default unless `default_enabled: false` is explicitly needed. - `preprocessor-hint` should be 1-3 sentences that describe when to select the mode, not the full system prompt. - `## Process` bullets should be user-facing and concrete. - `## System prompt` should define role, workflow, boundaries, tool behavior, and output expectations. - Capability fields such as `allowed-skills` are currently parsed but not fully enforced at runtime; do not rely on them as the only safety control. - If translations are not human-reviewed, do not mark localized files as verified by a human. ### Step 10: Validate Run the smallest checks that prove the change. Usually relevant: - `cd frontend/packages/ui && npm run build:translations` after i18n YAML edits - `cd frontend/packages/ui && npm run generate-apps-metadata` after focus metadata edits, if available in `package.json` - targeted parser or metadata-generation checks for `SKILL.md` - relevant lint or typecheck command for changed areas For any user-facing focus-mode behavior change, run a real OpenMates CLI chat quality check after the metadata is built and, when testing dev behavior, after the change is deployed to dev. Use the test-account helper or the compiled CLI, for example: - `node scripts/openmates_cli_test_account.mjs login --api-url https://api.dev.openmates.org` - `openmates --api-url https://api.dev.openmates.org chats new "<example request>" --json` Run multiple example requests that match the activation hint and inspect the actual assistant output. Record whether the focus mode activated, which skills were used, whether the answer followed the expected structure, and whether the quality met the draft's success criteria. If the CLI cannot be run, document the blocking reason instead of treating parser/build checks as behavior evidence. For user-facing focus-mode behavior, propose the relevant E2E test path and use the repo test runner after deploy when running Playwright: - `python3 scripts/tests.py run --spec focus-mode-settings.spec.ts` - `python3 scripts/tests.py run --spec focus-mode-mention.spec.ts` - `python3 scripts/tests.py run --spec focus-mode-rejection.spec.ts` - a new or updated focus-mode-specific spec if needed Do not run Playwright locally. ### Step 11: Add or Verify an Example Chat Every enabled focus mode must have at least one permanent example chat linked from its focus-mode details page. This applies to both new focus modes and prompt/routing improvements to existing focus modes. Before finishing: - Search `frontend/packages/ui/src/demo_chats/data/example_chats/` for an existing example with `metadata.app_focus_mode_examples` containing `"{appId}.{focusId}"`. - If none exists, create a real OpenMates chat through the CLI or app, share it, and scaffold it with `scripts/create-example-chat-from-share.mjs`. - Prefer a real CLI chat for reproducibility. If the focus mode needs explicit activation, use the CLI focus mention while creating the chat, but remove the internal `@focus:...` wire prefix from public example-chat user text after scaffolding. - Set `metadata.app_focus_mode_examples: ["{appId}.{focusId}"]` and `metadata.active_focus_id: "{appId}-{focusId}"` on the example chat so the focus-mode page can surface it and the demo chat opens with the active focus state visible. - Translate the new example-chat YAML, build translations, validate locales, and run `scripts/audit_example_chats.py` before deploying. - If a real example chat cannot be created, document the blocker explicitly; do not silently finish a focus-mode improvement without an example-chat plan. ## Draft Template Use this structure for Step 6 and Step 8. ```markdown ## Focus Mode Draft Name: App: Focus ID: Directory: Default enabled: Description: Activation hint: Process: - ... How to use: - ... - ... - ... System prompt: ... Allowed skills/apps: Non-goals: Safety and privacy: Open questions: ``` ## Implementation Checklist Before finishing, verify: - `SKILL.md` frontmatter starts and ends with `---` - `id` is snake_case and directory is kebab-case - title matches the display name intent - `## Process`, `## How to use`, and `## System prompt` sections exist when needed - `app.yml` contains or preserves compatible metadata while backend discovery still needs it - i18n YAML source files contain name, description, process, system prompt, and how-to-use strings where required - generated translations/metadata were rebuilt if source files changed - real OpenMates CLI chat requests covered the intended activation behavior and output-quality contract for behavior changes - at least one permanent example chat is linked via `metadata.app_focus_mode_examples` for the focus mode - relevant docs/tests were updated or explicitly deferred ## When to Escalate to a Full Spec Use `create-plan` before implementation if the focus mode changes runtime behavior, adds new persistence, introduces new API routes, changes activation/deactivation semantics, touches encryption/privacy-sensitive data flows, or requires new app skills/providers. Pure prompt/content additions can usually follow this skill without a full spec.
在 GitHub 查看