Agent Skills: Lessons Learned

[Testing] Create or update EasyPlatform test specifications in docs/test-specs/{Module}/. Covers external memory-driven analysis, 4-priority test generation, comprehensive document structure with ERD and traceability. Triggers on "test specs", "test specifications", "test cases", "test scenarios", "QA documentation", "Given-When-Then", "BDD", "TDD", "coverage".

UncategorizedID: duc01226/easyplatform/test-specs-docs

Install this agent skill to your local

pnpm dlx add-skill https://github.com/duc01226/EasyPlatform/tree/HEAD/.agents/skills/test-specs-docs

Skill Files

Browse the full folder contents for test-specs-docs.

Download Skill

Loading file tree…

.agents/skills/test-specs-docs/SKILL.md

Skill Metadata

Name
test-specs-docs
Description
'[DEPRECATED] Use when you need this skill has been merged into tdd-spec.'

Codex compatibility note:

  • Invoke repository skills with $skill-name in Codex; this mirrored copy rewrites legacy Claude /skill-name references.
  • Prefer the plan-hard skill for planning guidance in this Codex mirror.
  • Task tracker mandate: BEFORE executing any workflow or skill step, create/update task tracking for all steps and keep it synchronized as progress changes.
  • User-question prompts mean to ask the user directly in Codex.
  • Ignore Claude-specific mode-switch instructions when they appear.
  • Strict execution contract: when a user explicitly invokes a skill, execute that skill protocol as written.
  • Subagent authorization: when a skill is user-invoked or AI-detected and its protocol requires subagents, that skill activation authorizes use of the required spawn_agent subagent(s) for that task.
  • Do not skip, reorder, or merge protocol steps unless the user explicitly approves the deviation first.
  • For workflow skills, execute each listed child-skill step explicitly and report step-by-step evidence.
  • If a required step/tool cannot run in this environment, stop and ask the user before adapting.
<!-- CODEX:PROJECT-REFERENCE-LOADING:START -->

Codex Project-Reference Loading (No Hooks)

Codex does not receive Claude hook-based doc injection. When coding, planning, debugging, testing, or reviewing, open project docs explicitly using this routing.

Always read:

  • docs/project-config.json (project-specific paths, commands, modules, and workflow/test settings)
  • docs/project-reference/docs-index-reference.md (routes to the full docs/project-reference/* catalog)
  • docs/project-reference/lessons.md (always-on guardrails and anti-patterns)

Situation-based docs:

  • Backend/CQRS/API/domain/entity changes: backend-patterns-reference.md, domain-entities-reference.md, project-structure-reference.md
  • Frontend/UI/styling/design-system: frontend-patterns-reference.md, scss-styling-guide.md, design-system/README.md
  • Spec/test-case planning or TC mapping: feature-docs-reference.md
  • Integration test implementation/review: integration-test-reference.md
  • E2E test implementation/review: e2e-test-reference.md
  • Code review/audit work: code-review-rules.md plus domain docs above based on changed files

Do not read all docs blindly. Start from docs-index-reference.md, then open only relevant files for the task.

<!-- CODEX:PROJECT-REFERENCE-LOADING:END -->

[IMPORTANT] MUST ATTENTION keep task tracking synchronized, preserve evidence gates, and NEVER skip mandatory steps.

[DEPRECATED] This skill has been merged into $tdd-spec. Use $tdd-spec [direction=sync] instead.

  • Forward sync (feature docs → dashboard): $tdd-spec [direction=sync]
  • Reverse sync (dashboard → feature docs): $tdd-spec [direction=reverse]
  • Bidirectional reconciliation: $tdd-spec [direction=full]

All sync algorithms, orphan detection, staleness tracking, and quality gates are now in $tdd-spec under the ## Mode: Sync to Dashboard section.

Quick Summary

Goal: [DEPRECATED] This skill has been merged into tdd-spec. Use $tdd-spec [direction=sync] for forward sync, $tdd-spec [direction=reverse] for reverse sync, $tdd-spec [direction=full] for bidirectional reconciliation.

Workflow:

  1. Detect — classify request scope and target artifacts.
  2. Execute — apply required steps with evidence-backed actions.
  3. Verify — confirm constraints, output quality, and completion evidence.

Key Rules:

  • MUST ATTENTION keep claims evidence-based (file:line) with confidence >80% to act.
  • MUST ATTENTION keep task tracking updated as each step starts/completes.
  • NEVER skip mandatory workflow or skill gates.

Closing Reminders

IMPORTANT MUST ATTENTION apply Phase 1 compression before structural enhancement; preserve semantic meaning. IMPORTANT MUST ATTENTION NEVER alter YAML frontmatter, code blocks, tables, or SYNC-tag bodies during optimization. IMPORTANT MUST ATTENTION keep evidence gates and mandatory workflow/skill steps explicit and enforceable. IMPORTANT MUST ATTENTION add a final review task to verify output quality and unresolved risks.

<!-- CODEX:SYNC-PROMPT-PROTOCOLS:START -->

Hookless Prompt Protocol Mirror (Auto-Synced)

Source: .claude/hooks/lib/prompt-injections.cjs + .claude/.ck.json

[WORKFLOW-EXECUTION-PROTOCOL] [BLOCKING] Workflow Execution Protocol — MANDATORY IMPORTANT MUST CRITICAL. Do not skip for any reason.

  1. DETECT: Match prompt against workflow catalog
  2. ANALYZE: Find best-match workflow AND evaluate if a custom step combination would fit better
  3. ASK (REQUIRED FORMAT): Use a direct user question with this structure:
    • Question: "Which workflow do you want to activate?"
    • Option 1: "Activate [BestMatch Workflow] (Recommended)"
    • Option 2: "Activate custom workflow: [step1 → step2 → ...]" (include one-line rationale)
  4. ACTIVATE (if confirmed): Call $workflow-start <workflowId> for standard; sequence custom steps manually
  5. CREATE TASKS: task tracking for ALL workflow steps
  6. EXECUTE: Follow each step in sequence [CRITICAL-THINKING-MINDSET] Apply critical thinking, sequential thinking. Every claim needs traced proof, confidence >80% to act. Anti-hallucination principle: Never present guess as fact — cite sources for every claim, admit uncertainty freely, self-check output for errors, cross-reference independently, stay skeptical of own confidence — certainty without evidence root of all hallucination. AI Attention principle (Primacy-Recency): Put the 3 most critical rules at both top and bottom of long prompts/protocols so instruction adherence survives long context windows.

Learned Lessons

Lessons Learned

[CRITICAL] Hard-won project debugging/architecture rules. MUST ATTENTION apply BEFORE forming hypothesis or writing code.

Quick Summary

Goal: Prevent recurrence of known failure patterns — debugging, architecture, naming, AI orchestration, environment.

Top Rules (apply always):

  • MUST ATTENTION verify ALL preconditions (config, env, DB names, DI regs) BEFORE code-layer hypothesis
  • MUST ATTENTION fix responsible layer — NEVER patch symptom sites with caller-specific defensive code
  • MUST ATTENTION use ExecuteInjectScopedAsync for parallel async + repo/UoW — NEVER ExecuteUowTask
  • MUST ATTENTION name by PURPOSE not CONTENT — adding member forces rename = abstraction broken
  • MUST ATTENTION persist sub-agent findings incrementally after each file — NEVER batch at end
  • MUST ATTENTION Windows bash: verify Python alias (where python/where py) — NEVER assume python/python3 resolves

Debugging & Root Cause Reasoning

  • [2026-04-11] Holistic-first: verify environment before code. Failure → list ALL preconditions (config, env vars, DB names, endpoints, DI regs, credentials, permissions, data prerequisites) → verify each via evidence (grep/cat/query) BEFORE code-layer hypothesis. Worst rabbit holes: diving nearest layer while bug sits elsewhere — e.g., hours debugging "sync timeout", real cause: test appsettings pointing wrong DB. ALWAYS cheapest check first.
  • [2026-04-01] Ask "whose responsibility?" before fixing. Trace: bug caller (wrong data) or callee (wrong handling)? Fix responsible layer — NEVER patch symptom site masking real issue.
  • [2026-04-01] Trace data lifecycle, not error site. Follow data: creation → transformation → consumption. Bug usually where data created wrong, not consumed.
  • [2026-04-01] Code caller-agnostic. Functions/handlers/consumers don't know who invokes them. Comments/guards/messages describe business intent — NEVER reference specific callers (tests, seeders, scripts).

Architecture Invariants

  • [2026-05-09] User name materialization MUST ATTENTION go through User.UpdateName(firstName, middleName, lastName). Domain method (src/Services/bravoTALENTS/Employee.Domain/AggregatesModel/User.cs:202-209) recomputes FullName as single source of truth. Three sites still manually patch user.FullName = user.GetFullName() after assigning name fields — src/Services/bravoTALENTS/Employee.Application/Factories/UserFactory.cs:50, src/Services/bravoSURVEYS/LearningPlatform.Application/ApplyPlatform/MessageBus/Consumers/AccountUserDeletedEventBusConsumer.cs:102, src/Services/bravoINSIGHTS/Analyze/Analyze.Application/MessageBus/Consumers/AccountUserDeletedEventBusConsumer.cs:66. Next time touching any: replace manual patch with user.UpdateName(...) to maintain invariant.
  • [2026-03-31] ParallelAsync + repo/UoW MUST ATTENTION use ExecuteInjectScopedAsync, NEVER ExecuteUowTask. ExecuteUowTask creates new UoW but reuses outer DI scope (same DbContext) — parallel iterations sharing non-thread-safe DbContext silently corrupt data. ExecuteInjectScopedAsync creates new UoW + new DI scope (fresh repo per iteration).
  • [2026-03-31] Bus message naming MUST ATTENTION include service name prefix — core services NEVER consume feature events. Prefix declares schema ownership (AccountUserEntityEventBusMessage = Accounts owns). Core services (Accounts, Communication) leaders. Feature services (Growth, Talents) sending to core MUST ATTENTION use {CoreServiceName}...RequestBusMessage — NEVER define own event for core to consume.

Naming & Abstraction

  • [2026-04-12] Name PURPOSE not CONTENT — "OrXxx" anti-pattern. HrManagerOrHrOrPayrollHrOperationsPolicy names set members, not what guards. Add role → rename = broken abstraction. Rule: names express DOES/GUARDS, not CONTAINS. Test: adding/removing member forces rename? YES = content-driven = bad → rename to purpose (e.g., HrOperationsAccessPolicy). Nuance: "Or" fine behavioral idioms (FirstOrDefault, SuccessOrThrow) — expresses HAPPENS, not membership.

Environment & Tooling

  • [2026-04-20] Windows bash: NEVER assume python/python3 resolves — verify alias first. Python may not be bash PATH under those names. Check: where python / where py. ALWAYS prefer py (Windows Python Launcher) one-liners, node if JS alternative exists.

Test-specific lessons → docs/project-reference/integration-test-reference.md Lessons Learned section. Production-code anti-patterns → docs/project-reference/backend-patterns-reference.md Anti-Patterns section. Generic debugging/refactoring reminders → System Lessons .claude/hooks/lib/prompt-injections.cjs.


Closing Reminders

  • IMPORTANT MUST ATTENTION holistic-first: verify ALL preconditions (config, env, DB names, endpoints, DI regs) BEFORE code-layer hypothesis — cheapest check first
  • IMPORTANT MUST ATTENTION fix responsible layer — NEVER patch symptom site; trace caller (wrong data) vs callee (wrong handling), fix root owner
  • IMPORTANT MUST ATTENTION parallel async + repo/UoW → ALWAYS ExecuteInjectScopedAsync, NEVER ExecuteUowTask (shared DbContext = silent data corruption)
  • IMPORTANT MUST ATTENTION bus message prefix = schema ownership; feature services NEVER define events for core services — use {CoreServiceName}...RequestBusMessage
  • IMPORTANT MUST ATTENTION name by PURPOSE — adding/removing member forces rename = broken abstraction
  • IMPORTANT MUST ATTENTION sub-agents MUST write findings after each file/section — NEVER batch all findings into one final write
  • IMPORTANT MUST ATTENTION Windows bash: NEVER assume python/python3 resolves — run where python/where py first, use py launcher or node
  • IMPORTANT MUST ATTENTION every claim needs file:line evidence — confidence >80% to act, NEVER speculate

[LESSON-LEARNED-REMINDER] [BLOCKING] Task Planning & Continuous Improvement — MANDATORY. Do not skip.

Break work into small tasks (task tracking) before starting. Add final task: "Analyze AI mistakes & lessons learned".

Extract lessons — ROOT CAUSE ONLY, not symptom fixes:

  1. Name the FAILURE MODE (reasoning/assumption failure), not symptom — "assumed API existed without reading source" not "used wrong enum value".
  2. Generality test: does this failure mode apply to ≥3 contexts/codebases? If not, abstract one level up.
  3. Write as a universal rule — strip project-specific names/paths/classes. Useful on any codebase.
  4. Consolidate: multiple mistakes sharing one failure mode → ONE lesson.
  5. Recurrence gate: "Would this recur in future session WITHOUT this reminder?" — No → skip $learn.
  6. Auto-fix gate: "Could $code-review/$code-simplifier/$security/$lint catch this?" — Yes → improve review skill instead.
  7. BOTH gates pass → ask user to run $learn. [TASK-PLANNING] [MANDATORY] BEFORE executing any workflow or skill step, create/update task tracking for all planned steps, then keep it synchronized as each step starts/completes.
<!-- CODEX:SYNC-PROMPT-PROTOCOLS:END -->