菜单
Work with StellarDown Markdown knowledge artifacts: TASKS.md, dev-diary, completed task archives, docs domain documents, and migrated legacy Obsidian Markdown. Use when creating, moving, or editing project-facing Markdown records.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
This skill should be used when users want guidance on Spec-Driven Development methodology using GitHub's Spec-Kit. Guide users through executable specification workflows for both new projects (greenfield) and existing codebases (brownfield). After any SDD command generates artifacts, automatically provide structured 10-point summaries with feature status tracking, enabling natural language feature management and keeping users engaged throughout the process.
Canonical implementation pipeline for StellarDown after a domain document: failing tests, minimal implementation, green tests, and final document update when behavior changes.
Prepare export presets and verify production package contents.
Write C# gameplay code that stays inside the supported Electron2D 2D profile.
Import textures, fonts, audio and other resources without editing generated import cache files.
Validate, build, run and test an Electron2D project with structured diagnostics.
| name | obsidian-markdown |
| description | Work with StellarDown Markdown knowledge artifacts: TASKS.md, dev-diary, completed task archives, docs domain documents, and migrated legacy Obsidian Markdown. Use when creating, moving, or editing project-facing Markdown records. |
Use this skill for repository Markdown that acts as project memory, task state, domain documentation, or diary history.
The current live layout is:
TASKS.md - active task tracker.dev-diary/YYYY/MM Month/DD-MM-YYYY.md - development diary.completed-tasks/YYYY/MM Месяц.md - accepted/closed task archives and historical backlog grouped by completion month.docs/<domain>/ - domain documents that combine expected contract, current implemented state, limits, and verification notes in one place..temp/ - temporary drafts, probes, and generated scratch artifacts.docs/legacy/, docs/legacy-memory/, dev-diary/, and completed-tasks/ keep their historical internal format unless the user explicitly asks for normalization.dev-diary/, completed-tasks/, and TASKS.md.MEMORY.md, TODO.md, or workflow-preflight processes.For each session that changes the repository, update the current daily file before final response.
Use the same compact daily diary shape as the project AGENTS.md. New daily files start with a date heading. If an older daily file already exists without that heading or with a legacy entry shape, append the new entry to the tail and do not rewrite history just to migrate formatting.
Required shape for new daily files and new entries:
# Дневник разработки: DD-MM-YYYY
## HH:MM +03:00 - Agent: Codex
- Задача: T-0001 / ad-hoc / запрос пользователя
- Контекст: кратко, что агент собирался сделать.
- Действия:
- HH:MM - изучены инструкции, рабочая копия и связанная документация.
- HH:MM - изменены конкретные файлы.
- HH:MM - выполнены проверки и зафиксированы результаты.
- Изменения: какие файлы или документы были изменены.
- Решения: важные решения и почему.
- Проверки: какие команды проверки запускались и результат.
- Далее: что осталось сделать или что должен знать следующий агент.
Every new entry must include - Действия: with nested chronological HH:MM - ... bullets. Append new entries after older entries in the same file. Do not rewrite older diary history unless the user explicitly asks.
TASKS.md.T-0001.in progress.todo-... identifiers as Legacy anchor metadata, not as the primary ID for new tasks.completed-tasks/YYYY/MM Месяц.md only after explicit user acceptance.completed-tasks/T-0001.md.docs/<domain>/..temp/..codex, docs/, dev-diary/, or completed-tasks/..temp/ only when it becomes part of the intended durable repository state.