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.

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