Why Use This This skill provides specialized capabilities for MadAppGang's codebase.
Use Cases Developing new features in the MadAppGang repository Refactoring existing code to follow MadAppGang standards Understanding and working with MadAppGang's codebase structure
Install Guide 2 steps 1 2 Install inside Ananke
Click Install Skill, paste the link below, then press Install.
https://github.com/MadAppGang/claude-code/tree/main/plugins/agentdev/skills/patterns Skill Snapshot Auto scan of skill assets. Informational only.
Valid SKILL.md Checks against SKILL.md specification
Source & Community
Updated At Jan 19, 2026, 04:33 AM
Skill Stats
SKILL.md 232 Lines
Total Files 1
Total Size 0 B
License NOASSERTION
---
name: patterns
description: Common agent patterns and templates for Claude Code. Use when implementing agents to follow proven patterns for Tasks integration, quality checks, and external model invocation via claudish CLI.
---
plugin: agentdev
updated: 2026-02-11
# Agent Patterns
## External Model Invocation Pattern
External AI models are invoked via **Bash+claudish CLI** by the orchestrator (e.g., `/team`).
Agents do NOT need special blocks to support external models — the orchestrator calls
claudish directly:
```bash
# Orchestrator calls claudish directly via Bash tool
claudish --model {MODEL_ID} --stdin --quiet < prompt.md > result.md
```
This is 100% reliable because it's a deterministic CLI invocation, not a prompt-based delegation.
---
## Tasks Integration Pattern
Every agent must track workflow progress.
```xml
<critical_constraints>
<tasks_requirement>
You MUST use Tasks to track your workflow.
**Before starting**, create task list:
1. Phase 1 description
2. Phase 2 description
3. Phase 3 description
**Update continuously**:
- Mark "in_progress" when starting
- Mark "completed" immediately after finishing
- Keep only ONE task "in_progress" at a time
</tasks_requirement>
</critical_constraints>
<workflow>
<phase number="1" name="Phase Name">
<step>Initialize Tasks with all phases</step>
<step>Mark PHASE 1 as in_progress</step>
<step>... perform work ...</step>
<step>Mark PHASE 1 as completed</step>
<step>Mark PHASE 2 as in_progress</step>
</phase>
</workflow>
```
---
## Quality Checks Pattern (Implementers)
```xml
<implementation_standards>
<quality_checks mandatory="true">
Before presenting code, perform these checks in order:
<check name="formatting" order="1">
<tool>Biome.js</tool>
<command>bun run format</command>
<requirement>Must pass</requirement>
<on_failure>Fix and retry</on_failure>
</check>
<check name="linting" order="2">
<tool>Biome.js</tool>
<command>bun run lint</command>
<requirement>All errors resolved</requirement>
<on_failure>Fix errors, retry</on_failure>
</check>
<check name="type_checking" order="3">
<tool>TypeScript</tool>
<command>bun run typecheck</command>
<requirement>Zero type errors</requirement>
<on_failure>Resolve errors, retry</on_failure>
</check>
<check name="testing" order="4">
<tool>Vitest</tool>
<command>bun test</command>
<requirement>All tests pass</requirement>
<on_failure>Fix failing tests</on_failure>
</check>
</quality_checks>
</implementation_standards>
```
---
## Review Feedback Pattern (Reviewers)
```xml
<review_criteria>
<feedback_format>
## Review: {name}
**Status**: PASS | CONDITIONAL | FAIL
**Reviewer**: {model}
**Issue Summary**:
- CRITICAL: {count}
- HIGH: {count}
- MEDIUM: {count}
- LOW: {count}
### CRITICAL Issues
#### Issue 1: {Title}
- **Category**: YAML | XML | Security | Completeness
- **Description**: What's wrong
- **Impact**: Why it matters
- **Fix**: How to fix it
- **Location**: Section/line reference
### HIGH Priority Issues
[Same format]
### Approval Decision
**Status**: PASS | CONDITIONAL | FAIL
**Rationale**: Why this status
</feedback_format>
</review_criteria>
<approval_criteria>
<status name="PASS">
- 0 CRITICAL issues
- 0-2 HIGH issues
- All core sections present
</status>
<status name="CONDITIONAL">
- 0 CRITICAL issues
- 3-5 HIGH issues
- Core functionality works
</status>
<status name="FAIL">
- 1+ CRITICAL issues
- OR 6+ HIGH issues
- Blocks functionality
</status>
</approval_criteria>
```
---
## Orchestrator Phase Pattern (Commands)
```xml
<phases>
<phase number="1" name="Descriptive Name">
<objective>Clear statement of what this phase achieves</objective>
<steps>
<step>Mark PHASE 1 as in_progress in task list</step>
<step>Detailed action step</step>
<step>Detailed action step</step>
<step>Mark PHASE 1 as completed</step>
</steps>
<quality_gate>
Exit criteria - what must be true to proceed
</quality_gate>
</phase>
</phases>
<delegation_rules>
<rule scope="design">ALL design → architect agent</rule>
<rule scope="implementation">ALL implementation → developer agent</rule>
<rule scope="review">ALL reviews → reviewer agent</rule>
</delegation_rules>
```
---
## Agent Templates
### Planner Template
```yaml
---
name: {domain}-architect
description: |
Plans {domain} features with comprehensive design.
Examples: (1) "Design X" (2) "Plan Y" (3) "Architect Z"
model: sonnet
color: purple
tools: TaskCreate, TaskUpdate, TaskList, TaskGet, Read, Write, Glob, Grep, Bash
---
```
### Implementer Template
```yaml
---
name: {domain}-developer
description: |
Implements {domain} features with quality checks.
Examples: (1) "Create X" (2) "Build Y" (3) "Implement Z"
model: sonnet
color: green
tools: TaskCreate, TaskUpdate, TaskList, TaskGet, Read, Write, Edit, Bash, Glob, Grep
---
```
### Reviewer Template
```yaml
---
name: {domain}-reviewer
description: |
Reviews {domain} code for quality and standards.
Examples: (1) "Review X" (2) "Validate Y" (3) "Check Z"
model: sonnet
color: cyan
tools: TaskCreate, TaskUpdate, TaskList, TaskGet, Read, Glob, Grep, Bash
---
```
### Orchestrator Template
```yaml
---
description: |
Orchestrates {workflow} with multi-agent coordination.
Workflow: PHASE 1 → PHASE 2 → PHASE 3
allowed-tools: Task, AskUserQuestion, Bash, Read, TaskCreate, TaskUpdate, TaskList, TaskGet, Glob, Grep
---
```