halo-dev
GitHubHalo项目开发上下文指南,强制要求编码前阅读CONTEXT、ARCHITECTURE和quick.md。涵盖架构规范、响应式设计、主题系统及IPC同步约定,确保代码符合模块化、高质量及多端适配标准。
Trigger Scenarios
Install
npx skills add openkursar/hello-halo --skill halo-dev -g -y
SKILL.md
Frontmatter
{
"name": "halo-dev",
"description": "important!!! Must read and follow before writing or editing any code, and equally before planning, designing, or discussing architecture for this codebase (module placement, directory layout, IPC channels, theme, i18n) — decisions made while planning are what the later edit is bound by. Entry point to CONTEXT.md \/ ARCHITECTURE.md \/ quick.md. Covers architecture, conventions, quality standards, and responsive design requirements.",
"allowed-tools": "Read, Write, Edit, Bash",
"user-invocable": true
}
Halo Development Context v3
Mandatory Entry (Read in Order)
CONTEXT.md— Product vision, development principles (styling, responsive, security, i18n), and current state.ARCHITECTURE.md— Directory structure, data types, IPC channels, theme system, CSS rules, responsive design, layout modes, multi-platform, local storage, tech stack.quick.md— Hard development rules (with code examples), task-to-file routing, and checklists.
Do not start implementation before reading these three files.
All code changes must comply with the patterns, conventions, and structures described in these documents. This includes:
- Responsive design (mobile-first,
sm:breakpoint at 640px) - Theme system (CSS variables only, no hardcoded colors)
- Tailwind-first styling (no unnecessary CSS files)
- IPC channel synchronization (preload + transport + API)
- i18n (
t('English text')for all user-facing strings) - Production logging
If a change conflicts with the documented architecture, update the architecture document first with justification, then proceed.
Development Priority (Non-Negotiable)
- Modularity, quality, and maintainability come first.
- Performance must not regress (startup, runtime latency, memory).
- Responsive design is mandatory — every UI change must work at mobile width (< 640px).
- No hardcoded colors — use only CSS variable-based theme tokens.
- If a quick fix conflicts with architecture quality, choose the maintainable modular solution and request explicit user approval before proceeding.
Fast Navigation Policy
After the mandatory entry docs:
- Jump directly to touched module
DESIGN.md:src/main/apps/*/DESIGN.mdsrc/main/platform/*/DESIGN.md
- For transport-level changes, inspect:
src/main/ipc/src/main/http/routes/index.tssrc/preload/index.tssrc/renderer/api/index.ts
- For renderer changes, check:
- Existing component structure in
src/renderer/components/ - Existing stores in
src/renderer/stores/ - Existing hooks in
src/renderer/hooks/
- Existing component structure in
Source of Truth Priority
When docs and code differ:
- Actual code in
src/** - Module design docs (
src/main/apps/*/DESIGN.md,src/main/platform/*/DESIGN.md) quick.md,ARCHITECTURE.md,CONTEXT.md
Keeping These Documents Updated
After completing a development task, evaluate whether these documents need updating. Apply the following rules:
Update when the change significantly affects how a developer understands the codebase:
- New module or service added to the architecture
- New IPC channel introduced
- Major refactoring that changes code organization
- New architectural pattern or convention established
- Core data type added or significantly changed
- New component directory or page added
Do not update for changes that don't affect architectural understanding:
- Bug fixes
- Minor features within existing modules
- Styling or UI tweaks
- Performance optimizations that don't change structure
- Dependency updates
- Code cleanup or formatting
The threshold is: would a new AI developer make wrong assumptions without this information? If yes, update. If no, skip.
Version History
- 8e53dce Current 2026-08-20 09:12


