# Self Review

> Run a 4-pillar, 6-dimension alignment audit on the current project. Checks design currency, executes artifact verification, detects skill deposits. Use when the user says "self-review", "审视一下", or "audit". Report-only — never auto-fix.

- Skill: `motiful/self-review` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add motiful/self-review`
- Raw SKILL.md: https://api.skillmd.com/api/skills/motiful/self-review/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- License: MIT
- Author: motiful (https://skillmd.com/u/motiful)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/motiful/self-review

---


# Self-Review

Audit process: discover anchors in 4 pillars (Design, Artifact, Skill, Progress), lock scope from Progress, then check alignment across all 6 pillar-pair dimensions. Platform-agnostic, language-agnostic.

## Rules

- **Report only, never auto-fix** — flag issues, do not modify files. Exception: Dimension 2 MUST execute verification (build, run, CLI) — read-only execution.
- **Scope first** — lock scope from Progress before any dimension. Never flag deferred/out-of-scope items.
- **Progress first** — start from "what are we doing now?" and radiate outward.
- **Scan by content, not by file type** — a commit message can carry Design intent, a code comment can carry Progress status. Never skip content because "it's not in the right file type for this pillar."
- **Infer before skipping** — when a pillar has no explicit files, check implicit sources before declaring it empty.
- **Built-in principles + user standards** — the 6 principles are the baseline; project rules and domain skills add to it, never replace it.
- **Be specific** — cite file paths and line numbers.
- **No false positives** — only flag real drift. "Not yet built" is not drift if deferred.
- **Skill deposits need criteria** — evaluate against deposit criteria in dimensions.md (Dimension 3).
- **Always add current year to search queries** — for Currency and Assumptions checks.
- **Platform-agnostic, language-agnostic.**

## Execution Procedure

```python
def self_review(project_path):
    # STEP 1: Discover Anchors
    anchors = scan_anchors(project_path)               # see The 4 Pillars + Step 1 tables
    standards = scan_standards(project_path)            # see Project-Specific Standards
    domain_skills = scan_domain_skills(project_path)    # see Domain Skills
    infer_missing(anchors)                              # see Implicit Anchor Inference

    if anchors.design:
        introspection = evaluate_design(anchors.design) # see Design Introspection
        currency = check_currency(anchors.progress)     # see Currency & Assumptions Check

    # STEP 2: Lock Scope
    scope = lock_scope(anchors.progress)               # see Step 2: Lock Scope
    assert scope.current_phase                         # GATE — cannot audit without knowing phase

    # STEP 3: Run 6 Dimensions                         # references/dimensions.md
    # Priority — always run
    d1 = check_progress_design(anchors, scope, standards)
    d2 = check_progress_artifact(anchors, scope, standards)
    assert d2.verification_executed                    # GATE — must execute, not just report
    assert d2.verification_level >= min_level(artifact_type)  # GATE — see Verification Depth by Artifact Type in dimensions.md
    d3 = check_progress_skill(anchors, scope, standards)

    # Cross-pillar — always run
    d4 = check_design_artifact(anchors, scope, standards)
    d5 = check_design_skill(anchors, scope, standards)
    d6 = check_artifact_skill(anchors, scope, standards)

    # STEP 4: Report
    report(introspection, scope, [d1, d2, d3, d4, d5, d6])  # see Step 4: Report
```

## Audit Principles

Six principles guide all dimension checks. They are embedded as check questions in each dimension — you don't need to apply them separately.

| # | Principle | One-line definition |
|---|-----------|-------------------|
| T1 | Verifiable & Verified | Claims must be testable, and evidence of passing must exist |
| T2 | No Internal Contradiction | No conflicting statements across pillars |
| T3 | Simplest Sufficient Solution | Don't introduce what isn't needed |
| E1 | Feasible | Achievable with current resources |
| E2 | Boundary-Complete | No fatal gaps within current scope |
| E3 | Maintainable | Others can understand and continue the work |

## The 4 Pillars

| Pillar | Core question | What it covers | Common carriers (examples, not definitions) |
|--------|--------------|----------------|---------------------------------------------|
| **Design** | Why are we doing this? What should it become? | Intent, decisions, constraints, specs | CLAUDE.md, design docs, requirements, even commit messages or verbal agreements |
| **Artifact** | What was actually produced? | Any deliverable — code, documents, designs, videos, skills, configs | src/, articles, exported videos, design files, SKILL.md itself |
| **Skill** | How do we do things? What did we learn? | Reusable methods, standards, accumulated know-how | Style guides, workflows, conventions, templates, coding patterns |
| **Progress** | Where are we? What's next? | Plans, status, milestones, tracking | progress.md, changelogs, git log, TODO comments, roadmaps |

## Process

### Step 1: Discover Anchors

Scan the project for anchors in each pillar (all optional — skip pillars with no anchors after attempting inference):

| Pillar | Typical anchors |
|--------|----------------|
| Design | `CLAUDE.md`, `**/design/*.md`, `**/docs/*.md`, `README.md` |
| Artifact | `src/`, `lib/`, `app/`, `dist/`, `output/`, `**/types.ts` |
| Skill | `.claude/skills/`, `skill/`, `**/references/*.md`, `**/templates/` |
| Progress | `**/progress.md`, `**/plan/*.md`, `CHANGELOG.md`, `**/roadmap.md` |

Report which anchors you found and which pillars have none.

#### Project-Specific Standards

Beyond the standard anchors, scan for project-specific quality standards that should inform the audit. These files vary by platform — check whichever exist:

| Platform | Project instructions | Local/private overrides | Rules/standards |
|----------|---------------------|------------------------|-----------------|
| Claude Code | `CLAUDE.md` | `CLAUDE.local.md` | `.claude/rules/*.md` |
| Cursor | `.cursor/rules/*.mdc` | `.cursor/rules/personal.mdc` (gitignored) | `.cursorrules` (legacy) |
| Codex | `AGENTS.md` | `AGENTS.override.md` | — |
| OpenClaw | `AGENTS.md`, `SOUL.md` | via `openclaw.json` | — |
| Generic | `README.md`, `CONTRIBUTING.md` | — | `.editorconfig`, linter configs |

If found, these standards become additional checks in cross-pillar dimensions. For example:
- `CLAUDE.md` says "capture-pane is debug only" → Dimension 4 checks code doesn't use capture-pane for core logic
- `AGENTS.override.md` says "run tests before committing" → Dimension 2 checks if test evidence exists
- `CONTRIBUTING.md` says "no direct pushes to main" → Dimension 6 checks branch workflow

#### Domain Skills

Scan `.claude/skills/` (or platform equivalent) for two types of skills:

**Domain skills** — skills whose description matches the current project's domain. Treat the standards and rules defined in those skills as additional check criteria — layer them on top of the built-in principles when running dimensions. Only include domain skills that are clearly relevant. Do not force-apply unrelated skills.

Example: A `video-editing` skill defines "jump cuts must not exceed 3 frames" → Dimension 4 and 6 check this rule against the artifact.

**Rule-skills** — skills whose primary value is enforceable MUST/NEVER constraints (not workflows). These follow the rules-as-skills pattern. In-repo rule-skills are **always relevant** to the project they live in, regardless of domain match. Extract each MUST/NEVER constraint and elevate it to an audit standard with the same authority as `CLAUDE.md` rules.

Detection signals:
- Description or body contains MUST/NEVER/ALWAYS constraint patterns
- Has a Constraints section with enumerated rules
- Name contains "rules", "constraints", or "standards"
- Follows rules-as-skills three-layer format (trigger → constraints → verification)

Example: A `maintenance-rules` skill defines "MUST NOT push SKILL.md body over 500 lines" → Dimension 2 verifies line count, Dimension 6 checks compliance.

Report detected rule-skills and their extracted constraints in the Anchors section under Skill.

#### Implicit Anchor Inference

When a pillar has no dedicated files, attempt to infer its content from implicit sources before skipping:

| Pillar | Implicit sources to check |
|--------|--------------------------|
| Design | Commit messages, PR descriptions, README intro, inline comments stating intent |
| Artifact | Any output file (this pillar is almost never empty) |
| Skill | Recurring code patterns, consistent conventions across files |
| Progress | Git log timeline, branch names, TODO/FIXME comments |

Mark inferred anchors as `[inferred]` in the report. If inference produces nothing useful, then skip the pillar with a note.

#### Design Introspection

When Design anchors are found, evaluate the design itself — not just its alignment with other pillars. Apply the following checks:

- **Clarity**: Is the stated goal well-defined? Could someone new understand the intent?
- **Value**: Is this a well-formulated problem? Is it worth solving in this form?
- **Scope**: Is the scope appropriate — not too broad, not too narrow?
- **Assumptions**: Are there stale assumptions, blind spots, or unconsidered alternatives?
- **Currency**: Is the project solving the right problem with current tools? (See detailed check below.)
- **Simplicity**: Is this the simplest sufficient solution? Can anything be removed without losing capability? Are there simpler alternatives with equal explanatory/functional power?

#### Currency & Assumptions Check

**Scope rule**: Only check currency for in-scope items that are pending, in-progress, or blocked. Completed, working items are NOT checked — don't fix what isn't broken. Don't search dependency versions (that's a package manager's job).

**Check process**:

1. Extract unsolved problems from Progress (pending/blocked items only)
2. For each unsolved problem, search: `"<problem description> solution <current year>"`
3. Evaluate search results:

| Finding | Label | Action |
|---------|-------|--------|
| No relevant new solution | Current | No action |
| Community solution exists but immature (<6 months, few adopters, no major platform support) | Emerging | Note in report, don't recommend switching |
| Community solution with significant adoption (major platform support, established project) | Problem Dissolved | Flag: "This problem may already be solved by X. Verify before continuing custom work." Include source URL |
| A key design assumption has been invalidated (API added, limitation removed, standard changed) | Assumption Invalidated | Flag: "Design assumes X, but Y is now supported as of [date]." Include source URL |

4. For Assumptions specifically: extract hard assumptions from Design anchors (patterns like "because X doesn't support Y", "since there's no way to Z", "limited by W"). Search each to verify it still holds.

**Always add the current year to search queries** (e.g., "React server components 2026").

For each major design decision identified above, ask these three questions:
1. Can this actually be built/delivered with the resources available? (What would block it?)
2. What scenario within the current scope would break this? (What's the weakest point?)
3. Is there a way to achieve the same goal with fewer moving parts? (What can be removed?)

If any question reveals a concern, report it. These questions only apply to decisions that significantly affect the project direction — skip for minor choices.

Report design introspection findings as a preamble before dimensional checks.

### Step 2: Lock Scope

Before running any dimension checks, establish the audit boundary from Progress:

1. **Read current phase** from Progress anchors. Identify what the project claims to be working on *right now*.

2. **Classify all items into three categories:**

| Category | Definition | Audit treatment |
|----------|-----------|-----------------|
| **In-scope** | Items belonging to the current phase/milestone | Full dimensional check against all 6 principles |
| **Deferred** | Items explicitly postponed to a future phase | Only check: is it tracked somewhere? Not lost silently? |
| **Out-of-scope** | Items not in any plan | Do not check. Do not flag absence as a defect |

3. **State the locked scope explicitly in the report** so the reader knows what was and wasn't audited.

**The core rule: do not judge current work by future plans.** A feature designed for Phase 3 that doesn't exist yet is not a defect in Phase 1. An architecture that will need refactoring later is acceptable if the current phase is independently testable and shippable.

Flag Phase 1 artifacts that depend on unbuilt Phase 2 — those are real defects. But "Phase 2 hasn't started yet" is never a finding.

### Step 3: Run 6 Dimensions

Each dimension checks drift between two pillars. This is the complete C(4,2) combination — no exceptions, no artificial extras.

**Priority (Progress-centric) — always run:**
1. **Progress <> Design** — Are we aligned with design intent?
2. **Progress <> Artifact** — Does claimed status match actual deliverables? **Must execute verification.**
3. **Progress <> Skill** — Any lessons to capture? Existing skills need updating?

**Cross-pillar — always run:**
4. **Design <> Artifact** — Does the output match the design?
5. **Design <> Skill** — Do our methods support our design goals?
6. **Artifact <> Skill** — Does the output follow established methods?

See `references/dimensions.md` for detailed checks per dimension.

### Step 4: Report

Output a structured report:

```
## Self-Review Report

### Design Introspection
- [findings on clarity, value, scope, assumptions, currency, simplicity]

### Scope Lock
- **Current phase**: [phase name/description]
- **In-scope**: [items being audited]
- **Deferred**: [items tracked but not yet due]
- **Out-of-scope**: [not applicable to this audit]

### Anchors Found
- **Design**: [paths]
- **Artifact**: [paths]
- **Skill**: [paths]
- **Progress**: [paths]

### Priority Dimensions (Progress-centric)

#### 1. Progress <> Design [Aligned / Drift / Broken]
- [specific findings with file paths, scoped to current phase]

#### 2. Progress <> Artifact [Aligned / Drift / Broken]
- [specific findings, with verification evidence]

#### 3. Progress <> Skill [Aligned / Drift / Broken]
- [specific findings]

### Cross-pillar Dimensions

#### 4. Design <> Artifact [Aligned / Drift / Broken]
- [specific findings, scoped to current phase]

#### 5. Design <> Skill [Aligned / Drift / Broken]
- [specific findings]

#### 6. Artifact <> Skill [Aligned / Drift / Broken]
- [specific findings]

### Summary
- X/6 aligned, Y/6 drifted, Z/6 broken
- [top priority fixes, if any]
- [skill deposit candidates with recommendation]
```

#### Standard Recommendations

If the audit finds recurring quality issues with no corresponding standard, include a **Standard Recommendation** in the report:
1. Specify the exact file path where the standard should be persisted (use the platform table in Step 1)
2. Draft the standard text ready to be added
3. Explain why this standard is worth adding (what recurring issue it prevents)

**Persistence routing:**
- **Project-local standards** (single-project, simple) → platform-native file: `.claude/rules/<topic>.md` (CC), `AGENTS.override.md` (Codex), `.cursor/rules/<topic>.mdc` (Cursor)
- **Cross-project reusable standards** → suggest creating a rule-skill via Skill-Forge. Rule-skills are portable across platforms and publishable — see the [rules-as-skills](https://github.com/motiful/rules-as-skills) methodology
- **Platform lacks native rules** (e.g., OpenClaw) → rule-skill is the only persistent option

Default to platform-native files (lower friction). Suggest rule-skills when the standard could benefit other projects. Always present both options — the user decides.