codexkit 1.0.0

package/.codex/skills/verification/SKILL.md

@@ -0,0 +1,191 @@
+---
+name: verification
+description: Goal-backward verification framework with existence, substance, and wiring checks.
+---
+
+# verification
+
+## Purpose
+Prove implementation is complete, real, and integrated before claiming success.
+
+## Use This Skill When
+- Before marking a task done
+- Before opening/updating PRs
+- After bugfixes, refactors, migrations, or upgrades
+- When “works locally” confidence is weak
+
+## Core Model (Goal-Backward)
+1. **Exists** — requested artifacts are present
+2. **Substantive** — behavior is real, not placeholder
+3. **Wired** — logic is reachable through real paths
+4. **Evidence** — outputs are reproducible
+
+---
+
+## Level 1: Exists
+
+### Questions
+- Were requested files/functions/tests created or updated?
+- Are target symbols discoverable?
+- Is the change visible in current diff?
+
+### Commands
+```bash
+[ -f src/path/file.ts ] && echo FOUND || echo MISSING
+rg -n "export .*functionName|className|const functionName" src
+git status --short
+git diff --name-only
+```
+
+### Checklist
+- [ ] Requested files exist
+- [ ] Expected symbols exist
+- [ ] Expected tests are present
+- [ ] Diff scope matches task scope
+
+---
+
+## Level 2: Substantive
+
+### Questions
+- Is implementation behavioral, not scaffold?
+- Are error/edge paths handled where needed?
+- Do tests assert outcomes instead of structure only?
+
+### Stub/Placeholder Detection
+```bash
+rg -n "TODO|FIXME|placeholder|stub|implement me" src test
+rg -n "return null|onClick=\{\(\) => \{\}\}" src
+rg -n "mockResolvedValue\(undefined\)|Promise\.resolve\(\)" src test
+rg -n "catch \(.*\) \{\s*\}" src
+```
+
+### Validation Gates by Stack
+```bash
+# TypeScript/Node
+npm run lint
+npm run typecheck
+npm test
+
+# Python
+ruff check .
+mypy .
+pytest -q
+
+# Go
+go vet ./...
+go test ./...
+
+# Rust
+cargo clippy --all-targets --all-features -- -D warnings
+cargo test --all-features
+```
+
+### Checklist
+- [ ] No unresolved placeholders in touched paths
+- [ ] Success + failure behavior is covered
+- [ ] Lint/typecheck/tests pass for touched scope
+- [ ] No fake pass conditions in tests
+
+---
+
+## Level 3: Wired
+
+### Questions
+- Is changed logic called from real entrypoints?
+- Are routes/commands/imports connected correctly?
+- Is one user-critical path exercised?
+
+### Wiring Checks
+```bash
+rg -n "from './newModule'|from \"./newModule\"|newFunction\(" src
+rg -n "app\.(get|post|put|patch|delete)\(|router\.(get|post|put|patch|delete)\(" src
+rg -n "<NewComponent|NewComponent\(" src
+```
+
+### Runtime Smoke Examples
+```bash
+curl -sf http://localhost:3000/health
+curl -sf -X POST http://localhost:3000/api/endpoint -H "content-type: application/json" -d '{"x":1}'
+npm run test:integration
+```
+
+### Checklist
+- [ ] Export/import chain intact
+- [ ] Entrypoint reaches changed logic
+- [ ] Critical path verified
+- [ ] No dead exports/orphan code
+
+---
+
+## Cache Fingerprint (Reuse Guard)
+Reuse evidence only if repository state is unchanged.
+
+```bash
+BASE=$(git rev-parse HEAD 2>/dev/null || echo no-git)
+DIFF=$(git diff -- . | shasum -a 256 | cut -d' ' -f1)
+UNTRACKED=$(git ls-files --others --exclude-standard | shasum -a 256 | cut -d' ' -f1)
+echo "$BASE:$DIFF:$UNTRACKED"
+```
+
+### Rule
+- Same fingerprint + previous full pass => reuse
+- Fingerprint change => rerun affected gates
+- Toolchain version change => rerun full suite
+
+---
+
+## Verification Profiles
+
+### Fast (small low-risk)
+1. Exists checks
+2. Stub scan on touched files
+3. Targeted tests + typecheck
+4. One wiring proof
+
+### Standard (default)
+1. Exists on touched artifacts
+2. Stub scan on touched dirs
+3. Lint + typecheck + relevant tests
+4. One integration/smoke path
+
+### Strict (auth/payment/security/migrations)
+1. Full lint/typecheck/test
+2. Integration + e2e critical flows
+3. Invalid-input and timeout behavior checks
+4. Rollback viability confirmed
+
+---
+
+## Reporting Format
+```markdown
+## Verification Summary
+- Profile: standard
+- Result: pass/fail
+
+## Exists
+- file/symbol evidence
+
+## Substantive
+- stub scan result
+- lint/typecheck/test outputs
+
+## Wired
+- callsite/route evidence
+- smoke/integration evidence
+
+## Risks
+- remaining concerns or "none"
+```
+
+## High-Signal Failure Patterns
+- Tests green but route/command never reaches new logic
+- UI renders with no-op handlers
+- Feature works only with mocks
+- Validation skipped for changed workspace/package
+- Feature hidden behind default-off flag with no activation path
+
+## Exit Criteria
+- Exists + Substantive + Wired proven with command evidence
+- No unresolved stubs/placeholders in touched scope
+- Report includes reproducible commands and residual risks

package/.codex/skills/verification-before-completion/SKILL.md

@@ -0,0 +1,236 @@
+---
+name: verification-before-completion
+description: Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always
+version: 1.0.0
+tags: [workflow, code-quality]
+dependencies: []
+---
+
+# Verification Before Completion
+
+## When to Use
+
+- Before claiming tests/lint/build pass or a bug is fixed
+- Before committing, opening PRs, or stating completion in a status update
+
+## When NOT to Use
+
+- While still actively coding without a completion claim
+- When you cannot run verification commands yet (e.g., missing dependencies) — resolve first
+
+## Overview
+
+Claiming work is complete without verification is dishonesty, not efficiency.
+
+**Core principle:** Evidence before claims, always.
+
+**Violating the letter of this rule is violating the spirit of this rule.**
+
+## The Iron Law
+
+```
+NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE
+```
+
+If you haven't run the verification command in this message, you cannot claim it passes.
+
+## The Gate Function
+
+```
+BEFORE claiming any status or expressing satisfaction:
+
+1. IDENTIFY: What command proves this claim?
+2. RUN: Execute the FULL command (fresh, complete)
+3. READ: Full output, check exit code, count failures
+4. VERIFY: Does output confirm the claim?
+   - If NO: State actual status with evidence
+   - If YES: State claim WITH evidence
+5. ONLY THEN: Make the claim
+
+Skip any step = lying, not verifying
+
+```
+
+## Verification Checklist
+
+- [ ] Identify the exact command that proves the claim
+- [ ] Run the full command (fresh)
+- [ ] Read the full output and exit code
+- [ ] Confirm the output matches the claim
+- [ ] Only then state the completion claim with evidence
+
+## Common Failures
+
+| Claim                 | Requires                        | Not Sufficient                 |
+| --------------------- | ------------------------------- | ------------------------------ |
+| Tests pass            | Test command output: 0 failures | Previous run, "should pass"    |
+| Linter clean          | Linter output: 0 errors         | Partial check, extrapolation   |
+| Build succeeds        | Build command: exit 0           | Linter passing, logs look good |
+| Bug fixed             | Test original symptom: passes   | Code changed, assumed fixed    |
+| Regression test works | Red-green cycle verified        | Test passes once               |
+| Agent completed       | VCS diff shows changes          | Agent reports "success"        |
+| Requirements met      | Line-by-line checklist          | Tests passing                  |
+
+## Red Flags - STOP
+
+- Using "should", "probably", "seems to"
+- Expressing satisfaction before verification ("Great!", "Perfect!", "Done!", etc.)
+- About to commit/push/PR without verification
+- Trusting agent success reports
+- Relying on partial verification
+- Thinking "just this once"
+- Tired and wanting work over
+- **ANY wording implying success without having run verification**
+
+## Rationalization Prevention
+
+| Excuse                                  | Reality                |
+| --------------------------------------- | ---------------------- |
+| "Should work now"                       | RUN the verification   |
+| "I'm confident"                         | Confidence ≠ evidence  |
+| "Just this once"                        | No exceptions          |
+| "Linter passed"                         | Linter ≠ compiler      |
+| "Agent said success"                    | Verify independently   |
+| "I'm tired"                             | Exhaustion ≠ excuse    |
+| "Partial check is enough"               | Partial proves nothing |
+| "Different words so rule doesn't apply" | Spirit over letter     |
+
+## Key Patterns
+
+**Tests:**
+
+```
+✅ [Run test command] [See: 34/34 pass] "All tests pass"
+❌ "Should pass now" / "Looks correct"
+```
+
+**Regression tests (TDD Red-Green):**
+
+```
+✅ Write → Run (pass) → Revert fix → Run (MUST FAIL) → Restore → Run (pass)
+❌ "I've written a regression test" (without red-green verification)
+```
+
+**Build:**
+
+```
+✅ [Run build] [See: exit 0] "Build passes"
+❌ "Linter passed" (linter doesn't check compilation)
+```
+
+**Requirements:**
+
+```
+✅ Re-read plan → Create checklist → Verify each → Report gaps or completion
+❌ "Tests pass, phase complete"
+```
+
+**Agent delegation:**
+
+```
+✅ Agent reports success → Check VCS diff → Verify changes → Report actual state
+❌ Trust agent report
+```
+
+## Smart Verification
+
+The Iron Law demands evidence, but evidence should be gathered efficiently.
+
+### Incremental by Default
+
+Unless shipping or `--full` is passed, verify only what changed:
+
+- **Lint**: `oxlint <changed-files>` instead of linting the entire codebase
+- **Test**: `vitest run --changed` instead of running all tests
+- **Typecheck**: always full (type errors propagate across files)
+
+See the [Verification Protocol](./references/VERIFICATION_PROTOCOL.md) for exact commands.
+
+### Parallel Execution
+
+Run independent gates simultaneously to reduce wall-clock time:
+
+```
+Parallel: typecheck + lint → both must pass
+Sequential: test → build (ship only)
+```
+
+Total time = max(typecheck, lint) + test, not typecheck + lint + test.
+
+### Verification Cache
+
+If you just verified and nothing changed, don't re-verify:
+
+1. After gates pass, record a stamp in `.beads/verify.log`
+2. Before running gates, compare current state to last stamp
+3. If match → report cached PASS, skip redundant work
+4. Cache is always bypassed for `--full` and ship/release
+
+This matters when other commands need verification (e.g., closing beads, `/ship`). If you verified 30 seconds ago and made no changes, the cache lets you skip.
+
+## Enforcement Gates
+
+Prompt-level rules get ignored under pressure. These gates are **hard blocks** — they must be checked at the tool/action level, not just remembered.
+
+### Gate 1: Completion Claims Require verify.log
+
+Before ANY completion claim (bead close, PR creation, `/ship`, task completion):
+
+1. Check `.beads/verify.log` exists and contains a recent `PASS` stamp
+2. If verify.log is missing or stale (older than last file change) → **BLOCK** — run verification first
+3. If verify.log shows `FAIL` → **BLOCK** — do not proceed
+
+```
+✅ verify.log exists, PASS within last edit window → proceed
+❌ verify.log missing → STOP: "Run verification first"
+❌ verify.log shows FAIL → STOP: "Verification failed, fix before claiming complete"
+❌ verify.log stale (files changed since last PASS) → STOP: "Re-run verification"
+```
+
+### Gate 2: Agent Delegation Requires Post-Verification
+
+After ANY `task()` subagent returns with "success", follow the **Worker Distrust Protocol** from AGENTS.md — read changed files, run verification, check acceptance criteria. Do not trust agent self-reports.
+
+### Enforcement Principle
+
+> **Prompt rules fail under pressure. Gates fail safe.**
+>
+> When a constraint matters enough to be an iron law, enforce it at the action level:
+> check a file, verify a condition, reject if unmet. Don't rely on the agent
+> "remembering" to follow the rule.
+
+## Why This Matters
+
+From 24 failure memories:
+
+- your human partner said "I don't believe you" - trust broken
+- Undefined functions shipped - would crash
+- Missing requirements shipped - incomplete features
+- Time wasted on false completion → redirect → rework
+- Violates: "Honesty is a core value. If you lie, you'll be replaced."
+
+## When To Apply
+
+**ALWAYS before:**
+
+- ANY variation of success/completion claims
+- ANY expression of satisfaction
+- ANY positive statement about work state
+- Committing, PR creation, task completion
+- Moving to next task
+- Delegating to agents
+
+**Rule applies to:**
+
+- Exact phrases
+- Paraphrases and synonyms
+- Implications of success
+- ANY communication suggesting completion/correctness
+
+## The Bottom Line
+
+**No shortcuts for verification.**
+
+Run the command. Read the output. THEN claim the result.
+
+This is non-negotiable.

package/.codex/skills/visual-analysis/SKILL.md

@@ -0,0 +1,154 @@
+---
+name: visual-analysis
+description: Use when analyzing images, screenshots, UI mockups, or visual content for extracting information, comparing designs, or assessing visual properties like colors, typography, and layout
+version: 1.0.0
+tags: [design, research]
+dependencies: []
+---
+
+# Visual Analysis Skill
+
+> **Replaces** guessing at visual properties from code alone — direct inspection of rendered output for colors, layout, spacing, and typography
+
+## When to Use
+
+- Analyzing UI mockups or screenshots
+- Extracting information from images
+- Comparing visual designs
+- Quick visual assessments
+
+## When NOT to Use
+
+- Pure text/code review without any visual assets.
+
+## Workflow
+
+1. **Capture** — Get the image (screenshot, mockup, or user-provided)
+2. **Analyze** — Use vision agent to extract specific properties (colors as hex, font sizes, spacing in px/rem)
+3. **Compare** — Cross-reference extracted values against design tokens and existing CSS
+4. **Report** — List discrepancies with specific values and file locations
+
+## Quick Mode
+
+Fast, focused analysis for specific questions.
+
+**Prompt pattern:**
+
+```
+Analyze this image: [attach image]
+[specific question]
+```
+
+**Examples:**
+
+- "What text is visible in this UI?"
+- "List all colors used with their hex values"
+- "Identify all interactive elements"
+
+## Deep Mode
+
+Comprehensive analysis with structured output.
+
+**Prompt pattern:**
+
+```
+Analyze this image comprehensively:
+
+1. CONTENT INVENTORY
+   - All UI elements present
+   - Text content
+   - Icons and imagery
+
+2. VISUAL PROPERTIES
+   - Color palette (hex values)
+   - Typography (fonts, sizes, weights)
+   - Spacing patterns
+   - Layout structure
+
+3. OBSERVATIONS
+   - Design patterns used
+   - Potential issues
+   - Notable features
+
+Output as structured markdown.
+```
+
+## Common Analysis Patterns
+
+### UI Component Analysis
+
+```
+Analyze this UI component:
+
+1. Component type and purpose
+2. Visual states (hover, focus, disabled)
+3. Accessibility considerations
+4. Props/variants needed
+5. Similar patterns in common UI libraries
+```
+
+### Screenshot Comparison
+
+```
+Compare these two images:
+
+1. Visual differences (be specific about location)
+2. Missing elements
+3. Spacing/sizing discrepancies
+4. Color accuracy
+5. Priority fixes ranked by visual impact
+```
+
+### Color Extraction
+
+```
+Extract all colors from this image.
+
+Output as JSON:
+{
+  "primary": ["#hex1", "#hex2"],
+  "secondary": ["#hex3"],
+  "neutral": ["#hex4", "#hex5"],
+  "accent": ["#hex6"]
+}
+
+Include approximate usage percentage for each color.
+```
+
+### Layout Analysis
+
+```
+Analyze the layout structure:
+
+1. Grid system (columns, gutters)
+2. Container widths
+3. Section divisions
+4. Responsive breakpoint hints
+5. Flexbox vs Grid recommendations
+
+Output CSS/Tailwind structure.
+```
+
+## Output Formats
+
+- **Markdown** (default): Structured text
+- **JSON**: For design tokens
+- **Code**: Direct implementation
+
+## Storage
+
+Save findings to `.codex/memory/design/analysis/`
+
+## Anti-Patterns
+
+| Anti-Pattern                                                                   | Why It Fails                                                                 | Instead                                                                     |
+| ------------------------------------------------------------------------------ | ---------------------------------------------------------------------------- | --------------------------------------------------------------------------- |
+| Describing layout vaguely ("looks good") instead of extracting specific values | Feedback is non-actionable and hard to validate                              | Report measurable values (hex, px/rem, font size/weight) with locations     |
+| Not comparing against existing design tokens                                   | Findings drift from system standards and create inconsistent recommendations | Map extracted values to tokens first, then flag true mismatches             |
+| Analyzing low-resolution screenshots (artifacts mislead analysis)              | Compression/noise causes false readings for spacing and color                | Request higher-resolution captures or zoomed crops before final conclusions |
+
+## See Also
+
+- `mockup-to-code`
+- `design-system-audit`
+- `accessibility-audit`

package/.codex/skills/web-design-guidelines/SKILL.md

@@ -0,0 +1,46 @@
+---
+name: web-design-guidelines
+description: Review UI code for Web Interface Guidelines compliance. Use when asked to "review my UI", "check accessibility", "audit design", "review UX", or "check my site against best practices".
+version: 1.0.0
+tags: [ui, design]
+dependencies: []
+---
+
+# Web Interface Guidelines
+
+## When to Use
+
+- Reviewing UI files against Web Interface Guidelines for UX/design compliance.
+
+## When NOT to Use
+
+- Non-UI code reviews or when no files/pattern are provided.
+
+
+## How It Works
+
+1. Fetch the latest guidelines from the source URL below
+2. Read the specified files (or prompt user for files/pattern)
+3. Check against all rules in the fetched guidelines
+4. Output findings in the terse `file:line` format
+
+## Guidelines Source
+
+Fetch fresh guidelines before each review:
+
+```
+https://raw.githubusercontent.com/vercel-labs/web-interface-guidelines/main/command.md
+```
+
+Use WebFetch to retrieve the latest rules. The fetched content contains all the rules and output format instructions.
+
+## Usage
+
+When a user provides a file or pattern argument:
+
+1. Fetch guidelines from the source URL above
+2. Read the specified files
+3. Apply all rules from the fetched guidelines
+4. Output findings using the format specified in the guidelines
+
+If no files specified, ask the user which files to review.