This skill should be used when the user asks to 'find repeated feedback', 'what do I keep correcting', 'capture this pattern', 'DRY my prompting', 'stop repeating myself', 'turn this into a check', 'automate this correction', or when the same type of feedback has been given 3+ times across sessions.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
A direct command skips the review prompt. Inspect the source before running it.
This skill should be used when the user asks to 'find repeated feedback', 'what do I keep correcting', 'capture this pattern', 'DRY my prompting', 'stop repeating myself', 'turn this into a check', 'automate this correction', or when the same type of feedback has been given 3+ times across sessions.
user-invocable
false
Pattern Capture
Detect repetitive feedback across sessions and convert it into the right enforcement artifact โ a memory entry, a validation hook, an enforcement pattern, or a standalone skill.
The Problem This Solves
Users give the same corrections repeatedly:
"Don't mock the database in tests" (session 1, 3, 7, 12)
"Use jq explicit syntax, not shorthand" (session 2, 5, 8)
"Check the build before claiming it works" (session 1, 4, 6, 9, 11)
Each correction costs the user time and erodes trust. The DRY principle applies to prompting: if you've said it twice, it should be automated.
When to Use
User says "I keep telling you..." or "Again, don't..."
You notice you're receiving the same type of correction
At end of session, to audit what feedback was given
Proactively, when continuous-learning detects user_corrections patterns
User explicitly asks to capture a pattern or DRY their prompting
Process
Step 1: Gather Evidence
Collect instances of the repeated pattern. Sources (check in order):
1. Memory files (fastest)
โ Grep pattern="<keyword>" path="<memory_dir>" glob="*.md"
โ Look for feedback-type memories
2. Session transcripts (if CLAUDE_TRANSCRIPT_PATH is set)
โ Grep for user corrections: "no", "don't", "stop", "again", "I said"
โ Count occurrences of similar corrections
3. Spotless archives (if available, cross-session)
โ Search conversation history for repeated correction patterns
4. User report (always valid)
โ User says "I keep having to tell you X" = sufficient evidence
**NEVER GENERATE AN ARTIFACT WITHOUT EVIDENCE. This is not negotiable.**
**NEVER ADD ENFORCEMENT TO A SKILL WITHOUT READING THE FULL SKILL FIRST. This is not negotiable.**
Minimum evidence threshold: 2 independent instances (same correction, different contexts). A single user report of "I keep telling you" counts as meeting threshold โ trust the user's observation.
Step 2: Classify the Pattern
Every repeated pattern maps to exactly ONE artifact type. Use this decision tree. Evaluate branches top-to-bottom; stop at the FIRST match.
Is the pattern about WHEN to do something?
YES โ Is it about tool/command selection?
YES โ MEMORY (feedback type)
NO โ Is it about workflow sequencing?
YES โ ENFORCEMENT PATTERN (add to existing workflow skill)
NO โ MEMORY (feedback type)
NO โ
Is the pattern about HOW to do something?
YES โ Is it a single rule (< 3 sentences)?
YES โ Is it project-specific?
YES โ MEMORY (project type)
NO โ MEMORY (feedback type)
NO โ Does it require multi-step verification?
YES โ VALIDATION HOOK
NO โ Is it reusable across projects?
YES โ SKILL (learned skill)
NO โ MEMORY (feedback type)
NO โ
Is the pattern about WHAT NOT to do?
YES โ Can the violation be detected programmatically?
YES โ VALIDATION HOOK
NO โ RED FLAG (add to existing skill's Red Flags table)
NO โ
Default โ MEMORY (feedback type)
Artifact Type Reference
Artifact
When
Example
Where It Lives
Memory (feedback)
Simple behavioral rule
"Don't add trailing summaries"
<memory_dir>/feedback_*.md
Memory (project)
Project-specific convention
"jq 1.6 in container, use explicit syntax"
<memory_dir>/project_*.md
Enforcement pattern
Workflow drift prevention
"Must run build before claiming completion"
Added to existing SKILL.md
Validation hook
Programmatically checkable
"No mocks in integration tests"
PreToolUse/PostToolUse hook
Red Flag entry
Anti-pattern with observable trigger
"About to use git add ."
Added to existing skill's table
Learned skill
Multi-step reusable procedure
"Debug pixi environment issues"
~/.claude/skills/learned/
Step 3: Generate the Artifact
Based on classification, generate the appropriate artifact:
Litmus before adding: could a strong model derive this from the rule itself? If yes, strengthen the rule statement instead of adding a row.
Red Flag entry (for observable wrong actions โ action-targeted, never "if you catch yourself thinking"):
-**About to <observablebehavior>** โ STOP. <concreteharm โ oneline>.
For VALIDATION HOOKS
Generate a PreToolUse or PostToolUse hook:
// hooks/<hook-name>.ts// Pattern: <description of what this catches>// Source: User corrected this N times across sessionsexportdefault {
event: "PreToolUse", // or PostToolUsename: "<tool-name>", // e.g., "Bash", "Write", "Edit"asynchandler({ input }) {
// Detection logicconst violation = /* check for the anti-pattern */;
if (violation) {
return {
decision: "block", // or "ask"reason: "<explanation of why this is blocked>"
};
}
return { decision: "approve" };
}
};
For LEARNED SKILLS
Delegate to skill-creator:
Skill(skill="skill-creator", args="Create skill from captured pattern: <description>")
Provide the skill-creator with:
Pattern description and evidence
Example correct/incorrect behaviors
Suggested enforcement level (from classification)
Step 4: Verify Integration
After generating the artifact, verify it's properly integrated:
Artifact Type
Verification
Memory
Grep for the memory file, verify MEMORY.md updated
Enforcement pattern
Read the modified SKILL.md, verify pattern appears in correct section
Validation hook
Syntax check the hook file, verify it's in the right hooks directory
Red Flag entry
Read the modified skill, verify table is well-formed
Learned skill
Verify SKILL.md exists with frontmatter, description is trigger-only
Step 5: Report
Output a summary:
## Pattern Captured
**Pattern:** <one-line description>
**Evidence:** <N instances across M sessions>
**Classification:** <artifact type>
**Artifact:** <file path or location>
**Prevention:** <how this prevents future repetition>
Proactive Detection
When invoked without a specific pattern (e.g., "find repeated feedback"), scan all available sources:
Read all feedback-type memory files
Search session transcripts for correction language:
"no,? (don't|stop|not|never|instead|again)"
"I (already|just) (told|said|asked|mentioned)"
"(wrong|incorrect|that's not|not what I)"
Group similar corrections by semantic similarity
For each group with 2+ instances, run the classification tree
Present findings to user for confirmation before generating artifacts
Iron Laws
Fabricating patterns the user hasn't actually repeated leads to over-engineered enforcement that constrains legitimate behavior. Every artifact must trace to specific observed instances.
Adding a Red Flag or Iron Law without understanding the skill's existing enforcement creates conflicts, duplicates, and confusion. Read the entire SKILL.md before modifying it.
Red Flags
About to create a skill for a one-sentence rule โ STOP. Over-engineering; a memory entry suffices โ use the classification tree.
About to add enforcement without observed violations โ STOP. Speculative enforcement constrains legitimate work and devalues existing Iron Laws; wait for 2+ real instances.
About to modify a skill without reading it in full โ STOP. That creates conflicts with existing patterns; read the full SKILL.md first.
About to create a validation hook for a subjective rule โ STOP. Hooks need programmatic detection โ "code quality" isn't checkable; use a Red Flag or memory instead.
About to skip user confirmation for proactively detected patterns โ STOP. The classification may be wrong or unwanted; always present findings before generating.
Pattern Capture Facts
A captured pattern goes to the ONE most relevant skill โ shotgun-adding it to every plausible skill creates maintenance burden and contradictions, the opposite of the de-duplication this skill exists for.
Integration Points
System
How Pattern-Capture Integrates
continuous-learning
Consumes user_corrections patterns as input; pattern-capture classifies and routes them
skill-creator
Delegates learned skill generation; provides evidence and enforcement level
workflow-creator
Informational โ when adding enforcement to a workflow skill, consult workflow-creator's audit mode to verify the addition fits the workflow's phase structure
Memory system
Primary output target โ most patterns become feedback memories
Hook system
Secondary output โ programmatically detectable anti-patterns become hooks
Examples
Example 1: Simple Behavioral Rule โ Memory
Evidence: User said "stop summarizing at the end" in 3 sessions
Classification: WHEN to do something โ tool selection? No โ workflow? No โ MEMORY (feedback)
Artifact:
---
name: feedback_no_trailing_summaries
description: Do not add summary paragraphs after completing a task โ user reads diffs directly
type: feedback
---
Do not summarize what you just did at the end of responses. The user reads diffs and tool output directly.
**Context:** Trailing summaries waste time and feel patronizing to experienced users.
**Source:** Corrected 3 times across sessions.
Example 2: Build Verification โ Enforcement Pattern
Evidence: Agent claimed "build passes" without running build in 4 sessions
Classification: HOW โ multi-step verification? Yes โ but dev-accept already handles this โ ENFORCEMENT PATTERN
Artifact: Add to dev-accept's Red Flags table:
| "Build should still pass from earlier" | Earlier results are stale โ any code change invalidates them | Run `npm run build` fresh RIGHT NOW |
Example 3: No Mocks in Integration Tests โ Validation Hook
Evidence: Agent used jest.mock() in integration test files 3 times
Classification: WHAT NOT TO DO โ programmatically detectable? Yes (grep for jest.mock in tests/integration/) โ VALIDATION HOOK
Artifact: PostToolUse hook on Write/Edit that warns when jest.mock appears in integration test files.
Example 4: Project-Specific Convention โ Project Memory
Evidence: User corrected jq syntax 3 times โ container uses jq 1.6, not 1.7
Classification: HOW โ single rule โ project-specific โ MEMORY (project)
Artifact:
---
name: project_jq_16_explicit_syntax
description: NanoClaw container runs jq 1.6 which requires explicit field syntax, not shorthand
type: project
---
Container runs jq 1.6. Always use explicit syntax: `{title: .title}` not `{title, location: expr}`.
**Applies to:** NanoClaw container agent, any jq commands in container scripts.
**Context:** jq 1.6 does not support mixing shorthand + explicit fields. Causes silent failures.
**Source:** Corrected 3 times across sessions.
Example 5: Complex Debugging Procedure โ Learned Skill
Evidence: User walked through the same pixi debugging steps in 3 sessions
Classification: HOW โ single rule? No (5+ steps) โ multi-step verification? No โ reusable? Yes โ SKILL
Artifact: Delegate to skill-creator with the debugging steps as input.
References
Classification quick reference:references/classification-guide.md โ fast-path matrix and enforcement strength ladder
Artifact templates:references/artifact-templates.md โ copy-paste templates for all artifact types with formatting guidance
Enforcement checklist:references/enforcement-checklist.md โ full 12-pattern reference (when adding enforcement to existing skills)
Continuous-learning:../continuous-learning/SKILL.md โ upstream pattern detection (feeds into this skill)
Skill-creator:../skill-creator/SKILL.md โ downstream skill generation (this skill delegates to it for learned skills)
