SuperAPI AI Directory
Partner中文AI newsFavorites
Skillsonboard-codebase

onboard-codebase

General & other

View repository

Updated 10-15 22:11

About this skill

Skill: onboard-codebase

WHAT

Purpose and context

  • Purpose: Analyze unmapped codebase, extract technical/business context, populate Wiki per project standards.
  • Trigger (when to use):
    • Installing agentic setup into legacy/existing project.
    • Wiki outdated or has context gap from recent code changes.
  • Non-goals: do not modify project code, do not overwrite hand-written wiki pages without checking ## Origin, do not take README/comments as truth instead of code.

Mental model

codebase → infrastructure audit → domain logic + patterns → (frontend style nếu có) → business rules → entities → wiki (entities · concepts · fe-style · AGENT-business.md) → index + log → lint.

Input and output contract

Field Required? Meaning
In project codebase yes read implementation to verify every claim
Out llmwiki/wiki/entities/project-structure.md yes directory structure, stack, entry point, build/deploy
Out llmwiki/wiki/concepts/*.md yes domain concepts + patterns
Out llmwiki/wiki/concepts/fe-style.md when frontend exists actual values (hex, px/rem, class)
Out AGENT-business.md yes user stories + business rules inferred from code
Out llmwiki/wiki/entities/* + index + log yes services, external API, DB tables
Out draft output report yes Delivery section

Rules and capabilities

  • RULE-01 (MUST): ALWAYS read implementation to verify business claims.
  • RULE-02 (MUST): Cross-reference README.md/comments but prioritize truth in code.
  • RULE-03 (MUST): Focus on "Why" and "How" at code level, not just "What".
  • RULE-04 (MUST): NEVER overwrite existing manual wiki entries without checking ## Origin section.
  • RULE-05 (MUST): OKF v0.1 (R9): every wiki page starts with YAML frontmatter (---) with type non-empty (concept/entity/source) — copy _template.md accordingly. Keep ## Origin (R2).
  • RULE-06 (MUST): For fe-style.md: record actual values (hex codes, px/rem sizes, class names), not descriptions — goal is reproducible visual style without guessing.
  • Capabilities: read entire codebase; write llmwiki/wiki/ + AGENT-business.md; run wiki lint.

Failure boundaries

  • No frontend → skip step 3, do not create fe-style.md (succeeded narrow).
  • Hand-written wiki page already exists but ## Origin does not allow overwrite → clarify before editing.
  • Business claim cannot be verified in code → do not record as truth; state clearly it is unverified.
  • lint conflicting report → fix the page and rerun before considering it done.

HOW

Main workflow

Step Type Inputs Action Outputs/exit Failure/next
W01 judgment codebase Infrastructure Audit project-structure.md —
W02 judgment code domain Deep Code Analysis (services, models, patterns) concepts —
W03 judgment frontend Frontend & Style Audit fe-style.md no frontend → skip (B01)
W04 judgment code Business Logic Extraction AGENT-business.md claim not verifiable → do not record
W05 judgment code Entity Cataloging entities —
W06 effect results W01–W05 Knowledge Injection + index + log wiki updated manual page → check ## Origin
W07 deterministic wiki Final Verification: lint no conflict conflict → fix, repeat W07

Step-by-step details (source of truth for W01–W07):

  1. Infrastructure Audit:
    • Map directory structure.
    • Identify tech stack, entry points, build/deploy scripts.
    • Store in llmwiki/wiki/entities/project-structure.md.
  2. Deep Code Analysis:
    • Scan for core domain logic (Services, Models, Controllers).
    • Identify patterns (Repository, Event-driven, etc.).
    • Extract Concepts for llmwiki/wiki/concepts/.
  3. Frontend & Style Audit (skip if no frontend):
    • Identify UI framework (Next.js, React, Vue, etc.) and CSS approach (Tailwind, CSS Modules, styled-components, SCSS).
    • Extract design tokens: color palette, typography scale, spacing, breakpoints — from tailwind.config.*, CSS variables, or theme files.
    • Identify component library (shadcn/ui, MUI, Ant Design, Radix, Headless UI, etc.) and local wrappers.
    • Trace global styles: globals.css, base layout files, font loading strategy.
    • Document component naming conventions (PascalCase, feature-folder, colocated stories, etc.).
    • Note UI state management (Zustand, Jotai, Context, Redux, etc.) and data-fetching pattern (React Query, SWR, server actions, etc.).
    • Capture routing conventions (file-based, nested layouts, auth guards).
    • Store in llmwiki/wiki/concepts/fe-style.md.
  4. Business Logic Extraction:
    • Reverse-engineer user stories and business rules from code.
    • Generate/Update AGENT-business.md.
  5. Entity Cataloging:
    • List internal services, external APIs, database tables.
    • Create entries in llmwiki/wiki/entities/.
  6. Knowledge Injection:
    • Synthesize into Wiki structure.
    • Update llmwiki/wiki/index.md and llmwiki/wiki/log.md.
  7. Final Verification:
    • Run lint on generated wiki — check for contradictions.

Branches

ID Kind Guard Behavior Skip / failure Rejoin
B01 conditional_required project has frontend run step 3 Frontend & Style Audit no frontend → skip W04
B02 conditional_required target wiki page already exists, handwritten read ## Origin first; only update when not overwriting manual content unsure → ask user W06

Validation and stopping

Deterministic: lint wiki has no remaining contradictions; every page has frontmatter type + ## Origin (R2/R9). Needs review: business claims must trace back to read code. Stop after W07 is green + output report.

Examples

  • Positive: onboard a Next.js + Go repo → project-structure.md (stack, entry, build), domain concepts, fe-style.md write #0F172A, text-sm/14px, shadcn/ui, AGENT-business.md, DB table entities → lint clean → draft report.
  • Boundary/failure: repo only has Go backend → skip step 3, do not create fe-style.md; README says "supports refund" but code has no refund handler → do not write into AGENT-business.md as fact.

Delivery — Output Report

After all main skill tasks complete, write a propose draft to the wiki.

Steps

1. Build the filename:

  • Format: DDMMYY-<ten>.md
  • DDMMYY = today (e.g., 020626 for 2 June 2026)
  • <ten> = 2–4 kebab-case words summarising what was done (e.g., landing-page-coteccons, brand-kit-fintech, ingest-auth-spec)

2. Write llmwiki/wiki/sources/draft/DDMMYY-<ten>.md:

---
type: draft
title: "DDMMYY-<ten>"
status: proposed
tags: [<skill-name>, output-report]
timestamp: YYYY-MM-DD
---

# DDMMYY-<ten>
**Type:** draft
**Status:** proposed
**Tags:** <skill-name>, output-report
**Proposed:** YYYY-MM-DD

## What
<One sentence — what this skill invocation produced or decided>

## Output
<Key artefacts, files created/modified, or decisions made>

## Files
| File | Action |
|------|--------|
| `path/to/file` | created / modified |

## Notes
- Invoked via: `/<skill-name>` skill

## Origin
- **Draft:** `wiki/sources/draft/DDMMYY-<ten>.md`
- **Commit:** _(filled by verify-before-commit)_
- **Date promoted:** _(filled by verify-before-commit)_

3. Update wiki index & log:

  • llmwiki/wiki/index.md — append one row: | [DDMMYY-<ten>](sources/draft/DDMMYY-<ten>.md) | draft | YYYY-MM-DD |
  • llmwiki/wiki/log.md — append: ## YYYY-MM-DD — <skill-name> — <ten>

Skip only when the skill produces zero artefacts and zero decisions (e.g., a pure display mode like /caveman-stats).