菜单
Core reasoning patterns for building effective LLM agents. Use when designing agent behavior, debugging agent failures, improving agent reliability, or understanding ReAct/Plan-and-Execute patterns.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | agentic-patterns |
| description | Core reasoning patterns for building effective LLM agents. Use when designing agent behavior, debugging agent failures, improving agent reliability, or understanding ReAct/Plan-and-Execute patterns. |
| allowed_tools | ["Read","Glob","Grep","Task"] |
When designing agent behavior, debugging agent failures, improving agent reliability.
Core reasoning patterns for building effective LLM agents. Includes ReAct, Plan-and-Execute, Self-Reflection, confidence calibration, error recovery, multi-agent coordination, and context management strategies.
Purpose: Core reasoning patterns for building effective LLM agents.
Use when: Designing agent behavior, debugging agent failures, improving agent reliability.
The foundational agentic loop. Combines chain-of-thought with tool use.
THOUGHT: What am I trying to accomplish? What do I know?
ACTION: Execute tool/command based on reasoning
OBSERVATION: What was the result? Did it match expectations?
THOUGHT: Based on observation, what next?
... repeat until goal achieved
Why it works: Grounds LLM outputs in real observations. Reduces hallucinations.
When to use: Most tasks. This is the default pattern.
Example:
THOUGHT: I need to find where authentication is handled
ACTION: grep -r "authenticate" --include="*.go"
OBSERVATION: Found 3 files: auth.go, middleware.go, handlers.go
THOUGHT: middleware.go likely has the auth middleware, let me read it
Decompose complex goals into sub-tasks before acting.
1. PLAN: Break goal into discrete steps
2. EXECUTE: Work through each step
3. VERIFY: Check each step succeeded before moving on
4. ADJUST: Replan if something fails
Why it works: Prevents getting lost in complex tasks. Makes progress visible.
When to use: Multi-step tasks, unfamiliar codebases, architectural changes.
Example:
PLAN for "Add user authentication":
1. Check existing auth patterns in codebase
2. Design auth middleware
3. Implement token validation
4. Add protected routes
5. Write tests
6. Update documentation
Now executing step 1...
Evaluate own outputs before presenting them.
1. GENERATE: Produce initial output
2. CRITIQUE: What could be wrong? What did I assume?
3. REFINE: Improve based on critique
4. PRESENT: Only after reflection
Why it works: Catches errors before they propagate. Improves quality.
When to use: Code generation, architectural decisions, any output that matters.
Example:
GENERATED: Function to validate email
CRITIQUE: Did I handle edge cases? Empty string? Unicode?
REFINE: Add null check, use proper regex, handle IDN domains
PRESENT: Here's the validated function...
| Level | Indicators | Action |
|---|---|---|
| HIGH (proceed) | Matches known patterns, clear requirements, similar past success | Act autonomously |
| MEDIUM (verify) | Some unknowns, first time for this pattern, could break things | Ask before risky actions |
| LOW (ask) | Architectural change, security-sensitive, deleting files | Always ask user |
When uncertain, SAY SO:
GOOD: "I'm not sure if this is the right approach. Here's my reasoning..."
GOOD: "I found two possible solutions. Let me explain the tradeoffs..."
BAD: [silently picks one approach without mentioning alternatives]
BAD: [confidently states something without verifying]
Before acting, ask yourself:
1. ATTEMPT: Try the action
2. OBSERVE: Did it succeed?
3. DIAGNOSE: If failed, why?
4. ADJUST: Modify approach based on diagnosis
5. RETRY: Max 2 retries with different approaches
6. ESCALATE: If still failing, ask user
When stuck:
| Failure | Recovery |
|---|---|
| Tool returned error | Read error message, adjust inputs, retry |
| Unexpected output | Verify assumptions, try different approach |
| Stuck in loop | Stop, reflect, try fundamentally different approach |
| Context exhaustion | Summarize progress, ask user for direction |
When handing off to another agent:
Session file is source of truth. Always:
If agents disagree (e.g., Reviewer rejects Dev's code):
Don't: Load all potentially relevant files upfront Do: Store paths/identifiers, load only when needed
WRONG: Read all 50 test files to understand testing patterns
RIGHT: Read testing skill, then load specific test when implementing
Default: Quiet mode - follow patterns internally, show only key decisions
Verbose mode: User says "verbose mode" to enable explicit reasoning
When verbose, show:
THOUGHT: [articulate intent]
ACTION: [describe tool/command]
OBSERVATION: [verify result]
REFLECT: [adjust if needed]
When quiet, only show:
Remember: The goal is not to follow patterns rigidly, but to THINK before acting, VERIFY results, and ASK when uncertain.
Interactive playtest — full-stack (UI + Playwright + UX Designer) or headless (API-only + Python driver). Coordinates cross-workspace bug reporting via ping-pong file with FIXER.
LLM cost and cache forensics — reconcile server-log narrator costs against the Anthropic Admin API, attribute per-model spend, detect dead caching and invisible callers. Use when analyzing API costs, auditing cache efficiency, or when the Console bill doesn't match expectations.
Create epic or story context documents. Reads sprint YAML for epic/story data, reads context-schema.yaml for required sections, populates templates, and writes output to sprint/context/. Epic context is a single-agent operation (no tandem). Story context uses PM + tandem partner for domain-specific observations.
Jira CLI commands for sprint management. Use when viewing, assigning, or updating Jira issues from the command line.
Sprint status, backlog, and story management for Pennyfarthing. Use when checking current sprint status, finding available stories, reviewing backlog, or understanding story context and history. IMPORTANT: Always use `pf sprint` CLI commands - never manually edit sprint YAML.
List available workflows, show current workflow details, and switch workflows mid-session. Use when checking available workflow types (TDD, trivial, agent-docs), viewing current workflow phase, switching to a different workflow pattern, or managing BikeLane stepped workflows.