Claude Cursor Skill

document-code

AI DevKit · Document a code entry point with structured analysis, dependency mapping, and saved knowledge docs. Use when users ask to document, understand, or map code for a module, file, folder, function, or API.

LLM Mart · 0 points · 0 views 0 listing impressions 0 install-command copies
Virus-scanned Reviewed automatically before listing.

Full trust report

Download codeaholicguy-ai-devkit-skills_document-code-ac73d58.zip · 2 KB
Part of codeaholicguy/ai-devkit — 24 skills

Install

skills CLI npx skills add https://github.com/codeaholicguy/ai-devkit/tree/main/skills/document-code
Claude Code claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install codeaholicguy-ai-devkit@llmmart
Git git clone https://github.com/codeaholicguy/ai-devkit.git

The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole codeaholicguy/ai-devkit collection as a plugin from our marketplace. Git is the plain clone.

Skill manifest

Code Documentation Assistant

Build structured understanding of code entry points with an analysis-first workflow.

Hard Rule

  • Do not create documentation until the entry point is validated and analysis is complete.

Workflow

  1. Gather & Validate
  • Confirm entry point (file, folder, function, API), purpose, and desired depth.
  • Verify it exists; resolve ambiguity or suggest alternatives if not found.
  • Search for existing knowledge before analyzing: npx ai-devkit@latest memory search --query "<entry point name or purpose>"
  1. Collect Source Context
  • Summarize purpose, exports, key patterns.
  • Folders: list structure, highlight key modules.
  • Functions/APIs: capture signature, parameters, return values, error handling.
  1. Analyze Dependencies
  • Build dependency view up to depth 3, track visited nodes to avoid loops.
  • Categorize: imports, function calls, services, external packages.
  • Exclude external systems or generated code.
  1. Synthesize
  • Overview (purpose, language, high-level behavior).
  • Core logic, execution flow, patterns.
  • Error handling, performance, security considerations.
  • Improvements or risks discovered during analysis.
  1. Create Documentation
  • Normalize name to kebab-case (calculateTotalPrice → calculate-total-price).
  • Create docs/ai/implementation/knowledge-{name}.md using the Output Template — this is the source of truth.
  • Include mermaid diagrams when they clarify flows or relationships.
  1. Offer HTML Artifact
  • After the markdown is written, ask the user once: "Also generate an HTML artifact for easier scanning? (y/N)".
  • If yes, generate sibling docs/ai/implementation/knowledge-{name}.html per the HTML Artifact spec. Regenerate from the markdown on subsequent runs; never hand-edit.
  • If no or no response, stop here — markdown alone is a complete result.

HTML Artifact

Generated only when the user opts in at step 6. A self-contained HTML file optimized for scanning, not reference reading. Complements the markdown — does not replace it.

Constraints:

  • Single file. Inline CSS. No build step. Only external asset allowed is mermaid via CDN (https://cdn.jsdelivr.net/npm/mermaid/dist/mermaid.min.js).
  • Card-based grid layout, not a long scroll. The reader should capture structure at a glance.
  • Responsive down to laptop width. Print-friendly.
  • No interactivity beyond collapsible deep-dives and mermaid pan/zoom.

Section mapping (from the Output Template):

  • Overview → hero card: title, one-line purpose, language/type badges.
  • Implementation Details → grid of sectioned cards with short bullets, not prose.
  • Dependencies → graph card (mermaid) plus a categorized list (imports, calls, services, external).
  • Visual Diagrams → full-width rendered mermaid blocks.
  • Additional Insights → callout boxes, color-coded by kind (info, warning, risk).
  • Next Steps → checklist card.
  • Metadata → compact footer (date, depth, files touched).

Red Flags and Rationalizations

Rationalization Why It's Wrong Do Instead
"I already understand this code" Understanding ≠ documented understanding Write it down, then verify
"The code is self-documenting" Future readers lack your current context Capture the why, not just the what
"Dependencies are obvious" Implicit dependencies cause surprises Map them explicitly to depth 3

Validation

  • Documentation covers all Output Template sections.
  • If an HTML artifact was generated, it opens standalone in a browser, renders mermaid, and reflects the markdown content (no drift).
  • Summarize key insights, open questions, and related areas for deeper dives.
  • Confirm file path(s) and remind to commit.

Output Template

  • Overview
  • Implementation Details
  • Dependencies
  • Visual Diagrams (mermaid)
  • Additional Insights
  • Metadata (date, depth, files touched)
  • Next Steps
Files (ai-devkit)
  • agents
    • openai.yaml 321 B
      interface:
        display_name: "Code Documentation Assistant"
        short_description: "AI DevKit · Document code entry points with structured analysis"
        default_prompt: "Use $document-code to analyze this code entry point, map dependencies, and create docs/ai/implementation/knowledge-<name>.md after validation is complete."
      
  • SKILL.md 4 KB
    ---
    name: document-code
    description: AI DevKit · Document a code entry point with structured analysis, dependency mapping, and saved knowledge docs. Use when users ask to document, understand, or map code for a module, file, folder, function, or API.
    ---
    
    # Code Documentation Assistant
    
    Build structured understanding of code entry points with an analysis-first workflow.
    
    ## Hard Rule
    - Do not create documentation until the entry point is validated and analysis is complete.
    
    ## Workflow
    
    1. Gather & Validate
    - Confirm entry point (file, folder, function, API), purpose, and desired depth.
    - Verify it exists; resolve ambiguity or suggest alternatives if not found.
    - Search for existing knowledge before analyzing: `npx ai-devkit@latest memory search --query "<entry point name or purpose>"`
    
    2. Collect Source Context
    - Summarize purpose, exports, key patterns.
    - Folders: list structure, highlight key modules.
    - Functions/APIs: capture signature, parameters, return values, error handling.
    
    3. Analyze Dependencies
    - Build dependency view up to depth 3, track visited nodes to avoid loops.
    - Categorize: imports, function calls, services, external packages.
    - Exclude external systems or generated code.
    
    4. Synthesize
    - Overview (purpose, language, high-level behavior).
    - Core logic, execution flow, patterns.
    - Error handling, performance, security considerations.
    - Improvements or risks discovered during analysis.
    
    5. Create Documentation
    - Normalize name to kebab-case (`calculateTotalPrice` → `calculate-total-price`).
    - Create `docs/ai/implementation/knowledge-{name}.md` using the Output Template — this is the source of truth.
    - Include mermaid diagrams when they clarify flows or relationships.
    
    6. Offer HTML Artifact
    - After the markdown is written, ask the user once: "Also generate an HTML artifact for easier scanning? (y/N)".
    - If yes, generate sibling `docs/ai/implementation/knowledge-{name}.html` per the HTML Artifact spec. Regenerate from the markdown on subsequent runs; never hand-edit.
    - If no or no response, stop here — markdown alone is a complete result.
    
    ## HTML Artifact
    
    Generated only when the user opts in at step 6. A self-contained HTML file optimized for scanning, not reference reading. Complements the markdown — does not replace it.
    
    Constraints:
    - Single file. Inline CSS. No build step. Only external asset allowed is mermaid via CDN (`https://cdn.jsdelivr.net/npm/mermaid/dist/mermaid.min.js`).
    - Card-based grid layout, not a long scroll. The reader should capture structure at a glance.
    - Responsive down to laptop width. Print-friendly.
    - No interactivity beyond collapsible deep-dives and mermaid pan/zoom.
    
    Section mapping (from the Output Template):
    - Overview → hero card: title, one-line purpose, language/type badges.
    - Implementation Details → grid of sectioned cards with short bullets, not prose.
    - Dependencies → graph card (mermaid) plus a categorized list (imports, calls, services, external).
    - Visual Diagrams → full-width rendered mermaid blocks.
    - Additional Insights → callout boxes, color-coded by kind (info, warning, risk).
    - Next Steps → checklist card.
    - Metadata → compact footer (date, depth, files touched).
    
    ## Red Flags and Rationalizations
    
    | Rationalization | Why It's Wrong | Do Instead |
    |---|---|---|
    | "I already understand this code" | Understanding ≠ documented understanding | Write it down, then verify |
    | "The code is self-documenting" | Future readers lack your current context | Capture the why, not just the what |
    | "Dependencies are obvious" | Implicit dependencies cause surprises | Map them explicitly to depth 3 |
    
    ## Validation
    - Documentation covers all Output Template sections.
    - If an HTML artifact was generated, it opens standalone in a browser, renders mermaid, and reflects the markdown content (no drift).
    - Summarize key insights, open questions, and related areas for deeper dives.
    - Confirm file path(s) and remind to commit.
    
    ## Output Template
    - Overview
    - Implementation Details
    - Dependencies
    - Visual Diagrams (mermaid)
    - Additional Insights
    - Metadata (date, depth, files touched)
    - Next Steps
    

Comments (0)

Sign in to join the conversation.

No comments yet.

Reviews (0)

No reviews yet.

Related