openclaw-backups/archive/inactive-skills/reflect-learn/data/signal_patterns.md

Signal Detection Patterns

Comprehensive reference for detecting correction signals and learning opportunities in conversations.

Confidence Levels

HIGH Confidence (Explicit Corrections)

These patterns indicate the user is explicitly stating a rule or correction. Always apply these learnings.

Negative Directives

Pattern	Type	Example
never	correction	"Never use var in TypeScript"
don't / do not	correction	"Don't commit directly to main"
stop doing	correction	"Stop doing manual deployments"
wrong	correction	"That's wrong, use snake_case"
not like that	correction	"Not like that, indent with tabs"
incorrect	correction	"That's incorrect syntax"
should not / shouldn't	prohibition	"You shouldn't use eval()"
must not / mustn't	prohibition	"Must not expose secrets"

Regex Pattern:

\b(never|don't|do not|stop doing|wrong|not like that|incorrect|should not|shouldn't|must not|mustn't)\b

Positive Directives

Pattern	Type	Example
always	requirement	"Always validate inputs"
must	requirement	"You must use parameterized queries"
required	requirement	"It's required to have tests"
the rule is	explicit_rule	"The rule is no console.log in prod"
correct way	explicit_rule	"The correct way is to use hooks"

Regex Pattern:

\b(always|must|required|the rule is|correct way)\b

Frustration Markers

These indicate repeated corrections - highest priority learnings.

Pattern	Type	Example
I already told you	frustration	"I already told you about this"
again?	frustration	"Wrong again?"
not again	frustration	"Oh not again"
how many times	frustration	"How many times do I need to say..."

Regex Pattern:

(I already told you|again\?|not again|how many times)

Explicit Rules

Pattern	Type	Example
the rule is	explicit_rule	"The rule is we use ESLint"
you should know	explicit_rule	"You should know we use Prettier"
remember that	explicit_rule	"Remember that we're on Node 20"
don't forget	explicit_rule	"Don't forget the error handling"

Regex Pattern:

(the rule is|you should know|remember that|don't forget)

MEDIUM Confidence (Approved Approaches)

These patterns indicate the user approved a specific approach. Apply with reasonable confidence.

Approval Markers

Pattern	Type	Example
perfect	approval	"Perfect, that's what I wanted"
exactly	approval	"Exactly right"
that's right	approval	"That's right, keep it"
yes, like that	approval	"Yes, like that"
correct	approval	"Correct implementation"

Regex Pattern:

\b(perfect|exactly|that's right|yes, like that|correct)\b

Positive Feedback

Pattern	Type	Example
good	positive_feedback	"Good approach"
great job	positive_feedback	"Great job on the refactor"
well done	positive_feedback	"Well done with the tests"
nice	positive_feedback	"Nice solution"
excellent	positive_feedback	"Excellent work"

Regex Pattern:

\b(good|great job|well done|nice|excellent)\b

Continuation Markers

Pattern	Type	Example
keep doing	continuation	"Keep doing it this way"
continue with	continuation	"Continue with this approach"
stick with	continuation	"Stick with React hooks"

Regex Pattern:

\b(keep doing|continue with|stick with)\b

LOW Confidence (Observations)

These patterns suggest preferences but require validation before encoding as rules.

Suggestions

Pattern	Type	Example
maybe	suggestion	"Maybe try TypeScript"
perhaps	suggestion	"Perhaps use a different library"
might want to	suggestion	"You might want to add caching"
consider	suggestion	"Consider using memoization"

Regex Pattern:

\b(maybe|perhaps|might want to|consider)\b

Observations

Pattern	Type	Example
seems like	observation	"Seems like this works"
appears to	observation	"Appears to be faster"
looks like	observation	"Looks like a good pattern"

Regex Pattern:

\b(seems like|appears to|looks like)\b

Category Detection

Code Style

Patterns indicating code style preferences:

\b(naming|convention|style|format|indent|case|camelCase|snake_case|PascalCase)\b
\b(variable|function|class|method|parameter)\s+name
\b(semicolon|quote|single quote|double quote|tabs|spaces)\b

Examples:

• "Use snake_case for Python variables"
• "We prefer single quotes for strings"
• "Indent with 2 spaces, not tabs"

Architecture

Patterns indicating architectural decisions:

\b(pattern|architecture|design|structure|module|component|service)\b
\b(separation|coupling|cohesion|dependency|layer|abstraction)\b
\b(microservice|monolith|serverless|event-driven)\b

Examples:

• "Use dependency injection for services"
• "Keep components loosely coupled"
• "Follow the repository pattern"

Process

Patterns indicating workflow preferences:

\b(workflow|process|step|procedure|protocol|practice)\b
\b(commit|branch|merge|review|deploy|test|ci|cd)\b
\b(pr|pull request|code review|approval)\b

Examples:

• "Always run tests before commit"
• "Use conventional commits"
• "Squash commits on merge"

Domain

Patterns indicating business logic:

\b(business|domain|logic|rule|requirement|constraint)\b
\b(customer|user|client|account|order|payment|invoice)\b
\b(validate|verify|check|ensure|confirm)\b

Examples:

• "Orders must be validated before processing"
• "Users need email verification"
• "Payments require two-factor auth"

Tools

Patterns indicating tool preferences:

\b(tool|cli|command|terminal|shell|editor|ide)\b
\b(git|npm|yarn|pnpm|docker|kubernetes)\b
\b(config|setting|environment|variable|env)\b

Examples:

• "Use pnpm instead of npm"
• "Configure ESLint with these rules"
• "Run Docker in production"

New Skill

Patterns indicating skill-worthy discoveries:

\b(workaround|trick|hack|solution|fix|debug|resolve)\b
\b(error|bug|issue|problem)\s+(was|is|fixed|solved|resolved)\b
(took|spent)\s+\d+\s*(min|minute|hour|day)
\b(finally|after trying|turns out|the issue was)\b

Examples:

• "The workaround is to clear the cache first"
• "After 2 hours debugging, found the issue was..."
• "Turns out the error message was misleading"

Edge Cases

False Positives to Avoid

Some patterns may match but don't indicate learnings:

• Rhetorical questions: "Why would you never do X?" (not a directive)
• Hypotheticals: "If you never use Y, then..." (conditional)
• Quotes/references: "The docs say never..." (not user's directive)
• Negations: "It's not wrong to..." (opposite meaning)

Context Sensitivity

Consider surrounding context:

• "That's not wrong" - NOT a correction
• "That's not right" - IS a correction
• "Never mind" - NOT a directive about future behavior
• "Always" in a loop - NOT a behavioral directive

Combining Patterns

When multiple patterns match:

1. Use the highest confidence pattern
2. If equal confidence, use the most specific category
3. Prefer explicit rules over implied preferences
4. Prioritize frustration markers (indicate repeated issue)

Implementation Notes

The signal_detector.py script implements these patterns. To update patterns:

1. Add pattern to appropriate *_PATTERNS list
2. Run python signal_detector.py --test to verify
3. Add test case for new pattern
4. Update this documentation