From legacy-investigation
Present a reference guide for project documentation tailored to the task. Used at mission start and during impact investigation.
npx claudepluginhub t-hasuike/clysis --plugin legacy-investigationThis skill uses the workspace's default tool permissions.
> This is a generic skill from [CLysis](https://github.com/t-hasuike/CLysis).
Generates design tokens/docs from CSS/Tailwind/styled-components codebases, audits visual consistency across 10 dimensions, detects AI slop in UI.
Records polished WebM UI demo videos of web apps using Playwright with cursor overlay, natural pacing, and three-phase scripting. Activates for demo, walkthrough, screen recording, or tutorial requests.
Delivers idiomatic Kotlin patterns for null safety, immutability, sealed classes, coroutines, Flows, extensions, DSL builders, and Gradle DSL. Use when writing, reviewing, refactoring, or designing Kotlin code.
This is a generic skill from CLysis. Terminology can be customized via
config/terminology.md.
A guide skill that analyzes the nature of the task and presents the optimal reference order from knowledge/system/ and knowledge/domain/. Helps the leader's team reach "the knowledge needed for the current mission" as quickly as possible.
See config/terminology.md for term customization
/project-guide [task overview]
| Example | Task Type |
|---|---|
| /project-guide Order processing bug investigation | Bug fix |
| /project-guide Adding a new API endpoint | New feature addition |
| /project-guide External API specification change response | Specification change |
| /project-guide Understanding batch processing specifications | Investigation & analysis |
| /project-guide Local development environment setup | Environment setup |
| /project-guide Consolidating duplicate code | Refactoring |
For project-specific usage examples, keyword mappings, and notes, see PROJECT_EXAMPLES.md.
Create this file per project to document domain-specific settings.
$ARGUMENTS
Classify the task overview into one of the following:
| Type | Determination Criteria |
|---|---|
| New feature addition | Category addition, screen addition, API addition, etc. |
| Bug fix | Error correction, defect resolution |
| Specification change | Rule changes, external API changes |
| Investigation & analysis | Impact investigation, specification understanding, code reading |
| Environment setup | Local development environment, Docker, DB |
| Refactoring | Code improvement, technical debt resolution |
Output in the following format:
# Project Guide - [Task Overview]
## Recommended Reference Order
### Phase 1: System Understanding (required reading)
[Always presented regardless of task type]
1. knowledge/system/overview.md - Project overview
2. knowledge/system/repositories.md - Repository responsibility boundaries
### Phase 2: Task-Specific Knowledge
[Dynamically selected based on task type]
### Phase 3: Implementation Preparation
[Presented only when applicable]
### Phase 4: Impact Analysis
[Presented only when changes are involved]
## Related Domain Knowledge
[Present applicable files from knowledge/domain/]
## Notes
[Extract relevant notes from environment.md "common pitfalls"]
Present relevant files from knowledge/domain/ based on keywords in the task overview.
Project-specific mappings: Define keyword-to-file mappings in PROJECT_EXAMPLES.md.
Extract task-related notes from the "common pitfalls" section of environment.md.
Common notes (always presented):
Project-specific notes: Document in PROJECT_EXAMPLES.md.
After task completion, it is recommended to evaluate documents output to reports/ against the criteria in assessment/legacy_document_quality.md.
"Ready for next action" 5W Check:
# Project Guide - [Task Overview]
> **Task Type**: [New feature addition / Bug fix / Specification change, etc.]
> **Created**: YYYY-MM-DD
---
## Recommended Reference Order
### Phase 1: System Understanding (required reading)
1. `knowledge/system/overview.md` - Project overview
2. `knowledge/system/repositories.md` - Repository responsibility boundaries
### Phase 2: Task-Specific Knowledge
1. `knowledge/system/environment.md` - [Reference reason]
2. `knowledge/system/service_responsibilities.md` - [Reference reason]
...
### Phase 3: Implementation Preparation
1. `knowledge/system/typical_change_patterns.md` - [Reference reason]
2. `knowledge/system/schema_database.md` - [Reference reason]
...
### Phase 4: Impact Analysis
1. `knowledge/system/impact_analysis_template.md` - [Reference reason]
2. `knowledge/system/impact_analysis_example.md` - [Reference reason]
---
## Related Domain Knowledge
- `knowledge/domain/xxx.md` - [Relevance reason]
---
## Notes
### Common (required)
- Include project-specific soft-delete conditions (e.g., is_deleted = false) in all queries
- Project-specific type safety rules (e.g., PHP strict_types) required
- Synchronize duplicate code across multiple repositories
### Task-Specific
- [Task-specific notes extracted from environment.md]
| Type | Description | Required/Optional | Example |
|---|---|---|---|
| Task overview | Description of the task to be performed | Required | Order processing bug investigation, New API endpoint addition |
| Type | Format | Destination |
|---|---|---|
| Reference guide | Document reference order and related file list | stdout (report to leader) |
/current-spec -- Detailed investigation and specification of targets identified by the guide/change-impact -- Analyze impact scope identified by the guide