Root

Overview

Use this skill to govern Codex project work for Hikaze-Model-Manager-2 using the .codex directory structure, keeping immutable sources of truth stable while tracking jobs and design details.

Sources of truth and load order

1. •Read .codex/constitution/ for project principles, tech stack, and code standards.
2. •Read .codex/workflows/ for the static workflow framework.
3. •Read .codex/guidelines/ for implementation details and decisions.
4. •Read .codex/jobs/activated.md and the active job file to understand current work.

Hard rules

• •Do not edit .codex/constitution/ or .codex/workflows/ unless the user explicitly requests changes.
• •Propose suggestions for constitution/workflows only; do not modify without explicit user instruction.
• •Record new or changed design details in .codex/guidelines/ during design discussions.
• •Record designed but not implemented items in .codex/guidelines/not_implemented.md.
• •Keep all .codex content in Markdown.
• •When stating code or behavior facts, cite evidence (file path + line or command output); avoid assumptions.
• •Use a single file per job to carry phases and tasks.
• •The last task of every phase must be user manual verification.
• •Track branches as indented checklist items; complete same-indent branch items before returning to the parent flow.
• •Update .codex/jobs/activated.md whenever the active job changes.
• •If required .codex paths are missing, ask before creating them.

Job file format

Use jobs/<job>/<job>.md with Markdown checklists:

# Job: <job-name>

## Phase 1: <phase-name>
- [ ] Task: <task>
  - [ ] Branch: <subtask>
  - [ ] Branch: <subtask>
- [ ] Quality Gates
  - [ ] Build passes (if applicable)
  - [ ] Evidence recorded (file refs / command output)
  - [ ] Docs updated (if needed)
- [ ] User manual verification

## Phase 2: <phase-name>
- [ ] Task: <task>
- [ ] Quality Gates
  - [ ] Build passes (if applicable)
  - [ ] Evidence recorded (file refs / command output)
  - [ ] Docs updated (if needed)
- [ ] User manual verification

Workflow usage

• •Treat workflows as the static guidance framework that governs each job and phase.
• •Record workflow branches in the job file as indented checklists.
• •Return to the parent flow after all items at the branch indent are complete.

Sub-skills

Use specialized skills to reduce context and improve precision when scope is narrow:

• •hikaze-frontend: Vue/TypeScript/CSS UI work in web/model_manager_frontend or web/custom_node_frontend.
• •hikaze-backend: Python nodes and server work in nodes/ or backend/.
• •hikaze-api: API contracts, request/response changes, and frontend-backend integration.

Conductor migration (only if requested)

Migrate prompts from custom_nodes/Hikaze-Model-Manager-2/conductor/ to .codex/ only when the user asks:

• •conductor/product.md -> .codex/constitution/product.md
• •conductor/tech-stack.md -> .codex/constitution/tech-stack.md
• •conductor/code_styleguides/* -> .codex/constitution/code_styleguides/*
• •conductor/workflow.md -> .codex/workflows/default.md
• •conductor/product-guidelines.md -> .codex/guidelines/product-guidelines.md
• •conductor/archive/* -> .codex/jobs/archive/*
• •Do not migrate conductor/discrepancies/* unless the user explicitly requests it.

Language policy

Accept any input language. Choose output language by accuracy first, then token efficiency.