agentleFS
ivanestarivanestar/eitr/.claude/skills/protocol-123/SKILL.md

protocol-123

Skill4 starsChanged 2 months agoApache-2.0View on GitHub

Strict 9-phase multi-agent autonomous engineering and bugfixing pipeline triggered by '123' or 'по 123'. Enforces SDD-first specification, multi-agent plan review, user sign-off gateway, TDD-driven execution (Red-Green-Refactor), multi-agent code/test review, two-strike self-healing, and QA verification.

The file

We split this skill into the rules it gives an agent

4 rules. About 0 are common, 3 are distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈3

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Action: Run npm run build or the targeted test suite _before_ writing any code or plans.

    line 44
  2. Distinctive:

    Rule: If baseline is already failing (Red), explicitly document the broken baseline before starting so the agent does not attempt to repair …

    line 45
  3. Distinctive:

    Run the test to verify that it fails (Red) on the existing baseline, confirming non-vacuous assertions.

    line 100
  4. Distinctive:

    Targeted Tests: Run targeted vitest files for modified modules.

    line 128

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

The 123 Protocol Skill (v2.1)

Purpose

Provides a 100% deterministic engineering workflow combining Spec-Driven Architecture (SDD) with Test-Driven Execution (TDD) and multi-agent verification swarms.

Activation Rules & Trigger Phrases

  • Strict Trigger Rule (Explicit Activation Only):
    • The 123 Protocol is activated STRICTLY AND ONLY when the user explicitly requests it via keywords:
      • 123 / по 123 (Full Swarm)
      • таска по 123 / исправь по 123
      • 123-fast (Fast Track for 1-file minor fixes)
    • For standard requests without "123", execute directly in standard mode.
    • Proactive Suggestion (User Decision Gateway): For complex multi-file refactorings or architectural changes, the assistant may proactively ask: "Хотите выполнить эту задачу по протоколу 123 с полным мульти-агентным ревью?". The 123 pipeline is launched ONLY if the user explicitly approves.

Modes

  1. Full Protocol (123):
    • 9-phase lifecycle: live web & codebase recon, invariants discovery feeding the Architect, single Lead Reviewer with Arbiter escalation gateway, and TDD execution.
  2. Fast Track (123-fast):
    • 1 research -> 1 plan -> User Approval Gateway -> 1 TDD execution (Red -> Green) -> 1 reviewer -> QA.
    • Used for single-file, pre-scoped fixes.

Deterministic Orchestration Script

To eliminate LLM reasoning drift or omission of mandatory subagents (such as skipping web-researcher or invariant discovery), orchestrators can invoke the deterministic runner script:

  • node scripts/protocol-123.mjs plan [--mode=full|fast] [--json]: Outputs the exact phase graph, mandatory subagents, and exit gates.
  • node scripts/protocol-123.mjs prompt <subagent>: Emits the exact, non-negotiable prompt template for subagents (web-researcher, test-conditions-designer, code-reviewer, review-arbiter).
  • node scripts/protocol-123.mjs verify-phase <0-8>: Runs mechanical validation for the phase gate.
  • node scripts/protocol-123.mjs telemetry: Emits the standard telemetry summary table.

9-Phase Lifecycle (SDD + TDD Hybrid)

Phase 0: Pre-Flight Baseline Check

  • Agent: qa-guard.
  • Action: Run npm run build or the targeted test suite before writing any code or plans.
  • Rule: If baseline is already failing (Red), explicitly document the broken baseline before starting so the agent does not attempt to repair unrelated failures.

Phase 1: Research & Diagnosis (Explore, Web Recon & ISTQB Grounding)

  • Mandate: Uncompromising Engineering Rigor (Anti-Flattery Mandate). Act as a ruthless Senior SDET Partner. Unmask genuine production bottlenecks (MFA/SSO auth traps, deduplication gaps, context bloat, batch UX bottlenecks, lack of canvas support) and never artificially flatter or inflate assessment scores.
  • Agents:
    • A general-purpose research subagent (scoped read-only tools: grep_search, find_by_name, view_file): Deeply inspect codebase, trace root causes, locate all call sites and dependencies, collect concrete line-level evidence, and map Impact Radius across the full stack. No dedicated persona needed for this - any general-purpose subagent can be scoped to it directly.
    • web-researcher (Mandatory Unconditional Invocation): The orchestrator MUST ALWAYS launch web-researcher before Phase 2 plan formulation — relying on pre-trained memory or mental shortcuts is strictly prohibited. web-researcher executes two mandatory investigation tracks:
      1. Technical Upstream Recon: Targeted live web searches on official documentation (Playwright, Cypress, MCP, LLM frameworks, Node.js) to ground decisions in current upstream best practices, deprecations, known browser/runtime bugs, and real-world production traps.
      2. ISTQB Standards & Syllabi Alignment: Live web search across official ISTQB syllabi (CTFL v4.0, CTAL-TAE v2.0, CTAL-TA v4.0, CT-GenAI, CT-AI, CT-SEC) and the official glossary (glossary.istqb.org) to anchor architecture concepts, entry/exit criteria, test oracles, and test design techniques in standard international testing taxonomy and principles.
    • Phase 1 Handoff Gate: Phase 2 formulation cannot proceed until web-researcher delivers its structured synthesis (Top Pitfalls to Avoid, Upstream Recommendations, and ISTQB Taxonomy Mapping).

Phase 2: Invariants Discovery & Defensive Spec Formulation (SDD)

  • Workflow Pipeline (Invariants -> Defensive Architecture):
    1. Step 2a (Invariants Discovery): test-conditions-designer uncovers the critical positive requirements and negative invariants / boundary conditions BEFORE the Architect finalizes the plan.
      • High-Signal Invariants Cap: Enforce density over volume (MAX 15–20 total conditions: 6–10 atomic positive ACs and 8–12 critical negative boundary invariants across the 9 closed taxonomy categories).
      • Taxonomy Categories: invalid_input, boundary, missing_precondition, concurrent_conflict, state_violation, permission_denied, external_failure, data_integrity, error_path.
      • Defensive Oracle Polarity: Assert graceful error handling, input sanitization, and state preservation — NEVER unhandled crashes.
    2. Step 2b (Defensive Architecture Plan): architect takes the discovered invariants on input and designs the formal Markdown SDD plan with proactive architectural defenses (sanitization, retry bounds, error boundary wrapping, null safety).
  • Executive Summary & Specification requirements:
    1. Executive Summary Table: Target files list, breaking changes flag (Yes / No), test impact, risk assessment.
    2. Acceptance Criteria (AC) -> Test Matrix:
      Requirement / Bug ScenarioTarget Test FileAssertion Type
      AC-1: <Description>packages/*/test/<name>.test.ts<Deterministic Check>
    3. Exact Code Blocks: Complete before/after chunks and line numbers.
    4. Embedded Invariants Matrix: The discovered positive and negative conditions mapped to corresponding architectural defenses.

Phase 3: Lead Plan Review (Single Strong Reviewer)

  • Review Scope: Single-reviewer audit of the plan against code quality, security, multi-stack parity, and test determinism before presenting to the user.
  • Agent: code-reviewer (Lead Reviewer), armed with a 5-point unified rubric:
    1. Architecture & Plan Compliance (spec adherence, CPOM contracts, Zero Lock-in).
    2. TypeScript & Language Safety (strict typing, zero any, cross-platform paths).
    3. Security & Privacy (no hardcoded secrets, safe credential retrieval from env, path traversal prevention, gitignore).
    4. Flake & Determinism (zero arbitrary sleep, proper async order, web-first auto-retrying assertions).
    5. Cross-Target Parity (a capability landing across every AI assistant, CI provider and TMS it applies to - the generated stack is TypeScript + Playwright alone).
  • Arbiter Escalation Gateway (review-arbiter):
    • For standard single-reviewer execution, findings are output directly as actionable bullet points ([SEVERITY] File:Line -- Issue -- Fix) and hardened into the plan, eliminating extra token round-trips.
    • In multi-party or high-conflict escalations, review-arbiter remains available to adjudicate disputed findings against Ground Truth (AGENTS.md, CONVENTIONS.md).
  • Token Economy: Reviewers return concise, high-signal bullet points ([SEVERITY] File:Line -- Issue -- Fix).
  • Hardening: Automatically revise the plan artifact based on reviewer findings before presenting to the user.

Phase 4: User Approval Gateway (Human Intent Lock)

  • Artifact: Save hardened plan in artifacts directory (brain/<conv-id>/...).
  • Request Feedback: Set RequestFeedback: true.
  • CRITICAL LOCK: Absolutely ZERO code modifications are permitted until the user explicitly reviews and approves the plan.

Phase 5: Test-Driven Execution (TDD: Red $\rightarrow$ Green $\rightarrow$ Refactor)

  • Phase 5a (RED Phase - test-writer & eval-engineer):
    • test-writer: Synthesize targeted unit/integration tests covering 100% of the Phase 2 AC Matrix and Test Conditions Matrix (both positive paths and negative boundary vectors).
    • eval-engineer (Mandatory Eval Parity): Whenever creating or modifying an AI agent, operational skill, or rule generator, synthesize dedicated eval tests in packages/evals/test/ to verify prompt fidelity and negative constraint adherence.
    • Run the test to verify that it fails (Red) on the existing baseline, confirming non-vacuous assertions.
  • Phase 5b (GREEN Phase - core-developer):
    • Implement the minimal targeted code modifications strictly adhering to the approved spec to make all tests pass (Green).
  • Phase 5c (REFACTOR Phase - core-developer):
    • Clean up formatting and imports adhering strictly to project paradigms with zero opportunistic refactoring.

Phase 6: Lead Code & Test Review (Single Strong Reviewer)

  • Agent: code-reviewer (Lead Reviewer) inspecting the actual git diff for both application code and new tests.
  • Review Rubric:
    • Plan compliance, types, code style, Zero Lock-in, AC Matrix 100% coverage.
    • Security scanning (diff entropy, secrets protection, shell injection prevention).
    • Flake sentinel checks (zero arbitrary sleep, web-first auto-retrying assertions).
  • Arbiter Escalation Gateway (review-arbiter): Available on-demand if multi-party arbitration is required.
  • Test Quality Rubric:
    • Anti-Tautology Guard: Forbid trivial checks (expect(true).toBe(true)).
    • Anti-Vacuous Guard: Verify dynamic assertions on actual state.
    • Sandbox Cleanup: Enforce temp directory cleanup in afterAll/afterEach.

Phase 7: Autonomous Self-Healing with Two-Strike Rule

  • Action: Apply targeted fixes for reviewer findings immediately.
  • Two-Strike Rule: Max 2 fix attempts per defect. If a fix fails twice, immediately roll back the file (git checkout -- <file>) and escalate to the user with root cause analysis.

Phase 8: QA Guard, Evals Benchmark, Doc Sync & Final Report

  • Mandatory Pre-Test Build: qa-guard MUST ALWAYS execute npm run build (compiling all TypeScript sources and runtime JS assets) BEFORE running test suites, ensuring that tests run against fresh build artifacts.
  • Continuous Prompt Benchmark: Execute the full npm run eval suite (deterministic eval tests across every file listed in the "eval" script in the root package.json — never hardcode a test/file count here, it drifts every time a test is added; run npm run eval itself to see the current total; the suite also runs in CI via the "Run Deterministic Eval Suite" step in .github/workflows/ci.yml) to guarantee 0 regressions across all AI agents, skills, and assistant rules.
  • Targeted Tests: Run targeted vitest files for modified modules.
  • Agent doc-sync-enforcer: Synchronize CHANGELOG.md, README.md, ARCHITECTURE.md, TODO.md, ENGINE_VERSION in packages/engine/src/version.ts, and workspace package manifests (package.json, packages/*/package.json).
  • Final Report: Deliver a structured, high-signal summary report in chat, including the Protocol 123 Telemetry Summary table:
    ### Protocol 123 Telemetry Summary
    
    | Phase                           | Duration  | Est. Tokens (In/Out) | Est. Cost ($) | Status         |
    | ------------------------------- | --------- | -------------------- | ------------- | -------------- |
    | Phase 0: Pre-Flight Baseline    | 2.1s      | 1.2k / 0.3k          | $0.002        | PASSED         |
    | Phase 1: Recon & Web Research   | 4.5s      | 4.2k / 1.5k          | $0.009        | PASSED         |
    | Phase 2: Invariants & SDD Plan  | 5.0s      | 4.5k / 2.5k          | $0.012        | PASSED         |
    | Phase 3: Lead Plan Review       | 3.2s      | 3.5k / 1.2k          | $0.007        | PASSED         |
    | Phase 4: Human Intent Lock      | User      | 0 / 0                | $0.000        | APPROVED       |
    | Phase 5: TDD Execution          | 6.5s      | 5.0k / 3.0k          | $0.014        | PASSED         |
    | Phase 6: Lead Code Review       | 3.5s      | 3.8k / 1.4k          | $0.008        | PASSED         |
    | Phase 7: Two-Strike Self-Heal   | 0.0s      | 0 / 0                | $0.000        | SKIPPED        |
    | Phase 8: Quality Gate & Handoff | 3.0s      | 2.0k / 0.8k          | $0.004        | PASSED         |
    | **TOTAL**                       | **27.8s** | **24.2k / 10.7k**    | **~$0.056**   | **100% GREEN** |

UX Progress Notification Standard

On each phase transition, the agent MUST output a visible line in chat: [123 Protocol] Фаза X/8: [Описание текущего действия]...

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.