From done-or-not
Audit whether a claimed feature is actually done without modifying product implementation.
How this skill is triggered — by the user, by Claude, or both
Slash command
/done-or-not:done-or-notThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Use this skill to audit whether claimed feature work in a repository is
Use this skill to audit whether claimed feature work in a repository is truly implemented, semantically aligned, and supported by real implementation evidence.
This skill is an auditor, not a developer.
Use this skill when the user wants to:
dev, main, or masterdocs/implementation-audit/Do not use this skill when the user wants to:
docs/implementation-audit/ in the audited repoThe skill must not classify fake implementation before establishing project semantics.
The skill must not write outside docs/implementation-audit/.
The skill must never modify product implementation.
Discovery and proposal phases must not use final verdict language such
as Implemented, Real, Mostly real, Fake, Non-operational, or
Drifted.
During discovery and proposal, use only provisional or
presence-oriented labels such as Proposed, Claimed, Documented,
Observed, Inferred, Unknown, Future, Conflict, Confirmed,
and Not audited.
Operating invariant:
Read anything.
Write only audit memory.
Never modify implementation.
Done or Not enforces its audit-only behavior when invoked through its namespaced plugin commands:
/done-or-not:discover-project-semantics/done-or-not:propose-audit-docs/done-or-not:save-audit-docs/done-or-not:audit-feature/done-or-not:audit-merge-readinessNatural-language requests outside these commands may invoke general Claude Code behavior.
Done or Not is not a global sandbox or policy engine. Use the namespaced commands for audit work.
Follow this sequence:
Git Context
↓
Document-First Semantics Discovery
↓
Codebase Surface Understanding
↓
Candidate Feature Map
↓
User Confirmation
↓
Feature Authenticity Audit
↓
Merge Readiness Audit
↓
Optional Audit Memory Save
Do not skip directly from a user-provided feature label to a fake verdict.
Start every audit by checking Git context:
Branch-aware strictness matters:
main / master: high strictnessdev / develop: integration strictnessfeature/*: feature-scoped strictnessfix/* / bugfix/*: bug-path strictnesshotfix/*: very high strictnessprototype/* / spike/*: placeholder-tolerant only if clearly labeledWhen PR and remote state have not been checked from local context, say so explicitly rather than inferring them.
Read documents before code whenever possible:
README and product docsdocs/CLAUDE.md / AGENTS.mdThis phase builds candidate semantics. It must not produce a fake verdict.
If a feature map is produced here, use split status columns:
| ID | Feature | Presence Status | Authenticity Status | Evidence | Audit Needed / Notes |
|---|---|---|---|---|---|
Rules:
Presence Status may be Proposed, Claimed, Documented,
Observed, Inferred, Unknown, Future, Conflict, or
Confirmed.Authenticity Status may be Not audited, Preliminary, Partial,
Mostly real, Real, Non-operational, Fake, or Drifted
(these values are defined here for reference; final authenticity
verdicts are not used during discovery).Authenticity Status defaults to Not audited.Claimed, Observed, or Inferred to
implementation verdict language before a scoped audit.Use cold start mode when the repo has implementation but lacks reliable semantic audit context.
In cold start mode:
Authenticity Status: Not auditedUse new repo mode when the repository is new or nearly empty.
In new repo mode:
Proposed unless explicitly confirmedA user phrase like "audit triggers" is only an intent hint, not confirmed scope.
Before a real authenticity verdict, establish:
If semantics are not confirmed, output a preliminary audit only.
If the user runs /done-or-not:audit-feature without a feature ID or feature name:
docs/implementation-audit/feature-map.md if availableWhen auditing a confirmed feature, trace:
UI
↓
handler/action
↓
API/service
↓
schema/state
↓
persistence
↓
business behavior
↓
failure path
↓
tests
↓
documentation claim alignment
Allowed verdicts include:
Do not use these verdicts during discovery or proposal.
Apply the fake-implementation rule strictly:
No semantics -> no fake verdict.
Draft semantics -> preliminary audit only.
Confirmed semantics -> real authenticity gate.
Assess merge readiness relative to the destination branch:
devdev -> main or mastermain / master baselineCheck:
If auditing main or master with a clean working tree and no active
source/target merge, enter Main Baseline Readiness Mode.
In Main Baseline Readiness Mode:
Baseline Readiness Verdict or Main Baseline VerdictNo active merge is pending.audits/ record rather than a merges/ record if a saved record is desiredIn feature-branch or other active merge mode:
No active merge is pending.Do not merge, commit, or modify code.
Write is restricted to:
docs/implementation-audit/
If a user requests an out-of-bound write such as README.md,
docs/<anything outside implementation-audit>, or tests/...,
explicitly refuse each requested path verbatim first, then offer
allowed replacements only under docs/implementation-audit/.
This includes optional long-lived files and append-only records such as:
docs/implementation-audit/README.mddocs/implementation-audit/feature-map.mddocs/implementation-audit/implementation-semantics.mddocs/implementation-audit/placeholder-policy.mddocs/implementation-audit/git-context.mddocs/implementation-audit/audits/YYYY-MM-DDTHHMM-<topic>.mddocs/implementation-audit/decisions/YYYY-MM-DDTHHMM-<topic>.mddocs/implementation-audit/merges/YYYY-MM-DDTHHMM-<topic>.mdNever write outside that folder in the audited repository.
Discovery handoff rule:
/done-or-not:discover-project-semantics is read-only and must end
with an audit-memory status section.docs/implementation-audit/audits/YYYY-MM-DDTHHMM-project-semantics-discovery.md.Preferred outputs:
Use explicit section headings, evidence tables, conservative notes, and clear confirmation markers.
preliminary, inferred, or needs confirmation over
overconfident judgment.npx claudepluginhub fofxjc/done-or-not --plugin done-or-notCreates, edits, and optimizes skills for Claude Code, including drafting, evaluating with test prompts, iterating on performance, and improving skill descriptions for better triggering accuracy.