@agentikos/omega-os 0.2.0 → 0.19.6

package/omega/Agentik_SSOT/skills/logicaudit/SKILL.md

@@ -0,0 +1,165 @@
+---
+name: logicaudit
+description: Forensic logic audit — Where is the system fighting itself — wasted computation, redundant paths, the wrong amount of engineering?. Runs the gather (deterministic) + falsify (agentic) pipeline, batches fixes, dispatches capped workers, re-audits, and persists scores. Use when the user says "/logicaudit", "audit logic", or asks to verify the logic health of the project.
+when_to_use: User says /logicaudit, audit logic, check logic, verify logic, is logic healthy.
+argument-hint: "[--scope <path>] [--fix] [--max-workers N]"
+arguments: [args]
+allowed-tools: Bash Read Edit Grep Glob Write
+---
+
+# logicaudit — forensic audit (Agentik OS Quality Arsenal)
+
+> Where is the system fighting itself — wasted computation, redundant paths, the wrong amount of engineering?
+
+You are running the logicaudit forensic audit. Apply the **Gestalt-Popper
+doctrine**: identify the hinge point, scrutinise it 10x, then assume
+every name is a CLAIM and look for the divergence between the claim and
+the reality. Bias toward FAIL. A perfect score is earned by finding zero
+falsifiable claims, never by absence of effort.
+
+## Run
+
+The audit is one engine call — gather (deterministic) + falsify (agentic)
++ optional fix-dispatch (capped) + re-audit. Invoke the unified pipeline:
+
+```bash
+omega audit run logicaudit $args
+```
+
+Common options:
+
+| Flag | Effect |
+|---|---|
+| `--scope <path>` | scope the audit (file or directory) |
+| `--fix` | after analysing, batch findings + dispatch up to N workers + re-audit |
+| `--max-workers N` | cap parallel fix workers (default 3) |
+| `--min-severity high` | only batch + fix findings at or above this severity |
+
+Read-only by default. Add `--fix` to enable the dispatch + re-audit loop.
+
+## Phases under investigation
+
+The agentic pass walks each phase below and emits structured findings
+(claim vs. reality). Every PASS must cite ≥3 concrete checks.
+
+### 1. redundant-logic
+
+Semantically identical logic in 3+ places; checks repeated across middleware/handler/service (blurs who owns validation); overlapping modules; chained data transforms; self-defeating logic (cache invalidated before read).
+
+### 2. algorithmic-efficiency
+
+Real Big-O of every loop/recursion; O(n^2) hidden as Array.find inside Array.map; N+1 query/fetch patterns; unnecessary computation (sort just to test existence); string concat / regex compile in loops.
+
+### 3. pipeline-efficiency
+
+Sum of step times vs total pipeline time — overhead >50% means the pipeline design IS the bug; sequential steps with no data dependency; stages producing output nobody reads; restart-from-stage-1 vs checkpoint.
+
+### 4. orchestration-overhead
+
+Hop count user→result — which hops are essential vs ceremony; dispatch overhead vs task size (task < dispatch cost → do it in-place); intent preserved or diluted per hop; coordination tax in multi-agent work.
+
+### 5. abstraction-fit
+
+Over-abstraction (factory with one type, plugin system with one plugin, GenericHandler<T> always string); under-abstraction (15 lines copy-pasted 8×); wrong abstraction (UserService doing auth+billing+notifications).
+
+### 6. state-machines
+
+Implicit state from combined booleans (isLoading+hasError+isReady = impossible combos); states that CAN be represented but are impossible WILL be reached; missing transitions (Loading with no path to Error).
+
+### 7. data-flow-entropy
+
+Single source of truth per datum (same data in DB + local state + URL = 3 truths); transformation chain length; data duplication without sync; prop drilling through components that never use it; stale-data patterns.
+
+### 8. caching-intelligence
+
+Missing caches (pure function re-called with same inputs, static reference data re-queried); ineffective caches (2% hit rate = wrong key granularity); invalidation correctness; caching at the right layer.
+
+### 9. parallelization-gaps
+
+Independent ops awaited serially instead of Promise.all; N individual calls that should be one batch; load-everything-then-process instead of streaming; worker pool sized wrong for wait/compute ratio.
+
+### 10. config-complexity
+
+Total config surface vs how many values are EVER changed from default; same value defined in .env AND config AND CLI AND default with undocumented precedence; invalid config caught at startup not first request.
+
+### 11. error-logic
+
+Swallowed errors (empty catch, .catch(()=>null)); error info loss (rethrow as generic 'something went wrong', logged at INFO); retry on non-transient 4xx; retry without backoff/idempotency/ceiling; wrong fallback values.
+
+### 12. decision-tree-pruning
+
+Arrow anti-pattern (if→if→if→if→logic) — flatten with guard clauses; 40-case switch that should be a lookup map; feature flags always-ON or always-OFF; routing that could be a simple table.
+
+### 13. over-engineering
+
+Unused flexibility (EventEmitter with one listener, strategy pattern with one strategy); premature optimization; architecture astronautics (microservices for one dev, event sourcing for CRUD); speculative generality.
+
+### 14. under-engineering
+
+Missing validation at boundaries (user input reaches DB unsanitized); missing error boundaries (one component crash kills the page); missing observability on critical paths; complex algorithm with zero comments.
+
+### 15. dead-logic
+
+Unreachable code after return/throw; branches guarded by always-true/false conditions; functions defined-never-called-not-exported; dead feature flags; commented-out code blocks; unused imports/variables.
+
+## Falsification rules
+
+Complexity is guilt until proven innocent — every abstraction, config layer and indirection must justify its existence with measurement or be eliminated. Every optimization claim is a hypothesis: "this cache speeds it up" → prove it with hit-rate numbers; "this abstraction reduces complexity" → count lines/branches before and after. Categorise findings as CLAIM-vs-MEASUREMENT, ABSTRACTION-vs-USAGE, CACHE-vs-FRESHNESS, PARALLEL-vs-SEQUENTIAL, RETRY-vs-IDEMPOTENT, or CONFIG-vs-HARDCODE. An optimization with no measurable improvement is a failed hypothesis — revert it.
+
+## After the run
+
+The pipeline writes one structured verdict to:
+
+```
+Agentik_Runtime/audits.db    (history — `omega audit history logicaudit`)
+Agentik_Runtime/sessions/${CLAUDE_SESSION_ID}/.done.json   (this turn)
+```
+
+The `.done.json` schema:
+
+```json
+{
+  "status": "done_clean" | "pending" | "failed",
+  "summary": "<one-paragraph verdict>",
+  "artifacts": {
+    "audit": "logicaudit",
+    "score": 0-100,
+    "verified": bool,
+    "findings": [...],
+    "fix_plan": [...],
+    "dispatches": [...],
+    "reaudit_score": 0-100  // only when --fix was used
+  }
+}
+```
+
+## Hard rules (don't break these)
+
+1. **No fake "done".** First Law: only runtime tells the truth. If the
+   gather phase fails or the agentic verdict scores below the threshold,
+   you have NOT verified — set status to `pending` or `failed`.
+2. **Cap parallelism.** ≤ 3 fix workers at a time. The
+   batcher enforces this; do not call out to other dispatch mechanisms.
+3. **No worker per finding.** Findings are clustered by file footprint and
+   severity. One worker handles one disjoint batch.
+4. **Re-audit confirms.** After fixes land, the pipeline re-runs the same
+   gather + agentic phases. If the score did not improve, escalate honestly.
+5. **History is the trend.** `omega audit history logicaudit` shows whether the
+   codebase is improving over time on this dimension. Use it to decide
+   whether to push for `--fix` again.
+
+## Why this audit exists
+
+The 18 forensic audits are the OmegaOS verification layer. Claude's
+"I'm done" claims used to be unverified. With these audits running as
+the gate, completion is **derived from observable facts**, not declared
+by the worker. Run this audit any time someone (human or agent) claims
+the logic dimension is healthy. Insist on the score before you
+accept.
+
+## Reference
+
+Audit definition: `Agentik_SSOT/audits/logicaudit.yaml`
+Engine pipeline:  `omega_engine.audits.pipeline.AuditPipeline`
+Batcher:          `omega_engine.audits.batcher.batch_findings`
+History:          `omega_engine.audits.history`

package/omega/Agentik_SSOT/skills/motionaudit/SKILL.md

@@ -0,0 +1,165 @@
+---
+name: motionaudit
+description: Forensic motion audit — Does it MOVE with purpose — does every animation earn its place and run at 60fps?. Runs the gather (deterministic) + falsify (agentic) pipeline, batches fixes, dispatches capped workers, re-audits, and persists scores. Use when the user says "/motionaudit", "audit motion", or asks to verify the motion health of the project.
+when_to_use: User says /motionaudit, audit motion, check motion, verify motion, is motion healthy.
+argument-hint: "[--scope <path>] [--fix] [--max-workers N]"
+arguments: [args]
+allowed-tools: Bash Read Edit Grep Glob Write
+---
+
+# motionaudit — forensic audit (Agentik OS Quality Arsenal)
+
+> Does it MOVE with purpose — does every animation earn its place and run at 60fps?
+
+You are running the motionaudit forensic audit. Apply the **Gestalt-Popper
+doctrine**: identify the hinge point, scrutinise it 10x, then assume
+every name is a CLAIM and look for the divergence between the claim and
+the reality. Bias toward FAIL. A perfect score is earned by finding zero
+falsifiable claims, never by absence of effort.
+
+## Run
+
+The audit is one engine call — gather (deterministic) + falsify (agentic)
++ optional fix-dispatch (capped) + re-audit. Invoke the unified pipeline:
+
+```bash
+omega audit run motionaudit $args
+```
+
+Common options:
+
+| Flag | Effect |
+|---|---|
+| `--scope <path>` | scope the audit (file or directory) |
+| `--fix` | after analysing, batch findings + dispatch up to N workers + re-audit |
+| `--max-workers N` | cap parallel fix workers (default 3) |
+| `--min-severity high` | only batch + fix findings at or above this severity |
+
+Read-only by default. Add `--fix` to enable the dispatch + re-audit loop.
+
+## Phases under investigation
+
+The agentic pass walks each phase below and emits structured findings
+(claim vs. reality). Every PASS must cite ≥3 concrete checks.
+
+### 1. motion-inventory
+
+Catalog every animation — CSS transitions/keyframes, JS-driven (rAF, Web Animations API, GSAP, Framer Motion), scroll-driven, canvas/WebGL — with element, trigger, properties, duration, easing.
+
+### 2. purpose-verification
+
+The hinge — apply the Purpose Test to each animation: does it COMMUNICATE state/causality, ORIENT the user, or CREATE meaning? Remove it mentally — if nothing is lost, it is PURPOSELESS.
+
+### 3. easing-system
+
+Easing as a vocabulary — enters decelerate (ease-out), exits accelerate (ease-in); count unique curves; are they named tokens or arbitrary per-component cubic-beziers?
+
+### 4. duration-consistency
+
+Durations on a systematic scale (tokens), each in its appropriate range — micro 80-150ms, entrances 200-400ms, exits faster than entrances; total entry choreography under 800ms.
+
+### 5. choreography
+
+Page entrances introduce themselves as a sequence following content hierarchy with consistent stagger; exits are swift and directional; state transitions communicate spatial relationships.
+
+### 6. scroll-animations
+
+No scroll hijacking, user controls pace, gentle parallax (10-30%), progress-linked not fire-and-forget, passive listeners, IntersectionObserver unobserved after firing.
+
+### 7. page-transitions
+
+Route changes animate with directional logic rather than hard-cut, shared-element continuity where possible, View Transitions API where supported, no long blank screens.
+
+### 8. micro-interactions
+
+Every interactive element responds to hover/focus/press with physical feedback (translate/scale, not color-only), consistent timing, popovers appear FROM their trigger.
+
+### 9. loading-skeleton
+
+Loading states are skeletons matching final layout (not bare spinners), shimmer is CSS-only, progressive reveal, smooth skeleton-to-content transition.
+
+### 10. webgl-canvas
+
+WebGL/P5 justified over CSS, 60fps desktop / 30fps mobile, tiered fallback (WebGL2/WebGL1/static), lazy-loaded, geometries/textures disposed on unmount, paused when off-screen.
+
+### 11. css-performance
+
+Animations use ONLY transform and opacity — animating width/height/margin/box-shadow triggers layout or paint; will-change used sparingly; no read-write-read forced reflow in loops.
+
+### 12. reduced-motion
+
+prefers-reduced-motion is a designed alternative not a nuclear kill-all — state changes still visible (modal still opens instantly), ambient motion pausable, interaction never blocked.
+
+### 13. mobile-motion
+
+Touch-specific :active feedback (not repurposed hover), gesture physics with momentum, safe-area respect, rAF paused when hidden, 30fps minimum under 4x CPU throttle.
+
+### 14. motion-meaning-gap
+
+The absence of motion is a finding — list added/removed, counter updates, tab switches, accordions, filtering, sorting that hard-cut where a transition should communicate the change.
+
+### 15. motion-excess
+
+Animations that harm — competing simultaneous motion, entrances over 600ms, distracting loops near text, redundant nested animations, gratuitous WebGL that could be CSS.
+
+## Falsification rules
+
+Every animation is guilty until proven purposeful. "It looks cool" is not a reason — FALSIFY each animation's justification: what does the user understand faster because of this motion? Every PASS must cite at least 3 concrete checks (the grepped property, the measured duration, the frame trace). Categorise findings as PURPOSE-vs-DECORATION, SYSTEM-vs-RANDOM, COMPOSITED-vs-EXPENSIVE, or PRESENT-vs-MISSING. A page with one perfectly timed animation beats a page with twelve good ones. Bias toward FAIL.
+
+## After the run
+
+The pipeline writes one structured verdict to:
+
+```
+Agentik_Runtime/audits.db    (history — `omega audit history motionaudit`)
+Agentik_Runtime/sessions/${CLAUDE_SESSION_ID}/.done.json   (this turn)
+```
+
+The `.done.json` schema:
+
+```json
+{
+  "status": "done_clean" | "pending" | "failed",
+  "summary": "<one-paragraph verdict>",
+  "artifacts": {
+    "audit": "motionaudit",
+    "score": 0-100,
+    "verified": bool,
+    "findings": [...],
+    "fix_plan": [...],
+    "dispatches": [...],
+    "reaudit_score": 0-100  // only when --fix was used
+  }
+}
+```
+
+## Hard rules (don't break these)
+
+1. **No fake "done".** First Law: only runtime tells the truth. If the
+   gather phase fails or the agentic verdict scores below the threshold,
+   you have NOT verified — set status to `pending` or `failed`.
+2. **Cap parallelism.** ≤ 3 fix workers at a time. The
+   batcher enforces this; do not call out to other dispatch mechanisms.
+3. **No worker per finding.** Findings are clustered by file footprint and
+   severity. One worker handles one disjoint batch.
+4. **Re-audit confirms.** After fixes land, the pipeline re-runs the same
+   gather + agentic phases. If the score did not improve, escalate honestly.
+5. **History is the trend.** `omega audit history motionaudit` shows whether the
+   codebase is improving over time on this dimension. Use it to decide
+   whether to push for `--fix` again.
+
+## Why this audit exists
+
+The 18 forensic audits are the OmegaOS verification layer. Claude's
+"I'm done" claims used to be unverified. With these audits running as
+the gate, completion is **derived from observable facts**, not declared
+by the worker. Run this audit any time someone (human or agent) claims
+the motion dimension is healthy. Insist on the score before you
+accept.
+
+## Reference
+
+Audit definition: `Agentik_SSOT/audits/motionaudit.yaml`
+Engine pipeline:  `omega_engine.audits.pipeline.AuditPipeline`
+Batcher:          `omega_engine.audits.batcher.batch_findings`
+History:          `omega_engine.audits.history`

package/omega/Agentik_SSOT/skills/newcmd.md

@@ -0,0 +1,300 @@
+---
+name: newcmd
+description: >
+  Skill engineering lab. Creates production-grade commands with Quality DNA: Gestalt clarity gate,
+  strong identity, scope detection, input/output contracts, verification gates, and full Omega
+  registration (Oracle, Telegram, SMITH). For audits: adds Popper falsification + scoring.
+  Use when user says "/newcmd", "create a command", "new skill", "new audit", "forge".
+allowed-tools: ["Read", "Write", "Edit", "Bash", "Glob", "Grep", "Agent"]
+---
+
+# /newcmd — Skill Engineering Lab
+
+> *"A mediocre skill is worse than no skill — it teaches the system bad habits."*
+
+---
+
+## PHILOSOPHY: THE QUALITY DNA
+
+Every skill created by /newcmd carries the same DNA. Not because of bureaucracy — because it works.
+
+**Gestalt Clarity** applies to ALL skills (not just audits):
+- Understand BEFORE acting. A skill that jumps into execution without understanding context produces generic garbage.
+- Every skill has a HINGE MOMENT — the single decision/output that determines if the entire skill succeeded or failed. Identify it. Nail it.
+- One question resolves more than ten assumptions.
+
+**Popper Falsification** applies to AUDIT skills only:
+- Don't verify. Falsify. Prove it lies.
+- Every claim is a hypothesis. Test it.
+
+**The result:** Skills that feel like they were written by a domain expert who's done this 1000 times, not an AI following a template.
+
+---
+
+## SKILL TYPES & QUALITY DNA
+
+### TYPE 1: FORENSIC AUDIT (scored, multi-phase, auto-fix)
+
+```
+Examples: /codeaudit, /debugaudit, /perfaudit, /secaudit
+DNA: Gestalt + Popper
+Structure: 15-25 phases, scoring /300-450, auto-fix, re-audit
+```
+
+### TYPE 2: CREATIVE PIPELINE (multi-stage, iterative)
+
+```
+Examples: /gestalt, /deepux, /brand-identity, /vision
+DNA: Gestalt (clarity → research → structure → polish)
+Structure: 3-5 sequential stages, each gate-checked
+```
+
+### TYPE 3: WORKFLOW ORCHESTRATOR (multi-step, dependencies)
+
+```
+Examples: /build, /new, /planner, /linear-fix
+DNA: Gestalt (understand → plan → execute → verify)
+Structure: Sequential steps, rollback plan, completion gate
+```
+
+### TYPE 4: FOCUSED TOOL (single purpose, fast)
+
+```
+Examples: /reader, /tunnel, /switch, /prompt
+DNA: Gestalt-lite (scope detection, clear output)
+Structure: Input → Process → Output, minimal ceremony
+```
+
+---
+
+## THE UNIVERSAL QUALITY DNA (ALL skills MUST have)
+
+Every skill, regardless of type, MUST have these 8 elements:
+
+### DNA-1: IDENTITY (who am I?)
+```markdown
+# /name — Title
+
+> *"Punchy one-liner that captures the skill's mindset"*
+
+## IDENTITY
+You are not a {generic role}. You are a {specific expert persona}.
+{2-3 sentences establishing expertise, taste, and standards.}
+```
+
+**Why:** Without identity, the skill behaves like a generic assistant. With it, it behaves like a specialist.
+
+### DNA-2: SCOPE DETECTION (what does the user want?)
+```markdown
+## SCOPE DETECTION (automatic from user prompt)
+Parse the user's intent. No clarification needed for common patterns.
+
+"/{name}"              → Full pipeline, default scope
+"/{name} [target]"     → Scoped to specific target
+"/{name} [problem]"    → Focused on the described problem
+"/{name} --focus {area}"  → Narrower scope with full depth (rule 46: no --quick)
+```
+
+**Why:** A skill that always asks "what do you want?" wastes the user's time. Parse intent, ask only when genuinely ambiguous.
+
+### DNA-3: HINGE MOMENT (what's the ONE thing that matters most?)
+```markdown
+## HINGE MOMENT
+Before executing, identify the single output/decision/element
+that determines if this skill succeeded or failed.
+Allocate 50% of effort to the hinge moment, 50% to everything else.
+```
+
+**Why:** Equal effort across all steps produces mediocre everything. Concentrated effort on the hinge produces excellence where it matters.
+
+### DNA-4: INPUT/OUTPUT CONTRACT (what goes in, what comes out?)
+```markdown
+## OUTPUT CONTRACT
+Clearly define:
+- What files/artifacts are created
+- Where they're saved
+- What format they use
+- What the user should do with them
+```
+
+**Why:** A skill that produces output the user can't find or use is useless.
+
+### DNA-5: PROGRESSIVE DEPTH (simple → advanced)
+```markdown
+## USAGE
+Simple:   /{name}                → Default behavior, sensible defaults
+Targeted: /{name} [scope]        → Focused on specific area  
+Advanced: /{name} --deep [scope] → Maximum depth, all options
+```
+
+**Why:** New users need simplicity. Power users need depth. Both from the same command.
+
+### DNA-6: VERIFICATION GATE (did it actually work?)
+```markdown
+## VERIFICATION
+Before reporting done:
+- [ ] Output exists and is well-formed
+- [ ] Build/compile/import passes (if code was changed)
+- [ ] The hinge moment was nailed (not just attempted)
+```
+
+**Why:** "Done" without verification is a lie. Every skill self-checks.
+
+### DNA-7: INTEGRATION (how does it connect to the ecosystem?)
+```markdown
+## ECOSYSTEM INTEGRATION
+- When to use BEFORE this skill: {prerequisites}
+- When to use AFTER this skill: {next steps}
+- Related skills: {complementary commands}
+```
+
+**Why:** Skills in isolation are tools. Skills in context are a system.
+
+### DNA-8: DOMAIN EXPERTISE (not generic — specific)
+```
+The skill must contain domain-specific knowledge that a generic 
+assistant wouldn't have. Specific checks, specific patterns, 
+specific best practices, specific anti-patterns.
+
+BAD:  "Check if the code is good"
+GOOD: "Check if N+1 queries exist by scanning for loops that 
+       call database queries. Pattern: for item in items: db.get(item.related_id)"
+```
+
+**Why:** Generic instructions produce generic results. Specific instructions produce expert results.
+
+---
+
+## ADDITIONAL DNA FOR AUDIT SKILLS (Type 1 only)
+
+On top of the 8 universal DNA elements, audit skills add:
+
+### AUDIT-DNA-1: POPPER FALSIFICATION
+```
+Don't verify it works. Prove it LIES.
+Every phase asks: "where does this claim diverge from reality?"
+Falsification categories specific to the domain.
+```
+
+### AUDIT-DNA-2: SCORING MATRIX
+```
+Each phase scored 0-10, weighted by user impact.
+Total 300-450 points. Normalized to /100. Letter grade S-F.
+```
+
+### AUDIT-DNA-3: AUTO-FIX PIPELINE
+```
+Phase N+1: Generate fix plan (prioritized by severity)
+Phase N+2: Execute fixes (sequential, with rollback)  
+Phase N+3: Re-audit (verify fixes, detect regressions)
+```
+
+### AUDIT-DNA-4: PARALLEL EXECUTION
+```
+Group phases into 4-5 waves for maximum parallelism.
+Wave 1: Discovery (sequential)
+Wave 2-3: Analysis (parallel agents)
+Wave 4: Verdict + Fix (sequential)
+```
+
+---
+
+## PROCESS
+
+### Step 1: UNDERSTAND
+Ask 1-2 questions max. Determine:
+- Domain and purpose
+- Type (audit / creative / workflow / tool)
+- Expected output
+
+### Step 2: RESEARCH
+Before writing a single line:
+- Read 2-3 existing skills of the same type for structural reference
+- Identify domain best practices (what would a world expert check?)
+- Identify the HINGE MOMENT for this domain
+
+### Step 3: GENERATE
+Write the skill file applying ALL Quality DNA elements.
+File should be:
+- Audit: 500-800 lines (comprehensive, forensic)
+- Creative: 300-500 lines (stages, examples, quality gates)
+- Workflow: 200-400 lines (steps, dependencies, verification)
+- Tool: 100-200 lines (focused, fast, clear)
+
+### Step 4: REGISTER IN OMEGA
+
+**Mandatory for ALL skills:**
+
+1. **Oracle routing** — `~/.claude/rules/001-smart-routing.md`
+   Add to Key Routes table with trigger patterns
+
+2. **CLAUDE.md** — `~/CLAUDE.md`
+   Add to appropriate table
+
+3. **AISB Telegram bot** — 3 files:
+   - `bot/aisb/handlers.py` → SKILL_COMMANDS dict + aliases
+   - `bot/aisb/commands.py` → help text
+   - `bot/aisb/prompts.py` → oracle skills list
+
+4. **AISB docs** (audits only):
+   - `~/.aisb/docs/ARCHITECTURE.md` → command table
+   - `~/.aisb/docs/ORCHESTRATION.md` → command table
+
+5. **Verify:**
+   ```bash
+   cd ~/VibeCoding/work/agentik-monitor/bot && source venv/bin/activate
+   python -c "from aisb.handlers import SKILL_COMMANDS; print('{name}' in SKILL_COMMANDS)"
+   ```
+
+### Step 5: QUALITY GATE
+
+Before reporting done:
+- [ ] File exists and contains ALL applicable DNA elements
+- [ ] Identity is specific (not generic)
+- [ ] Scope detection handles 3+ patterns
+- [ ] Hinge moment is identified and emphasized
+- [ ] Domain expertise is specific (not "check if good")
+- [ ] Output contract is clear
+- [ ] Verification gate exists
+- [ ] Bot imports pass after registration
+- [ ] At least 2 trigger phrases in description
+
+### Step 6: REPORT
+
+```
+Command: /{name}
+Type:    {audit | creative | workflow | tool}
+DNA:     {8/8 universal + N/4 audit-specific}
+Hinge:   {the ONE thing that determines success}
+File:    ~/.claude/commands/{name}.md ({N} lines)
+Omega:   Oracle ✓ | CLAUDE.md ✓ | Telegram ✓ | Docs ✓
+```
+
+---
+
+## ANTI-PATTERNS (what NOT to do)
+
+| Anti-Pattern | Why it's bad | What to do instead |
+|-------------|-------------|-------------------|
+| Generic identity ("You are a helpful assistant") | Produces bland output | Specific expert persona with taste |
+| No scope detection ("What would you like?") | Wastes user time | Parse intent from prompt |
+| Equal effort on all steps | Mediocre everywhere | 50% effort on hinge moment |
+| "Check if it's good" | Generic, unverifiable | Specific checks with specific criteria |
+| No verification gate | "Done" is unverified | Self-check before reporting |
+| No ecosystem integration | Isolated tool | References related skills |
+| Copy-paste template | Soulless skill | Domain-specific expertise |
+
+---
+
+## SMITH INTEGRATION
+
+SMITH improves skills over time by:
+1. Reading results from repeated use across projects
+2. Identifying phases/steps that consistently produce weak output → strengthen them
+3. Identifying domain patterns not covered → propose new checks
+4. Adjusting scoring weights based on real-world severity distribution
+5. Proposing new skills based on frequently requested capabilities
+
+---
+
+*"/newcmd — Engineer skills, don't template them. Quality DNA in every command."*