context-project-docs

Governs canonical project Markdown documents and notes/ naming conventions for research repositories.

Updated Jul 3, 2026
One-click install
npx skills add https://github.com/mnazaal/dotfiles --skill context-project-docs-mnazaal
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: context-project-docs
Source: https://github.com/mnazaal/dotfiles/tree/main/.agents/skills/context-project-docs
Command: npx skills add https://github.com/mnazaal/dotfiles --skill context-project-docs-mnazaal

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes assets (resource) components.

What problem does it solve? AI agents and contributors tend to proliferate standing Markdown files (SUMMARY.md, NOTES.md, IMPLEMENTATION.md) that duplicate content, drift out of sync, and bury the real state of a project. This Skill enforces a bounded, canonical documentation set so every fact has exactly one home. ## Core Features & Use Cases - Canonical doc set: Defines exactly four standing documents — PLAN.md (decisions and next steps), LOG.md (prepend-only run/result log), CONTEXT.md (glossary), and README.md (outward-facing snapshot) — each created lazily on first real content. - notes/ vocabulary: Reserves main.html and claims.md as single-owner files and restricts all other notes to a closed prefix set (deriv-, design-, lit-, review-, draft-, probe_*.py), with one-note-per-topic rewrite rules and no dates in filenames. - HTML note template: Ships a theme-aware notes-template.html with MathJax, tables, and callout boxes so working notes render consistently across projects and color schemes. - Use Case: Before an agent writes a new SUMMARY.md after a research run, this Skill redirects the result into a prepend-only LOG.md entry with a pointer to a prefixed note in notes/, keeping the doc inventory bounded. ## Quick Start Before creating or editing any project Markdown file, apply the context-project-docs rules to decide whether the content belongs in PLAN.md, LOG.md, CONTEXT.md, README.md, or a prefixed note under notes/.

Frequently Asked Questions about context-project-docs

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I structure project documentation for a research code repository?▼

Use four standing documents: PLAN.md for decisions and next steps, LOG.md as a prepend-only run/result log, CONTEXT.md as a glossary, and README.md as the outward-facing snapshot. Keep detailed working notes under notes/ with prefixed filenames, and create each file lazily on first real content.

How should I name files in a research notes directory?▼

Use a closed prefix vocabulary: deriv- for derivations, design- for method designs, lit- for literature maps, review- for reviews, draft- for paper fragments, and probe_*.py for analysis scripts. Never put dates in filenames; git history is the date of record.

Should my project have a CHANGELOG.md or SUMMARY.md file?▼

No. Conventional commits plus git log serve as the changelog, and generated, provenance-stamped overviews replace hand-maintained summaries. Minting SUMMARY.md, NOTES.md, or IMPLEMENTATION.md files is exactly the document-proliferation failure mode this convention prevents.

How do I write entries in a project LOG.md file?▼

Prepend new entries at the top so the file is reverse chronological. Each entry contains a heading with date, a verdict or summary, load-bearing numbers, pointers to artifacts or commits, and the next action; corrections are new entries, never rewrites.

What format should working research notes use instead of Markdown?▼

Working notes are self-contained HTML files copied from the provided notes-template.html, which includes a theme-aware stylesheet, MathJax configuration, and table and callout markup. Markdown remains the format for the standing docs and the reserved claims.md ledger.