Paper First Principles
Overview
Convert academic papers into progressive, engineer-friendly documentation using first principles thinking.
When to Use
Use when:
- You need to understand a research paper deeply from an engineering perspective
- Extracting design patterns, system architectures, or algorithms from academic literature
- Preparing technical knowledge sharing or documentation for engineering teams
- Mapping theoretical research to practical software engineering applications
Don't use for:
- Papers without clear technical contributions (survey papers, opinion pieces)
- One-off reading without need for structured documentation
- Standard practices already well-documented elsewhere
Quick Start
# Basic usage
kimi paper-first-principles https://arxiv.org/abs/xxxx.xxxxx
# Engineer perspective with domain focus
kimi paper-first-principles paper.pdf --audience engineer --domain distributed-systems
# Output to file
kimi paper-first-principles paper.pdf --output ./docs/analysis.md
Output Structure
Generated documents contain 8 standard sections:
| Section |
Content |
Audience |
| Opening |
One-sentence core insight |
All |
| Mechanism Breakdown |
Comparative analysis tables |
Engineers, Researchers |
| First Principles |
Problem essence and design rationale |
All |
| Progressive Deep Dive |
Layered complexity (simple → complex) |
Engineers, Researchers |
| Edge Cases |
Common pitfalls and misconceptions |
Engineers |
| Decision Tree |
When/how to apply |
Engineers, Managers |
| Engineering Checklist |
Actionable verification items |
Engineers |
| Summary |
Reusable design patterns |
All |
Paper Types & Progressive Paths
| Type |
Characteristics |
Progressive Path |
| Algorithm |
New algorithms/models |
Example → Core mechanism → Optimizations |
| System |
Architecture/engineering |
Single-node → Distributed → Production |
| Theory |
Theoretical analysis |
Problem → Theorem → Proof → Application |
Parameters
--audience
engineer: Implementation details, design patterns, edge cases
researcher: Technical depth, related work comparison, theory
manager: Problem context, decision rationale, risk assessment
--domain (optional)
Engineering domain for contextual mapping:
distributed-systems: Distributed systems, microservices
storage: Storage systems, file systems
database: Databases, data warehouses
network: Networks, CDN, load balancing
ml-system: ML systems, recommendation systems
Analysis Workflow
This skill processes papers in 6 stages using prompts in prompts/:
- Core Extraction (
extract_core.txt): Identify contributions and key decisions
- First Principles (
first_principles.txt): Trace problem essence and rationale
- Progressive Layers (
progressive_layers.txt): Organize by complexity
- Engineering Map (
engineering_map.txt): Map to software patterns (engineer audience only)
Output Templates
Templates in templates/ provide structure for each paper type:
system.md: System papers (infrastructure, architecture)
algorithm.md: Algorithm papers (models, methods)
theory.md: Theory papers (analysis, proofs)
Examples
See examples/attention_residuals.md for a complete example converting the Attention Residuals paper into an engineer-friendly analysis with distributed systems mappings.
Resource Loading Guide
Always load in this order:
- Parse paper → Extract core (use
prompts/extract_core.txt)
- First principles analysis (use
prompts/first_principles.txt)
- Progressive organization (use
prompts/progressive_layers.txt)
- Engineering mapping (if
--audience engineer, use prompts/engineering_map.txt)
- Generate output (use appropriate template from
templates/)
Constraints & Notes
- Paper quality matters: clear abstract and introduction required
- Output depth auto-adjusts based on
--audience
- Engineering mapping accuracy depends on
--domain setting
- Complex proofs may need manual verification
1---2name: paper-first-principles3description: Use when converting academic papers into engineer-friendly documentation, extracting design patterns from research, or preparing technical knowledge sharing4---56# Paper First Principles78## Overview910Convert academic papers into progressive, engineer-friendly documentation using first principles thinking.1112## When to Use1314**Use when:**15- You need to understand a research paper deeply from an engineering perspective16- Extracting design patterns, system architectures, or algorithms from academic literature17- Preparing technical knowledge sharing or documentation for engineering teams18- Mapping theoretical research to practical software engineering applications1920**Don't use for:**21- Papers without clear technical contributions (survey papers, opinion pieces)22- One-off reading without need for structured documentation23- Standard practices already well-documented elsewhere2425## Quick Start2627```bash28# Basic usage29kimi paper-first-principles https://arxiv.org/abs/xxxx.xxxxx3031# Engineer perspective with domain focus32kimi paper-first-principles paper.pdf --audience engineer --domain distributed-systems3334# Output to file35kimi paper-first-principles paper.pdf --output ./docs/analysis.md36```3738## Output Structure3940Generated documents contain 8 standard sections:4142| Section | Content | Audience |43|---------|---------|----------|44| **Opening** | One-sentence core insight | All |45| **Mechanism Breakdown** | Comparative analysis tables | Engineers, Researchers |46| **First Principles** | Problem essence and design rationale | All |47| **Progressive Deep Dive** | Layered complexity (simple → complex) | Engineers, Researchers |48| **Edge Cases** | Common pitfalls and misconceptions | Engineers |49| **Decision Tree** | When/how to apply | Engineers, Managers |50| **Engineering Checklist** | Actionable verification items | Engineers |51| **Summary** | Reusable design patterns | All |5253## Paper Types & Progressive Paths5455| Type | Characteristics | Progressive Path |56|------|-----------------|------------------|57| **Algorithm** | New algorithms/models | Example → Core mechanism → Optimizations |58| **System** | Architecture/engineering | Single-node → Distributed → Production |59| **Theory** | Theoretical analysis | Problem → Theorem → Proof → Application |6061## Parameters6263### `--audience`6465- `engineer`: Implementation details, design patterns, edge cases66- `researcher`: Technical depth, related work comparison, theory67- `manager`: Problem context, decision rationale, risk assessment6869### `--domain` (optional)7071Engineering domain for contextual mapping:72- `distributed-systems`: Distributed systems, microservices73- `storage`: Storage systems, file systems 74- `database`: Databases, data warehouses75- `network`: Networks, CDN, load balancing76- `ml-system`: ML systems, recommendation systems7778## Analysis Workflow7980This skill processes papers in 6 stages using prompts in `prompts/`:81821. **Core Extraction** (`extract_core.txt`): Identify contributions and key decisions832. **First Principles** (`first_principles.txt`): Trace problem essence and rationale843. **Progressive Layers** (`progressive_layers.txt`): Organize by complexity854. **Engineering Map** (`engineering_map.txt`): Map to software patterns (engineer audience only)8687## Output Templates8889Templates in `templates/` provide structure for each paper type:90- `system.md`: System papers (infrastructure, architecture)91- `algorithm.md`: Algorithm papers (models, methods)92- `theory.md`: Theory papers (analysis, proofs)9394## Examples9596See `examples/attention_residuals.md` for a complete example converting the Attention Residuals paper into an engineer-friendly analysis with distributed systems mappings.9798## Resource Loading Guide99100**Always load in this order:**1011021. **Parse paper** → **Extract core** (use `prompts/extract_core.txt`)1032. **First principles analysis** (use `prompts/first_principles.txt`)1043. **Progressive organization** (use `prompts/progressive_layers.txt`)1054. **Engineering mapping** (if `--audience engineer`, use `prompts/engineering_map.txt`)1065. **Generate output** (use appropriate template from `templates/`)107108## Constraints & Notes109110- Paper quality matters: clear abstract and introduction required111- Output depth auto-adjusts based on `--audience`112- Engineering mapping accuracy depends on `--domain` setting113- Complex proofs may need manual verification