# Project Knowledge

> Helps Codex build a clear knowledge base for any code project, so you do not need to re-explain the same repo over and over. Use it when you want short, durable docs about what the project does, how it is built, and how it runs. Good for new projects, inherited codebases, and messy repos with no clear documentation. Trigger on requests like: "опиши проект", "собери базу знаний проекта", "заполни документацию проекта", "create project docs", "audit project docs".

- Skill: `aggel008/project-knowledge` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add aggel008/project-knowledge`
- Raw SKILL.md: https://api.skillmd.com/api/skills/aggel008/project-knowledge/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: aggel008 (https://skillmd.com/u/aggel008)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/aggel008/project-knowledge

---


# Project Knowledge

This skill creates a small set of docs that explain a project in plain language.

Use it when:

- you start working with a new repo
- the repo has no clear documentation
- you keep repeating the same project context in chats
- you want Codex to understand the project faster on future tasks

Main benefit:

- less repeated explanation
- faster onboarding into any repo
- clearer handoff between planning, coding, and review

## Output

Create or update:

- `docs/project_knowledge/project.md`
- `docs/project_knowledge/architecture.md`
- `docs/project_knowledge/patterns.md`
- `docs/project_knowledge/deployment.md`
- `docs/project_knowledge/ux-guidelines.md` only if the project has meaningful UI

For file responsibilities and section guidance, read [file-set.md](references/file-set.md).

## Workflow

1. Read the repository structure and the current docs state.
2. If docs already exist, preserve useful content and remove stale or duplicate content.
3. Read only the code and configs needed to establish:
   - what the project does
   - who it serves
   - major components
   - important dependencies
   - how it runs and deploys
4. Ask only for missing decisions that cannot be inferred safely.
5. Write or update the project knowledge files in concise prose.
6. Keep root-level instructions and README minimal. Durable operating knowledge belongs in `docs/project_knowledge/`.

## Rules

- Prefer facts tied to the current repo over generic framework explanations.
- Do not paste code blocks into these docs unless absolutely necessary.
- Link to source files when implementation details matter.
- Keep information in one place only. Cross-reference instead of duplicating.
- Record operational details that are hard to recover from code alone: env var names, service names, logs, deploy entry points, runtime assumptions.

## Separation

Do not confuse these artifacts:

- `docs/project_knowledge/`: stable project truth
- `docs/project_status_YYYY-MM-DD.md`: point-in-time operator status
- `work/<feature>/`: temporary feature planning and execution docs