niahere 0.2.61 → 0.2.62

package/defaults/memory-promoter.md

@@ -0,0 +1,99 @@
+You are the memory promoter. You run nightly at 3am.
+
+Your job is to review the memory staging log and decide which candidates
+deserve promotion to durable memory. You are stage 2 of a two-stage memory
+architecture — the consolidator writes candidates to staging.md after each
+chat session; you review them and either promote, reject, or leave for
+another week.
+
+## Step 1 — Read all memory files
+
+Read these in full:
+
+- `~/.niahere/self/staging.md` — the candidate log you will work on
+- `~/.niahere/self/memory.md` — existing durable facts (avoid duplicates)
+- `~/.niahere/self/rules.md` — existing behavioral rules (avoid duplicates)
+
+The staging.md header documents the entry format:
+`- [count×] [type] content :: first_seen → last_seen`
+
+## Step 2 — Reap expired candidates
+
+First pass: remove junk that never recurred.
+
+Delete any entry where ALL of these are true:
+
+- `count == 1`
+- `last_seen` is more than 14 days before today
+- (i.e. it appeared once, no one confirmed it, and the TTL passed)
+
+## Step 3 — Review reinforced candidates
+
+For each entry with `count >= 2`, decide ONE of: PROMOTE / REJECT / WAIT.
+
+### PROMOTE — requires ALL of these:
+
+- **Durability**: would this still matter in 30+ days?
+- **Day-1 test**: would a fresh copy of nia starting tomorrow benefit from
+  knowing this on day 1 of its first session?
+- **Category fit**: type is exactly one of: `persona | project | reference | correction`
+- **Not already durable**: no matching entry in `memory.md` or `rules.md`
+- **Not derivable**: cannot be reconstructed by reading the codebase, git
+  log, config files, or live system state
+
+### REJECT — if ANY of these:
+
+- Transient state ("currently working on X", "today's task")
+- Single-session noise dressed up as a pattern
+- Status dump, error log, or command output masquerading as a memory
+- Already covered by an existing `memory.md` or `rules.md` entry
+- Derivable from code, config, or git history
+- Type is not one of the four allowed types
+
+### WAIT — only if:
+
+- Genuinely uncertain AND entry age < 7 days
+- Give it another week to see if it gets reinforced further
+
+Default for uncertain cases older than 7 days: REJECT. Promotion is a
+one-way door into every future session — be conservative.
+
+## Step 4 — Apply decisions
+
+For each PROMOTE decision, rewrite the candidate as a concise, dated line
+(≤200 chars) and append to the correct file:
+
+- `type == correction` → append to `~/.niahere/self/rules.md` (under a
+  "## Promoted YYYY-MM-DD" section you create if missing)
+- `type in (persona, project, reference)` → append to `~/.niahere/self/memory.md`
+  (under a "## Promoted YYYY-MM-DD" section you create if missing)
+
+Then remove the promoted line from `staging.md`.
+
+For each REJECT decision, remove the line from `staging.md`. You do not
+need to record rejections — they are the default and shouldn't clutter the
+log. If you reject a lot of entries from one source, that's a signal the
+consolidator prompt may need tightening — mention it in your summary.
+
+For each WAIT decision, leave the line in `staging.md` unchanged.
+
+## Step 5 — Report
+
+Print exactly one summary line in this format:
+
+`memory-promoter: reaped N / promoted M / rejected K / waiting W`
+
+No preamble, no prose. If something looked off (e.g. many rejections from
+one source, a candidate that seemed important but failed the day-1 test),
+add one additional line after the summary — keep it brief.
+
+## Hard rules
+
+- Never invent memories. Only promote what is literally in `staging.md`.
+- Never touch `memory.md` or `rules.md` except to APPEND a promoted line.
+  Do not reorder, rewrite, or edit existing entries.
+- Never promote an entry with `count < 2`. The reinforcement gate is
+  non-negotiable.
+- Do not message the user. This is a silent background job.
+- If `staging.md` is empty or contains only the header, report
+  `memory-promoter: staging empty` and exit.

package/defaults/self/staging.md

@@ -0,0 +1,48 @@
+# Memory Staging
+
+Candidate memories waiting for reinforcement before promotion to `memory.md`.
+Auto-managed by the consolidator (which writes candidates after chat sessions)
+and the nightly `memory-promoter` job (which reviews and promotes).
+
+## How it works
+
+- The consolidator appends candidates here after chat sessions — one line per
+  candidate, tagged with a type and a count.
+- If a candidate is observed in another session, the consolidator bumps its
+  count instead of adding a duplicate.
+- The `memory-promoter` job runs nightly at 3am. It promotes candidates with
+  `count >= 2` that pass durability review to `memory.md` (or `rules.md` for
+  behavioral corrections), and reaps entries older than 14 days that never
+  reached count 2.
+
+## Entry format
+
+```
+- [count×] [type] content :: first_seen → last_seen
+```
+
+- `count` — how many distinct sessions this was observed in
+- `type` — one of: `persona | project | reference | correction`
+- `content` — the candidate memory, one concise line
+- `first_seen` / `last_seen` — ISO dates (YYYY-MM-DD)
+
+## Types
+
+| Type         | What                                                         | Promotes to |
+| ------------ | ------------------------------------------------------------ | ----------- |
+| `persona`    | Facts about the owner — role, habits, preferences, schedule  | `memory.md` |
+| `project`    | Active work decisions, architecture, stakeholders, deadlines | `memory.md` |
+| `reference`  | Pointers to external systems (dashboards, repos, channels)   | `memory.md` |
+| `correction` | Behavioral preferences the user wants changed                | `rules.md`  |
+
+Anything that doesn't fit these four is not a durable memory — don't stage it.
+
+## Rules
+
+- Do not edit by hand — use the consolidator/promoter flow.
+- Entries need `count >= 2` to be eligible for promotion.
+- Entries with `count < 2` expire after 14 days of no reinforcement.
+- The consolidator writes ONLY to this file — never directly to `memory.md`
+  or `rules.md`. Only the promoter can write to the durable files.
+
+---

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "niahere",
-  "version": "0.2.61",
+  "version": "0.2.62",
   "description": "A personal AI assistant daemon — chat, scheduled jobs, persona system, extensible via skills.",
   "type": "module",
   "scripts": {

package/skills/code-review/pr-review.md

@@ -12,6 +12,7 @@ Before looking at any code, read these files if they exist:
 - `CONTRIBUTING.md` — contribution guidelines
 
 From these, extract:
+
 - **Language & framework** (TypeScript/Bun, Python/Django, Rust, Go, etc.)
 - **Code style rules** (naming, imports, formatting)
 - **Testing expectations** (unit, integration, what framework)
@@ -62,24 +63,28 @@ Run these passes in order. Each pass focuses on one concern — don't mix them.
 Adapt to the project's language. Apply that language's conventions:
 
 **TypeScript/JavaScript:**
+
 - Proper typing (no unnecessary `any`, correct generics, discriminated unions)
 - Async/await over raw promises, proper error propagation
 - Immutability preferences, const over let
 - Node.js/Bun API usage (streams, buffers, path handling)
 
 **Python:**
+
 - PEP 8, Pythonic idioms (comprehensions, context managers, generators)
 - Type hints where the project uses them
 - Proper exception hierarchy, avoid bare `except:`
 - f-strings over `.format()` or `%`
 
 **Go:**
+
 - Error handling patterns (check errors, don't ignore)
 - Naming conventions (exported vs unexported, receiver names)
 - Goroutine safety, channel usage, context propagation
 - Avoid unnecessary interfaces
 
 **Rust:**
+
 - Ownership and borrowing correctness
 - Error handling (`Result`/`Option`, avoid `.unwrap()` in library code)
 - Clippy-clean idioms, iterator chains over manual loops
@@ -87,6 +92,8 @@ Adapt to the project's language. Apply that language's conventions:
 
 **Other languages:** Apply equivalent idiomatic standards. When unsure, check what the existing codebase does.
 
+**Frontend/UI diffs:** When the PR touches animations, CSS, components, icons, typography, or anything user-facing, also review against the rules in the [userinterface-wiki](../userinterface-wiki/SKILL.md) skill (e.g. `timing-under-300ms`, `easing-entrance-ease-out`, `ux-fitts-target-size`, `visual-concentric-radius`, `type-tabular-nums-for-data`). Cite specific rule IDs in findings so the author can look them up at `../userinterface-wiki/rules/<rule-id>.md`.
+
 ### Pass 4: Security
 
 - Input validation at system boundaries (user input, API payloads, file uploads)
@@ -117,7 +124,7 @@ Adapt to the project's language. Apply that language's conventions:
 ### Pass 7: Documentation & Naming
 
 - Are names self-documenting? (variables, functions, types)
-- Complex logic has comments explaining *why*, not *what*
+- Complex logic has comments explaining _why_, not _what_
 - Public APIs have documentation
 - Misleading names or outdated comments
 - Breaking changes documented
@@ -130,24 +137,30 @@ Structure the review as:
 ## PR Review: <title or summary>
 
 ### Summary
+
 <1-2 sentences on what the PR does and overall assessment>
 
 ### Critical (must fix)
+
 - **[file:line]** Description of the issue
   - Why it matters
   - Suggested fix
 
 ### Important (should fix)
+
 - **[file:line]** Description
 
 ### Suggestions (nice to have)
+
 - **[file:line]** Description
 
 ### Positive
+
 - Call out good patterns, clean abstractions, solid test coverage
 ```
 
 **Severity guide:**
+
 - **Critical:** Bugs, security issues, data loss risks, broken functionality
 - **Important:** Design issues, missing tests, performance problems, convention violations
 - **Suggestions:** Style improvements, alternative approaches, minor cleanups

package/skills/cro/page.md

@@ -19,11 +19,13 @@ Analyze the page across these dimensions, in order of impact:
 ### 1. Value Proposition Clarity (Highest Impact)
 
 **Check for:**
+
 - Can a visitor understand what this is and why they should care within 5 seconds?
 - Is the primary benefit clear, specific, and differentiated?
 - Is it written in the customer's language (not company jargon)?
 
 **Common issues:**
+
 - Feature-focused instead of benefit-focused
 - Too vague or too clever (sacrificing clarity)
 - Trying to say everything instead of the most important thing
@@ -31,11 +33,13 @@ Analyze the page across these dimensions, in order of impact:
 ### 2. Headline Effectiveness
 
 **Evaluate:**
+
 - Does it communicate the core value proposition?
 - Is it specific enough to be meaningful?
 - Does it match the traffic source's messaging?
 
 **Strong headline patterns:**
+
 - Outcome-focused: "Get [desired outcome] without [pain point]"
 - Specificity: Include numbers, timeframes, or concrete details
 - Social proof: "Join 10,000+ teams who..."
@@ -43,6 +47,7 @@ Analyze the page across these dimensions, in order of impact:
 ### 3. CTA Placement, Copy, and Hierarchy
 
 **Primary CTA assessment:**
+
 - Is there one clear primary action?
 - Is it visible without scrolling?
 - Does the button copy communicate value, not just action?
@@ -50,20 +55,25 @@ Analyze the page across these dimensions, in order of impact:
   - Strong: "Start Free Trial," "Get My Report," "See Pricing"
 
 **CTA hierarchy:**
+
 - Is there a logical primary vs. secondary CTA structure?
 - Are CTAs repeated at key decision points?
 
 ### 4. Visual Hierarchy and Scannability
 
 **Check:**
+
 - Can someone scanning get the main message?
 - Are the most important elements visually prominent?
 - Is there enough white space?
 - Do images support or distract from the message?
 
+**Concrete UI rules for this section:** Load the [userinterface-wiki](../userinterface-wiki/SKILL.md) skill for rule-level guidance — especially `ux-fitts-target-size` (CTA size), `ux-hicks-minimize-choices` (page choice load), `ux-millers-chunking` (scannable groups of 5-9), `ux-von-restorff-emphasis` (making the primary CTA stand out), `ux-serial-position` (hero and footer placement), `ux-aesthetic-usability` (polish drives perceived trust), and `ux-peak-end-finish-strong` (close with clear success state). Cite rule IDs when pointing out specific page problems.
+
 ### 5. Trust Signals and Social Proof
 
 **Types to look for:**
+
 - Customer logos (especially recognizable ones)
 - Testimonials (specific, attributed, with photos)
 - Case study snippets with real numbers
@@ -75,6 +85,7 @@ Analyze the page across these dimensions, in order of impact:
 ### 6. Objection Handling
 
 **Common objections to address:**
+
 - Price/value concerns
 - "Will this work for my situation?"
 - Implementation difficulty
@@ -85,6 +96,7 @@ Analyze the page across these dimensions, in order of impact:
 ### 7. Friction Points
 
 **Look for:**
+
 - Too many form fields
 - Unclear next steps
 - Confusing navigation
@@ -99,15 +111,19 @@ Analyze the page across these dimensions, in order of impact:
 Structure your recommendations as:
 
 ### Quick Wins (Implement Now)
+
 Easy changes with likely immediate impact.
 
 ### High-Impact Changes (Prioritize)
+
 Bigger changes that require more effort but will significantly improve conversions.
 
 ### Test Ideas
+
 Hypotheses worth A/B testing rather than assuming.
 
 ### Copy Alternatives
+
 For key elements (headlines, CTAs), provide 2-3 alternatives with rationale.
 
 ---
@@ -115,26 +131,31 @@ For key elements (headlines, CTAs), provide 2-3 alternatives with rationale.
 ## Page-Specific Frameworks
 
 ### Homepage CRO
+
 - Clear positioning for cold visitors
 - Quick path to most common conversion
 - Handle both "ready to buy" and "still researching"
 
 ### Landing Page CRO
+
 - Message match with traffic source
 - Single CTA (remove navigation if possible)
 - Complete argument on one page
 
 ### Pricing Page CRO
+
 - Clear plan comparison
 - Recommended plan indication
 - Address "which plan is right for me?" anxiety
 
 ### Feature Page CRO
+
 - Connect feature to benefit
 - Use cases and examples
 - Clear path to try/buy
 
 ### Blog Post CRO
+
 - Contextual CTAs matching content topic
 - Inline CTAs at natural stopping points
 
@@ -143,6 +164,7 @@ For key elements (headlines, CTAs), provide 2-3 alternatives with rationale.
 ## Experiment Ideas
 
 When recommending experiments, consider tests for:
+
 - Hero section (headline, visual, CTA)
 - Trust signals and social proof placement
 - Pricing presentation

package/skills/frontend-design/SKILL.md

@@ -10,9 +10,13 @@ This skill covers two areas: building UIs that look crafted (not generated), and
 
 ## Routing
 
-| When the task involves... | Load |
-|---------------------------|------|
-| Building frontend UIs, web pages, dashboards, components, CSS, layouts, responsive design, accessibility | [building.md](building.md) |
+| When the task involves...                                                                                                             | Load                         |
+| ------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------- |
+| Building frontend UIs, web pages, dashboards, components, CSS, layouts, responsive design, accessibility                              | [building.md](building.md)   |
 | Creating, reading, applying, evolving, or auditing DESIGN.md files; extracting design tokens; translating tokens to framework configs | [design-md.md](design-md.md) |
 
 **Both apply?** Load both. When a DESIGN.md exists in the project, its tokens override the general principles in building.md.
+
+## Companion Skill
+
+For concrete rule-level UI values (animation timings, easing curves, spring params, Laws of UX target sizes, typography features, shadow/radius math, prefetching patterns), also load the [userinterface-wiki](../userinterface-wiki/SKILL.md) skill. frontend-design sets direction; userinterface-wiki provides the 152 prioritized rules with code examples.

package/skills/frontend-design/building.md

@@ -2,6 +2,10 @@
 
 Build interfaces that feel crafted, not generated. This skill prevents "AI slop" — the generic, soulless, template-looking output that AI tools default to.
 
+## Companion Reference
+
+For concrete, rule-level guidance on animation timing, easing, springs, exit animations, CSS pseudo-elements, audio feedback, morphing icons, container animation, Laws of UX, predictive prefetching, typography, and visual design (shadows, radii, spacing), load the [userinterface-wiki](../userinterface-wiki/SKILL.md) skill. It contains 152 prioritized rules (e.g. `timing-under-300ms`, `ux-fitts-target-size`, `visual-concentric-radius`, `type-tabular-nums-for-data`) with code examples at `../userinterface-wiki/rules/<rule-id>.md`. Use it whenever you need a specific number, easing curve, or pattern — this file sets direction, userinterface-wiki sets values.
+
 ## The Problem: AI Slop
 
 AI-generated UIs are instantly recognizable: overly perfect gradients, predictable purple-on-white palettes, card grids with rounded corners, safe Inter/Roboto fonts, and layouts that all look interchangeable. This happens because AI pattern-matches from training data rather than making intentional design choices.
@@ -23,6 +27,7 @@ If you can't answer these, you're about to produce slop.
 Typography is the single biggest differentiator between generic and intentional design.
 
 **Do:**
+
 - Choose a specific typeface that matches the personality. Google Fonts has hundreds — use them.
 - Use type scale with purpose: large headings (2.5rem+), comfortable body (1rem-1.125rem), small labels
 - Vary font weights deliberately: light for elegance, bold for impact, medium for body
@@ -31,6 +36,7 @@ Typography is the single biggest differentiator between generic and intentional
 - Mix a display/heading font with a body font for contrast
 
 **Don't:**
+
 - Default to Inter, Roboto, Arial, or system fonts without reason
 - Use the same font weight everywhere
 - Skip setting line-height and letter-spacing
@@ -39,6 +45,7 @@ Typography is the single biggest differentiator between generic and intentional
 ## Color
 
 **Do:**
+
 - Pick a clear direction: warm, cool, monochrome, earthy, vibrant
 - Define CSS variables for your palette: `--color-primary`, `--color-surface`, `--color-text`, `--color-accent`
 - Use neutrals that aren't pure white or pure black — off-whites (`#f8f7f4`), warm grays (`#2d2a27`), soft darks
@@ -46,6 +53,7 @@ Typography is the single biggest differentiator between generic and intentional
 - Test contrast ratios for accessibility (WCAG AA minimum: 4.5:1 for text)
 
 **Don't:**
+
 - Default to purple-on-white (the most common AI slop palette)
 - Use pure `#000` on pure `#fff` — it's harsh
 - Pick colors without defining the full palette upfront
@@ -54,6 +62,7 @@ Typography is the single biggest differentiator between generic and intentional
 ## Layout & Spacing
 
 **Do:**
+
 - Use CSS Grid for page structure, Flexbox for component-level layout
 - Define a spacing scale with CSS variables: `--space-xs` through `--space-3xl`
 - Use `rem` units for spacing and font sizes (better cross-device scaling)
@@ -62,6 +71,7 @@ Typography is the single biggest differentiator between generic and intentional
 - Use `max-width` on content areas (65-75ch for readable text, ~1200px for page containers)
 
 **Don't:**
+
 - Use hardcoded pixel values scattered through the code
 - Make everything a card grid — vary your layout patterns
 - Forget mobile: test at 375px width minimum
@@ -72,6 +82,7 @@ Typography is the single biggest differentiator between generic and intentional
 This is what separates crafted from generic.
 
 **Do:**
+
 - Use gradients, subtle patterns, or textured backgrounds instead of flat single colors
 - Add meaningful animations: page-load fades, staggered reveals, hover transitions
 - Create visual hierarchy with size contrast — make the important things big
@@ -79,6 +90,7 @@ This is what separates crafted from generic.
 - Consider asymmetric layouts for landing pages — not everything needs to be centered
 
 **Don't:**
+
 - Add micro-animations to everything — a few purposeful ones beat many generic ones
 - Use the same border-radius everywhere
 - Make every section look the same — vary the visual rhythm
@@ -87,6 +99,7 @@ This is what separates crafted from generic.
 ## Component Quality
 
 **Do:**
+
 - Build with semantic HTML: `<nav>`, `<main>`, `<section>`, `<article>`, `<button>`
 - Handle all states: default, hover, focus, active, disabled, loading, error, empty
 - Use `focus-visible` for keyboard focus styles
@@ -94,6 +107,7 @@ This is what separates crafted from generic.
 - Use `prefers-color-scheme` when implementing dark/light modes
 
 **Don't:**
+
 - Use `<div>` for everything
 - Skip empty states and error states — these are where AI-generated UIs always fail
 - Forget keyboard navigation and screen reader support
@@ -113,8 +127,8 @@ This is what separates crafted from generic.
   --color-accent: #f59e0b;
 
   /* Typography */
-  --font-heading: 'Instrument Serif', serif;
-  --font-body: 'DM Sans', sans-serif;
+  --font-heading: "Instrument Serif", serif;
+  --font-body: "DM Sans", sans-serif;
 
   /* Spacing scale */
   --space-xs: 0.25rem;
@@ -149,6 +163,7 @@ Read the project's CSS/design tokens before writing new styles. Match what exist
 ## Responsive Checklist
 
 Before finishing any UI work:
+
 - [ ] Works at 375px (mobile)
 - [ ] Works at 768px (tablet)
 - [ ] Works at 1440px+ (desktop)