菜单
Anti-pattern prevention guidelines for Agile V agents. Prevents common LLM coding mistakes while maintaining Agile V traceability. Use when implementing requirements to avoid overcomplication, silent assumptions, scope creep, and verification failures.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | agile-v-behavioral |
| description | Anti-pattern prevention guidelines for Agile V agents. Prevents common LLM coding mistakes while maintaining Agile V traceability. Use when implementing requirements to avoid overcomplication, silent assumptions, scope creep, and verification failures. |
| license | CC-BY-SA-4.0 |
| metadata | {"version":"1.0","standard":"Agile V","author":"agile-v.org","adapted_from":[{"name":"Karpathy Skills","url":"https://github.com/forrestchang/andrej-karpathy-skills","license":"MIT","sections":"Behavioral Guidelines","note":"Four behavioral principles adapted under the MIT License and integrated with Agile V traceability framework."}]} |
Anti-pattern prevention for Agile V agents. Combines proven behavioral guidelines with Agile V traceability to prevent common LLM failures.
Companion skill: Load agile-v-core first. This skill extends core directives with behavioral safeguards.
Tradeoff: These guidelines bias toward caution and clarity over speed. For trivial single-REQ implementations, use judgment.
Don't assume. Don't hide confusion. Surface tradeoffs. Document decisions.
DECISION_LOG.md entry with timestamp, rationale, alternatives consideredExample:
REQ-0042: "Improve error handling"
❌ Don't: Silently add try/catch blocks everywhere
✅ Do: Halt and ask:
- "Improve" how? (user-facing messages? logging? retry logic?)
- Which error scenarios? (network? validation? unexpected data?)
- What's acceptable error UX? (fail silently? show message? redirect?)
Then log decision:
DECISION: Add validation error handling with user-facing messages
RATIONALE: User reported confusing silent failures on form submission
LINKED_REQ: REQ-0042 (refined to REQ-0042a: validation error UX)
Minimum code that satisfies REQ acceptance criteria. Nothing speculative.
Ask yourself: "Would a senior engineer call this overcomplicated?" If yes, simplify.
ART-XXXX links to exactly one REQ-XXXX. If code doesn't map to REQ acceptance criteria, it's out of scope.Example:
# ❌ Over-engineered for single REQ
# REQ-0010: Calculate 10% discount on orders over $100
class DiscountStrategy(ABC):
@abstractmethod
def calculate(self, amount: float) -> float: pass
class PercentageDiscount(DiscountStrategy): ...
class TieredDiscount(DiscountStrategy): ...
class ConfigurableDiscountEngine: ...
# ✅ Simple, traceable to REQ-0010
# ART-0010: Discount calculation
# Implements: REQ-0010 (10% discount on orders >$100)
def calculate_discount(order_total):
"""REQ-0010: 10% discount for orders over $100."""
if order_total > 100:
return order_total * 0.10
return 0.0
When abstraction IS warranted:
REQ-0010 (discount), REQ-0015 (shipping calc), REQ-0020 (tax calc) all need pricing rules → abstraction justified. Document in Decision Log.Touch only what changed REQs require. Clean up only your own mess.
new or modified REQs or active CRsThe Test: Every changed line should trace directly to a REQ-XXXX or CR-XXXX. If not, revert it.
Example:
Cycle 2: CR-0005 requires changing password validation (REQ-0002)
# ❌ Scope creep
def validate_password(password):
# Changed per CR-0005
if len(password) > 128:
return False, "Max 128 chars"
# UNRELATED: Reformatted entire function, fixed typo in adjacent comment,
# "improved" variable naming in unrelated login() function
# ✅ Surgical
def validate_password(password):
# CR-0005: Add max length validation
if len(password) > 128:
return False, "Password must be 128 characters or less"
# (rest of function unchanged)
Transform REQ acceptance criteria into TC-XXXX. Success = TC passes, not "code runs."
Every REQ acceptance criterion becomes a test case:
TC-XXXX: Invalid inputs rejected with specific error messagesTC-XXXX: Reproduce bug, verify fix, ensure no regressionTC-XXXX: All existing tests pass before and afterFor Multi-Step Synthesis: State a brief plan with verification checkpoints:
REQ-0025: User profile update with avatar upload
Build Plan:
1. Create upload endpoint → verify: TC-0025-01 (accepts valid image)
2. Add image validation → verify: TC-0025-02 (rejects invalid files)
3. Save to storage → verify: TC-0025-03 (file persisted, URL returned)
4. Update user record → verify: TC-0025-04 (DB reflects new avatar)
5. Integration test → verify: TC-0025-05 (end-to-end flow)
Weak vs Strong Success Criteria:
| Weak (avoid) | Strong (use) |
|---|---|
| "Make it work" | "TC-0025-01 passes: Valid JPEG upload returns 200 + URL" |
| "Add tests" | "TC-0025-02: Rejects files >5MB with 413 error" |
| "Improve performance" | "TC-0025-06: Upload completes in <2s for 1MB file" |
Strong criteria enable independent Red Team verification and auto-fix loops without constant clarification.
Before marking artifact complete, verify:
# ART-XXXX: ... | Implements: REQ-XXXX presentAlways load alongside agile-v-core and any build agent skill. This skill adds behavioral guardrails that prevent the four most common agent failure modes: silent assumptions, overengineering, scope creep, and weak test criteria.
License: CC-BY-SA-4.0 | Author: Agile V™
Adapted from: Karpathy Skills (MIT License) | Homepage: https://github.com/Agile-V/agile_v_skills
Risk management, CAPA protocol, human gate approval records, AI agent security controls, and periodic revalidation. Load when running gates, handling CAPAs, or auditing compliance and security posture.
Foundational values, directives, and context engineering rules for all Agile V agents. Load first in every Agile V session.
Orchestration pipeline, wave execution, handoff protocols, and checkpoint types for the Agile V 5-stage workflow. Load when orchestrating multi-agent pipelines or managing stage transitions.
Generates code, firmware, HDL, or other technical artifacts strictly derived from approved requirements. Language-agnostic. Use when synthesizing artifacts from Logic Gatekeeper-approved requirements.
Automates Principle No. 9 (Decision Logging) and Principle No. 5 (Regulatory Readiness). The 'Chronicler' ensuring every choice is backed by a 'Why' and mapped to a requirement for ISO/GxP auditability.
Validates requirements for ambiguity and physical hardware constraints. Use this after requirements are generated but before code/hardware synthesis begins.