mirror of
https://github.com/duthaho/claudekit.git
synced 2026-08-05 11:10:19 +03:00
feat: adding new skills, including testing patterns and methodologies, along with bundled resources for better usability.
This commit is contained in:
@@ -1,9 +1,11 @@
|
||||
---
|
||||
name: verification-before-completion
|
||||
description: >
|
||||
Trigger this skill whenever about to claim ANY work is complete, fixed, passing, or done. Activate whenever you are tempted to say "done", "fixed", "tests pass", "build succeeds", "deployed", or any completion claim. Also trigger before committing code, before creating PRs, before responding to the user that a task is finished, or when reviewing agent-produced work. This is mandatory -- NEVER claim completion without running verification commands and reading their output. Evidence before assertions, always.
|
||||
---
|
||||
|
||||
# Verification Before Completion
|
||||
|
||||
## Description
|
||||
|
||||
Mandatory verification process before claiming any task is complete. This skill enforces evidence-based completion rather than assumption-based claims.
|
||||
|
||||
## When to Use
|
||||
|
||||
- Before claiming tests pass
|
||||
@@ -12,6 +14,12 @@ Mandatory verification process before claiming any task is complete. This skill
|
||||
- Before marking any task complete
|
||||
- Before declaring success to user
|
||||
|
||||
## When NOT to Use
|
||||
|
||||
- Mid-task progress updates where you are reporting interim status, not claiming completion
|
||||
- Research or exploration tasks where the output is knowledge, not code
|
||||
- Design or brainstorming phases where no verifiable artifacts have been produced yet
|
||||
|
||||
---
|
||||
|
||||
## The 5-Step Verification Process
|
||||
@@ -260,3 +268,9 @@ Use before claiming completion:
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Related Skills
|
||||
|
||||
- `methodology/test-driven-development` -- TDD naturally produces verifiable work; verification confirms the TDD cycle was followed correctly
|
||||
- `methodology/systematic-debugging` -- After debugging, verification ensures the fix actually resolves the issue
|
||||
- `methodology/requesting-code-review` -- Verification should happen before requesting review to avoid wasting reviewer time on broken code
|
||||
|
||||
+116
@@ -0,0 +1,116 @@
|
||||
# Verification Checklist
|
||||
|
||||
Use this checklist before claiming any work is complete. Copy it into your task, PR, or plan and fill in the specifics. Every box must be checked with evidence — not assumptions.
|
||||
|
||||
---
|
||||
|
||||
## Core Verification
|
||||
|
||||
### Tests
|
||||
|
||||
- [ ] **All existing tests pass**
|
||||
- Command: `___`
|
||||
- Output: [paste summary or confirm "all N tests passed"]
|
||||
|
||||
- [ ] **New tests added for new behavior**
|
||||
- Test files: `___`
|
||||
- Coverage of changed code: `___`%
|
||||
|
||||
- [ ] **Edge cases tested**
|
||||
- [ ] Empty/null inputs
|
||||
- [ ] Boundary values
|
||||
- [ ] Error conditions
|
||||
- [ ] Concurrent access (if applicable)
|
||||
|
||||
### Build
|
||||
|
||||
- [ ] **Build succeeds with no errors**
|
||||
- Command: `___`
|
||||
- Output: [confirm clean build]
|
||||
|
||||
- [ ] **No new warnings introduced**
|
||||
- Linter: `___`
|
||||
- Type checker: `___`
|
||||
|
||||
### Manual Verification
|
||||
|
||||
- [ ] **The specific change works as intended**
|
||||
- What I did: [exact steps taken]
|
||||
- What I observed: [exact result]
|
||||
- What was expected: [matches requirement]
|
||||
|
||||
- [ ] **Related functionality still works**
|
||||
- Checked: [list related features tested]
|
||||
|
||||
---
|
||||
|
||||
## Safety Checks
|
||||
|
||||
### No Unintended Side Effects
|
||||
|
||||
- [ ] **Reviewed the full diff** — No accidental changes to unrelated files
|
||||
```bash
|
||||
git diff --stat
|
||||
```
|
||||
|
||||
- [ ] **No debug code left in place** — No `console.log`, `print()`, `debugger`, `TODO: remove`
|
||||
|
||||
- [ ] **No commented-out code** — Either the code is needed or it isn't
|
||||
|
||||
### Error Handling
|
||||
|
||||
- [ ] **Errors produce clear messages** — Not generic "something went wrong"
|
||||
- [ ] **Errors don't leak sensitive information** — No stack traces, internal paths, or credentials in user-facing errors
|
||||
- [ ] **Failure modes are graceful** — The system degrades rather than crashes
|
||||
|
||||
### Security
|
||||
|
||||
- [ ] **No hardcoded secrets** — API keys, passwords, tokens are in environment variables
|
||||
- [ ] **Input is validated** — User input is checked before processing
|
||||
- [ ] **Output is encoded** — Rendered content is escaped appropriately
|
||||
- [ ] **No new `eval()` or dynamic code execution**
|
||||
- [ ] **Dependencies are from trusted sources** — No typosquatting, pinned versions
|
||||
|
||||
---
|
||||
|
||||
## Documentation
|
||||
|
||||
- [ ] **Code is self-documenting** — Clear names, obvious structure
|
||||
- [ ] **Complex logic has comments** — Explaining WHY, not WHAT
|
||||
- [ ] **Public API changes are documented** — Updated docstrings, OpenAPI specs, README
|
||||
- [ ] **Breaking changes are called out** — In commit message, PR description, or changelog
|
||||
|
||||
---
|
||||
|
||||
## Completion Criteria
|
||||
|
||||
- [ ] **All acceptance criteria from the plan/ticket are met**
|
||||
- [ ] Criterion 1: ___
|
||||
- [ ] Criterion 2: ___
|
||||
|
||||
- [ ] **The change has been verified with actual commands, not just code reading**
|
||||
|
||||
- [ ] **Confidence level:** High / Medium / Low
|
||||
- If Medium or Low, explain what additional verification would increase confidence: ___
|
||||
|
||||
---
|
||||
|
||||
## Evidence Summary
|
||||
|
||||
Record the key evidence here for reviewers:
|
||||
|
||||
| Check | Evidence |
|
||||
|-------|---------|
|
||||
| Tests pass | [command + result] |
|
||||
| Build clean | [command + result] |
|
||||
| Manual test | [steps + result] |
|
||||
| No regressions | [how verified] |
|
||||
|
||||
---
|
||||
|
||||
## Usage Notes
|
||||
|
||||
- **Do not check boxes without evidence.** "I think it works" is not verification.
|
||||
- **Run commands and observe output.** Paste or summarize actual results.
|
||||
- **N/A is acceptable** for items that genuinely don't apply, but add a note explaining why.
|
||||
- **If confidence is low**, list what would increase it and discuss with the team before marking complete.
|
||||
Reference in New Issue
Block a user