slaid098/opencode-config
1
0
Fork 0
Code Issues 2 Pull requests Projects Releases Packages Wiki Activity Actions
opencode-config/.opencode/skills/get-project-map/SKILL.md
Sergey b2329210d5
chore(cleanup): delete docs-reviewer infrastructure (#210) 
* chore(cleanup): remove docs-reviewer agent and post-docs-review tool

* chore(cleanup): remove scaffold-handoff, adr-refs check, CI and tests

* chore(cleanup): remove docs/project-map directory

* chore(cleanup): drop docs-reviewer entry and post_docs_review keys from opencode.json

* chore(cleanup): drop docs-reviewer refs from tests, skills and shared tools comment

---------

Co-authored-by: opencode-agent <agent@opencode.local>
2026-08-01 04:15:41 +03:00

3 KiB
Raw Blame History

name description
get-project-map Use when you need to view or update the current project folder/file structure (especially after creating/deleting files or switching branches), or understand package layout in the workspace. Also when user says "структура проекта", "project map", "дерево файлов".

Навык получения карты проекта (Project Map)

Этот навык позволяет мгновенно получить актуальное дерево каталогов всего репозитория с учетом .gitignore без загрузки содержимого самих файлов в контекст.

Команда для выполнения:

Запусти в терминале следующую команду: repomix --no-files --stdout

Prerequisite: repomix должен быть установлен (npm i -g repomix или через Dockerfile). Если не установлен — установи перед использованием.

Твои действия:

  1. Запусти указанную команду в терминале. Она выведет дерево каталогов и список файлов с их размерами прямо в stdout.
  2. Изучи полученную структуру воркспейсов, чтобы точно знать расположение файлов и пакетов.
  3. Не сохраняй вывод в файлы на диск — читай его напрямую из вывода терминала.

Handoff файлы (docs/handoff/)

Контекст передаётся между сессиями через handoff-файлы — один файл на PR.

Структура

  • docs/handoff/pr-<N>-<slug>.md — handoff для PR #N

Шаблон

---
pr: <N>
title: <PR title>
---

## Что сделано
<2-3 строки>

## Почему
<1-2 строки>

## Pending
<что осталось, или "—">

## Watch out
<gotchas, или "—">

ADR файлы (docs/decisions/)

Архитектурные решения сохраняются в ADR (Architecture Decision Records).

Структура

  • docs/decisions/<NN>-pr-<N>-<slug>.md — один файл на решение
  • Numbering: 001, 002, 003, ... (zero-padded, sequential)

Шаблон

# ADR-<NN>: <title>

## Статус
Accepted (<YYYY-MM-DD>)

## Контекст
<почему нужно было решение>

## Решение
<что решили>

## Альтернативы
- <вариант>: <почему не подошёл>

Когда создавать ADR

  • Новый паттерн или конвенция
  • Архитектурное изменение (новый модуль, изменённые зависимости)
  • Неочевидное решение (почему X, а не Y)

Когда НЕ создавать ADR

  • Bug fixes
  • Refactoring without architectural change
  • Documentation updates