Claude Skill

agent-loop-testing

Use this skill when you need evidence-bounded loop state, plan/action/observation cycles, stop conditions, budgets, repetition, and trace evidence; triggers include Agent 循环 and Agent loop.

LLM Mart · 0 points · 0 views 0 listing impressions 0 install-command copies
Virus-scanned Reviewed automatically before listing.

Full trust report

Download naodeng-awesome-qa-skills-skills_en_testing-types_agent-loop-testing-c44b892.zip · 6 KB
Part of naodeng/awesome-qa-skills — 97 skills

Install

skills CLI npx skills add https://github.com/naodeng/awesome-qa-skills/tree/main/skills/en/testing-types/agent-loop-testing
Claude Code claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install naodeng-awesome-qa-skills@llmmart
Git git clone https://github.com/naodeng/awesome-qa-skills.git

The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole naodeng/awesome-qa-skills collection as a plugin from our marketplace. Git is the plain clone.

Skill manifest

Agent Loop Testing

When to Use

  • Use this skill when you need evidence-bounded analysis, design, or validation preparation for loop state, plan/action/observation cycles, stop conditions, budgets, repetition, and trace evidence.
  • Use it to review an Agent, RAG, or LLM plan, result, or evidence set and produce actionable improvements.
  • Use it when context is incomplete but a bounded first pass with assumptions, gaps, and human-decision boundaries is still useful.

Output Format Options

  • Default to Markdown organized by domain risk, evidence state, priority, and boundary.
  • When the user requests tables, CSV, JSON, or ticket fields, preserve the same finding fields, evidence, and decision boundaries.
  • Before machine consumption, confirm the schema, enums, required fields, and evidence sources.

How to Use

  1. Read and follow prompts/agent-loop-testing.md, including its input audit, domain coverage, and output order.
  2. Extract scope, environment, version, time window, constraints, success criteria, and available evidence, with attention to loop state, plan/action/observation, stop condition, budget, repetition.
  3. Separate confirmed facts, evidence-backed inferences, candidate recommendations, and Human decisions before ranking by risk and evidence strength.
  4. Turn high-risk items into preconditions, steps, expected behavior or decision criteria, required evidence, and a validation method.
  5. When input is incomplete, deliver a bounded first pass, state unsupported conclusions, and never present static material as execution evidence.

Reference Files

  • Always read prompts/agent-loop-testing.md; it is the complete execution specification for this skill.
  • For evaluation, read evals/eval.yaml and the matching cases under evals/cases/.
  • Load references/, examples/, scripts/, or output-formats.md only when those directories exist and the task needs them.

Core Constraints

  • Keep the analysis focused on loop state, plan/action/observation cycles, stop conditions, budgets, repetition, and trace evidence; do not replace business owners or Human risk acceptance, exception approval, or safety decisions.
  • Never invent system behavior, fields, model outputs, data, thresholds, root causes, execution records, or pass claims.
  • Static design, plans, file presence, or a dry run retain their evidence state and cannot become proof of real execution.
  • When evidence is insufficient, use pending confirmation, blocked, unassessed, or NOT_SCORED and give the smallest validation method.
  • For user data, production, or safety work, use least privilege, masked data, mocks, dry runs, or isolation.

Delivery Checklist

  • Covered loop state, plan/action/observation, stop condition, budget, repetition, with source, evidence state, and validation method for each.
  • Separated facts, inferences, candidate recommendations, gaps, and Human decisions.
  • Gave high-risk items P0/P1/P2/P3 or an equivalent priority, owner role, and close condition.
  • Did not turn plans, static checks, or dry runs into test execution, all-passed, or safety-approved claims.
  • Stated residual risk, stop/escalation conditions, and next actions.

Common Pitfalls

  • Listing checks without triggers, expected concerns, owner roles, close conditions, and evidence.
  • Treating adjacent tests or model tools as a complete Agent loop judgment.
  • Using unexplained numbers for false precision or writing correlation as causation.
  • Refusing incomplete input, or pretending that incomplete evidence is conclusive.

Best Practices

  • Start with paths most likely to cause user harm, business loss, or decision blockage.
  • Use the smallest verifiable experiment to reduce uncertainty and record conditions, versions, sources, and evidence.
  • Make the Skill independently installable, executable, and reviewable by another engineer.
Files (awesome-qa-skills)
  • agents
    • openai.yaml 290 B
      version: 1
      metadata:
        key: agent-loop-testing
      interface:
        display_name: "Agent Loop Testing"
        short_description: "Produce evidence-bounded Agent loop analysis"
        default_prompt: "Use the agent-loop-testing skill to perform Agent loop analysis."
      policy:
        allow_implicit_invocation: true
      
  • evals
    • cases
      • basic-success.yaml 1.4 KB
        id: basic-success
        title: "Agent Loop Testing: domain-complete scenario"
        description: |
          Checks that the skill produces domain-specific Agent loop analysis that is evidence-based, prioritized, and executable.
        
        input:
          prompt: |
            Use the agent-loop-testing skill for this scenario: a tool-using Agent repeats the same tool call after task failure, and the team needs to review loop state, stop conditions, budgets, and trace evidence. Provide Agent loop priorities, core execution items, expected behavior or decision criteria, evidence, and open questions.
        
        expect:
          must_contain:
            - "object/rule"
            - "source"
            - "trigger or applicability"
            - "expected concern/rationale"
            - "evidence state"
            - "impact/priority"
            - "owner role"
            - "close condition"
            - "validation method"
            - "ALT-"
            - "Task Understanding"
            - "Input Audit"
            - "Agent loop"
            - "expected"
          must_not_contain:
            - "I cannot"
            - "unable to help"
        
        judge:
          type: rule_based
          success:
            - output_contains:
                all:
                  - "object/rule"
                  - "source"
                  - "trigger or applicability"
                  - "expected concern/rationale"
                  - "evidence state"
                  - "impact/priority"
                  - "owner role"
                  - "close condition"
                  - "validation method"
                  - "ALT-"
                  - "Task Understanding"
                  - "Input Audit"
                  - "Agent loop"
        
      • edge-incomplete-input.yaml 917 B
        id: edge-incomplete-input
        title: "Agent Loop Testing: bounded first pass with incomplete input"
        description: |
          Checks that missing context leads to a bounded first pass with assumptions and gaps, not refusal or invention.
        
        input:
          prompt: |
            Use the agent-loop-testing skill. The only known fact is: a tool-using Agent repeats the same tool call after task failure, and the team needs to review loop state, stop conditions, budgets, and trace evidence. No more environment, version, model, or supporting evidence is available. Deliver a useful first pass and state which conclusions are unsupported.
        
        expect:
          must_contain:
            - "Working Assumptions"
            - "Open Questions"
            - "evidence"
            - "Next Actions"
          must_not_contain:
            - "I cannot"
            - "unable to help"
        
        judge:
          type: rule_based
          success:
            - output_contains:
                all:
                  - "Working Assumptions"
                  - "Open Questions"
        
      • edge-scope-boundary.yaml 953 B
        id: edge-scope-boundary
        title: "Agent Loop Testing: execution and safety boundary"
        description: |
          Checks that missing runtime records do not become execution, pass, or safety claims and that the domain validation boundary remains explicit.
        
        input:
          prompt: |
            Use the agent-loop-testing skill to review this scenario: a tool-using Agent repeats the same tool call after task failure, and the team needs to review loop state, stop conditions, budgets, and trace evidence. Only static material is available and no runtime record is supplied. State what cannot be written as "tests were executed", "all tests passed", or "release approved", then give stop conditions and next validation.
        
        expect:
          must_contain:
            - "Agent loop"
            - "cannot"
            - "Open Questions"
          must_not_contain:
            - "I cannot"
            - "unable to help"
        
        judge:
          type: rule_based
          success:
            - output_contains:
                all:
                  - "Agent loop"
                  - "cannot"
        
    • eval.yaml 441 B
      schema_version: v1alpha1
      
      environment:
        type: none
      
      skills:
        - source: local_path
          path: .
      
      engine:
        name: claude_code
      
      cases:
        files:
          - evals/cases/basic-success.yaml
          - evals/cases/edge-incomplete-input.yaml
          - evals/cases/edge-scope-boundary.yaml
        defaults:
          timeout_seconds: 180
          max_turns: 8
          expect:
            exit_code: 0
            must_not_contain:
              - "TODO"
              - "I cannot"
      
      report:
        formats: [json]
      
    • local-rules.json 137 B
      {
        "skill": "agent-loop-testing",
        "max_commands": 20,
        "max_total_tokens": 100000,
        "permissions": {
          "max_escalations": 0
        }
      }
      
    • trigger-prompts.csv 582 B · in bundle
  • prompts
    • agent-loop-testing.md 4.6 KB
      # Agent Loop Testing Prompt
      
      Build an executable, reviewable, and traceable evidence boundary for loop state, plan/action/observation cycles, stop conditions, budgets, repetition, and trace evidence.
      
      ## Input
      
      Start with an input audit and record known, missing, conflicting, stale, out_of_scope, and assumptions:
      
      - known: scope, Agent loop material, constraints, or results directly supported by a source.
      - missing: material needed to assess loop state, plan/action/observation cycles, stop conditions, budgets, repetition, and trace evidence that has not been supplied.
      - conflicting: inconsistent goals, definitions, conditions, or behaviors across sources.
      - stale: architecture, version, model, dataset, or record that may be out of date.
      - out_of_scope: actions outside this Skill, unauthorized actions, or actions requiring a real environment.
      - assumptions: temporary assumptions for a bounded first pass, each with a validation method.
      
      ## What to do
      
      1. Restate the objective, subject, scope, and success criteria in one sentence.
      2. Audit completeness, credibility, recency, and comparability, focusing on loop state, plan/action/observation, stop condition, budget, repetition.
      3. Build a risk or failure model for Agent loop, including triggers, expected concerns, impact, and evidence needs.
      4. Convert the analysis into concrete scenarios, assertions, validation steps, decision gates, or improvement experiments.
      5. Report residual risk, evidence gaps, and next actions without presenting assumptions as facts.
      
      ## Execution Rules
      
      - Give a source, evidence state, and validation method for every important conclusion.
      - Each scenario must include preconditions, action or stimulus, expected behavior or decision criterion, required evidence, and a stop condition.
      - Use P0/P1/P2/P3 or an equivalent scale and explain business impact, likelihood, detectability, or decision cost.
      - Make loop state, plan/action/observation cycles, stop conditions, budgets, repetition, and trace evidence concrete; do not substitute adjacent test types, tool names, or one example for domain reasoning.
      - Never invent numbers, thresholds, model behavior, root causes, system behavior, execution records, all-passed claims, or safety approval.
      - For user data, production, or safety work, default to least privilege, masked data, mocks, dry runs, or isolation.
      - Separate facts, inferences, candidate recommendations, and Human decisions; only Human can confirm risk acceptance, exceptions, and safety judgments.
      
      ## Minimum Coverage Checklist
      
      - loop state, plan/action/observation, stop condition, budget, repetition
      - confirmed facts, working assumptions, open questions, evidence quality, and recency
      - high-risk paths, blockers, stop/escalation/rollback or human-handoff conditions
      - smallest validation action, owner role, close condition, residual risk, and Human decision
      - facts, evidence-backed inferences, candidate recommendations, Human decisions
      
      ## Output
      
      ### 1. Task Understanding and Scope
      
      State the objective, subject, inclusions, exclusions, success criteria, and unauthorized actions.
      
      ### 2. Input Audit
      
      List known, missing, conflicting, stale, out_of_scope, and assumptions with source, recency, and evidence quality.
      
      ### 3. Agent loop Analysis and Priorities
      
      Describe scenarios, triggers, expected behavior, impact, priority, and evidence gaps for loop state, plan/action/observation cycles, stop conditions, budgets, repetition, and trace evidence.
      
      ### ALT-## Finding Contract
      
      Each finding must include:
      
      - object/rule
      - source
      - trigger or applicability
      - expected concern/rationale
      - evidence state
      - impact/priority
      - owner role
      - close condition
      - validation method
      
      ### 4. Candidate Validation and Residual Risk
      
      Separate candidate recommendations from actual execution and state the smallest validation action, stop/escalation conditions, residual risk, and open questions.
      
      ### 5. Human Decisions
      
      List only items requiring Human confirmation, risk acceptance, exception authorization, rollback, or safety judgment.
      
      The output must keep these sections separate: facts, evidence-backed inferences, candidate recommendations, Human decisions.
      
      ## Quality Bar
      
      - Tailor the content to Agent loop; do not merely rename a generic template.
      - Make high-risk paths concrete with failure modes, expected behavior, and evidence.
      - Never infer numbers, root causes, or system behavior without support.
      - Static analysis, plans, or dry runs are not proof of real execution, all tests passing, or safety approval.
      - Let an executor act without guessing and a reviewer trace the boundary between facts, inferences, recommendations, and Human decisions.
      
  • SKILL.md 4 KB
    ---
    name: agent-loop-testing
    description: Use this skill when you need evidence-bounded loop state, plan/action/observation cycles, stop conditions, budgets, repetition, and trace evidence; triggers include Agent 循环 and Agent loop.
    ---
    
    # Agent Loop Testing
    
    ## When to Use
    
    - Use this skill when you need evidence-bounded analysis, design, or validation preparation for loop state, plan/action/observation cycles, stop conditions, budgets, repetition, and trace evidence.
    - Use it to review an Agent, RAG, or LLM plan, result, or evidence set and produce actionable improvements.
    - Use it when context is incomplete but a bounded first pass with assumptions, gaps, and human-decision boundaries is still useful.
    
    ## Output Format Options
    
    - Default to Markdown organized by domain risk, evidence state, priority, and boundary.
    - When the user requests tables, CSV, JSON, or ticket fields, preserve the same finding fields, evidence, and decision boundaries.
    - Before machine consumption, confirm the schema, enums, required fields, and evidence sources.
    
    ## How to Use
    
    1. Read and follow `prompts/agent-loop-testing.md`, including its input audit, domain coverage, and output order.
    2. Extract scope, environment, version, time window, constraints, success criteria, and available evidence, with attention to loop state, plan/action/observation, stop condition, budget, repetition.
    3. Separate confirmed facts, evidence-backed inferences, candidate recommendations, and Human decisions before ranking by risk and evidence strength.
    4. Turn high-risk items into preconditions, steps, expected behavior or decision criteria, required evidence, and a validation method.
    5. When input is incomplete, deliver a bounded first pass, state unsupported conclusions, and never present static material as execution evidence.
    
    ## Reference Files
    
    - Always read `prompts/agent-loop-testing.md`; it is the complete execution specification for this skill.
    - For evaluation, read `evals/eval.yaml` and the matching cases under `evals/cases/`.
    - Load `references/`, `examples/`, `scripts/`, or `output-formats.md` only when those directories exist and the task needs them.
    
    ## Core Constraints
    
    - Keep the analysis focused on loop state, plan/action/observation cycles, stop conditions, budgets, repetition, and trace evidence; do not replace business owners or Human risk acceptance, exception approval, or safety decisions.
    - Never invent system behavior, fields, model outputs, data, thresholds, root causes, execution records, or pass claims.
    - Static design, plans, file presence, or a dry run retain their evidence state and cannot become proof of real execution.
    - When evidence is insufficient, use pending confirmation, blocked, unassessed, or NOT_SCORED and give the smallest validation method.
    - For user data, production, or safety work, use least privilege, masked data, mocks, dry runs, or isolation.
    
    ## Delivery Checklist
    
    - [ ] Covered loop state, plan/action/observation, stop condition, budget, repetition, with source, evidence state, and validation method for each.
    - [ ] Separated facts, inferences, candidate recommendations, gaps, and Human decisions.
    - [ ] Gave high-risk items P0/P1/P2/P3 or an equivalent priority, owner role, and close condition.
    - [ ] Did not turn plans, static checks, or dry runs into test execution, all-passed, or safety-approved claims.
    - [ ] Stated residual risk, stop/escalation conditions, and next actions.
    
    ## Common Pitfalls
    
    - Listing checks without triggers, expected concerns, owner roles, close conditions, and evidence.
    - Treating adjacent tests or model tools as a complete Agent loop judgment.
    - Using unexplained numbers for false precision or writing correlation as causation.
    - Refusing incomplete input, or pretending that incomplete evidence is conclusive.
    
    ## Best Practices
    
    - Start with paths most likely to cause user harm, business loss, or decision blockage.
    - Use the smallest verifiable experiment to reduce uncertainty and record conditions, versions, sources, and evidence.
    - Make the Skill independently installable, executable, and reviewable by another engineer.
    

Comments (0)

Sign in to join the conversation.

No comments yet.

Reviews (0)

No reviews yet.

Related