Deep codebase analysis to generate 9 comprehensive documentation files. Adapts based on path choice - Greenfield extracts business logic only (tech-agnostic), Brownfield extracts business logic + technical implementation (tech-prescriptive). This is Step 2 of 6 in the reverse engineering process.
/plugin marketplace add jschulte/stackshift/plugin install jschulte-stackshift@jschulte/stackshiftThis skill inherits all available tools. When active, it can use any tool Claude has access to.
Step 2 of 6 in the Reverse Engineering to Spec-Driven Development process.
Estimated Time: 30-45 minutes
Prerequisites: Step 1 completed (analysis-report.md and path selection)
Output: 9 comprehensive documentation files in docs/reverse-engineering/
Path-Dependent Behavior:
Note: Output is the same regardless of implementation framework (Spec Kit or BMAD). The framework choice only affects what happens at Gear 6 (handoff).
Use this skill when:
Trigger Phrases:
This skill performs deep codebase analysis and generates 9 comprehensive documentation files.
Content adapts based on your route (greenfield vs brownfield):
/speckit.analyze validation9 Documentation Files Generated:
Load state file to check detection type and route:
# Check what kind of application we're analyzing
DETECTION_TYPE=$(cat .stackshift-state.json | jq -r '.detection_type // .path')
echo "Detection: $DETECTION_TYPE"
# Check extraction approach
ROUTE=$(cat .stackshift-state.json | jq -r '.route // .path')
echo "Route: $ROUTE"
# Check spec output location (Greenfield only)
SPEC_OUTPUT=$(cat .stackshift-state.json | jq -r '.config.spec_output_location // "."')
echo "Writing specs to: $SPEC_OUTPUT"
# Create output directories if needed
if [ "$SPEC_OUTPUT" != "." ]; then
mkdir -p "$SPEC_OUTPUT/docs/reverse-engineering"
mkdir -p "$SPEC_OUTPUT/.specify/memory/specifications"
fi
State file structure:
{
"detection_type": "monorepo-service", // What kind of app
"route": "greenfield", // How to spec it
"implementation_framework": "speckit", // speckit or bmad (affects Gear 6 only)
"config": {
"spec_output_location": "~/git/my-new-app",
"build_location": "~/git/my-new-app",
"target_stack": "Next.js 15..."
}
}
Output structure (same for all frameworks):
docs/reverse-engineering/
├── functional-specification.md
├── integration-points.md
├── configuration-reference.md
├── data-architecture.md
├── operations-guide.md
├── technical-debt-analysis.md
├── observability-requirements.md
├── visual-design-system.md
└── test-documentation.md
Extraction approach based on detection + route:
| Detection Type | + Greenfield | + Brownfield |
|---|---|---|
| Monorepo Service | Business logic only (tech-agnostic) | Full implementation + shared packages (tech-prescriptive) |
| Nx App | Business logic only (framework-agnostic) | Full Nx/Angular implementation details |
| Generic App | Business logic only | Full implementation |
How it works:
detection_type determines WHAT patterns to look for (shared packages, Nx project config, monorepo structure, etc.)route determines HOW to document them (tech-agnostic vs tech-prescriptive)Examples:
Approach depends on path:
Use the Task tool with subagent_type=stackshift:code-analyzer (or Explore as fallback) to analyze:
See operations/backend-analysis.md
See operations/frontend-analysis.md
See operations/infrastructure-analysis.md
See operations/testing-analysis.md
Create docs/reverse-engineering/ directory and generate all 8 documentation files.
See operations/generate-docs.md for templates and guidelines.
All 9 documentation files are written to docs/reverse-engineering/ regardless of implementation framework choice.
Focus: Business logic, WHAT the system does (not HOW)
Sections:
Critical: Framework-agnostic, testable, measurable
Complete inventory of all configuration:
All data models and API contracts:
How to deploy and maintain:
Issues and improvements:
Logging, monitoring, alerting:
UI/UX patterns:
Testing requirements:
docs/reverse-engineering/ directory createdOnce all documentation is generated and reviewed:
For GitHub Spec Kit (implementation_framework: speckit):
/stackshift.create-specs to transform docs into .specify/ specsFor BMAD Method (implementation_framework: bmad):
*workflow-initDO:
DON'T:
Use the Explore agent to ensure you find:
Each document must be:
subagent_type=stackshift:code-analyzer for path-aware extractionsubagent_type=Explore if StackShift agent not availablestackshift:code-analyzer agent understands greenfield vs brownfield routes automaticallyRemember: This is Step 2 of 6. The documentation you generate here will be transformed into formal specifications in Step 3.
Creating algorithmic art using p5.js with seeded randomness and interactive parameter exploration. Use this when users request creating art using code, generative art, algorithmic art, flow fields, or particle systems. Create original algorithmic art rather than copying existing artists' work to avoid copyright violations.
Applies Anthropic's official brand colors and typography to any sort of artifact that may benefit from having Anthropic's look-and-feel. Use it when brand colors or style guidelines, visual formatting, or company design standards apply.
Create beautiful visual art in .png and .pdf documents using design philosophy. You should use this skill when the user asks to create a poster, piece of art, design, or other static piece. Create original visual designs, never copying existing artists' work to avoid copyright violations.