📦 deps(thirdparty): update snapshots
This commit is contained in:
@@ -0,0 +1,150 @@
|
||||
---
|
||||
name: patterns
|
||||
description: This skill should be used when recognizing recurring themes, identifying patterns in work or data, or when "pattern", "recurring", or "repeated" are mentioned. For implementation, see codify skill.
|
||||
metadata:
|
||||
version: "1.1.0"
|
||||
related-skills:
|
||||
- codify
|
||||
- codebase-recon
|
||||
- report-findings
|
||||
---
|
||||
|
||||
# Pattern Identification
|
||||
|
||||
Observe signals → classify patterns → validate with evidence → document findings.
|
||||
|
||||
## Steps
|
||||
|
||||
1. Collect signals from conversation, code, or data
|
||||
2. Classify pattern type (workflow, orchestration, heuristic, anti-pattern)
|
||||
3. Validate against evidence threshold (3+ instances, multiple contexts)
|
||||
4. Document pattern with constraints and examples
|
||||
5. If implementation needed, delegate by loading the `outfitter:codify` skill
|
||||
|
||||
<when_to_use>
|
||||
|
||||
- Recognizing recurring themes in work or data
|
||||
- Codifying best practices from experience
|
||||
- Extracting workflows from repeated success
|
||||
- Identifying anti-patterns from repeated failures
|
||||
- Building decision frameworks from observations
|
||||
|
||||
NOT for: single occurrences, unvalidated hunches, premature abstraction
|
||||
|
||||
</when_to_use>
|
||||
|
||||
<signal_identification>
|
||||
|
||||
Watch for these signal categories:
|
||||
|
||||
| Category | Watch For | Indicates |
|
||||
|----------|-----------|-----------|
|
||||
| **Success** | Completion, positive feedback, repetition, efficiency | Pattern worth codifying |
|
||||
| **Frustration** | Backtracking, clarification loops, rework, confusion | Anti-pattern to document |
|
||||
| **Workflow** | Sequence consistency, decision points, quality gates | Process pattern |
|
||||
| **Orchestration** | Multi-component coordination, state management, routing | Coordination pattern |
|
||||
|
||||
See [signal-types.md](references/signal-types.md) for detailed taxonomy.
|
||||
|
||||
</signal_identification>
|
||||
|
||||
<pattern_classification>
|
||||
|
||||
Four primary pattern types:
|
||||
|
||||
| Type | Characteristics | Use When |
|
||||
|------|-----------------|----------|
|
||||
| **Workflow** | Sequential stages, clear transitions, quality gates | Process has ordered steps |
|
||||
| **Orchestration** | Coordinates components, manages state, routes work | Multiple actors involved |
|
||||
| **Heuristic** | Condition → action mapping, context-sensitive | Repeated decisions |
|
||||
| **Anti-Pattern** | Common mistake, causes rework, has better alternative | Preventing failures |
|
||||
|
||||
See [pattern-types.md](references/pattern-types.md) for templates and examples.
|
||||
|
||||
</pattern_classification>
|
||||
|
||||
<evidence_thresholds>
|
||||
|
||||
## Codification Criteria
|
||||
|
||||
Don't codify after first occurrence. Require:
|
||||
- **3+ instances** — minimum repetition to establish pattern
|
||||
- **Multiple contexts** — works across different scenarios
|
||||
- **Clear boundaries** — know when to apply vs not apply
|
||||
- **Measurable benefit** — improves outcome compared to ad-hoc approach
|
||||
|
||||
## Quality Indicators
|
||||
|
||||
| Strong Pattern | Weak Pattern |
|
||||
|----------------|--------------|
|
||||
| Consistent structure | Varies each use |
|
||||
| Transferable to others | Requires specific expertise |
|
||||
| Handles edge cases | Breaks on deviation |
|
||||
| Saves time/effort | Overhead exceeds value |
|
||||
|
||||
</evidence_thresholds>
|
||||
|
||||
<progressive_formalization>
|
||||
|
||||
**Observation** (1-2 instances):
|
||||
- Note for future reference
|
||||
- "This worked well, watch for recurrence"
|
||||
|
||||
**Hypothesis** (3+ instances):
|
||||
- Draft informal guideline
|
||||
- Test consciously in next case
|
||||
|
||||
**Codification** (validated pattern):
|
||||
- Create formal documentation
|
||||
- Include examples and constraints
|
||||
|
||||
**Refinement** (ongoing):
|
||||
- Update based on usage
|
||||
- Add edge cases
|
||||
|
||||
</progressive_formalization>
|
||||
|
||||
<workflow>
|
||||
|
||||
Loop: Observe → Classify → Validate → Document
|
||||
|
||||
1. **Collect signals** — note successes, failures, recurring behaviors
|
||||
2. **Classify pattern type** — workflow, orchestration, heuristic, anti-pattern
|
||||
3. **Check evidence threshold** — 3+ instances? Multiple contexts?
|
||||
4. **Extract quality criteria** — what makes it work?
|
||||
5. **Document pattern** — name, when, what, why
|
||||
6. **Test deliberately** — apply consciously, track variance
|
||||
7. **Refine** — adjust based on feedback
|
||||
|
||||
</workflow>
|
||||
|
||||
<rules>
|
||||
|
||||
ALWAYS:
|
||||
- Require 3+ instances before codifying
|
||||
- Validate across multiple contexts
|
||||
- Document both when to use AND when not to
|
||||
- Include concrete examples
|
||||
- Track pattern effectiveness over time
|
||||
|
||||
NEVER:
|
||||
- Codify after single occurrence
|
||||
- Abstract without evidence
|
||||
- Ignore context-sensitivity
|
||||
- Skip validation step
|
||||
- Assume transferability without testing
|
||||
|
||||
</rules>
|
||||
|
||||
<references>
|
||||
|
||||
- [signal-types.md](references/signal-types.md) — detailed signal taxonomy
|
||||
- [pattern-types.md](references/pattern-types.md) — pattern templates and examples
|
||||
|
||||
**Identification vs Implementation**:
|
||||
- This skill (`patterns`) identifies and documents patterns
|
||||
- `codify` skill implements patterns as Claude Code components (skills, commands, hooks, agents)
|
||||
|
||||
Use `patterns` to answer "what patterns exist?" Use `codify` to answer "how do I turn this into a reusable component?"
|
||||
|
||||
</references>
|
||||
@@ -0,0 +1,188 @@
|
||||
# Pattern Types
|
||||
|
||||
Classification system for different types of reusable patterns.
|
||||
|
||||
## Workflow Pattern
|
||||
|
||||
Sequential process with defined stages.
|
||||
|
||||
**Characteristics**:
|
||||
- Sequential stages with clear transitions
|
||||
- Decision points triggering next steps
|
||||
- Quality gates or validation checkpoints
|
||||
- Repeatable across similar contexts
|
||||
|
||||
**Example structure**:
|
||||
|
||||
```
|
||||
Stage 1 → Validation → Stage 2 → Validation → Stage 3 → Complete
|
||||
```
|
||||
|
||||
**When to codify as workflow**:
|
||||
- Steps always occur in same order
|
||||
- Each stage has clear entry/exit criteria
|
||||
- Others can follow the sequence
|
||||
- Consistent outcomes when followed
|
||||
|
||||
**Template**:
|
||||
|
||||
```markdown
|
||||
# Workflow: {Name}
|
||||
|
||||
## Stages
|
||||
1. {Stage} — {purpose}, exit when {condition}
|
||||
2. {Stage} — {purpose}, exit when {condition}
|
||||
3. {Stage} — {purpose}, exit when {condition}
|
||||
|
||||
## Quality Gates
|
||||
- Before Stage 2: {validation}
|
||||
- Before Stage 3: {validation}
|
||||
|
||||
## Exit Criteria
|
||||
{how to know workflow is complete}
|
||||
```
|
||||
|
||||
## Orchestration Pattern
|
||||
|
||||
Coordinates multiple components or actors.
|
||||
|
||||
**Characteristics**:
|
||||
- Coordinates multiple components or actors
|
||||
- Manages state across sub-tasks
|
||||
- Routes work based on conditions
|
||||
- Aggregates results
|
||||
|
||||
**Example structure**:
|
||||
|
||||
```
|
||||
Input → Router → [Component A, Component B, Component C] → Aggregator → Output
|
||||
```
|
||||
|
||||
**When to codify as orchestration**:
|
||||
- Multiple independent actors
|
||||
- Complex routing logic
|
||||
- State needs tracking across components
|
||||
- Results need aggregation
|
||||
|
||||
**Template**:
|
||||
|
||||
```markdown
|
||||
# Orchestration: {Name}
|
||||
|
||||
## Components
|
||||
- {Component A} — {responsibility}
|
||||
- {Component B} — {responsibility}
|
||||
|
||||
## Routing
|
||||
- When {condition} → route to {component}
|
||||
- When {condition} → route to {component}
|
||||
|
||||
## State Management
|
||||
{how state is tracked across components}
|
||||
|
||||
## Aggregation
|
||||
{how results are combined}
|
||||
```
|
||||
|
||||
## Heuristic Pattern
|
||||
|
||||
Decision-making guideline or rule of thumb.
|
||||
|
||||
**Characteristics**:
|
||||
- Decision-making guideline
|
||||
- Condition → action mapping
|
||||
- Context-sensitive application
|
||||
- Often has exceptions
|
||||
|
||||
**Example structure**:
|
||||
|
||||
```
|
||||
If {condition}, then {action}
|
||||
Unless {exception}, in which case {alternative}
|
||||
```
|
||||
|
||||
**When to codify as heuristic**:
|
||||
- Repeated decision point
|
||||
- Clear trigger condition
|
||||
- Consistent recommended action
|
||||
- Known exceptions
|
||||
|
||||
**Template**:
|
||||
|
||||
```markdown
|
||||
# Heuristic: {Name}
|
||||
|
||||
## Rule
|
||||
When {condition}, {action}.
|
||||
|
||||
## Rationale
|
||||
{why this rule works}
|
||||
|
||||
## Exceptions
|
||||
- When {exception}: {alternative action}
|
||||
|
||||
## Examples
|
||||
- {Situation}: Applied heuristic, {outcome}
|
||||
```
|
||||
|
||||
## Anti-Pattern
|
||||
|
||||
Common mistake that leads to problems.
|
||||
|
||||
**Characteristics**:
|
||||
- Common mistake leading to rework
|
||||
- Inefficiency despite seeming reasonable
|
||||
- Causes specific failure modes
|
||||
- Has better alternative
|
||||
|
||||
**Example structure**:
|
||||
|
||||
```
|
||||
Appears reasonable → Causes {problem} → Better approach: {alternative}
|
||||
```
|
||||
|
||||
**When to codify as anti-pattern**:
|
||||
- Seen same mistake 3+ times
|
||||
- Clear negative consequence
|
||||
- Better alternative exists
|
||||
- Others might make same mistake
|
||||
|
||||
**Template**:
|
||||
|
||||
```markdown
|
||||
# Anti-Pattern: {Name}
|
||||
|
||||
## The Pattern
|
||||
{what people commonly do}
|
||||
|
||||
## Why It Seems Right
|
||||
{why this approach is tempting}
|
||||
|
||||
## What Goes Wrong
|
||||
{negative consequences}
|
||||
|
||||
## Better Approach
|
||||
{recommended alternative}
|
||||
|
||||
## How to Recognize
|
||||
{warning signs you're falling into this}
|
||||
```
|
||||
|
||||
## Pattern Selection Matrix
|
||||
|
||||
| Pattern Type | Key Indicator | Use When |
|
||||
|--------------|---------------|----------|
|
||||
| Workflow | Sequential steps | Process has clear stages |
|
||||
| Orchestration | Multiple actors | Coordination needed |
|
||||
| Heuristic | Decision point | Repeated judgment calls |
|
||||
| Anti-Pattern | Repeated failure | Want to prevent mistakes |
|
||||
|
||||
## Hybrid Patterns
|
||||
|
||||
Some patterns combine types:
|
||||
|
||||
- **Workflow + Heuristics**: Process with embedded decision rules
|
||||
- **Orchestration + Workflow**: Coordinated multi-stage process
|
||||
- **Heuristic + Anti-Pattern**: "Do X, avoid Y" guidance
|
||||
|
||||
Choose primary classification based on dominant characteristic.
|
||||
@@ -0,0 +1,86 @@
|
||||
# Signal Types for Pattern Recognition
|
||||
|
||||
Detailed taxonomy of signals to watch for when identifying patterns.
|
||||
|
||||
## Success Signals
|
||||
|
||||
Indicators that a pattern is working well:
|
||||
|
||||
| Signal | What to Look For | Evidence |
|
||||
|--------|------------------|----------|
|
||||
| **Completion markers** | Task finished smoothly, no backtracking | Clean execution, no rework |
|
||||
| **Positive feedback** | Confirmation of value or effectiveness | User satisfaction, explicit praise |
|
||||
| **Repetition** | Same approach used 3+ times | Consistent application across contexts |
|
||||
| **Efficiency** | Solved problem faster/cleaner | Time savings, reduced complexity |
|
||||
|
||||
### Recognizing Success
|
||||
|
||||
- Task completes without pivots
|
||||
- Solution reused without modification
|
||||
- Positive outcomes compound over time
|
||||
- Others adopt the approach
|
||||
|
||||
## Frustration Signals
|
||||
|
||||
Indicators of anti-patterns or problematic approaches:
|
||||
|
||||
| Signal | What to Look For | Evidence |
|
||||
|--------|------------------|----------|
|
||||
| **Backtracking** | Undoing previous work | Multiple reverts, starting over |
|
||||
| **Clarification loops** | Multiple rounds to understand | Repeated questions, misalignment |
|
||||
| **Rework** | Implementing then replacing | Wasted effort, duplicated work |
|
||||
| **Confusion markers** | Misalignment between expectation and outcome | Surprise, disappointment |
|
||||
|
||||
### Recognizing Frustration
|
||||
|
||||
- Repeated failed attempts at same approach
|
||||
- Escalating complexity without progress
|
||||
- Tension between expectation and result
|
||||
- Time spent exceeds value delivered
|
||||
|
||||
## Workflow Signals
|
||||
|
||||
Indicators of procedural patterns:
|
||||
|
||||
| Signal | What to Look For | Evidence |
|
||||
|--------|------------------|----------|
|
||||
| **Sequence consistency** | Same steps in same order | Repeatable process |
|
||||
| **Decision points** | Recurring choices at specific moments | Branch logic, conditionals |
|
||||
| **Quality gates** | Checkpoints before proceeding | Validation steps, reviews |
|
||||
| **Exit conditions** | How completion is determined | Clear done criteria |
|
||||
|
||||
### Recognizing Workflow Patterns
|
||||
|
||||
- Steps always occur in same sequence
|
||||
- Specific conditions trigger specific actions
|
||||
- Consistent validation before advancement
|
||||
- Clear definition of "done"
|
||||
|
||||
## Orchestration Signals
|
||||
|
||||
Indicators of coordination patterns:
|
||||
|
||||
| Signal | What to Look For | Evidence |
|
||||
|--------|------------------|----------|
|
||||
| **Multi-component coordination** | Multiple parts working together | Integration points |
|
||||
| **State management** | Tracking across sub-tasks | Shared context, handoffs |
|
||||
| **Routing logic** | Work directed based on conditions | Conditional branching |
|
||||
| **Aggregation** | Results combined from sources | Merge points, synthesis |
|
||||
|
||||
## Signal Quality Assessment
|
||||
|
||||
Not all signals are equal. Assess:
|
||||
|
||||
**Strong signals**:
|
||||
- Repeated observation (3+ times)
|
||||
- Clear cause-effect relationship
|
||||
- Consistent across contexts
|
||||
- Objectively measurable
|
||||
|
||||
**Weak signals**:
|
||||
- Single occurrence
|
||||
- Correlation without causation
|
||||
- Context-dependent
|
||||
- Subjective interpretation
|
||||
|
||||
Require strong signals before codifying patterns.
|
||||
Reference in New Issue
Block a user