Proof Of Work
Turn agent work into binary, evidence-backed acceptance criteria and user-verifiable Definition of Done checklists.
Overview
proof-of-work is an agent skill most often used in Ship (also Build, Validate) that formats Definition of Done acceptance criteria with evidence and user verification steps.
Install
npx skills add https://github.com/athola/claude-night-market --skill proof-of-workWhat is this skill?
- Four core principles: SMART, binary pass/fail, user-verifiable steps, and evidence-backed criteria
- Markdown task template with Acceptance Criteria, Test Evidence, Status, and User Verification Steps
- Ready-made DoD scenarios including configuration setup and similar completion patterns
- Explicit COMPLETE, PARTIAL, and BLOCKED statuses with blocker notes
- Aligns with Agile Definition of Done acceptance-criteria practice
- Four core principles: SMART, binary outcomes, user-verifiable, evidence-backed
Adoption & trust: 1 installs on skills.sh; 304 GitHub stars; 2/3 security scanners passed (skills.sh audits); trending (+100% hot-view momentum).
What problem does it solve?
Agents say a task is finished, but you have no testable checklist or evidence map to confirm it actually works.
Who is it for?
Solo builders who want human-in-the-loop sign-off on agent-delivered config, features, or integrations.
Skip if: Teams whose requirements are already fully covered by automated CI with no manual verification gap.
When should I use this skill?
Closing an agent task and you need Definition of Done acceptance criteria with test evidence and user verification steps.
What do I get? / Deliverables
You produce a pass/fail acceptance-criteria block with linked evidence, status, and user verification steps before marking work complete.
- Markdown DoD block with acceptance criteria and evidence table
- COMPLETE, PARTIAL, or BLOCKED status with blockers
- Numbered user verification instructions
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Canonical shelf is Ship review because the skill’s output is pass/fail verification before you call a task complete or merge. Acceptance criteria and test evidence map directly to code review and launch readiness gates, not initial ideation.
Where it fits
Define binary exit criteria for a landing-page prototype before you commit to full Build.
Attach evidence-backed checklists to implementation tasks so the agent cannot close work without test proof.
Run user verification steps on an LSP or MCP config change before calling the integration complete.
Document PASS/FAIL evidence after a production config or monitoring fix.
How it compares
Structured DoD template for agent handoffs—not a substitute for automated test suites or product discovery brainstorming.
Common Questions / FAQ
Who is proof-of-work for?
Indie developers and agent users who need clear, testable completion criteria when Claude or similar tools claim a setup or feature is done.
When should I use proof-of-work?
In Ship (review) before merging or releasing; in Build (pm) when closing implementation tasks; in Validate (scope) to lock prototype exit criteria; in Operate (iterate) when verifying incident or config fixes with evidence.
Is proof-of-work safe to install?
It is documentation-only templates with no runtime hooks—still review the Security Audits panel on this Prism page before trusting any Night Market skill in automated workflows.
SKILL.md
READMESKILL.md - Proof Of Work
# Acceptance Criteria Definition of Done (DoD) templates for common completion scenarios. Based on [Agile acceptance criteria best practices](https://www.atlassian.com/agile/project-management/definition-of-done). ## Core Principles 1. **SMART Criteria:** Specific, Measurable, Achievable, Relevant, Testable 2. **Binary Outcomes:** Must be pass/fail, no "partially complete" 3. **User-Verifiable:** User can independently test each criterion 4. **Evidence-Backed:** Each criterion links to proof ## Template Format ```markdown ## Task: [Description] ### Acceptance Criteria - [ ] [Criterion 1 - specific, testable] - [ ] [Criterion 2 - specific, testable] - [ ] [Criterion 3 - specific, testable] ### Test Evidence - Criterion 1: [Evidence reference] → PASS / FAIL - Criterion 2: [Evidence reference] → PASS / FAIL - Criterion 3: [Evidence reference] → PASS / FAIL ### Status - COMPLETE: All criteria passed - PARTIAL: Some criteria passed (list blockers) - BLOCKED: Cannot complete (explain why) ### User Verification Steps 1. [Step-by-step instructions for user to verify] 2. [Expected outcome at each step] ``` --- ## Common Scenarios ### 1. Configuration Setup ```markdown ## Task: Configure LSP for Claude Code ### Acceptance Criteria - [ ] Language servers installed and in $PATH - [ ] MCP configuration file contains cclsp entry - [ ] ENABLE_LSP_TOOL environment variable set to 1 - [ ] cclsp starts without errors when Claude Code launches - [ ] LSP tools (find_definition, find_references) are callable from Claude ### Test Evidence - Language servers: [E1] `which pylsp` returns valid path → PASS - MCP config: [E2] `.mcp.json` contains cclsp entry → PASS - Env var: [E3] `echo $ENABLE_LSP_TOOL` returns "1" → PASS - cclsp starts: [E4] `ps aux | grep cclsp` shows running process → FAIL - LSP tools available: [E5] Cannot test (blocked by E4) → BLOCKED ### Status BLOCKED - cclsp does not start in Claude Code 2.0.76 due to bug #14803 ### Known Issues - Issue #14803: LSP plugin loading broken in versions 2.0.69-2.0.76 - Source: https://github.com/anthropics/claude-code/issues/14803 ### User Verification Steps Cannot provide verification steps - task is blocked by upstream bug. **Workaround Options:** 1. Downgrade to Claude Code 2.0.67 2. Wait for fix in future release ``` --- ### 2. Feature Implementation ```markdown ## Task: Implement user authentication ### Acceptance Criteria - [ ] User can register with email/password - [ ] User can log in with valid credentials - [ ] User cannot log in with invalid credentials - [ ] Session persists across page refreshes - [ ] User can log out and session is cleared - [ ] Passwords are hashed (not stored in plaintext) - [ ] All auth endpoints have rate limiting - [ ] Auth flow has >85% test coverage ### Test Evidence - Registration: [E1] `curl -X POST /register` returns 201 → PASS - Valid login: [E2] `curl -X POST /login` with correct creds → PASS - Invalid login: [E3] `curl -X POST /login` with wrong creds returns 401 → PASS - Session persistence: [E4] Tested in browser, session survives refresh → PASS - Logout: [E5] Session cleared after `/logout` → PASS - Password hashing: [E6] DB query shows bcrypt hash, not plaintext → PASS - Rate limiting: [E7] 6th request within 1min returns 429 → PASS - Test coverage: [E8] `pytest --cov` shows 87% for auth module → PASS ### Status COMPLETE - All criteria passed ### User Verification Steps 1. Run test suite: `pytest tests/test_auth.py -v` 2. Expected: All tests pass (8/8) 3. Start dev server: `npm run dev` 4. Visit `/register`, create account 5. Expected: Redirected to dashboard 6. Refresh page 7. Expected: Still logged in 8. Click logout 9. Expected: Redirected to login page ``` --- ### 3. Bug Fix ```markdown ## Task: Fix memory leak in connection pool ### Acceptance Criteria - [ ] Memory leak reproduced and characterized - [ ] Root cause identified and documented - [ ] Fix implemented and tested - [ ] Memory usage stable over 1000 operati