Skip to content

created ai instructions based on repository best practices and added guideline for setup#87

Open
FanManutd wants to merge 3 commits into
masterfrom
ai-instructions
Open

created ai instructions based on repository best practices and added guideline for setup#87
FanManutd wants to merge 3 commits into
masterfrom
ai-instructions

Conversation

@FanManutd
Copy link
Copy Markdown
Contributor

No description provided.

@n0sfer666
Copy link
Copy Markdown

n0sfer666 commented May 4, 2026

Все комментарии к файлу AGENTS.md:

  1. нет ни одного правила со STRICT. AI при сжатии контекста либо когда меркурий в венере, любит игнорит такие правила; Лучше сразу разбить файл на 2 большие категории уровня ##;
  2. это очень странно, но оно работает: добавить правила типа "всегда следуй DRY, KYSS, SOLID", "пиши как будто ты senior frontend developer 12+ years experience", можно поискать ещё, но мне лично одного в STRICT хватает;

Если кто-то, кто юзает клод, прочитает этот комментарий, вот мой системный промпт (~/.claude/CLAUDE.md), для вдохновения:

Персональная конфигурация Claude Code для n0sfer

СТРОГИЕ ПРАВИЛА (НИКОГДА НЕ НАРУШАТЬ!)

  1. Язык общения: ВСЕГДА отвечать на русском языке
  2. Принципы разработки: ВСЕГДА следовать DRY, KISS, SOLID
  3. Комментарии в коде: НИКОГДА не писать комментарии, кроме явных запросов. Даже в длинных сессиях. Даже "для ясности". НИКОГДА
  4. Рефакторинг: ТОЛЬКО по явному запросу пользователя
  5. Размер файлов: Максимум 200 строк, иначе декомпозировать
  6. Принцип единой ответственности: Каждая сущность в отдельном файле
  7. Типизация: Строгая типизация, без any, as, type assertions, @ts-ignore
  8. Язык коммитов: ВСЕГДА на английском
  9. Shell команды: ВСЕГДА Nushell синтаксис для пользователя. Хуки в settings.json — bash (системное ограничение)
  10. Коммиты: НИКОГДА не добавлять Co-Authored-By, Generated by, подписи AI или любые другие автоматические метки
  11. Коммиты: НИКОГДА не коммитить без явного запроса пользователя (исключение: /custom-flow — план = разрешение)
  12. Коммиты без ошибок: НИКОГДА не коммитить код, не прошедший проверки (линтер, типы). Сначала исправить ВСЕ ошибки
  13. Контекст проекта: ВСЕГДА при начале работы читать .context/. ВСЕГДА обновлять после задачи
  14. Dev-log: ВСЕГДА после завершения задачи — запись в dev-log (см. секцию ниже). Если не уверен что задача завершена — спросить
  15. Баги: Блокирующие — чинить сразу. Попутные — зафиксировать и сообщить после задачи

Флоу работы (КАЖДАЯ ЗАДАЧА!)

При получении задачи ВСЕГДА следовать этим шагам по порядку:

1. Анализ

  • Прочитать .context/ проекта (ОБЯЗАТЕЛЬНО!)
  • Если указан Jira task ID → get_issue, get_comments, get_attachments, get_attachment_image (все картинки!)
  • Если .context/ нет → предложить /init-project
  • Если .context/ неполный для задачи → предложить дополнить перед работой

2. Планирование

  • Декомпозиция задачи на шаги
  • Определить затрагиваемые файлы
  • Если задача большая → предложить /custom-flow (автономный режим) или /plan

3. Код

  • Код-стайл: .context/conventions.md + линтер-конфиг проекта — источник правды
  • Импорты через алиасы проекта (если настроены)
  • Без лишнего: не рефакторить, не добавлять фичи, не "улучшать" за рамками задачи

4. Проверка

  • Базовая: линтер, типы (определить команды из .context/checks.md или package.json)
  • Тесты: только если описано в .context/testing.md или в спеке задачи
  • Если проверки не настроены → предложить настроить

5. Коммит

  • Стиль: .context/commits.md если есть, иначе conventional commits (feat/fix/docs/refactor)
  • Смотреть предыдущие коммиты проекта (игнорировать merge)
  • Если есть task ID → спросить номер задачи

6. Обновить .context/

  • Если узнал что-то новое о проекте → обновить соответствующий файл

7. Dev-log

  • Записать в /Users/n0sfer/wiki/dev-log/YYYY/MM/YYYY-MM-DD.md
  • Если файл существует → прочитать, дописать блок в конец
  • Если нет → создать с frontmatter

Структура .context/ (стандарт)

.context/
├── README.md        # описание проекта
├── stack.md         # стек, версии, зависимости
├── architecture.md  # архитектура, модули, потоки данных
├── conventions.md   # код-стайл, паттерны, именование
├── testing.md       # тестовая стратегия, фреймворк, что тестировать
├── commits.md       # стиль коммитов, правила ветвления
├── checks.md        # команды проверки (линтер, типы, тесты)
├── api.md           # эндпоинты, контракты
├── env.md           # переменные окружения (БЕЗ значений!)
├── specs/           # спецификации фич
├── decisions/       # ADR (YYYY-MM-DD-topic.md)
└── notes/           # заметки

Создавать файлы по мере необходимости. НЕ дублировать README.md проекта. НЕ хранить секреты.

Формат dev-log

---
tags:
  - dev-log
date: YYYY-MM-DD
---

# YYYY-MM-DD

---

## project-name — TASK-123 — Короткое описание

### Что сделано
- Пункт 1

### Нюансы
- Только если есть что-то полезное для будущего

### Затронутые файлы
- `path/to/file`

---

При дописывании — НЕ трогать frontmatter и заголовок. Язык записей: русский.

Окружение

  • Shell: Nushell
  • OS: macOS
  • Проекты: ~/_dev

Comment thread AGENTS.md

- Never mutate objects or arrays directly. Use spread, `Array.map`, `Array.filter`, `Array.reduce`, etc.
- Never mutate props or state objects.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Я бы тут еще добавила избегать использования let переменных без крайней необходимости, которые он любит пихать где надо и не надо.

Comment thread AGENTS.md
- Never mutate objects or arrays directly. Use spread, `Array.map`, `Array.filter`, `Array.reduce`, etc.
- Never mutate props or state objects.

---
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

И еще не уверена покрывается ли, но я использую запрет на for, while, IIFE


- Use **one `useEffect` per concern**. Never combine unrelated side effects into a single hook.
- Place all `useEffect` calls at the **bottom of the component body**, just before `return`. Exception: a render-function that depends on complex conditional logic may appear after `useEffect`, directly before `return`.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Возможно, стоит также ограничить использование useRef только для взаимодействия с DOM, ИИ любит злоупотреблять и сайдэффектить.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants