From legacy-knowledge
> This is a generic skill from [CLysis](https://github.com/t-hasuike/CLysis).
npx claudepluginhub t-hasuike/clysis --plugin legacy-knowledgeThis skill uses the workspace's default tool permissions.
> This is a generic skill from [CLysis](https://github.com/t-hasuike/CLysis).
Guides Next.js Cache Components and Partial Prerendering (PPR) with cacheComponents enabled. Implements 'use cache', cacheLife(), cacheTag(), revalidateTag(), static/dynamic optimization, and cache debugging.
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.
Performs token-optimized structural code search using tree-sitter AST parsing to discover symbols, outline files, and unfold code without reading full files.
This is a generic skill from CLysis. Terminology can be customized via
config/terminology.md.
Execution: Receives diagnostic results from /doc-check, then executes document organization. Has two functions:
| Function | Content | Target |
|---|---|---|
| Promotion | Classify reports/ files by character and file them into knowledge/ or workspace/ | New files |
| Reorganization | Verify existing knowledge/ files are in the correct character/location, then move/rename as needed | Existing files |
/doc-check (diagnosis) → detect problems, promotion decision, placement errors
↓
/doc-organize (execution) → classify and file or reorganize
Role responsibilities:
| Role | Responsibility |
|---|---|
| Leader | Approve organization/reorganization decisions, make final judgments |
| Planner | For large-scale reorganization (10+ files), task decomposition and planning strategy |
| Worker | Execute character classification, file placement, and mark assignments |
| Auditor | Quality audit of classification results (accuracy, naming compliance) |
Strict compliance with F002: Leader does not personally organize files. Consult planner, delegate execution to workers, request auditor for quality assurance.
Distinction from /doc-check:
/doc-check = Judge (integrity verification + As-Is/To-Be promotion judgment + placement error detection)/doc-organize = Execute (character classification → placement → mark assignment → move)| Character | Definition | Storage | Example |
|---|---|---|---|
| Domain Knowledge | Business rules, term definitions, confirmed facts | knowledge/domain/ | Photo size definitions, incentive calculation rules |
| System Knowledge | Architecture, structure, behavior, infrastructure configuration | knowledge/system/ | Repository structure, database connection config, S3 bucket layout |
| Quality Records | Distortions, risks, technical debt, diagnostic results | knowledge/quality/ | Core distortion patterns, cross-cutting risk inventory |
| Decision Records | Option comparison, decision rationale, consequences (ADR format) | workspace/in_progress/adr/ | Payment calculation method selection, repository split decision |
| Implementation Specs | Detailed specifications for engineer implementation | workspace/in_progress/ | API specs, validation rule details |
| Runbooks | Environment setup, troubleshooting, operational procedures | knowledge/runbooks/ | Local dev environment setup, deployment procedures |
| Standards & Guidelines | Checklists, maturity models, review rules | knowledge/standards/ | PR checklist, legacy maturity model |
| Document Type | Applicable Character | Rationale |
|---|---|---|
| PRD (Product Spec) | Compound (decompose by section) | Spans domain knowledge + system knowledge + implementation specs |
| Non-functional requirements (SLA, performance) | System knowledge | Describes infrastructure configuration and constraints |
| Test specs | Implementation specs | Engineers use for implementation and verification |
| UI/UX specs | Domain knowledge | Defines business processes and user operations |
| API specs | Implementation specs | Endpoint/request/response format details |
| ER diagrams, table designs | System knowledge | Data structure and relationship descriptions |
| Deployment procedures | Runbooks | Environment operation procedures |
| Release notes | Decision records | Records change context and impact |
| Decision | Definition | Conditions |
|---|---|---|
| Promote | Integrate summary version into knowledge/ or workspace/ | Referenced across multiple sessions + knowledge confirmed |
| Discard | Delete temporary notes, duplicates, obsolete content | Content merged elsewhere or information outdated |
| Hold | Keep in reports/ (waiting for decision maker judgment) | Future plans, improvement proposals (To-Be) requiring decision maker approval |
| Investigation Purpose | Processing Decision | Decision Maker |
|---|---|---|
| Current spec survey (As-Is) | Immediate promotion | Leader/Worker |
| Future plans, improvement proposals (To-Be) | Hold (promote after decision maker approval) | Decision maker |
| One-time investigation | Discard candidate (discard if no value) | Leader |
File names should make character and purpose immediately clear:
| Character | Prefix | Applied to |
|---|---|---|
| System knowledge (bird's eye) | birdseye_ | High-level overviews, architecture diagrams |
| System knowledge (fish eye) | fisheye_ | Time-series flows, process tracing |
| System knowledge (worm's eye) | wormseye_ | Implementation details, specification confirmation |
| Quality records (bird's eye) | birdseye_ | Risk overview |
| Quality records (worm's eye) | wormseye_ | Distortion pattern details |
| Domain knowledge (bird's eye) | birdseye_ | Business process overview |
| Domain knowledge (fish eye) | fisheye_ | Business workflows, time-series processes |
| Domain knowledge (worm's eye) | wormseye_ | Business rules, term definitions, detailed specs |
| Decision records | adr_ | ADR-format decision records |
| Implementation specs | spec_ | Engineer-readable detailed specifications |
| Runbooks | runbook_ | Environment setup, operational procedures |
| Standards & guidelines | standard_ | Checklists, maturity models, review rules |
When a document matches multiple character conditions, classify in this order:
PRDs span multiple characters. Decompose by section during promotion:
| PRD Section | Promotion Target Character |
|---|---|
| Business requirements, term definitions | Domain knowledge |
| System configuration, architecture | System knowledge |
| API specs, database design | Implementation specs |
| Non-functional requirements | System knowledge |
| Screen specs, operation flow | Domain knowledge |
> **Promoted**: integrated into knowledge/xxx/yyy.md (YYYY-MM-DD)flowchart TD
A["1. Obtain target file list"] --> B["2. Classify each file by character"]
B --> C["3. Decide processing action (promote/discard/hold)"]
C --> D["4. Leader confirms (classification results, filing plan)"]
D --> E{Leader approval}
E -->|Rejected| F["End"]
E -->|Approved| G{Large scale?}
G -->|10+ files| H["Consult planner (task decomposition)"]
G -->|10 or fewer| I["Delegate to workers"]
H --> I
I --> J["Execute: place files + assign marks"]
J --> K["Report"]
Clear, professional reporting with business etiquette. Clearly state OK/NG, explicitly state what is unclear.
When describing domain terms and flag names, always explicitly state "whose/what".
app/Services/xxx.php:45-67knowledge/domain/ file names| Type | Content | Required/Optional |
|---|---|---|
| Target scope | reports/ or knowledge/ file path | Required |
| /doc-check results | Promotion candidates, placement errors | Optional (improves accuracy if provided) |
| Type | Format | Destination |
|---|---|---|
| Organization result report | Markdown | reports/ + stdout |
| Filed files | knowledge/ or workspace/ | Character-specific storage location |
| Skill | Condition |
|---|---|
/doc-check | Post-organization integrity verification |
/doc-update | Freshness management of filed knowledge/ files |
| Skill | Relationship |
|---|---|
/doc-check | Upstream: Diagnosis results (promotion candidate list) used as input |
/doc-update | Downstream: Freshness management of promoted knowledge/ files |
/current-spec | Source: Investigation results output to reports/, then input to doc-organize |