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

ln-631-test-business-logic-auditor

Detects tests that validate framework/library behavior (Prisma, Express, bcrypt, JWT, axios, React hooks) instead of OUR code. Returns findings with REMOVE decisions.

インストール方法を見る

含まれるファイル(1)

  • SKILL.md6.6 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.

Business Logic Focus Auditor (L3 Worker)

Specialized worker auditing tests for Business Logic Focus (Category 1).

Purpose & Scope

  • Worker in ln-630 coordinator pipeline
  • Audit Business Logic Focus (Category 1: High Priority)
  • Detect tests validating framework/library behavior (NOT our code)
  • Calculate compliance score (X/10)

Inputs (from Coordinator)

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

Receives contextStore with: tech_stack, testFilesMetadata, codebase_root, output_dir.

Workflow

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

  1. Parse Context: Extract tech stack, framework detection patterns, test file list, output_dir from contextStore
  2. Scan Codebase (Layer 1): Scan test files for framework/library tests (see Audit Rules below) 2b) Context Analysis (Layer 2 — MANDATORY): For each candidate, read test code and ask:
    • Does this test custom code that wraps a framework primitive (e.g., custom hook using useState)? → KEEP (testing integration, not framework)
    • Does this test ONLY call framework API with no custom logic? → flag for removal
    • Is this a test helper/utility that imports libraries for mocking setup? → skip (not a test of framework behavior)
  3. Collect Findings: Record each violation with severity, location (file:line), effort estimate (S/M/L), recommendation
  4. Calculate Score: Count violations by severity, calculate compliance score (X/10)
  5. Write Report: Build full markdown report in memory per shared/templates/audit_worker_report_template.md, write to {output_dir}/631-business-logic.md in single Write call
  6. Return Summary: Return minimal summary to coordinator (see Output Format)

Audit Rules

1. Framework Tests Detection

What: Tests validating framework behavior (Express, Fastify, Koa) instead of OUR business logic

Detection Patterns:

  • (express|fastify|koa).(use|get|post|put|delete|patch)
  • Test names: "middleware is called", "route handler works", "Express app listens"

Severity: MEDIUM

Recommendation: Consider removing IF test only validates framework behavior. If testing integration of custom code with framework → KEEP

Effort: S (delete test file or test block)

2. ORM/Database Library Tests

What: Tests validating Prisma/Mongoose/Sequelize/TypeORM behavior

Detection Patterns:

  • (prisma|mongoose|sequelize|typeorm).(find|findMany|create|update|delete|upsert)
  • Test names: "Prisma findMany returns array", "Mongoose save works"

Severity: MEDIUM

Recommendation: Consider removing IF test only validates ORM behavior. If testing custom query logic or repository patterns → KEEP

Effort: S

3. Crypto/Hashing Library Tests

What: Tests validating bcrypt/argon2 hashing behavior

Detection Patterns:

  • (bcrypt|argon2).(hash|compare|verify|hashSync)
  • Test names: "bcrypt hashes password", "argon2 compares correctly"

Severity: MEDIUM

Recommendation: Consider removing IF test only validates library behavior. If testing custom password policy or hashing wrapper → KEEP

Effort: S

4. JWT/Token Library Tests

What: Tests validating JWT signing/verification

Detection Patterns:

  • (jwt|jsonwebtoken).(sign|verify|decode)
  • Test names: "JWT signs token", "JWT verifies signature"

Severity: MEDIUM

Recommendation: Consider removing IF test only validates JWT library. If testing custom token payload, claims logic, or auth flow → KEEP

Effort: S

5. HTTP Client Library Tests

What: Tests validating axios/fetch/got behavior

Detection Patterns:

  • (axios|fetch|got|request).(get|post|put|delete|patch)
  • Test names: "axios makes GET request", "fetch returns data"

Severity: MEDIUM

Recommendation: Consider removing IF test only validates HTTP client behavior. If testing custom API wrapper, retry logic, or error mapping → KEEP

Effort: S

6. React Hooks/Framework Tests

What: Tests validating React hooks behavior (useState, useEffect, etc.)

Detection Patterns:

  • (useState|useEffect|useContext|useReducer|useMemo|useCallback)
  • Test names: "useState updates state", "useEffect runs on mount"

Severity: LOW (acceptable if testing OUR custom hook logic)

Recommendation: REVIEW — if testing framework behavior → DELETE; if testing custom hook → KEEP

Effort: S-M

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}/631-business-logic.md with category: "Business Logic Focus" and checks: framework_tests, orm_tests, crypto_tests, jwt_tests, http_client_tests, react_hooks_tests.

Return summary to coordinator:

Report written: docs/project/.audit/ln-630/{YYYY-MM-DD}/631-business-logic.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
  • Framework-specific patterns: Match detection patterns to project's actual tech stack
  • Effort realism: S = <1h, M = 1-4h, L = >4h
  • Context-aware: Custom wrappers around libraries (e.g., custom hook using useState) are OUR code — do not flag
  • Exclude test helpers: Do not flag shared test utilities that import libraries for mocking setup

Definition of Done

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

  • contextStore parsed successfully (including output_dir)
  • All 6 checks completed (framework, ORM, crypto, JWT, HTTP client, React hooks)
  • Findings collected with severity, location, effort, recommendation
  • Score calculated using penalty algorithm
  • Report written to {output_dir}/631-business-logic.md (atomic single Write call)
  • Summary returned to coordinator

Reference Files

  • Audit output schema: shared/references/audit_output_schema.md

Version: 3.0.0 Last Updated: 2025-12-23

レビュー

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

同じリポジトリのスキル

概要と使いどころ

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月13日 更新

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月13日 更新

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月13日 更新

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月13日 更新

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月13日 更新

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月13日 更新

tensology のスキルをすべて見る

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