本文へ移動
cccskills
無料GitHub で公開

ln-623-code-principles-auditor

Checks DRY (10 types), KISS/YAGNI, error handling, DI patterns. Returns findings with severity, location, effort, pattern_signature.

インストール方法を見る

含まれるファイル(3)

  • SKILL.md14.7 KB
  • references/detection_patterns.md11.9 KB
  • references/refactoring_decision_tree.md3.8 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

Paths: File paths (shared/, references/, ../ln-*) are relative to skills repo root. If not found at CWD, locate this SKILL.md directory and go up one level for repo root.

Code Principles Auditor (L3 Worker)

Specialized worker auditing code principles (DRY, KISS, YAGNI) and design patterns.

Purpose & Scope

  • Worker in ln-620 coordinator pipeline - invoked by ln-620-codebase-auditor
  • Audit code principles (DRY/KISS/YAGNI, error handling, DI)
  • Return structured findings with severity, location, effort, pattern_signature, recommendations
  • Calculate compliance score (X/10) for Code Principles category

Inputs (from Coordinator)

MANDATORY READ: Load shared/references/audit_worker_core_contract.md.

Receives contextStore with: tech_stack, best_practices, principles, codebase_root, output_dir.

Domain-aware: Supports domain_mode + current_domain (see audit_output_schema.md#domain-aware-worker-output).

Workflow

MANDATORY READ: Load shared/references/two_layer_detection.md for detection methodology.

  1. Parse context — extract fields, determine scan_path (domain-aware if specified), extract output_dir
  2. Load detection patterns
    • MANDATORY READ: Load references/detection_patterns.md for language-specific Grep/Glob patterns
    • Select patterns matching project's tech_stack
  3. Scan codebase for violations (Layer 1)
    • All Grep/Glob patterns use scan_path (not codebase_root)
    • Follow step-by-step detection from detection_patterns.md
    • Apply exclusions from detection_patterns.md#exclusions
  4. Analyze context per candidate (Layer 2)
    • DRY: read both code blocks to confirm true duplication (not just similar naming or shared interface)
    • KISS: check if abstraction serves DI pattern (valid single-impl interface) or is premature
    • YAGNI: check if feature flag was recently added (intentional) or dormant for months
  5. Generate recommendations
    • MANDATORY READ: Load references/refactoring_decision_tree.md for pattern selection
    • Match each finding to appropriate refactoring pattern via decision tree
  6. Collect findings with severity, location, effort, pattern_id, pattern_signature, recommendation
    • Tag each finding with domain: domain_name (if domain-aware)
    • Assign pattern_signature for cross-domain matching by ln-620
  7. Calculate score using penalty algorithm
  8. Write Report: Build full markdown report in memory per shared/templates/audit_worker_report_template.md, write to {output_dir}/623-principles-{domain}.md (or 623-principles.md in global mode) in single Write call. Include <!-- FINDINGS-EXTENDED --> JSON block with pattern_signature fields for cross-domain DRY analysis
  9. Return Summary: Return minimal summary to coordinator (see Output Format)

Two-Layer Detection (MANDATORY)

MANDATORY READ: shared/references/two_layer_detection.md

All findings require Layer 2 context analysis. Layer 1 finding without Layer 2 = NOT a valid finding. Before reporting, ask: "Is this violation intentional or justified by design?"

Finding TypeLayer 2 Downgrade Examples
DRYModules with different lifecycle/ownership → skip. Intentional duplication for decoupling → skip
KISSFramework-required abstraction (e.g., DI in Spring) → downgrade. Single implementation today but interface for testing → skip
YAGNIFeature flag used in A/B testing → skip. Config option used by ops team → skip
Error HandlingCentralized handler absent in 50-line script → downgrade to LOW
DIDependencies replaceable via params/closures → skip ARCH-DI

Audit Rules

1. DRY Violations (Don't Repeat Yourself)

MANDATORY READ: Load references/detection_patterns.md for detection steps per type.

TypeWhatSeverityException (skip/downgrade)Default RecommendationEffort
1.1 Identical CodeSame functions/constants/blocks (>10 lines) in multiple filesHIGH: business-critical (auth, payment). MEDIUM: utilities. LOW: simple constants <5xDifferent lifecycle/ownership modules → skip. Intentional decoupling → skipExtract function → decide location by duplication scopeM
1.2 Duplicated ValidationSame validation patterns (email, password, phone, URL) across filesHIGH: auth/payment. MEDIUM: user input 3+x. LOW: format checks <3xDifferent security contexts (auth vs public) → skipExtract to shared validators moduleM
1.3 Repeated Error MessagesHardcoded error strings instead of centralized catalogMEDIUM: critical messages hardcoded or no error catalog. LOW: <3 placesUser-facing strings requiring per-context wording → downgradeCreate constants/error-messages fileM
1.4 Similar PatternsFunctions with same call sequence/control flow but different names/entitiesMEDIUM: business logic in critical paths. LOW: utilities <3xModules with divergent evolution expected → skipExtract common logic (see decision tree for pattern)M
1.5 Duplicated SQL/ORMSame queries in different servicesHIGH: payment/auth queries. MEDIUM: common 3+x. LOW: simple <3xDifferent bounded contexts; shared DB is worse than duplication → skipExtract to Repository layerM
1.6 Copy-Pasted TestsIdentical setup/teardown/fixtures across test filesMEDIUM: setup in 5+ files. LOW: <5 filesTests intentionally isolated for clarity/independence → downgradeExtract to test helpersM
1.7 Repeated API ResponsesSame response object shapes without DTOsMEDIUM: in 5+ endpoints. LOW: <5 endpointsResponses with different versioning lifecycle → skipCreate DTO/Response classesM
1.8 Duplicated Middleware ChainsIdentical middleware/decorator stacks on multiple routesMEDIUM: same chain on 5+ routes. LOW: <5 routesRoutes with different auth/rate-limit requirements → skipCreate named middleware group, apply at router levelM
1.9 Duplicated Type DefinitionsInterfaces/structs/types with 80%+ same fieldsMEDIUM: in 5+ files. LOW: 2-4 filesTypes with different ownership/evolution paths → skipCreate shared base type, extend where neededM
1.10 Duplicated Mapping LogicSame entity→DTO / DTO→entity transformations in multiple locationsMEDIUM: in 3+ locations. LOW: 2 locationsMappings with different validation/enrichment rules → skipCreate dedicated Mapper class/functionM

Recommendation selection: Use references/refactoring_decision_tree.md to choose the right refactoring pattern based on duplication location (Level 1) and logic type (Level 2).

2. KISS Violations (Keep It Simple, Stupid)

ViolationDetectionSeverityException (skip/downgrade)RecommendationEffort
Abstract class with 1 implementationGrep abstract class → count subclassesHIGH: prevents understanding core logicInterface for DI/testing → skip. Framework-required (Spring, ASP.NET) → skipRemove abstraction, inlineL
Factory for <3 typesGrep factory patterns → count branchesMEDIUM: unnecessary patternFactory used for DI/testing swap → downgradeReplace with direct constructionM
Deep inheritance >3 levelsTrace extends chainHIGH: fragile hierarchyFramework-mandated hierarchy (UI widgets, ORM models) → downgradeFlatten with compositionL
Excessive generic constraintsGrep <T extends ... & ...>LOW: acceptable tradeoffType safety for public API boundary → skipSimplify constraintsM
Wrapper-only classesRead: all methods delegate to innerMEDIUM: unnecessary indirectionAdapter pattern for external API isolation → skipRemove wrapper, use inner directlyM

3. YAGNI Violations (You Aren't Gonna Need It)

ViolationDetectionSeverityException (skip/downgrade)RecommendationEffort
Dead feature flags (always true/false)Grep flags → verify never toggledLOW: cleanup neededA/B testing flags → skip. Ops-controlled toggles → skipRemove flag, keep active code pathM
Abstract methods never overriddenGrep abstract → search implementationsMEDIUM: unused extensibilityPlugin/extension point in public library → downgradeRemove abstract, make concreteM
Unused config optionsGrep config key → 0 referencesLOW: dead configEnv-specific configs (staging/prod) → verify before flaggingRemove optionS
Interface with 1 implementationGrep interface → count implementorsMEDIUM: premature abstractionInterface for DI/testing mock → skipRemove interface, use class directlyM
Premature generics (used with 1 type)Grep generic usage → count type paramsLOW: over-engineeringPublic library API designed for consumers → skipReplace generic with concrete typeS

4. Missing Error Handling

  • Find async functions without try-catch
  • Check API routes without error middleware
  • Verify database calls have error handling
SeverityCriteria
CRITICALPayment/auth without error handling
HIGHUser-facing operations without error handling
MEDIUMInternal operations without error handling

Effort: M

5. Centralized Error Handling

  • Search for centralized error handler: ErrorHandler, errorHandler, error-handler.*
  • Check if middleware delegates to handler
  • Verify async routes use promises/async-await
  • Anti-pattern: process.on("uncaughtException") usage
SeverityCriteria
HIGHNo centralized error handler
HIGHUsing uncaughtException listener (Express anti-pattern)
MEDIUMMiddleware handles errors directly (no delegation)
MEDIUMAsync routes without proper error handling
LOWStack traces exposed in production

Outcome Goal: All errors are logged with context and return clear user-facing messages. No error is silently swallowed. Stack traces never leak to production responses. Implementation choice (ErrorHandler class, middleware, decorator) depends on project stack and size.

Effort: M-L

6. Dependency Injection / Centralized Init

  • Check for DI container: inversify, awilix, tsyringe (Node), dependency_injector (Python), Spring @Autowired (Java), ASP.NET IServiceCollection (C#)
  • Grep for new SomeService() in business logic (direct instantiation)
  • Check for bootstrap module: bootstrap.ts, init.py, Startup.cs, app.module.ts
SeverityCriteria
MEDIUMNo DI container (tight coupling)
MEDIUMDirect instantiation in business logic
LOWMixed DI and direct imports

Outcome Goal: Dependencies are replaceable for testing without modifying production code. No tight coupling between service instantiation and business logic. Implementation choice (DI container, factory functions, parameter injection, closures) depends on project size and stack.

Effort: L

7. Missing Best Practices Guide

  • Check for: docs/architecture.md, docs/best-practices.md, ARCHITECTURE.md, CONTRIBUTING.md
SeverityCriteria
LOWNo architecture/best practices guide

Recommendation: Create docs/architecture.md with layering rules, error handling patterns, DI usage, coding conventions.

Effort: S

Scoring Algorithm

MANDATORY READ: Load shared/references/audit_worker_core_contract.md and shared/references/audit_scoring.md.

Output Format

MANDATORY READ: Load shared/references/audit_worker_core_contract.md and shared/templates/audit_worker_report_template.md.

Write report to {output_dir}/623-principles-{domain}.md (or 623-principles.md in global mode) with category: "Architecture & Design".

FINDINGS-EXTENDED block (required for this worker): After the Findings table, include a <!-- FINDINGS-EXTENDED --> JSON block containing all DRY findings with pattern_signature for cross-domain matching by ln-620 coordinator. Follow shared/templates/audit_worker_report_template.md.

pattern_id: DRY type identifier (dry_1.1 through dry_1.10). Omit for non-DRY findings.

pattern_signature: Normalized key for the detected pattern (e.g., validation_email, sql_users_findByEmail, middleware_auth_validate_ratelimit). Same signature in multiple domains triggers cross-domain DRY finding. Format is defined in references/detection_patterns.md.

Return summary to coordinator:

Report written: docs/project/.audit/ln-620/{YYYY-MM-DD}/623-principles-users.md
Score: X.X/10 | Issues: N (C:N H:N M:N L:N)

Critical Rules

MANDATORY READ: Load shared/references/audit_worker_core_contract.md.

  • Do not auto-fix: Report only
  • Domain-aware scanning: If domain_mode="domain-aware", scan ONLY scan_path
  • Tag findings: Include domain field in each finding when domain-aware
  • Pattern signatures: Include pattern_id + pattern_signature for every DRY finding
  • Context-aware: Use project's principles.md to define what's acceptable
  • Effort realism: S = <1h, M = 1-4h, L = >4h
  • Exclusions: Skip generated code, vendor, migrations (see detection_patterns.md#exclusions)

Definition of Done

MANDATORY READ: Load shared/references/audit_worker_core_contract.md.

  • contextStore parsed (including domain_mode, current_domain, output_dir)
  • scan_path determined (domain path or codebase root)
  • Detection patterns loaded from references/detection_patterns.md
  • All 7 checks completed (scoped to scan_path):
    • DRY (10 subcategories: 1.1-1.10), KISS, YAGNI, Error Handling, Centralized Errors, DI/Init, Best Practices Guide
  • Recommendations selected via references/refactoring_decision_tree.md
  • Findings collected with severity, location, effort, pattern_id, pattern_signature, recommendation, domain
  • Score calculated per shared/references/audit_scoring.md
  • Report written to {output_dir}/623-principles-{domain}.md with FINDINGS-EXTENDED block (atomic single Write call)
  • Summary returned to coordinator

Reference Files


Version: 5.0.0 Last Updated: 2026-02-08

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

同じリポジトリのスキル

概要と使いどころ

Design, implement, and audit inclusive digital products using WCAG 2.2 Level AA standards. Use this skill to generate semantic ARIA for Web and accessibility traits for Web and Native platforms (iOS/Android).

日本語の概要は準備中です。原文の説明を表示しています。

tensology/decisionsai172026年10月10日 更新

Whole site or product — a full web accessibility (a11y) audit against WCAG 2.2, following the WCAG-EM methodology. Defines scope, samples representative pages and flows, runs the automated tier (`accessibility-scan`) and the hands-on manual tier (`accessibility-inspect`), and produces one conformance report. Grades each finding by severity and evidence basis, and states per-criterion conformance as pass, fail, or undetermined (needs a human). Use it for 'audit my site for accessibility', 'is this product accessible', 'a11y audit', 'WCAG or Section 508 conformance report', or any multi-page assessment. Assesses; does not fix (use `accessibility-fix`) or diff (use `accessibility-diff`). For a single page use `accessibility-scan`; for hands-on keyboard and screen-reader checks use `accessibility-inspect`.

日本語の概要は準備中です。原文の説明を表示しています。

tensology/decisionsai172026年10月10日 更新

Regression check — diff a live page's web accessibility (a11y) violations against a baseline. By default it compares your uncommitted changes (stash-based); pass `--branch [<name>]` to compare against a branch. Reports the new WCAG violations introduced, the ones fixed, and the count of pre-existing ones. Use it for 'did my change break accessibility', 'what a11y issues did this PR add', or as a CI gate. For a full scan of one page use `accessibility-scan`; for a whole site use `accessibility-audit`.

日本語の概要は準備中です。原文の説明を表示しています。

tensology/decisionsai172026年10月10日 更新

Remediation only — repair web accessibility (a11y) violations against WCAG 2.2 with a baseline, edit, and verify loop. Takes a target (URL, files, directory) or a findings worklist from `accessibility-scan`/`accessibility-inspect`/`accessibility-audit`, applies mechanical fixes as given, leaves TODOs for visual or contextual judgment, and verifies by re-running the baseline check. It only fixes. To find issues use `accessibility-scan` (one page, automated), `accessibility-inspect` (one page, manual), or `accessibility-audit` (whole site, WCAG-EM); to check for regressions use `accessibility-diff`. Use it for 'fix the a11y issues in X', 'make this accessible', 'add missing alt text and labels', 'apply these accessibility fixes', 'remediate these violations'.

日本語の概要は準備中です。原文の説明を表示しています。

tensology/decisionsai172026年10月10日 更新

One page, hands-on manual tier — drive a live page through the web accessibility (a11y) checks a rule engine can't decide: keyboard operation and focus order, screen-reader names, roles and states from the accessibility tree, reflow and zoom, reduced motion, form errors, and target size. Grades each finding by evidence basis (verified / confirm-with-a-human / human-required) and severity, and closes every criterion in a ledger: verified, flagged, not exercised, or N/A. Locates and assesses; does not fix (use `accessibility-fix`). Use it for keyboard testing, focus-order checks, screen-reader or a11y-tree review, reflow and zoom at 200%, or 'is this operable, not just lint-clean'. The automated tier is `accessibility-scan`; `accessibility-audit` runs both across a sampled site.

日本語の概要は準備中です。原文の説明を表示しています。

tensology/decisionsai172026年10月10日 更新

One page, automated tier — run the web accessibility (a11y) rule engine against a live page and locate every violation it can detect mechanically. Pass a URL, a config target name (e.g. `accesslint:accessibility-scan dev`), or nothing to use the default target from `accesslint.config.json`. Ensures a debuggable Chrome, runs the @accesslint/core engine over CDP, and returns a worklist of live-DOM WCAG 2.2 violations, each grounded to its DOM selector and source `file:line`. Locates; doesn't edit. Use it for 'is this page accessible', 'check a11y on this URL', 'find contrast and alt-text issues', or to verify a UI change. For hands-on keyboard and screen-reader checks use `accessibility-inspect`; for a whole site or product use `accessibility-audit`; to diff against uncommitted changes or a branch use `accessibility-diff`.

日本語の概要は準備中です。原文の説明を表示しています。

tensology/decisionsai172026年10月10日 更新

tensology のスキルをすべて見る

このスキルの問題を報告する