ima-claude 2.20.0 → 2.26.0

package/plugins/ima-claude/skills/save-session/SKILL.md

@@ -5,77 +5,48 @@ description: "Save session state to Serena MCP memory (no file path confusion)"
 
 # save-session
 
-Save current session state to Serena MCP memory for cross-session persistence.
+Use `mcp__serena__write_memory` with memory name `session-state`.
 
-## Trigger Phrases
-
-- "save session"
-- "save the session"
-- "save current session"
-- "create session save"
-- "checkpoint session"
-
-## Instructions
-
-Use `mcp__serena__write_memory` to save session state.
-
-**Memory name**: `session-state`
-
-**Content format**:
+## Content Format
 
 ```markdown
 # Session State
 Saved: {current_date_time}
 
 ## Current Task
-{1-2 sentences describing the active task or goal}
+{1-2 sentences describing active task or goal}
 
 ## Modified Files
 - {path/to/file1}
-- {path/to/file2}
 
 ## Decisions Made
 - {Key decision 1}
-- {Key decision 2}
 
 ## Technical Context
-- **Relevant code**: {endpoints, functions, components involved}
+- **Relevant code**: {endpoints, functions, components}
 - **Patterns**: {FP patterns, type constraints, architectural decisions}
 - **Dependencies**: {external libraries, services, APIs}
 
 ## Outstanding Items
 - [ ] {Incomplete item or next step}
-- [ ] {Blocker or open question}
 
 ## Resume Hint
 {One sentence: what to do first when resuming}
 ```
 
-## Rules
+## Include / Exclude
 
-**Include:**
-- Active task state (what's in progress)
-- Files touched this session
-- Decisions that affect future work
-- Blockers or open questions
-- Enough context to resume without re-reading entire codebase
+**Include:** active task state, files touched, decisions affecting future work, blockers, enough context to resume without re-reading codebase.
 
-**Exclude:**
-- Conversation history or dialogue
-- Code snippets (the actual files have the code)
-- Completed work that doesn't affect next steps
-- Research paths that led nowhere
-- Obvious context (project name, basic structure)
+**Exclude:** conversation history, code snippets (files have the code), completed work not affecting next steps, dead-end research paths, obvious context.
 
 ## After Writing
 
-Confirm with: "Session saved to Serena memory 'session-state'"
+Confirm: "Session saved to Serena memory 'session-state'"
 
-**Note:** For persistent knowledge (decisions, patterns, preferences) that should survive beyond this session, use Vestige via `smart_ingest` — not Serena memory. Serena is for ephemeral session state only.
+**Note:** For decisions/patterns/preferences surviving beyond this session, use Vestige `smart_ingest` — not Serena. Serena is ephemeral session state only.
 
 ## Technical Notes
 
-- Uses Serena MCP `write_memory` tool (no file path confusion)
-- Memory persists across Claude sessions in project context
 - Overwrites previous session-state (single checkpoint model)
-- Project-specific storage (appropriate for session state)
+- Project-specific storage (project-bound)

package/plugins/ima-claude/skills/scorecard/SKILL.md

@@ -5,7 +5,7 @@ description: "Generate a quick visual scorecard for any project's README. Scores
 
 # Scorecard — Project Quality Assessment
 
-Generate a compact visual scorecard and insert it into the project README.
+Generate compact visual scorecard and insert into project README.
 
 ## Invocation
 
@@ -19,36 +19,42 @@ Arguments are domain skills to evaluate against. If none provided, auto-detect f
 
 ## Process
 
-Use `task-master` to organize all work. Delegate review categories to parallel agents.
-
 ### Step 1: Setup
 
-1. Invoke `task-master` skill for orchestration
-2. Invoke each domain skill passed as arguments (these define the code standards to score against)
-3. Identify the project's primary language(s) and framework(s)
-4. Locate the README (or note its absence)
+1. Invoke `task-master` for orchestration
+2. Load each domain skill passed as argument (defines code standards to score against)
+3. Identify project's primary language(s) and framework(s)
+4. Locate README (or note its absence)
 
-### Step 2: Parallel Review (delegate via task-master)
+### Step 2: Run project validators (REQUIRED)
 
-Spawn parallel agents for each scoring category:
+Before any grading, discover and run the project's configured gate. Same discovery order as the `reviewer` agent:
 
-| Category | What to Evaluate | Key Signals |
-|----------|-----------------|-------------|
-| **Code Standards** | FP adherence, naming, patterns, consistency | Pure functions, immutability, composition, no anti-patterns from loaded skills |
-| **Security** | Input validation, injection risks, auth patterns, secrets | OWASP top 10, hardcoded credentials, SQL/XSS/command injection, dependency vulnerabilities |
-| **Test Coverage** | Test existence, quality, edge cases | Test files present, assertions meaningful, critical paths covered |
-| **Documentation** | README quality, inline docs where needed, API docs | Setup instructions, usage examples, architecture notes |
-| **Maintainability** | Complexity, coupling, file organization, dead code | Small functions, clear boundaries, no circular deps, sensible structure |
+| Ecosystem | Where to look |
+|---|---|
+| PHP | `composer.json` scripts — `check`, `test`, `phpcs`, `phpcs:report` |
+| JS/TS | `package.json` scripts — `test`, `lint`, `typecheck`, `check` |
+| Make-based | `Makefile` targets — `check`, `test`, `lint`, `ci` |
+| Python | `pyproject.toml` / `tox.ini` / `noxfile.py` |
+| Ruby | `Rakefile` — `ci`, `test`, `rubocop` |
+
+Capture exit codes, error/warning counts, and test coverage % (run the coverage variant — `composer test:coverage`, `npm test -- --coverage` — when available). These are primary evidence for Code Standards, Security, and Test Coverage grades.
 
-Each agent should:
-- Use `model: "sonnet"` (Opus orchestrates, Sonnet evaluates)
-- Scan relevant files for its category
-- Return a letter grade (A-F) with 2-3 bullet points justifying the score
-- Be honest — inflated scores help nobody
+Grades without validator backing are vibes grades. Don't ship them. No validators configured is itself a signal — floor Code Standards at C until they exist.
 
-### Step 3: Compile Scores
+### Step 3: Parallel Review
+
+Spawn parallel agents per category (`model: "sonnet"`). Each returns letter grade (A-F) + 2-3 justifying bullets rooted in validator output. Be honest — inflated scores help nobody.
+
+| Category | What to Evaluate | Key Signals |
+|----------|-----------------|-------------|
+| **Code Standards** | FP adherence, naming, patterns | Pure functions, immutability, composition, no anti-patterns |
+| **Security** | Input validation, injection, auth, secrets | OWASP top 10, hardcoded credentials, SQL/XSS/command injection |
+| **Test Coverage** | Test existence, quality, edge cases | Test files present, meaningful assertions, critical paths covered |
+| **Documentation** | README quality, inline docs, API docs | Setup instructions, usage examples, architecture notes |
+| **Maintainability** | Complexity, coupling, file organization | Small functions, clear boundaries, no circular deps |
 
-Collect agent results into the scorecard table format:
+### Step 4: Compile Scores
 
 ```markdown
 ## Scorecard
@@ -67,30 +73,26 @@ Collect agent results into the scorecard table format:
 ### Grading Scale
 
 **Formatting rules (non-negotiable):**
-- Use **exact emoji characters**: `🟢` `🟡` `🔴` — never GitHub shortcodes (`:green_circle:`), never Unicode geometric shapes (`●`, `◐`, `○`). Shortcodes don't render outside GitHub; geometric shapes are grey in terminals.
-- Use **whole letter grades only**: A, B, C, D, F — no `+` or `-` modifiers. Nuance belongs in the Notes column, not the grade.
-- Format as `🟢 A` (emoji + space + letter) — no backticks around the grade in the README output.
+- Use **exact emoji characters**: `🟢` `🟡` `🔴` — never GitHub shortcodes (`:green_circle:`), never Unicode geometric shapes
+- **Whole letter grades only**: A, B, C, D, F — no `+` or `-`. Nuance goes in Notes column
+- Format as `🟢 A` (emoji + space + letter) — no backticks in README output
 
 | Grade | Indicator | Meaning |
 |-------|-----------|---------|
-| A | 🟢 A | Excellent — meets or exceeds standards |
+| A | 🟢 A | Excellent |
 | B | 🟢 B | Good — minor improvements possible |
-| C | 🟡 C | Adequate — notable gaps to address |
+| C | 🟡 C | Adequate — notable gaps |
 | D | 🔴 D | Poor — significant issues |
 | F | 🔴 F | Failing — critical problems |
 
-### Step 4: Insert into README
+### Step 5: Insert into README
 
-- Find the existing `## Scorecard` section and replace it, OR
-- Insert after the first heading (title) if no scorecard section exists
-- Keep the table compact — no lengthy explanations in the README
-- Present the full scorecard to the user before writing, in case they want adjustments
+- Replace existing `## Scorecard` section, or insert after first heading if absent
+- Present full scorecard to user before writing
+- Notes: 5-10 words max each
 
-## Guidelines
+## Rules
 
-- **Honest scores only.** A scorecard that says everything is an A is useless.
-- **Notes are terse.** Each note is 5-10 words max. The scorecard is a glance, not a report.
-- **Domain skills define "Code Standards."** The loaded FP/framework skills set the bar for what good looks like.
-- **Security is always evaluated** regardless of which domain skills are passed.
-- **Auto-detect when no skills given.** Scan for package.json (JS), composer.json (PHP), etc. and suggest appropriate skills.
-- **Date stamp every scorecard** so readers know how fresh it is.
+- Security always evaluated regardless of domain skills passed
+- Auto-detect skills when none given (scan package.json, composer.json, etc.)
+- Date-stamp every scorecard

package/plugins/ima-claude/skills/skill-analyzer/SKILL.md

@@ -5,103 +5,75 @@ description: Analyzes Skills against best practices and provides actionable impr
 
 # Skill Analyzer
 
-Evaluate Skills against documented best practices and provide actionable feedback.
+Evaluate Skills against best practices and provide actionable feedback.
 
 ## Quick Start
 
-1. Run automated validation:
-   ```bash
-   python scripts/analyze_skill.py /path/to/skill-directory
-   ```
-
-2. Review the analysis report for issues and recommendations
+```bash
+python scripts/analyze_skill.py /path/to/skill-directory
+```
 
-3. For manual deep-dive, follow the Analysis Workflow below
+Review report → apply fixes → verify with checklists below.
 
-## Analysis Workflow
+## Analysis Phases
 
 ### Phase 1: Structural Validation
 
-Check YAML frontmatter requirements:
-- `name`: Present, ≤64 chars, lowercase letters/numbers/hyphens only, no reserved words (anthropic, claude)
-- `description`: Present, non-empty, ≤1024 chars, no XML tags
+Frontmatter:
+- `name`: present, ≤64 chars, lowercase letters/numbers/hyphens, no reserved words (anthropic, claude)
+- `description`: present, non-empty, ≤1024 chars, no XML tags
 
-Check file organization:
-- SKILL.md exists at root
-- Body ≤500 lines (optimal context efficiency)
-- References are one level deep from SKILL.md (no nested chains)
+File organization:
+- `SKILL.md` exists at root
+- Body ≤500 lines
+- References one level deep from SKILL.md (no nested chains)
 
 ### Phase 2: Description Quality
 
-**Good descriptions include:**
-- What the skill does
-- When/triggers for using it
-- Key terms users might mention
+Good descriptions: what the skill does + trigger contexts + key terms.
 
-**Red flags:**
-- Vague: "helps with documents", "processes data"
-- First/second person: "I can help you...", "You can use this to..."
-- Missing trigger contexts
-
-**Example transformation:**
-```
-Bad:  "Helps with PDFs"
-Good: "Extracts text and tables from PDF files, fills forms, merges documents. 
-       Use when working with PDF files or when the user mentions PDFs, forms, 
-       or document extraction."
-```
+| Bad | Good |
+|-----|------|
+| "Helps with PDFs" | "Extracts text and tables from PDF files, fills forms, merges documents. Use when working with PDFs, forms, or document extraction." |
+| "I can help you..." | Third-person, action-oriented |
+| Missing trigger contexts | Explicit trigger phrases |
 
 ### Phase 3: Content Efficiency
 
-**Check for over-explanation:**
-- Does the skill explain concepts Claude already knows?
-- Are there verbose paragraphs that could be concise code examples?
-- Token cost vs. value delivered?
+For each section ask: Does Claude need this? Can Claude already know this? Does it justify token cost?
 
-**Conciseness test:** For each section ask:
-1. "Does Claude really need this?"
-2. "Can I assume Claude knows this?"
-3. "Does this justify its token cost?"
+Compress verbose paragraphs to code examples. Drop explanations of concepts Claude already knows.
 
 ### Phase 4: Progressive Disclosure
 
-**Verify proper layering:**
-1. Metadata (name + description) - triggers skill selection
-2. SKILL.md body - core instructions loaded on trigger
-3. Reference files - loaded only when needed
+Verify layering:
+1. Frontmatter → triggers skill selection
+2. SKILL.md body → core instructions on trigger
+3. Reference files → loaded only when needed
 
-**Check reference patterns:**
-- Large content (>100 lines) split into separate files
-- Reference files have table of contents if >100 lines
-- Domain-specific content organized by domain
-- Clear pointers in SKILL.md to when each reference should be read
+Reference files: split content >100 lines, include ToC if >100 lines, clear pointers in SKILL.md for when to load each.
 
 ### Phase 5: Workflow Quality
 
-For skills with multi-step processes:
-- Steps are clear and sequential
-- Decision points have conditional guidance
-- Feedback loops exist for quality-critical operations
+For multi-step skills:
+- Steps are sequential and unambiguous
+- Decision points have branching criteria
 - Validation steps precede irreversible actions
 
 ### Phase 6: Anti-Pattern Detection
 
-Check for these common issues:
-
-| Anti-Pattern | Detection | Fix |
-|--------------|-----------|-----|
-| Too many options | Multiple equivalent approaches offered | Provide one default + escape hatch |
-| Windows paths | Backslashes in file paths | Use forward slashes everywhere |
-| Time-sensitive info | Dates, "before/after X" conditionals | Use "old patterns" section or remove |
-| Inconsistent terminology | Same concept, multiple terms | Choose one term throughout |
-| Deeply nested refs | File A → File B → File C | Flatten to one level from SKILL.md |
-| Voodoo constants | Unexplained magic numbers in scripts | Document why each value was chosen |
-| Excessive files | README, CHANGELOG, QUICK_REFERENCE | Only SKILL.md + essential resources |
+| Anti-Pattern | Fix |
+|--------------|-----|
+| Multiple equivalent approaches offered | One default + escape hatch |
+| Windows backslash paths | Use forward slashes |
+| Dates or "before/after X" conditionals | Use "old patterns" section or remove |
+| Same concept, multiple terms | Choose one term throughout |
+| File A → B → C reference chains | Flatten to one level from SKILL.md |
+| Unexplained magic numbers | Document why each value was chosen |
+| README, CHANGELOG, QUICK_REFERENCE files | Only SKILL.md + essential resources |
 
 ## Output Report Format
 
-After analysis, produce a structured report:
-
 ```markdown
 # Skill Analysis: [skill-name]
 
@@ -111,10 +83,10 @@ After analysis, produce a structured report:
 - Description quality: [Good/Needs Work]
 
 ## Critical Issues
-[Issues that must be fixed]
+[Must fix]
 
 ## Recommendations
-[Improvements that would help but aren't blocking]
+[Helpful but not blocking]
 
 ## Strengths
 [What the skill does well]
@@ -122,6 +94,5 @@ After analysis, produce a structured report:
 
 ## Detailed Checklists
 
-For comprehensive evaluation criteria, see:
-- [references/core-checklist.md](references/core-checklist.md) - Essential quality checks
-- [references/advanced-checklist.md](references/advanced-checklist.md) - For skills with scripts/code
+- [references/core-checklist.md](references/core-checklist.md) — Essential quality checks
+- [references/advanced-checklist.md](references/advanced-checklist.md) — For skills with scripts/code