菜单
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.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/edwinhu/workflows --skill pattern-capture命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
Use for feature development and engineering changes.
This skill should be used when the user asks to 'start data analysis', 'plan a data project', 'explore this dataset', 'what should I analyze', 'set up a new study', or needs the data-science workflow.
Use when the user asks to 'run a work workflow', 'do this properly', 'clarify, plan, and verify this', 'small structured task', or 'don't just wing it' for a bounded task too small for a specialized workflow.
正在显示 SKILL.md
| name | pattern-capture |
| description | 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 |
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.
Users give the same corrections repeatedly:
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.
user_corrections patternsCollect 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
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.
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 | 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/ |
Based on classification, generate the appropriate artifact:
---
name: feedback_<descriptive-slug>
description: <one-line description specific enough to match in future>
type: feedback
---
<The rule, stated clearly>
**Context:** <Why this matters — what went wrong when it was violated>
**Source:** <How this was discovered — "corrected N times" or "user reported">
Write to memory directory and update MEMORY.md index.
Identify which skill the pattern belongs to, then add the appropriate enforcement element:
Iron Law (for high-drift actions the agent rationalizes skipping):
<EXTREMELY-IMPORTANT>
**[RULE IN ALL CAPS]. This is not negotiable.**
[One sentence explaining concrete user harm if violated.]
</EXTREMELY-IMPORTANT>
Fact Row entry (for incident-learned knowledge the agent overrode or lacked — supersedes Rationalization Table entries, v5.36.0):
- <Non-derivable fact from the observed incident — number / threshold / tool quirk / mechanic>.
<Consequence of ignoring it, as a property of the action: counterproductive / unhelpful / dishonest / incompetent.>
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 <observable behavior>** → STOP. <concrete harm — one line>.
Generate a PreToolUse or PostToolUse hook:
// hooks/<hook-name>.ts
// Pattern: <description of what this catches>
// Source: User corrected this N times across sessions
export default {
event: "PreToolUse", // or PostToolUse
name: "<tool-name>", // e.g., "Bash", "Write", "Edit"
async handler({ input }) {
// Detection logic
const violation = /* check for the anti-pattern */;
if (violation) {
return {
decision: "block", // or "ask"
reason: "<explanation of why this is blocked>"
};
}
return { decision: "approve" };
}
};
Delegate to skill-creator:
Skill(skill="skill-creator", args="Create skill from captured pattern: <description>")
Provide the skill-creator with:
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 |
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>
When invoked without a specific pattern (e.g., "find repeated feedback"), scan all available sources:
"no,? (don't|stop|not|never|instead|again)""I (already|just) (told|said|asked|mentioned)""(wrong|incorrect|that's not|not what I)"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.
| 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 |
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.
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 |
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.
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.
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-guide.md — fast-path matrix and enforcement strength ladderreferences/artifact-templates.md — copy-paste templates for all artifact types with formatting guidancereferences/enforcement-checklist.md — full 12-pattern reference (when adding enforcement to existing skills)../continuous-learning/SKILL.md — upstream pattern detection (feeds into this skill)../skill-creator/SKILL.md — downstream skill generation (this skill delegates to it for learned skills)