القائمة
Explains code in plain language with architecture diagrams. Use when the user asks to understand how code works, needs onboarding help, or wants a high-level explanation of a module or system.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Write a session-specific /compact instruction that preserves irreconstructible context — tickets, PRs, async state, rejected alternatives, the why — instead of the default generic summary. Use when the user asks to compact, says "compacta", "compact smart", "/compact-smart", or when a long session is about to lose its thread.
Interactive skill for eliciting, formalizing, and persisting DynamoDB access patterns. Use when the user wants to start designing a DynamoDB table, define entities, or document how their application will read and write data. This is Step 1 of a 3-step pipeline: access patterns -> table design -> query interfaces. The output is a structured .md file that feeds into the dynamodb-table-design skill.
Generates language-agnostic repository interfaces (method signatures, input/output types, and entity models) from a DynamoDB table design document. Use when the user has a table design .md file (from dynamodb-table-design skill) and wants to generate the code skeleton for their data access layer. This is Step 3 of a 3-step pipeline: access patterns -> table design -> query interfaces.
Orchestrator for the DynamoDB single-table design pipeline. Use when the user wants to design a DynamoDB table end-to-end or is unsure which step to start with. Routes to the appropriate specialized skill: dynamodb-access-patterns, dynamodb-table-design, or dynamodb-query-interfaces.
Designs a DynamoDB single-table structure from a documented set of access patterns. Use when the user has an access patterns .md file (from dynamodb-access-patterns skill) and wants to design partition keys, sort keys, GSIs, composite keys, and map every access pattern to a concrete DynamoDB query operation. This is Step 2 of a 3-step pipeline: access patterns -> table design -> query interfaces.
Reviews code for bugs, security vulnerabilities, performance issues, and style. Use when the user asks for a code review or wants feedback on their changes.
| name | explain-code |
| description | Explains code in plain language with architecture diagrams. Use when the user asks to understand how code works, needs onboarding help, or wants a high-level explanation of a module or system. |
When explaining code, follow this structure:
Start with a single sentence explaining what this code does at the highest level.
Describe the key components and how they interact. Use a text-based diagram if there are 3+ components:
[Component A] --> [Component B] --> [Component C]
| ^
+---> [Component D] ---------------+
List the 3-5 most important concepts someone needs to understand to work with this code. Avoid jargon — explain terms the first time you use them.
Trace how data moves through the system for the most common operation. Use numbered steps.
Identify where and how a developer would typically add new functionality.
Adjust depth based on what was asked. If the user asks about a single function, keep it brief. If they ask about a whole module or system, go deeper.