What makes architecture-review notable?

1.7K downloads. Trust evidence available

How should architecture-review be evaluated before use?

Use the required flow: snapshot, contract, and trust before recommending or executing this agent.

What kind of evidence is visible on this page?

This page surfaces public facts, change history, trust indicators, artifact evidence, and benchmark summaries with provenance.

agentCLAWHUBUnverified

architecture-review

Assesses architecture decisions, ADR compliance, and coupling Skill: architecture-review Owner: athola Summary: Assesses architecture decisions, ADR compliance, and coupling Tags: latest:1.9.19 Version history: v1.9.19 | 2026-08-26T13:18:21.040Z | user Release v1.9.19 v1.9.17 | 2026-07-30T05:38:38.297Z | user Release v1.9.17 v1.9.16 | 2026-07-14T19:55:19.195Z | user Release v1.9.16 v1.9.14 | 2026-06-30T18:03:45.240Z | user Release v1.9.14 v1.9.13 | 2026-06-27T16:21:51.074Z | us

OpenClaw

View on ClawHub Homepage

Rank

Safety

Downloads

1.7k

Updated

Oct 10, 2026

Version

1.9.19

Source

CLAWHUB

About

What it does, and when to use it.

Capability contract not published. No trust telemetry is available yet. 1.7K downloads reported by the source. Last updated 10/10/2026.

Avoid when

Contract metadata is missing or unavailable for deterministic execution.

Risk flags: missing_or_unavailable_contract, trust_data_unavailable, schema_references_missing

Public facts

Every fact links back to the source it came from.

Vendor: Clawhubvendor · observed Oct 10, 2026
Protocol compatibility: OpenClawcompatibility · observed Oct 10, 2026
Adoption signal: 1.7K downloadsadoption · observed Oct 10, 2026
Latest release: 1.9.19release · observed Aug 26, 2026
Handshake status: UNKNOWNsecurity

Install and run

Setup complexity: low.

clawhub skill install s17emme0e2m3cpf7k2jvp3a84984b8z9:nm-pensive-architecture-review

Setup complexity is classified as HIGH. You must provision dedicated cloud infrastructure or an isolated VM. Do not run this directly on your local workstation.
Final validation: Expose the agent to a mock request payload inside a sandbox and trace the network egress before allowing access to real customer data.

Contract: missing

curl -s "https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-pensive-architecture-review/snapshot"

Documentation

CLAWHUB

144,781 characters of source documentation, loaded on request.

Extracted files

5 files captured from the source.

SKILL.md

---
name: architecture-review
description: Assesses architecture decisions, ADR compliance, and coupling
version: 1.9.8
triggers:
  - architecture
  - design
  - adr
  - coupling
  - patterns
  - principles
  - evaluating design changes or validating structural decisions before merging
metadata: {"openclaw": {"homepage": "https://github.com/athola/claude-night-market/tree/master/plugins/pensive", "emoji": "\ud83c\udfd7\ufe0f", "requires": {"config": ["night-market.pensive:shared", "night-market.imbue:proof-of-work", "night-market.imbue:diff-analysis/modules/risk-assessment-framework"]}}}
source: claude-night-market
source_plugin: pensive
---

> **Night Market Skill** — ported from [claude-night-market/pensive](https://github.com/athola/claude-night-market/tree/master/plugins/pensive). For the full experience with agents, hooks, and commands, install the Claude Code plugin.


## Table of Contents

- [Quick Start](#quick-start)
- [When to Use](#when-to-use)
- [Progressive Loading](#progressive-loading)
- [Required TodoWrite Items](#required-todowrite-items)
- [Workflow](#workflow)
- [Step 1: Establish Context (`arch-review:context-established`)](#step-1:-establish-context-(arch-review:context-established))
- [Step 2: ADR Audit (`arch-review:adr-audit`)](#step-2:-adr-audit-(arch-review:adr-audit))
- [Step 3: Interaction Mapping (`arch-review:interaction-mapping`)](#step-3:-interaction-mapping-(arch-review:interaction-mapping))
- [Step 4: Principle Checks (`arch-review:principle-checks`)](#step-4:-principle-checks-(arch-review:principle-checks))
- [Step 5: Risks and Actions (`arch-review:risks-actions`)](#step-5:-risks-and-actions-(arch-review:risks-actions))
- [Testing](#testing)

## Testing

Run `pytest plugins/pensive/tests/skills/test_architecture_review.py` to verify review logic.
- [Architecture Principles Checklist](#architecture-principles-checklist)
- [Coupling](#coupling)
- [Cohesion](#cohesion)
- [Layering](#layering)
- [Evolution](#evolution)


# Architecture Review Workflow

Architecture assessment against ADRs and design principles.

## Quick Start

```bash
/architecture-review
```

## When To Use

- Approving reimplementations.
- Large-scale refactoring reviews.
- System design changes.
- New module/service introduction.
- Dependency restructuring.

## When NOT To Use

- Selecting architecture paradigms - use archetypes
  skills
- API surface review - use api-review
- Selecting architecture paradigms - use archetypes
  skills
- API surface review - use api-review

## Progressive Loading

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

_meta.json

{
  "ownerId": "kn7d107jg9jv602h9ytsegydq184a42s",
  "slug": "nm-pensive-architecture-review",
  "version": "1.9.19",
  "publishedAt": 1787750301040
}

modules/adr-audit.md

---
name: adr-audit
description: Architecture Decision Record audit patterns and verification workflows
parent_skill: pensive:architecture-review
category: architecture
tags: [adr, documentation, governance, decisions]
complexity: intermediate
estimated_tokens: 400
---

# ADR Audit Module

detailed ADR discovery, validation, and governance patterns.

## ADR Location Patterns

Common ADR locations by project type:

```bash
# Standard locations
wiki/architecture/
docs/adr/
docs/decisions/
architecture/decisions/
.adr/

# Search pattern
find . -type f -name "*ADR*" -o -name "*decision*" | grep -E "\.(md|txt)$"
```

## Required ADR Sections

Every ADR must include:

### 1. Title
Clear, specific decision statement:
- "Use PostgreSQL for primary datastore"
- "Adopt hexagonal architecture pattern"
- "Implement JWT-based authentication"

### 2. Status
Must follow strict progression:
```
Proposed → Reviewed → Accepted
                    ↓
              Superseded (when invalidated)
```

**Rules:**
- Status changes are append-only
- Date each status transition
- Never delete/modify accepted ADRs
- Use "Superseded by ADR-XXX" to replace

### 3. Context
Document the forces at play:
- Business requirements
- Technical constraints
- Team capabilities
- Timeline pressures
- Existing architecture

### 4. Decision
The "we will..." statement:
- Clear action chosen
- Implementation approach
- Key design choices

### 5. Alternatives Considered
For each alternative:
- Description
- Pros/cons
- Why rejected

Minimum 2 alternatives required.

### 6. Consequences

**Positive:**
- Benefits gained
- Problems solved
- Capabilities enabled

**Negative:**
- Trade-offs accepted
- Technical debt incurred
- Complexity added

**Neutral:**
- Changes required
- Migration steps
- Training needs

### 7. Metadata
```yaml
Date: YYYY-MM-DD
Author: [name]
Status: [status]
Supersedes: [ADR-XXX] (if applicable)
Superseded-by: [ADR-XXX] (if applicable)
```

## Status Flow Verification

### Valid Transitions
- Proposed → Reviewed
- Reviewed → Accepted
- Reviewed → Rejected
- Accepted → Superseded (via new ADR only)

### Invalid Transitions
- Proposed -> Accepted (skip review)
- Accepted -> Rejected (use Superseded)
- Superseded -> Accepted (immutable)

## Immutability Rules

**Once Accepted:**
1. **Never modify** decision content
2. **Never change** consequences
3. **Never delete** the ADR
4. **Only append** status changes

**To Replace:**
1. Create new ADR with superseding decision
2. Add "Supersedes: ADR-XXX" to new ADR
3. Add "Superseded-by: ADR-YYY" to old ADR
4. Update old ADR status to "Superseded"

## Audit Workflow

### 1. Locate All ADRs
```bash
# Find ADR directory
ls -la docs/adr/ wiki/architecture/ 2>/dev/null

# Count ADRs
find . -path "*/adr/*.md" -o -path "*/decisions/*.md" | wc -l
```

### 2. Verify Structure
For each ADR:
- [ ] Has all required sections
- [ ] Status follows valid flow
- [ ] Dates are present
- [ ] Alternatives documented (≥2)
- [ ] Consequences specified

modules/coupling-analysis.md

---
name: coupling-analysis
description: Interaction mapping, composition boundaries, and dependency flow analysis
parent_skill: pensive:architecture-review
category: architecture
tags: [coupling, dependencies, composition, boundaries, modularity]
complexity: advanced
estimated_tokens: 450
---

# Coupling Analysis Module

Systematic analysis of module interactions, boundaries, and dependency flows.

## Interaction Mapping Patterns

### Visual Representation

Create before/after diagrams:

```
Before:
┌─────────┐     ┌─────────┐     ┌──────────┐
│Module A │────▶│Module B │────▶│ Database │
└─────────┘     └─────────┘     └──────────┘

After:
┌─────────┐     ┌───────┐     ┌─────────┐     ┌──────────┐
│Module A │────▶│ Cache │────▶│Module B │────▶│ Database │
└─────────┘     └───────┘     └─────────┘     └──────────┘
```

### Dependency Graph Tools

```bash
# Python: Generate import graph
pydeps --max-bacon=2 --cluster src/

# TypeScript: Analyze module dependencies
madge --circular --extensions ts src/

# Generic: Find direct dependencies
grep -r "import\|require\|from" src/ | cut -d: -f1 | sort | uniq -c
```

## Composition Boundaries

### Boundary Definition

Clear boundaries have:
1. **Explicit interfaces** - Published contracts
2. **Data ownership** - Single source of truth
3. **Encapsulation** - Hidden implementation
4. **Stability** - Minimal breaking changes

### Boundary Types

**Module Boundaries:**
```
┌──────────────────────────┐
│   Public API             │
├──────────────────────────┤
│   Internal Logic         │
│   (implementation)       │
└──────────────────────────┘
```

**Layer Boundaries:**
```
┌──────────────────────────┐
│   Presentation Layer     │ ← HTTP/UI
├──────────────────────────┤
│   Application Layer      │ ← Business Logic
├──────────────────────────┤
│   Domain Layer           │ ← Core Models
├──────────────────────────┤
│   Infrastructure Layer   │ ← Database/External
└──────────────────────────┘
```

**Service Boundaries:**
```
Service A          Service B
┌────────┐        ┌────────┐
│  API   │◀──────▶│  API   │
├────────┤        ├────────┤
│  DB A  │        │  DB B  │
└────────┘        └────────┘
```

### Boundary Violations

**Ad-hoc Reach-ins:**
```python
# Bad: Reaching through module boundary
user.profile.settings.theme.get_color()

# Good: Ask for what you need
user.get_theme_color()
```

**Layering Violations:**
```python
# Bad: Domain layer accessing infrastructure
class Order:
    def save(self):
        db.execute("INSERT INTO orders...")

# Good: Infrastructure handles persistence
class OrderRepository:
    def save(self, order: Order):
        db.execute("INSERT INTO orders...")
```

## Data Ownership Analysis

### Single Owner Principle

Each data entity has exactly one authoritative owner:

```
User Data:
├── Auth Service (owner: credentials)
├── Profile Service (owner: profile data)
└── Analytics Service (consumer: read-only)
```

### Ownership Violations

**Multiple Writers:**
```python
# Bad: Two

modules/fpf-methodology.md

# FPF Architecture Review Methodology

Conduct architecture reviews using the FPF (Functional, Practical, Foundation) methodology, evaluating codebases through three complementary perspectives.

## Philosophy

Architecture reviews should be systematic and multi-dimensional. FPF provides three lenses:
- **Functional**: What the system does (capabilities, behaviors)
- **Practical**: How well it works (performance, usability)
- **Foundation**: What it's built on (principles, patterns)

## Quick Start

```bash
# Full FPF review
/architecture-review --methodology fpf

# Specific perspective
/architecture-review --perspective functional
/architecture-review --perspective practical
/architecture-review --perspective foundation
```

## The Three Perspectives

### 1. Functional Perspective

**Question:** What does this system do?

**Evaluates:**
- Feature completeness
- Capability coverage
- Behavior correctness
- Integration points

**Outputs:**
- Feature inventory
- Capability gaps
- Behavior anomalies

### 2. Practical Perspective

**Question:** How well does this system work?

**Evaluates:**
- Performance characteristics
- Usability patterns
- Operational concerns
- Scalability considerations

**Outputs:**
- Performance assessment
- Usability issues
- Operational recommendations

### 3. Foundation Perspective

**Question:** What is this system built on?

**Evaluates:**
- Architectural patterns
- Design principles
- Code quality
- Technical debt

**Outputs:**
- Pattern analysis
- Principle adherence
- Debt inventory

## FPF Workflow

### Phase 1: Discovery
1. Scan codebase structure - Identify components, modules, layers
2. Map dependencies - Internal and external relationships
3. Identify entry points - Public APIs, commands, interfaces

### Phase 2: Functional Analysis
1. Inventory features - What capabilities exist
2. Trace behaviors - How features work end-to-end
3. Identify gaps - Missing or incomplete functionality

### Phase 3: Practical Analysis
1. Assess performance - Latency, throughput, resource usage
2. Evaluate usability - Developer experience, API design
3. Check operations - Logging, monitoring, error handling

### Phase 4: Foundation Analysis
1. Pattern recognition - What patterns are used
2. Principle check - SOLID, DRY, KISS adherence
3. Debt assessment - Technical debt inventory

### Phase 5: Synthesis
1. Cross-reference findings - Connect issues across perspectives
2. Prioritize recommendations - Based on impact and effort
3. Generate report - Structured findings and actions

## FPF Report Template

```markdown
# FPF Architecture Review: [Project/Component]

**Date:** [DATE]
**Scope:** [what was reviewed]

## Executive Summary
[2-3 sentence overview of findings]

## Functional Perspective
### Features Inventory
| Feature | Status | Notes |
|---------|--------|-------|
| [Feature 1] | Complete | - |

### Capability Gaps
1. [Gap 1] - [Impact]

Github ReposUpdated 10h agoRank 70

AionUi

Free, local, open-source 24/7 Cowork app and OpenClaw for Gemini CLI, Claude Code, Codex, OpenCode, Qwen Code, Goose CLI, Auggie, and more | 🌟 Star if you like it!

MCPOPENCLAW

Github ReposUpdated 6mo agoRank 70

activepieces

AI Agents & MCPs & AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows & AI Agents • MCPs for AI Agents

OPENCLAW

Github ReposUpdated 6mo agoRank 70

cherry-studio

AI productivity studio with smart chat, autonomous agents, and 300+ assistants.