القائمة
Assess architecture decisions, ADR compliance, coupling analysis, and design principles
يُحدَّد Prompt الذي يراجع المصدر أولًا بشكل افتراضي. يمكنك التبديل إلى أمر مباشر أو تنزيل نسخة محلية.
اقرأ SKILL.md وأي ملفات مرافقة يعرضها SkillsMP قبل أن تقرر التثبيت.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
يتجاوز الأمر المباشر Prompt المخصّص للمراجعة. افحص المصدر قبل تشغيله.
npx skills add https://github.com/aibot88/sec_skill_store --skill architecture-reviewيبقى الأمر في سطر واحد. مرّر أفقيًا لمراجعته كاملًا قبل النسخ.
تفضّل نسخة محلية؟ نزّل الملفات المتاحة حاليًا لدى SkillsMP.
Guides the creation of agile user stories and Gherkin feature files. Use when the user wants to create a user story, write acceptance criteria, define Gherkin scenarios, or author BDD feature files. This should trigger for requests such as Create a user story; Write a user story; I need to write a user story. Part of cursor-rules-java project
Guía técnica completa para integrar 250+ servicios externos con agentes IA usando Composio. Cubre instalación, autenticación OAuth, gestión de herramientas, triggers y flujos multi-servicio.
Facilitates conversational discovery to create Architectural Decision Records (ADRs) for non-functional requirements using the ISO/IEC 25010:2023 quality model. Use when the user wants to document quality attributes, NFR decisions, security/performance/scalability architecture, or design systems with measurable quality criteria. This should trigger for requests such as Create ADR for Non-functional requirements; Document Non-functional requirements; Capture Non-functional requirements; Generate Non-functional requirements in an ADR. Part of cursor-rules-java project
استنادا إلى تصنيف SOC المهني
عرض SKILL.md
| name | architecture-review |
| description | Assess architecture decisions, ADR compliance, coupling analysis, and design principles |
| version | 1.9.0 |
| alwaysApply | false |
| category | architecture |
| tags | ["architecture","design","adr","coupling","patterns","principles"] |
| tools | ["adr-auditor","coupling-analyzer","principle-checker"] |
| usage_patterns | ["architecture-assessment","adr-audit","refactor-review","design-validation"] |
| complexity | advanced |
| model_hint | deep |
| estimated_tokens | 300 |
| progressive_loading | true |
| dependencies | ["pensive:shared","imbue:proof-of-work","imbue:diff-analysis/modules/risk-assessment-framework"] |
| modules | ["modules/adr-audit.md","modules/coupling-analysis.md","modules/principle-checks.md","modules/fpf-methodology.md"] |
arch-review:context-established)arch-review:adr-audit)arch-review:interaction-mapping)arch-review:principle-checks)arch-review:risks-actions)Run pytest plugins/pensive/tests/skills/test_architecture_review.py to verify review logic.
Architecture assessment against ADRs and design principles.
/architecture-review
Load modules based on review scope:
modules/adr-audit.md (~400 tokens): ADR verification and documentation.modules/coupling-analysis.md (~450 tokens): Dependency analysis and boundary violations.modules/principle-checks.md (~500 tokens): Code quality, security, and performance.modules/fpf-methodology.md (~800 tokens): FPF (Functional, Practical, Foundation) multi-perspective review methodology.Load all modules for full reviews. For focused reviews, load only relevant modules.
arch-review:context-established: Repository, branch, motivation.arch-review:adr-audit: ADR verification and new ADR needs.arch-review:interaction-mapping: Module coupling analysis.arch-review:invariant-check: Invariant conflict detection and 3-option analysis.arch-review:principle-checks: LoD, security, performance.arch-review:risks-actions: Recommendation and follow-ups.arch-review:context-established)Confirm repository and branch:
pwd
git status -sb
Document:
arch-review:adr-audit)Load: modules/adr-audit.md
arch-review:interaction-mapping)Load: modules/coupling-analysis.md
arch-review:invariant-check)Before checking principles, identify whether the changes conflict with existing design invariants. This is the highest-judgment step in architecture review — models get this wrong more often than any other call.
Identify existing invariants:
# Detect boundary crossings in changed files
git diff --name-only | while read f; do
head -20 "$f" 2>/dev/null | rg "^(import|from|use |require)" || true
done
When a conflict is detected:
Do NOT recommend a resolution. Present the three options and escalate to human judgment:
| Option | When Right | When Wrong |
|---|---|---|
| Preserve invariant (reject feature) | Invariant simplifies many things; feature is marginal | Feature is genuinely needed and invariant is stale |
| Layer on top (add inelegantly) | Feature is needed; invariant still valuable; imperfection is OK | Layering creates a maintenance trap that will compound |
| Revise invariant (change the design) | Genuine new learning invalidates the original reasoning | You're "cleaning up" a decision you don't fully understand |
Output format:
### Invariant Conflicts
[I1] **[Invariant name]** — [what decision it represents]
- **Conflict**: [what change clashes]
- **Options**: Preserve / Layer / Revise
- **Recommendation**: ESCALATE TO HUMAN
- **Risk if wrong**: [what compounds]
Why this matters: Bad invariant decisions compound. After a few wrong calls the codebase becomes unsalvageable. This is a judgment problem, not a context problem — the agent should surface it, not solve it.
arch-review:principle-checks)Load: modules/principle-checks.md
arch-review:risks-actions)Summarize using imbue:diff-analysis/modules/risk-assessment-framework:
List follow-ups with owners and dates.
Provide recommendation: