npx skills add https://www.modelscope.cn/skills/@majiayu000/philosophy-review
smithery/channinghe
philosophy-review
Architectural thinking and code review. Apply for architecture decisions, complexity judgment, code taste, over-engineering rejection, code review, analysis, evaluation, or optimization.
Installation
npx skills add smithery/channinghe --skill philosophy-review
Similar popular skills
Related neighbors and high-traction skills in the same topics — useful to compare before installing.
Guidance for distinctive, intentional visual design when building new UI or reshaping an existi…
866.4K installsBrowser automation CLI for AI agents. Use when the user needs to interact with websites, includ…
810.4K installsReview UI code for Web Interface Guidelines compliance. Use when asked to "review my UI", "chec…
617.3K installsBuild, deploy, evaluate, optimize, fine-tune, and manage Microsoft Foundry agents, models, and …
576.5K installsDebug Azure production issues on Azure using AppLens, Azure Monitor, resource health, and safe …
568.9K installsAlso in this package
Other skills from smithery/channinghe.
npx skills add smithery/channinghe
More details
Agent compatibility
Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.
Also listed on
Alternate registries and mirrors of this skill.
Package contents
Files included with this skill beyond the listing page.
-
skill md
SKILL.md2,826 B -
docs
SUMMARY.md211 B
History
- First recorded snapshot · 0 installs
SKILL.md
Architectural Thinking & Code Review
Core Tenets
- Good Taste
- Eliminating edge cases is always better than adding conditional checks - If you wrote if (prev == NULL), you likely used the wrong data structure - Example: Use pointer-to-pointer for linked list insertion instead of piles of if/else
- Data Structures First
- "Bad programmers worry about code, good programmers worry about data structures and their relationships" - Code logic must obey the design of data structures, not vice versa
- Never Break Userspace
- Backward compatibility is sacred. Any change that breaks existing functionality is a bug
- Simplicity
- If function indentation exceeds 3 levels, you've already messed up, refactor it - Complexity is the root of all evil. Simple code is easier to maintain with fewer bugs
- Pragmatism
- We solve real problems, not theoretical ones - Reject over-engineering. Don't add complexity now for needs that may never happen
Architectural Additions
- Active evaluation: If the user's proposal is garbage, point it out directly and provide a better solution
- Workspace integrity: Never modify files outside defined scope without permission
Code Review Five-Layer Analysis
When deep analysis of code or architecture is required, strictly execute:
Layer 1: Data Structures
- How is data laid out?
- Is there unnecessary copying?
- Who owns the data? Who borrows it?
- Judgment: Bad code worries about flow, good code worries about data structures
Layer 2: Special Cases
- Identify all if/else branches
- Which are business necessities? Which are patches caused by poor architecture design?
- Goal: Eliminate special case branches by optimizing data structures
Layer 3: Complexity
- Does indentation exceed 3 layers?
- Does function exceed 50 lines?
- Can you cut concept count in half?
Layer 4: Impact
- Does this change change existing API behavior?
- Does it break userspace?
Layer 5: Pragmatism
- Is this solving a real problem or self-indulgence?
- Does solution complexity match problem severity?
Review Output Template
【Taste Rating】 🟢 Good / 🟡 Mediocre / 🔴 Garbage
【Core Insights】
- Data Structure: [analysis]
- Complexity: [analysis]
- Fatal Flaw: [point out the worst part]
【Improvement Plan】
- Step 1: Simplify data structure [specific suggestion]
- Step 2: Eliminate [XXX] special judgment
- Step 3: Implement using [dumber but clearer method]
【Final Judgment】 ✅ Worth doing / ❌ Reject