Skill

current-prd

Reverse-engineer PRD (Product Requirements Document) from existing codebase. Scans code structure, APIs, services, and DB schema to generate structured specification documents.

Install

npx claudepluginhub t-hasuike/clysis --plugin legacy-knowledge

Tool Access

This skill uses the workspace's default tool permissions.

Preview

> This is a generic skill from [CLysis](https://github.com/t-hasuike/CLysis).

SKILL.md

Similar Skills

cache-components

Guides Next.js Cache Components and Partial Prerendering (PPR) with cacheComponents enabled. Implements 'use cache', cacheLife(), cacheTag(), revalidateTag(), static/dynamic optimization, and cache debugging.

cache-components

139.1k

claude-opus-4-5-migration

2 files

Migrates code, prompts, and API calls from Claude Sonnet 4.0/4.5 or Opus 4.1 to Opus 4.5, updating model strings on Anthropic, AWS, GCP, Azure platforms.

claude-opus-4-5-migration

83.2k

smart-explore

Performs token-optimized structural code search using tree-sitter AST parsing to discover symbols, outline files, and unfold code without reading full files.

claude-mem

65.8k

Stats

Parent Repo Stars0

Parent Repo Forks0

Last CommitApr 6, 2026

Actions

View Source View Plugin View on GitHub View README

/current-prd -- Code-to-PRD Generation Skill

This is a generic skill from CLysis. Terminology can be customized via config/terminology.md.

Overview

Generate a PRD (Product Requirements Document) by reverse-engineering an existing codebase. Instead of writing specs from scratch, extract the actual behavior from code and organize it into structured documentation that can be maintained as a living document.

When to Use

Onboarding to a legacy codebase with no documentation
Updating outdated specifications to match current implementation
Creating a baseline spec before refactoring
Bridging the gap between code reality and documented expectations

Three-Phase Workflow

Phase 1: Global Scan (Automated Collection)

Collect facts that can be extracted without human input:

Technology Stack: package managers (composer.json, package.json, go.mod), framework versions, language versions
Entry Points: routes/api.php, web.php, console commands (Artisan), batch scripts
Infrastructure: docker-compose.yml, Dockerfile, .env.example
Database: schema files, migration history, table/column inventory
Directory Structure: top-level organization, naming patterns

Output: reports/current-prd-{repo}-phase1.md

Phase 2: Module Analysis (Deep Dive)

For each significant module/service discovered in Phase 1:

Controller → Service → Repository chain: trace the call hierarchy
Input/Output contracts: request validation, response shapes, error handling
Database operations: which tables are read/written, JOIN patterns, transaction boundaries
External integrations: API calls, SFTP, S3, SQS, email
Business rules: conditional logic, flag-based branching, calculation formulas
Cross-repository dependencies: shared DB tables, API calls between repos

Output: reports/current-prd-{repo}-phase2.md

Phase 3: Structured Output (PRD Assembly)

Assemble findings into PRD format, mapped to the project's knowledge structure:

System Overview: maps to knowledge/system/01_overview/
Architecture & Structure: maps to knowledge/system/02_structure/
Data Flow & Behavior: maps to knowledge/system/03_behavior/
API Specification: endpoint list with request/response schemas
Database Model: table relationships, key columns, business meaning
Batch Process Specification: schedule, input/output, dependencies
Cross-Repository Dependency Map: which repos read/write shared resources

Output: reports/current-prd-{repo}-final.md

Scope Control

To manage token consumption on large codebases, scope can be limited:

full: scan entire repository (use for small repos or initial baseline)
[module-name]: scan specific module/feature area (e.g., "order-processing", "payment")

Output Rules

Output to reports/ only. Never overwrite knowledge/ directly
Human reviews output, then uses /doc-organize to promote to knowledge/
State observations only. No modification proposals (state assessment phase rule)
Subject-first rule: always specify "whose/what's" for domain terms

Integration with Existing Skills

Existing Skill	Relationship
/current-spec	Point investigation and detailed specification. current-prd is the surface-level counterpart
/current-prd	Promotes bulk findings. current-spec promotes individual findings
/doc-organize	Transfers current-prd output from reports/ to knowledge/
/current-legacy	Phase 0 auto-collection overlaps. current-prd extends with Module Analysis

I/O Specification

INPUT

Type	Content	Required
Repository path	Local path to target repository	Required
Scope	`full` or module name	Optional (default: full)

OUTPUT

Type	Format	Destination
Phase 1 report	Markdown (tech stack, endpoints, DB tables)	`reports/current-prd-{repo}-phase1.md`
Phase 2 report	Markdown (module analysis, dependencies)	`reports/current-prd-{repo}-phase2.md`
Final PRD	Markdown (assembled PRD with knowledge/ mapping)	`reports/current-prd-{repo}-final.md`

Post-processing

Human reviews final PRD
/doc-organize promotes relevant sections to knowledge/
/doc-update adjusts depth for target audience

Quality Checklist

All endpoints discovered and documented
Database tables mapped to business domain
Cross-repository dependencies identified
External integrations documented (SFTP, S3, API calls)
Batch processes with schedule and I/O documented
No modification proposals included (state assessment only)