📦 deps(thirdparty): update snapshots

This commit is contained in:
ci[bot]
2026-05-29 08:33:53 +00:00
parent fdb52f1e96
commit 06e0d13d57
1615 changed files with 232858 additions and 0 deletions
@@ -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.