Help us improve
Share bugs, ideas, or general feedback.
From karimo
Captures feedback on KARIMO or Claude Code operations with auto-detection of issue complexity, generates rules for simple cases or launches adaptive investigation for complex ones.
npx claudepluginhub opensesh/karimo --plugin karimoHow this command is triggered — by the user, by Claude, or both
Slash command
/karimo:feedbackFiles this command reads when invoked
The summary Claude sees in its command listing — used to decide when to auto-load this command
# /karimo:feedback — Unified Feedback Command Intelligent feedback capture with automatic complexity detection and adaptive investigation. ## Purpose Unified command for capturing feedback about KARIMO or Claude Code operation. Auto-detects whether feedback needs quick rule creation (simple) or deep investigation (complex). **Key Principle:** Focus on "what's broken" not "what are we building." --- ## Usage --- ## Adaptive Flow --- ## Interactive Mode ### Step 1: Collect Initial Feedback Prompt the user: > "What feedback do you have about how KARIMO or Claude Code is workin...
/feedbackInteractively collects feedback on successes, corrections, agent issues, workflow problems, or suggestions, then submits to Supabase for learning system.
/review-gladiatorReviews session history observations, clusters patterns, generates workflow recommendations, and suggests changes or existing solutions.
/learnRecords lessons learned from input, errors, sessions, or git history into CLAUDE.md. Supports listing, editing, removing entries and git-based automation suggestions.
/self-improveBootstraps a self-improving agent workspace: scaffolds .learnings/ and memory/, captures errors and learnings, detects patterns, promotes to project memory. Also supports init, log, promote, migrate, status, resume, review, state.
/improveAnalyzes plugin user interactions, performance metrics, usage patterns, and errors to generate structured improvement prompts stored in ./improvements/unified-improvements.json.
/self-reflectExtracts learnings from recent PR reviews, conversations, and session patterns to update the knowledge base.
Share bugs, ideas, or general feedback.
Intelligent feedback capture with automatic complexity detection and adaptive investigation.
Unified command for capturing feedback about KARIMO or Claude Code operation. Auto-detects whether feedback needs quick rule creation (simple) or deep investigation (complex).
Key Principle: Focus on "what's broken" not "what are we building."
/karimo:feedback # Interactive mode with auto-detection
/karimo:feedback --from-metrics {prd-slug} # Batch mode from execution metrics
/karimo:feedback --undo # Remove recent learnings
Initial Feedback
│
▼
Complexity Detection
│
├─► SIMPLE PATH (70% of cases, < 5 min)
│ │
│ ├─ Ask 0-3 clarifying questions (if needed)
│ ├─ Generate rule immediately
│ ├─ Confirm with user
│ └─ Write to .karimo/learnings/{category}/
│
└─► COMPLEX PATH (30% of cases, 10-20 min)
│
├─ Notify: "This needs investigation. Starting adaptive interview..."
│
├─ Adaptive interview (3-7 questions)
│ - Problem Scoping
│ - Evidence
│ - Root Cause
│ - Desired State
│
├─ Spawn @karimo-feedback-auditor for evidence gathering
│
├─ Create feedback document (.karimo/feedback/{slug}.md)
│
└─ Present recommended changes → Apply approved changes
Prompt the user:
"What feedback do you have about how KARIMO or Claude Code is working? Describe what's broken, what's suboptimal, or patterns you want changed."
Accept free-form input. Examples:
Analyze the feedback for signals:
Example: "Never let agents use any types — use proper TypeScript interfaces"
Example: "Tests are failing when we deploy but pass locally — investigate why"
When simple signals detected:
If file/component not specific enough:
"Which file or component? Can you point me to an example?"
If rule scope unclear:
"Should this apply to all components or specific areas?"
If fix ambiguous:
"What should the ideal behavior be?"
Transform feedback into actionable rule:
Input: "Never use inline styles — use Tailwind classes"
Output:
**Anti-pattern:** Never use inline styles. Always use Tailwind utility classes.
Reference existing components for class patterns.
**Context:** Inline styles bypass the design system and make components harder to theme.
**Added:** 2024-03-11
"Creating
.karimo/learnings/anti-patterns/2026-03-12-no-inline-styles.md:# No Inline Styles **Category:** anti-pattern **Severity:** important **Added:** 2026-03-12 **Source:** /karimo:feedback ## Description Never use inline styles. Always use Tailwind utility classes. ## Context Inline styles bypass the design system and make components harder to theme. Reference existing components for class patterns. ## Example ```tsx // Bad <div style={{ marginTop: '8px' }}>...</div> // Good <div className="mt-2">...</div>Correct? [Y/n/edit]"
Create learning file in appropriate category directory:
patterns/ — Approaches that work wellanti-patterns/ — Approaches to avoidproject-notes/ — Project-specific contextexecution-rules/ — Mandatory guidelinesFile naming: {YYYY-MM-DD}-{short-slug}.md
Example:
.karimo/learnings/anti-patterns/2026-03-12-no-inline-styles.md
git add .karimo/learnings/
git commit -m "chore(feedback): add rule - no inline styles
Co-Authored-By: Claude <noreply@anthropic.com>"
"Learning captured. Agents will see this rule on next task."
When complex signals detected:
"This needs investigation. Starting adaptive interview to gather details..."
agent: @karimo-interviewer.md
mode: feedback
model: opus # Recommended for adaptive questioning
protocol: .karimo/templates/FEEDBACK_INTERVIEW_PROTOCOL.md
The interviewer conducts adaptive questioning across 4 categories:
Category 1: Problem Scoping (1-2 questions)
Category 2: Evidence (1-2 questions)
Category 3: Root Cause (1-2 questions)
Category 4: Desired State (1-2 questions)
Stop conditions:
Interviewer produces structured directives:
investigation:
problem: "Tests failing on deploy but passing locally"
slug: "deploy-test-failures"
scope:
- CI/CD workflows
- Test environment configuration
- Deployment scripts
data_sources:
status_json:
- user-profiles
- payment-flow
pr_history:
- "#123"
- "#127"
file_patterns:
- ".github/workflows/*.yml"
- "tests/**/*.test.ts"
config_files:
- ".karimo/config.yaml"
- "package.json"
question_to_answer: "Why do tests pass locally but fail in CI/CD?"
hypothesis: "Environment variable or dependency difference between local and CI"
desired_state: "Tests pass consistently in all environments"
agent: @karimo-feedback-auditor.md
input: investigation directives from interviewer
tools: Read, Grep, Glob, Bash (gh CLI)
time_budget: 5-10 minutes
Auditor investigates and returns:
Generate .karimo/feedback/deploy-test-failures.md using template:
# Feedback: deploy-test-failures
**Type:** tooling
**Status:** investigating → resolved (after changes applied)
**Created:** 2024-03-11
## Problem Statement
Tests pass locally but fail in CI/CD
## Evidence Gathered
{From feedback-auditor}
## Root Cause Analysis
{From feedback-auditor}
## Recommended Changes
{From feedback-auditor}
## Applied Changes
{Tracked after user approval}
## Verification
{Success criteria for future PRDs}
Show user the proposed changes:
"Investigation complete. Found root cause: missing environment variables in GitHub Actions.
Recommended changes:
- Update
.github/workflows/test.yml
- Add DATABASE_URL env var
- Confidence: High
- Add rule to
.karimo/learnings/execution-rules/
- "Always verify test environment parity between local and CI"
- Confidence: High
- Update
.karimo/config.yamlboundaries
- Add
.github/workflows/torequire_review- Confidence: Medium
Apply these changes? [all/1,2/none/edit]"
For each approved change:
git add .karimo/feedback/deploy-test-failures.md .karimo/learnings/ .karimo/config.yaml .github/workflows/test.yml
git commit -m "chore(feedback): fix deploy test failures
Investigation findings:
- Root cause: missing DATABASE_URL in CI
- Added env var to GitHub Actions workflow
- Added rule to verify test environment parity
- Added CI workflows to require_review boundary
See .karimo/feedback/deploy-test-failures.md for full investigation.
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>"
"Feedback captured and changes applied.
Created:
.karimo/feedback/deploy-test-failures.mdUpdated:.karimo/learnings/,.karimo/config.yaml,.github/workflows/test.ymlFuture PRDs will include this fix."
Preserved from previous version with no changes.
/karimo:feedback --from-metrics {prd-slug}
Read metrics.json
METRICS_FILE=".karimo/prds/${prd_slug}/metrics.json"
Extract learning candidates:
Present suggested learnings:
📊 Learnings from: user-profiles
Found 4 learning candidates in metrics.json:
1. [2a] High loops (5)
→ "Profile form validation patterns may be more complex than estimated"
Category: gotcha
2. [2a] Runtime dependency
→ "Always check authentication requirements for API tasks during PRD planning"
Category: rule
3. [3b] Model escalation (Sonnet → Opus)
→ "Tasks involving complex state management should start at complexity 5+"
Category: rule
4. [4a] Hard gate (3 review failures)
→ "Integration tests for external services need mocking patterns"
Category: gotcha
Select learnings to capture: [all/1,2,4/none]
Capture selected learnings:
.karimo/learnings/{category}/ directorieschore(feedback): batch capture from {prd-slug} metricsUser provides: "Three things: agents use inline styles, tests are flaky, and deployment fails"
Response:
I'm seeing three distinct issues:
1. Inline styles (simple)
2. Flaky tests (complex - needs investigation)
3. Deployment failures (complex - needs investigation)
Options:
A) Handle inline styles now (simple path), investigate others separately
B) Pick one complex issue to investigate now
C) Quick rules for all three (if you know the fixes)
What would you prefer?
Starts simple: "Agents should add JSDoc comments" Becomes complex: "...but I'm not sure which functions need it or if there's a pattern"
Response:
This is more complex than I initially thought. I recommend switching to investigation
mode to determine the right pattern by looking at existing code.
Should I start an adaptive interview to gather details?
User: "Something's not working right"
Response:
Can you be more specific? For example:
- Which PRD or task showed the problem?
- What did you expect vs what happened?
- Is this about agent behavior, code quality, or workflow?
Even if you don't know the root cause, specific examples help me investigate.
Preserved from previous version with no changes.
/karimo:feedback --undo
Shows recent learnings and allows removal:
"Recent learnings:
- [2024-03-11] Anti-pattern: Never use inline styles
- [2024-03-10] Rule: Add JSDoc to exported functions
Which would you like to remove?"
Simple Path:
.karimo/learnings/{category}/{date}-{slug}.md (created)Complex Path:
.karimo/feedback/{slug}.md (created).karimo/learnings/{category}/{date}-{slug}.md (created).karimo/config.yaml (if boundaries updated).claude/KARIMO_RULES.md (if rules updated)Batch Mode:
.karimo/learnings/{category}/{date}-{slug}.md (created).karimo/prds/{prd-slug}/metrics.json (updated with captured flag)Simple path: Direct rule generation (no protocol)
Complex path: .karimo/templates/FEEDBACK_INTERVIEW_PROTOCOL.md
Feedback auditor: .claude/agents/karimo/feedback-auditor.md
Feedback document template: .karimo/templates/FEEDBACK_DOCUMENT_TEMPLATE.md
Simple path complete when:
.karimo/learnings/{category}/Complex path complete when:
Batch mode complete when:
.karimo/learnings/{category}/This unified command replaces the legacy /karimo-learn workflow. All learning capture now flows through /karimo:feedback with intelligent complexity detection.