ワンクリックでManusで任意のスキルを実行

work-audit

スター1

フォーク0

更新日2026年6月25日 15:59

Review project deliverables for defects, quality issues, and gaps before they are accepted, published, or handed off. Use this skill when reviewing any project output — code, documents, designs, data, reports, plans — to find problems before they cause rework downstream. Trigger phrases: "review this before we ship it", "audit this deliverable", "find issues in this", "QA this output", "something feels off about this", "check this before sending", "review the quality of this work", "is this good enough to ship?", "find defects in this code/document/design". This skill finds WHAT IS WRONG with what was produced. DISAMBIGUATION — "review this" is ambiguous; choose by what you're checking for: defects and quality issues in the deliverable → work-audit (this skill); whether the work matches the agreed scope and requirement → project-qa; whether the code is correctly tested and verified → testing-strategy; whether the plan has hidden risks or blind spots → tenth-man. When the request is a general "review before sh

インストール

Codex または Claude でインストールこの Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。

Manusで実行

ソース

Thxn6nan

Thxn6nan/nemo-skills-collection

GitHub リポジトリを開く Creator のリポジトリを見る

ダウンロード

Manusで実行

Work Audit Skill

Reviews deliverables for defects before they are accepted or move downstream. A defect found before handoff costs a fraction of one found after.

Core Principle

The purpose of audit is not to assign blame — it is to find problems while they are still cheap to fix. A defect in a draft costs minutes. The same defect after delivery costs hours or days.

Defect Taxonomy

All defects are classified into five types:

Code	Type	Description
L	Logic Error	The output is wrong — incorrect reasoning, bad calculation, wrong result
O	Omission	Something required is missing
R	Regression	The work broke something that was working before
S	Standard Violation	Output doesn't match agreed conventions or requirements
I	Integrity Issue	Output is correct now but fragile — likely to break or mislead later

Audit Workflow

Step 1 — Establish Acceptance Criteria

Before finding defects, be clear about what "correct" looks like. If acceptance criteria don't exist → define them before auditing.

ACCEPTANCE CRITERIA FORMAT:
  AC-1: <what the deliverable must do or contain>
        Pass: <what passing looks like>
        Fail: <what failing looks like>
  AC-2: ...

Step 2 — Select the Appropriate Checklist

Run the checklist matching the deliverable type: See references/audit-checklists.md

Code → correctness, error handling, security, maintainability, tests
Document / Report → completeness, accuracy, consistency, clarity
Plan → feasibility, completeness, dependencies, assumptions stated
Data / Config → schema validity, required fields, value ranges
Design → requirement coverage, edge cases, consistency

Step 3 — Classify and Record Each Defect

DEFECT-N [Type Code] Short Title
  What is wrong:   <specific description>
  Where:           <file, section, line, field, or step>
  Expected:        <what it should be>
  Actual:          <what it is>
  Severity:        [Critical | High | Medium | Low]
  Fix:             <concrete corrective action>

Severity guide:

Critical — Causes failure, data loss, security issue, or blocks use entirely
High — Causes incorrect behavior users will encounter; must fix before shipping
Medium — Incorrect in edge cases or degrades quality; fix in next revision
Low — Cosmetic, inconsistent with standards, minor polish

Step 4 — Deliver the Audit Report

AUDIT RESULT: [PASS | PASS WITH NOTES | FAIL]

Quality Score: 100 − (Critical×25 + High×10 + Medium×3 + Low×1)

Defects:
  Critical: <N>  → must fix before shipping
  High:     <N>  → must fix before shipping
  Medium:   <N>  → fix in next revision
  Low:      <N>  → optional polish

Required fixes: <list Critical + High defects>

Result rules:

Any Critical → FAIL
Any High → FAIL
Medium only → PASS WITH NOTES
Low only → PASS
No defects → PASS (document as clean)

Severity → Action

Finding	Required Action
Critical	Stop. Fix before any further use or distribution
High	Fix before this deliverable is accepted or shipped
Medium	Log and fix in next revision; does not block acceptance
Low	Fix if time allows; no block

Reference Files

references/audit-checklists.md — Checklists by deliverable type
references/audit-report-format.md — Full report template with examples

このリポジトリの他の Skills

同じリポジトリ

debugging-rootcause

Thxn6nan/nemo-skills-collection

Find why something isn't working — the real cause, not just the symptom. Use this skill when a bug, failure, or unexpected behavior needs to be diagnosed before it can be fixed. Covers hypothesis-driven debugging, evidence gathering, root cause isolation, and verification. Trigger phrases: "why isn't this working?", "find the root cause", "something is broken but I don't know why", "debug this", "the error doesn't make sense", "it works locally but not in production", "intermittent failure", "trace this bug", "what's causing this?". This skill finds WHY — work-audit finds WHAT IS WRONG, project-monitor detects THAT something is wrong. DISAMBIGUATION — use a different skill instead when: the problem is in production NOW with users affected, needing coordinated crisis response (use incident-response; it calls this skill for its diagnosis step); the problem is specifically slowness or capacity under load (use performance-scaling); reviewing not-yet-broken work for latent defects (use work-audit). Choose debuggin

2026-06-251

performance-scaling

Thxn6nan/nemo-skills-collection

Diagnose performance problems, optimize bottlenecks, and plan for scale. Covers profiling, load testing, capacity planning, and scaling decisions (vertical vs horizontal, caching, CDN, database read replicas, etc.). Use this skill when something is too slow, when preparing for growth, when load testing before a launch, or when deciding how to scale a system. Trigger phrases: "this is too slow", "optimize performance", "load test this", "prepare for 10x traffic", "capacity planning", "the system is struggling under load", "should we scale horizontally or vertically?", "where is the bottleneck?", "performance profiling", "latency is too high". DISAMBIGUATION — use a different skill instead when: the slowness is a sudden production incident affecting users now (use incident-response); the cause is a specific bug rather than capacity or load (use debugging-rootcause); the slowness is specifically database queries or schema (use database-maintenance). Choose performance-scaling for profiling, optimization, load te

2026-06-251

retrospective

Thxn6nan/nemo-skills-collection

Extract actionable learning from completed work — what went well, what didn't, and what will actually change as a result. Use after a project, sprint, release, or significant event. Produces concrete action items, not just discussion. Trigger phrases: "retrospective", "retro", "what did we learn from this project?", "what went wrong?", "how do we improve?", "post-project review", "what should we do differently next time?", "team reflection", "lessons learned". A retrospective without action items is a venting session. This skill produces change. DISAMBIGUATION — "what went wrong" is ambiguous: learning from a COMPLETED project or sprint to improve future work → retrospective (this skill); finding the technical cause of a SPECIFIC failure or bug → debugging-rootcause; deciding the future DIRECTION of an ongoing project → project-compass. Choose retrospective when the work is done and the goal is team learning.

2026-06-251

testing-strategy

Thxn6nan/nemo-skills-collection

Plan and implement a complete testing approach — unit tests, coverage analysis, verification, and validation. Use this skill when writing tests for new code, when coverage is insufficient, when tests don't catch real bugs, when validating that work meets requirements, or when setting up a testing strategy for a project. Trigger phrases: "write unit tests", "test this code", "improve test coverage", "coverage analysis", "verify this works", "validate this meets requirements", "testing strategy", "how do we test this?", "tests aren't catching bugs", "what should we test?", "is this correct?", "does this do what was asked?". Covers V&V — Verification ("built it right") and Validation ("built the right thing"). DISAMBIGUATION — choose by test level: unit tests, coverage analysis, and verification/validation of individual components → testing-strategy (this skill); full system flows from user input to output, integration test strategy → e2e-testing; finding defects in an already-produced deliverable → work-audit.

2026-06-251

anti-hallucination

Thxn6nan/nemo-skills-collection

Detect, prevent, and verify hallucinations in agent outputs — especially numerical calculations, factual claims, data references, citations, and reasoning chains. Use this skill whenever an agent produces numbers, statistics, dates, names, quotes, or data-derived conclusions that could be fabricated or wrong. Trigger when the user says "verify this output", "the agent made up numbers", "check these calculations", "fact-check the agent", "the agent cited something wrong", "I don't trust this output", or when reviewing any agent output that will be used for decisions, reports, or communications. Also trigger proactively when designing agents that handle financial data, medical information, legal content, or any high-stakes numerical work. Anti-hallucination has three modes: PREVENT (before), DETECT (during), VERIFY (after).

2026-06-251

goal-evaluator

Thxn6nan/nemo-skills-collection

Evaluate whether a goal, feature, project, or investment is worth pursuing — before committing resources to it. Covers ROI, opportunity cost, timing, reversibility, strategic fit, bias correction, and exit criteria. Use this skill when deciding whether to start something new, when a goal feels compelling but unclear, when you need to justify a commitment, or when you suspect the real cost or value hasn't been honestly assessed. Trigger phrases: "is this worth doing", "should we pursue this", "evaluate this goal", "is the ROI good enough", "is the scope too small to bother", "help us decide if this is worth it", "we're thinking of doing X — is it a good idea", "is this the right thing to focus on", "assess this opportunity", "should we invest in this". Outputs one of five verdicts: PURSUE / REFINE / DEFER / DESCOPE / DROP. Use before project-compass (direction) and working-standards (execution).

2026-06-251

name

work-audit

description

Work Audit Skill

Reviews deliverables for defects before they are accepted or move downstream. A defect found before handoff costs a fraction of one found after.

Core Principle

The purpose of audit is not to assign blame — it is to find problems while they are still cheap to fix. A defect in a draft costs minutes. The same defect after delivery costs hours or days.

Defect Taxonomy

All defects are classified into five types:

Code	Type	Description
L	Logic Error	The output is wrong — incorrect reasoning, bad calculation, wrong result
O	Omission	Something required is missing
R	Regression	The work broke something that was working before
S	Standard Violation	Output doesn't match agreed conventions or requirements
I	Integrity Issue	Output is correct now but fragile — likely to break or mislead later

Audit Workflow

Step 1 — Establish Acceptance Criteria

Before finding defects, be clear about what "correct" looks like. If acceptance criteria don't exist → define them before auditing.

ACCEPTANCE CRITERIA FORMAT:
  AC-1: <what the deliverable must do or contain>
        Pass: <what passing looks like>
        Fail: <what failing looks like>
  AC-2: ...

Step 2 — Select the Appropriate Checklist

Run the checklist matching the deliverable type: See references/audit-checklists.md

Code → correctness, error handling, security, maintainability, tests
Document / Report → completeness, accuracy, consistency, clarity
Plan → feasibility, completeness, dependencies, assumptions stated
Data / Config → schema validity, required fields, value ranges
Design → requirement coverage, edge cases, consistency

Step 3 — Classify and Record Each Defect

DEFECT-N [Type Code] Short Title
  What is wrong:   <specific description>
  Where:           <file, section, line, field, or step>
  Expected:        <what it should be>
  Actual:          <what it is>
  Severity:        [Critical | High | Medium | Low]
  Fix:             <concrete corrective action>

Severity guide:

Critical — Causes failure, data loss, security issue, or blocks use entirely
High — Causes incorrect behavior users will encounter; must fix before shipping
Medium — Incorrect in edge cases or degrades quality; fix in next revision
Low — Cosmetic, inconsistent with standards, minor polish

Step 4 — Deliver the Audit Report

AUDIT RESULT: [PASS | PASS WITH NOTES | FAIL]

Quality Score: 100 − (Critical×25 + High×10 + Medium×3 + Low×1)

Defects:
  Critical: <N>  → must fix before shipping
  High:     <N>  → must fix before shipping
  Medium:   <N>  → fix in next revision
  Low:      <N>  → optional polish

Required fixes: <list Critical + High defects>

Result rules:

Any Critical → FAIL
Any High → FAIL
Medium only → PASS WITH NOTES
Low only → PASS
No defects → PASS (document as clean)

Severity → Action

Finding	Required Action
Critical	Stop. Fix before any further use or distribution
High	Fix before this deliverable is accepted or shipped
Medium	Log and fix in next revision; does not block acceptance
Low	Fix if time allows; no block

Reference Files

references/audit-checklists.md — Checklists by deliverable type
references/audit-report-format.md — Full report template with examples