Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/CleanExpo/Unite-Group --skill finished-auditコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか?SkillsMP が現在取得できるファイルをダウンロードできます。
SOC 職業分類に基づく
SKILL.md を表示中
| id | finished-audit |
| name | finished-audit |
| type | Capability Uplift |
| version | 1.0.0 |
| created | 20/03/2026 |
| modified | 20/03/2026 |
| status | active |
| triggers | ["are we done","is this finished","audit completion","verify done","check if complete","is it ready","can we ship","can we close this"] |
| description | > |
Purpose: Systematically verify that "finished" is actually true. No vague summaries. No optimistic assumptions. Evidence only.
Use this skill when:
The following phrases indicate a false completion claim. Never output them:
| Banned Phrase | Reason |
|---|---|
| "Done!" | No evidence |
| "That's complete." | No evidence |
| "Everything is working." | No evidence |
| "You're production ready." | No evidence |
| "Finished." | No evidence |
| "It's ready." | Subjective |
| "Should be working." | Unverified |
| "Looks good." | Subjective |
| "Tests are passing." | No output shown |
definition-of-done-builder or provided)If no DoD exists: activate definition-of-done-builder first.
If DoD exists: use it as the audit checklist.
For each criterion in the DoD:
| Status | Meaning | Accepted as proof? |
|---|---|---|
| PROVEN | Evidence exists, verified | Yes |
| CLAIMED | Evidence claimed but not shown | No |
| UNKNOWN |
| Not verified either way |
| No |
| MISSING | Confirmed absent or broken | No |
Completion % = (PROVEN count / total criteria count) × 100
If ALL criteria = PROVEN:
→ Output: COMPLETION APPROVED
If ANY criterion = UNKNOWN, CLAIMED, or MISSING:
→ Output: NOT COMPLETE
→ List every blocking criterion
→ Specify exact next action per blocker
FINISHED AUDIT
═══════════════════════════════════════════════════
Task: [task description]
Audit Date: [DD/MM/YYYY]
Completion: [N]% ([proven]/[total] criteria PROVEN)
STATUS: NOT COMPLETE
BLOCKING CRITERIA
─────────────────
[criterion] — Status: UNKNOWN
Required: [exact action to verify]
[criterion] — Status: MISSING
Required: [exact remediation]
[criterion] — Status: CLAIMED (evidence not shown)
Required: [show exact output/screenshot]
NEXT ACTION
─────────────
[Single most important thing to do right now]
═══════════════════════════════════════════════════
FINISHED AUDIT
═══════════════════════════════════════════════════
Task: [task description]
Audit Date: [DD/MM/YYYY]
Completion: 100% ([N]/[N] criteria PROVEN)
STATUS: COMPLETION APPROVED
PROOF ARTIFACTS
─────────────────
[criterion] — Proof: [artifact description + path/output]
[criterion] — Proof: [artifact]
...
APPROVED FOR: [merge/deploy/close/ship — as appropriate]
═══════════════════════════════════════════════════
Before accepting a PROVEN status:
| Failure | Recovery |
|---|---|
| No DoD exists | Activate definition-of-done-builder first |
| Proof is a screenshot of wrong state | Request updated screenshot |
| Proof is from a different environment | Request production environment proof |
| Developer argues criterion is "not needed" | Escalate to PM Agent — DoD is non-negotiable |
Input: "I've shipped the auth feature, it's done."
Audit output: NOT COMPLETE — 6/9 criteria PROVEN. 3 criteria UNKNOWN (no production URL proof, no rate limiting proof, JWT secret check missing).
Input: "The feature is complete." Output: "Great! Looks like it's done." — REJECTED (no audit performed)
The authoritative environment-variable registry for the Unite-Group Nexus. Use whenever adding, reading, renaming, or debugging an env var or secret — new integration config, a `process.env.X` read, an auth/OAuth wiring, a cron secret, a "which variable holds this" question, or a "works locally but not in prod" symptom. Also use before pinning any variable name in code, and when reconciling the two credential planes (Vercel prod vs the local hermes fleet). Prevents the `APIFY_API_KEY` vs `APIFY_API_TOKEN` class of drift.
Create, verify, and promote Supabase schema changes via database branches. Every schema change/migration must be validated on a Supabase database branch before prod (see CLAUDE.md line 44).
Verify production Supabase schema before shipping code that touches it. Use BEFORE writing or reviewing ANY code that reads or writes a Supabase table in the Nexus — new queries, inserts, updates, CHECK-constrained values, RLS-dependent reads, cron data access — even one-line changes and even when the table "obviously" exists. Also use immediately when a query fails with "column does not exist", when inserts appear to succeed but produce no rows, or when generated TypeScript types disagree with runtime behaviour.