halo-dev

GitHub

Halo项目开发上下文指南,强制要求编码前阅读CONTEXT、ARCHITECTURE和quick.md。涵盖架构规范、响应式设计、主题系统及IPC同步约定,确保代码符合模块化、高质量及多端适配标准。

.claude/skills/halo-dev/SKILL.md openkursar/hello-halo

Trigger Scenarios

编写或编辑Halo项目代码前 规划或设计Halo项目架构时

Install

npx skills add openkursar/hello-halo --skill halo-dev -g -y
More Options

Non-standard path

npx skills add https://github.com/openkursar/hello-halo/tree/main/.claude/skills/halo-dev -g -y

Use without installing

npx skills use openkursar/hello-halo@halo-dev

指定 Agent (Claude Code)

npx skills add openkursar/hello-halo --skill halo-dev -a claude-code -g -y

安装 repo 全部 skill

npx skills add openkursar/hello-halo --all -g -y

预览 repo 内 skill

npx skills add openkursar/hello-halo --list

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)

  1. CONTEXT.md — Product vision, development principles (styling, responsive, security, i18n), and current state.
  2. ARCHITECTURE.md — Directory structure, data types, IPC channels, theme system, CSS rules, responsive design, layout modes, multi-platform, local storage, tech stack.
  3. 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.md
    • src/main/platform/*/DESIGN.md
  • For transport-level changes, inspect:
    • src/main/ipc/
    • src/main/http/routes/index.ts
    • src/preload/index.ts
    • src/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/

Source of Truth Priority

When docs and code differ:

  1. Actual code in src/**
  2. Module design docs (src/main/apps/*/DESIGN.md, src/main/platform/*/DESIGN.md)
  3. 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

Same Skill Collection

.claude/skills/code-commit/SKILL.md
.claude/skills/code-merge/SKILL.md
.claude/skills/code-review/SKILL.md
.claude/skills/comment-review/SKILL.md
.claude/skills/code-review-simple/SKILL.md

Metadata

Files
0
Version
8e53dce
Hash
34636925
Indexed
2026-08-20 09:12

- 위키
Copyright © 2011-2026 iteam. Current version is 2.155.2. UTC+08:00, 2026-08-24 23:38
浙ICP备14020137号-1 $방문자$