paper-first-principles
Skill22 starsChanged 7 months agoMITView on GitHub
Use when converting academic papers into engineer-friendly documentation, extracting design patterns from research, or preparing technical knowledge sharing
In this repository17 other files it gives its agents.
- code-analysisSkill
- code-generatorSkill
- contributingSkill
- daily-logSkill
- devflowSkill
- git-workflowSkill
- hexo-blog-updateSkill
- kimicode-vision-bridgeSkill
- knowledge-base-cacheSkill
- layered-first-principles-teachingSkill
- msvc-buildSkill
- mvp-designSkill
- requirement-clarificationSkill
- research-to-practiceSkill
- taskmaster-skillSkill
- ue5-umgSkill
- unity-mcpSkill
The file
Files
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.mdOutput 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 casesresearcher: Technical depth, related work comparison, theorymanager: Problem context, decision rationale, risk assessment
--domain (optional)
Engineering domain for contextual mapping:
distributed-systems: Distributed systems, microservicesstorage: Storage systems, file systemsdatabase: Databases, data warehousesnetwork: Networks, CDN, load balancingml-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, useprompts/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
--domainsetting - Complex proofs may need manual verification
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

