@minhduydev/mdpi 0.3.0

package/dist/template/.pi/skills/agent-code-quality-gate/SKILL.md

@@ -0,0 +1,131 @@
+---
+name: agent-code-quality-gate
+description: Use before a coding agent claims implementation work is complete, especially after bugfixes, feature edits, refactors, or subagent changes - converts code quality into an operational gate for scope, duplication, behavior tests, verification evidence, and regressions.
+---
+
+# Agent Code Quality Gate
+
+## Overview
+
+Code quality for an agent is not "clean-looking code." It is a small, reviewable, verified change that improves or preserves system health while solving the requested problem.
+
+Core rule: **do not claim completion until the diff is scoped, integrated, tested for behavior, and freshly verified.**
+
+## When to Use
+
+Use before saying work is complete, fixed, passing, ready, or high quality after:
+
+- implementing a feature or bugfix;
+- editing production code or tests;
+- receiving subagent/worker changes;
+- refactoring, optimizing, or migrating code;
+- touching security, auth, data, concurrency, payments, accessibility, performance, or public APIs.
+
+Do not use as a substitute for specialist review. For final merge/security/API review, also load the relevant review/security/API skill.
+
+## When NOT to Use
+
+- The change is trivial (typo, rename, formatting) with no behavior impact
+- You haven't implemented anything yet — the gate is for claiming completion, not starting
+- For specialist review needs (security audit, API contract, merge approval) — load the dedicated review/security/API skill instead of relying on this gate alone
+
+## Quality Gate
+
+Answer every item. If any answer is "no" or "unknown," either fix it, verify it, or report the remaining risk explicitly.
+
+| Gate | Pass condition | Reject if |
+| --- | --- | --- |
+| Goal | The change satisfies the user's actual request and acceptance criteria. | It solves a nearby or imagined problem. |
+| Scope | Every changed line traces to the current request. | Drive-by cleanup, broad formatting, or speculative refactor is mixed in. |
+| Design fit | The change belongs in the touched layer and follows existing architecture. | It adds a parallel pattern, hidden business logic, or misplaced abstraction. |
+| Simplicity | The solution is the smallest clear working change. | It adds flexibility for hypothetical future needs. |
+| Duplication | Existing helpers/components/patterns were searched and reused. | A second home for the same concept was created. |
+| Behavior | Relevant happy path, edge cases, and failure path were considered. | Only the obvious path works. |
+| Tests | Tests are meaningful for behavior and would fail if the behavior broke. | Tests only assert mocks, snapshots, implementation details, or coverage numbers. |
+| Verification | Fresh relevant lint/typecheck/test/build/manual check evidence exists. | Success is inferred from code appearance or a subagent report. |
+| Regressions | Security, reliability, performance, accessibility, compatibility, and developer workflow are not worsened. | Any regression is unexamined or hand-waved. |
+| Reviewability | Diff is coherent and easy to review. | Reviewer must reverse-engineer why unrelated changes exist. |
+
+## Agent-Specific Failure Modes
+
+Brutally check for these before completion:
+
+- **Hallucinated API:** Did you verify signatures/options against local types, source, or official docs?
+- **Fake confidence:** Are you saying "should work" instead of citing command output or runtime evidence?
+- **Subagent trust:** Did you read changed files and verify independently instead of trusting a summary?
+- **Mock theater:** Do tests prove production behavior, or just that mocks were called?
+- **Coverage worship:** Coverage can reveal untested code; it does not prove test quality.
+- **Speculative abstraction:** Did you add generic hooks/options/classes before the actual need exists?
+- **Duplicate utility:** Did you search before creating a helper/component/schema wrapper?
+- **Generated-file edit:** Did you modify generated output instead of the canonical schema/generator/input?
+- **Silent behavior change:** Did any external behavior, API shape, data format, or command contract change without explicit approval?
+- **Unreviewable diff:** Did formatting churn or cleanup obscure the real behavior change?
+
+## Minimal Completion Procedure
+
+1. Re-read the user request and acceptance criteria.
+2. Inspect the diff, not just the files.
+3. Remove unrelated or speculative changes.
+4. Search for existing concepts before keeping new helpers/components.
+5. Check behavioral edges: invalid input, empty state, permission failure, error path, concurrency/race risk where relevant.
+6. Run the smallest relevant verification first; expand only if risk requires it.
+7. If tests were added or changed, run those tests directly and confirm they fail for the right reason when practical.
+8. Record exact evidence in the final response: command/check + result + remaining risk.
+
+## Source-Backed Principles
+
+- Google Engineering Practices: approve changes that improve overall code health; reject changes that worsen it even if they appear functional. Review design, functionality, complexity, tests, names, comments, style, consistency, docs, and every relevant line.
+- Martin Fowler on test coverage: coverage is useful for finding untested code, but high coverage is not proof of good tests.
+- OWASP Secure Coding Practices: quality includes input validation, output encoding, auth/session/access control, cryptography, error handling/logging, data protection, database/file/memory safety, and general secure coding.
+
+## Final Response Evidence Pattern
+
+Use this shape when reporting completion:
+
+```text
+Changed <what> in <file:line> to satisfy <requirement>.
+Verification: <command/check> passed/failed with <specific result>.
+Risk: <none known | untested area and why>.
+```
+
+Never say "done," "fixed," "passes," or "high quality" without fresh evidence.
+
+## Skill Result Contract
+
+```xml
+<skill_result>
+  <skill>agent-code-quality-gate</skill>
+  <status>success|partial|blocked|failure</status>
+  <evidence>Diff reviewed, scope checked, tests/verification run, sources checked if APIs used</evidence>
+  <artifacts>Files reviewed or commands run</artifacts>
+  <risks>Remaining unverified paths or none</risks>
+</skill_result>
+```
+
+## Common Rationalizations
+
+| Rationalization | Reality |
+|---|---|
+| "The tests pass, it's done" | Passing tests ≠ correct scope, clean diff, or safe behavior. |
+| "The subagent said it was fine" | Subagent reports are self-assessments. Always verify independently. |
+| "The changes are small, no gate needed" | Small changes introduce regressions too. The gate is proportional, not optional. |
+| "I reviewed it myself" | Authors are blind to their own assumptions. Independent verification matters. |
+
+## Red Flags
+
+- Subagent completion claimed without diff review
+- Verification evidence that doesn't match the reported changes
+- Scope creep in implementation (touched files outside task description)
+- No regression test for the changed behavior
+- Duplication of existing patterns instead of reuse
+
+## Verification
+
+Before claiming implementation work is complete:
+
+- [ ] All changes are within the agreed scope (no unrelated files touched)
+- [ ] No code duplication was introduced that could reuse existing patterns
+- [ ] Tests pass and cover the changed behavior with regression protection
+- [ ] Diff review confirms changes match the task description
+- [ ] Subagent-reported evidence was independently verified
+- [ ] Lint, typecheck, and build pass

package/dist/template/.pi/skills/api-and-interface-design/SKILL.md

@@ -0,0 +1,159 @@
+---
+name: api-and-interface-design
+description: Use when designing REST/GraphQL APIs, SDK interfaces, or public module boundaries — covers contract-first design, versioning, error shapes, and backward compatibility
+---
+
+# API & Interface Design
+
+> **Replaces** ad-hoc API creation where endpoints, error shapes, and versioning are afterthoughts
+
+## When to Use
+
+- Designing a new API endpoint, SDK method, or public module interface
+- Reviewing or extending an existing API for backward compatibility
+- Defining error responses, pagination, or authentication contracts
+
+## When NOT to Use
+
+- Internal-only helper functions that no external code calls
+- Prototyping where the API shape will change frequently (use after stabilization)
+
+## Overview
+
+APIs are contracts. Once published, they're hard to change without breaking consumers. Design the contract first, implement second.
+
+**Core principle:** Define the contract (types, errors, versioning) before writing implementation. Make breaking changes impossible through careful interface design.
+
+## Contract-First Process
+
+```
+1. DEFINE  — Write TypeScript types / OpenAPI schema for request & response
+2. REVIEW  — Check backward compatibility, error coverage, naming consistency
+3. IMPLEMENT — Code against the contract, not the other way around
+4. VERIFY  — Validate implementation matches contract exactly
+```
+
+## API Design Checklist
+
+### Naming
+
+- [ ] Resource-oriented URLs (nouns, not verbs): `/users/{id}` not `/getUser`
+- [ ] Consistent casing (camelCase for JSON fields, kebab-case for URLs)
+- [ ] Plural collection names: `/users` not `/user`
+- [ ] Avoid abbreviations — `configuration` not `config` in public APIs
+
+### Request Design
+
+- [ ] Use appropriate HTTP methods (GET reads, POST creates, PUT replaces, PATCH updates, DELETE removes)
+- [ ] Validate all input with schemas (zod, JSON Schema) at the boundary
+- [ ] Accept only what you need — reject unknown fields
+- [ ] Use query params for filtering/pagination, body for creation/mutation
+
+### Response Design
+
+- [ ] Consistent envelope: `{ data, error, meta }` or flat depending on convention
+- [ ] Include pagination metadata: `{ total, page, pageSize, hasMore }`
+- [ ] Return created/updated resource in mutation responses
+- [ ] Use ISO 8601 for dates, UTC always
+
+### Error Design
+
+```typescript
+// Consistent error shape
+interface ApiError {
+  code: string; // machine-readable: "VALIDATION_ERROR", "NOT_FOUND"
+  message: string; // human-readable description
+  details?: unknown; // field-level errors, context
+  requestId?: string; // correlation ID for debugging
+}
+```
+
+- [ ] Use standard HTTP status codes correctly (400 vs 422 vs 500)
+- [ ] Never expose stack traces or internal errors to clients
+- [ ] Include actionable error messages
+- [ ] Document all possible error codes per endpoint
+
+### Versioning
+
+| Strategy      | When                               | Example                               |
+| ------------- | ---------------------------------- | ------------------------------------- |
+| URL prefix    | Breaking changes to resources      | `/v1/users`, `/v2/users`              |
+| Header        | Breaking changes, same URL desired | `Accept: application/vnd.api.v2+json` |
+| Query param   | Simple, low-ceremony               | `/users?version=2`                    |
+| No versioning | Internal APIs, single consumer     | Direct updates                        |
+
+**Default:** URL prefix versioning for public APIs, no versioning for internal.
+
+### Backward Compatibility Rules
+
+| Safe (Non-Breaking)       | Unsafe (Breaking)        |
+| ------------------------- | ------------------------ |
+| Add optional fields       | Remove or rename fields  |
+| Add new endpoints         | Change field types       |
+| Add new enum values       | Remove enum values       |
+| Widen input validation    | Tighten input validation |
+| Add optional query params | Change URL structure     |
+
+## Common Rationalizations
+
+| Excuse                           | Rebuttal                                                                 |
+| -------------------------------- | ------------------------------------------------------------------------ |
+| "It's just an internal API"      | Internal APIs become external. Design the contract now.                  |
+| "We can change it later"         | Every consumer you add makes changes harder. Get it right early.         |
+| "The frontend team will adapt"   | Consumers shouldn't break because you didn't plan the interface.         |
+| "Error handling is boilerplate"  | Inconsistent errors cause more debugging than any boilerplate saves.     |
+| "Versioning is overkill for now" | Adding versioning later requires migrating all consumers simultaneously. |
+
+## TypeScript Patterns
+
+### Strict Input/Output Types
+
+```typescript
+// [x] Separate input and output types
+interface CreateUserInput {
+  name: string;
+  email: string;
+}
+
+interface User {
+  id: string;
+  name: string;
+  email: string;
+  createdAt: string; // ISO 8601
+}
+
+// [x] Validate at boundary
+const createUserSchema = z.object({
+  name: z.string().min(1).max(100),
+  email: z.string().email(),
+});
+```
+
+### Discriminated Unions for Results
+
+```typescript
+type ApiResult<T> = { success: true; data: T } | { success: false; error: ApiError };
+```
+
+## Red Flags — STOP
+
+- Endpoint returns different shapes depending on internal state
+- Error responses have no consistent structure
+- URL contains verbs (`/createUser`, `/deleteItem`)
+- No input validation at the API boundary
+- Response includes internal database IDs or implementation details
+- Breaking change deployed without version bump
+
+## Verification
+
+- [ ] All endpoints have typed request/response schemas
+- [ ] Error responses follow the consistent error shape
+- [ ] Breaking changes increment the API version
+- [ ] Input validation rejects invalid/extra fields
+- [ ] Response matches documented contract exactly
+
+## See Also
+
+- **defense-in-depth** — Validation at every layer, not just the API boundary
+- **incremental-implementation** — Build API endpoints as thin vertical slices
+- **test-driven-development** — Write API contract tests before implementation

package/dist/template/.pi/skills/behavioral-kernel/SKILL.md

@@ -0,0 +1,92 @@
+---
+name: behavioral-kernel
+description: Use when work starts drifting into silent assumptions, overengineering, drive-by refactors, or vague completion claims. Re-centers the agent on a compact Pi-native execution kernel with concrete anti-pattern examples.
+---
+
+# Behavioral Kernel
+
+A short reset skill for non-trivial work when the larger prompt is getting noisy.
+
+## When to Use
+
+- Work is drifting into silent assumptions, overengineering, or drive-by refactors
+- You're about to add abstraction for a single use case
+- You're changing adjacent code "while you're here"
+- Completion is being claimed without a named proof path
+- You're silently picking one interpretation from multiple valid readings
+
+## When NOT to Use
+
+- The task is a trivial, single-step change with an obvious answer
+- You already surfaced assumptions and named the verification path up front
+- Pure lookup/reference questions (no decision or diff involved)
+
+## Kernel
+
+1. **Clarify before committing** — surface assumptions or ask instead of silently choosing.
+2. **Choose the smallest working change** — solve today's problem directly before inventing flexibility.
+3. **Keep diffs surgical** — change only what the request requires; log unrelated issues and keep moving.
+4. **Define proof before acting** — say how success will be verified before implementation, then run that proof after.
+
+## Apply the Kernel
+
+Before coding, write down:
+
+- the ambiguity or assumptions in 1-3 bullets
+- the smallest acceptable diff
+- what you are explicitly not touching
+- the verification command, test path, or evidence you will use
+
+## Drift Signals
+
+Stop and reload this kernel if you catch yourself:
+
+- adding abstraction for a single use case
+- changing adjacent code "while you're here"
+- postponing verification until the end
+- claiming completion without a named proof path
+- silently picking one interpretation from multiple valid readings
+
+## Recovery Move
+
+When drift is detected:
+
+1. Re-state the request in one sentence.
+2. Re-state the smallest working change.
+3. Re-state the proof path.
+4. Delete or avoid anything outside that boundary.
+
+## Pi-Specific Notes
+
+- pi-srcwalk tools (`semantic_query`, `semantic_inspect`, `semantic_grep`, `semantic_show`) replace srcwalk CLI
+- pi-search tools (`websearch`, `codesearch`, `context7`, `grepsearch`, `web_fetch`) replace webclaw
+- `memory_search` (pi-hermes-memory) = durable LTM across sessions; `vcc_recall` = active-session history (not LTM)
+- `subagent` tool replaces `task()` for delegation
+- Avoid building "infrastructure for infrastructure's sake" — Pi already has 13 npm extensions
+
+## Common Rationalizations
+
+| Rationalization | Reality |
+|---|---|
+| "I know what to do without reading the skill" | Drift happens silently. Re-read the kernel before it compounds. |
+| "This edge case isn't important right now" | Edge cases ignored become edge-case bugs in production later. |
+| "I'll just make this one quick change" | "Quick changes" outside scope are the primary vector for entropy. |
+| "The skill is too restrictive for this task" | The restrictions exist because they prevent known failure modes. |
+
+## Red Flags
+
+- Adding abstraction for a single use case
+- Changing adjacent code "while you're here"
+- Postponing verification until the end
+- Claiming completion without a named proof path
+- Silently picking one interpretation from multiple valid readings
+
+## Verification
+
+After applying the behavioral kernel:
+
+- [ ] The task scope is clearly defined and bounded
+- [ ] No unrelated code was modified "while you're here"
+- [ ] The smallest working change was chosen for each step
+- [ ] Verification evidence exists before any completion claim
+- [ ] Assumptions were surfaced and confirmed, not silently acted on

package/dist/template/.pi/skills/brainstorming/SKILL.md

@@ -0,0 +1,138 @@
+---
+name: brainstorming
+description: Use when creating or developing, before writing code or implementation plans - refines rough ideas into fully-formed designs through collaborative questioning, alternative exploration, and incremental validation. Don't use during clear 'mechanical' processes
+---
+
+# Brainstorming Ideas Into Designs
+
+> **Replaces** jumping straight to implementation without exploring alternatives, constraints, or edge cases
+## When to Use
+
+- You have a rough idea that needs clarification into a design or spec
+- You need to explore multiple approaches and validate trade-offs before coding
+
+## When NOT to Use
+
+- Requirements are already clear and execution is mechanical
+- You are already in implementation with a validated plan or PRD
+
+## Overview
+
+Help turn ideas into fully formed designs and specs through natural collaborative dialogue.
+
+Start by understanding the current project context, then ask questions one at a time to refine the idea. Once you understand what you're building, present the design in small sections (200-300 words), checking after each section whether it looks right so far.
+
+**Part of:** `development-lifecycle` skill (Phase 1: Ideation)
+
+**Output template:** `.pi/templates/design.md`
+
+## The Process
+
+**Understanding the idea:**
+
+- Check out the current project state first (files, docs, recent commits)
+- Ask questions one at a time to refine the idea
+- Prefer multiple choice questions when possible, but open-ended is fine too
+- Only one question per message - if a topic needs more exploration, break it into multiple questions
+- Focus on understanding: purpose, constraints, success criteria
+
+**Exploring approaches:**
+
+- Propose 2-3 different approaches with trade-offs
+- Present options conversationally with your recommendation and reasoning
+- Lead with your recommended option and explain why
+
+**Presenting the design:**
+
+- Once you believe you understand what you're building, present the design
+- Break it into sections of 200-300 words
+- Ask after each section whether it looks right so far
+- Cover: architecture, components, data flow, error handling, testing
+- Be ready to go back and clarify if something doesn't make sense
+
+## After the Design
+
+**Documentation:**
+
+- Write the validated design to `.pi/artifacts/<slug>/design.md`
+- Use template from `.pi/templates/design.md`
+- Use elements-of-style:writing-clearly-and-concisely skill if available
+- Commit the design document to git
+
+**Next Phase (if continuing):**
+
+- Ask: "Ready to create the PRD?"
+- Load next skill: `spec-driven-development` (auto-discovered from `.pi/skills/`)
+- This moves to Phase 2: Specification
+
+**Alternative paths:**
+
+- Use `using-git-worktrees` skill to create isolated workspace first
+- Use `planning-and-task-breakdown` skill if skipping formal PRD
+
+**Full lifecycle reference:**
+
+- Use `development-lifecycle` skill to see all phases
+
+## Key Principles
+
+- **One question at a time** - Don't overwhelm with multiple questions
+- **Multiple choice preferred** - Easier to answer than open-ended when possible
+- **YAGNI ruthlessly** - Remove unnecessary features from all designs
+- **Explore alternatives** - Always propose 2-3 approaches before settling
+- **Incremental validation** - Present design in sections, validate each
+- **Be flexible** - Go back and clarify when something doesn't make sense
+
+## Example Flow
+
+**User request**: "Add dark mode to the app"
+
+**Good brainstorming questions**:
+1. "Should dark mode be system-preference-aware, manual toggle, or both?"
+2. "Where does theme state live — CSS variables, React context, localStorage?"
+3. "Are there existing color tokens, or do we need to create a design token system?"
+4. "What about images/icons — do they need dark variants?"
+
+**Bad brainstorming** (jumping to solution):
+1. "I'll add a ThemeContext with useState and toggle button" ← skipped alternatives
+
+## Anti-Patterns
+
+| Anti-Pattern | Why It Fails | Instead |
+| --- | --- | --- |
+| Asking questions the codebase can answer (search first) | Wastes turns and slows decisions; signals weak preparation | Do quick repo/docs lookup first, then ask only unresolved questions |
+| Brainstorming during mechanical/routine tasks | Adds overhead when execution is already clear | Skip to execution using the relevant implementation skill |
+| Generating 10+ alternatives without narrowing criteria | Creates analysis paralysis and no decision pressure | Present 2-3 viable options with explicit decision criteria |
+| Continuing to brainstorm after a clear direction emerges | Burns time and erodes momentum | Confirm direction, summarize decisions, transition to PRD/plan |
+
+## See Also
+
+- `planning-and-task-breakdown` - Turn validated direction into zero-ambiguity implementation tasks
+- `spec-driven-development` - Capture behavioral requirements before implementation
+
+## Common Rationalizations
+
+| Rationalization | Reality |
+|---|---|
+| "I already know what to build" | Premature convergence is the #1 cause of wrong solutions. Explore alternatives first. |
+| "Asking too many questions wastes time" | 10 questions now saves 10 hours of rework later. |
+| "We'll figure out edge cases during implementation" | Edge cases discovered late become hacks. Surface them during design. |
+| "The first idea is usually the best" | First ideas are biased by recency and familiarity. Generate alternatives. |
+
+## Red Flags
+
+- Jumping to implementation without exploring alternatives
+- Asking zero clarification questions before proposing a design
+- The design is a single paragraph with no trade-offs discussed
+- User's first idea accepted as final without alternatives explored
+- Design doesn't reference existing codebase patterns or constraints
+
+## Verification
+
+After completing a brainstorming session:
+
+- [ ] At least 2-3 distinct approaches were explored and compared
+- [ ] Trade-offs for each approach are documented
+- [ ] The recommended approach has clear rationale
+- [ ] Key assumptions are surfaced and validated
+- [ ] The design is written to `.pi/artifacts/<slug>/design.md`

package/dist/template/.pi/skills/browser-testing-with-devtools/SKILL.md

@@ -0,0 +1,90 @@
+---
+name: browser-testing-with-devtools
+description: "Use when verifying or debugging browser behavior with live runtime evidence: DOM state, console errors, network requests, screenshots, performance traces, or end-to-end user flows. Routes between Chrome DevTools and Playwright."
+---
+
+# Browser Testing with DevTools
+
+## Overview
+
+Browser testing proves what users actually experience. Use runtime evidence instead of assuming UI code works from static inspection.
+
+## When to Use
+
+- Building, debugging, or reviewing anything that runs in a browser.
+- Validating forms, navigation, responsive layout, accessibility-visible state, or screenshots.
+- Investigating console errors, network failures, hydration issues, or performance regressions.
+- Reproducing bugs that only appear in a real browser runtime.
+
+## When NOT to Use
+
+- Pure backend or CLI-only changes.
+- Unit-level logic that is faster and clearer to test without a browser.
+
+## Tool Routing
+
+| Need | Use |
+| --- | --- |
+| Cross-browser automation, screenshots, repeatable flows | `playwright` |
+| Live Chrome inspection, console/network/runtime state | `chrome-devtools` |
+| Bot-protected docs or static page extraction | `webclaw` (load via `/skill:webclaw`) |
+| UI implementation guidance | `frontend-design` |
+
+## Process
+
+1. Define the user-visible behavior to prove.
+2. Start the app or identify the target URL.
+3. Choose the lightest browser tool that can produce evidence.
+4. Capture initial state: page URL, screenshot or DOM snapshot, console/network baseline if relevant.
+5. Exercise the user flow with stable selectors or accessible labels.
+6. Capture final evidence: screenshot, DOM state, response status, console output, or trace.
+7. If a bug appears, hand off to `debugging-and-error-recovery` with reproduction steps.
+8. Record exact commands/tool actions and observed result.
+
+## Common Rationalizations
+
+| Rationalization | Rebuttal |
+| --- | --- |
+| "The component compiles, so the browser is fine." | Runtime integration, CSS, hydration, and network behavior fail outside compilation. |
+| "A screenshot is enough." | Screenshots miss console errors, failed requests, and inaccessible states. |
+| "Manual clicking is faster." | Repeatable scripted flows create evidence and prevent regression. |
+| "The test is flaky, just wait longer." | Use condition-based waiting and prove the actual state changed. |
+
+## Red Flags
+
+- No browser evidence for UI behavior changes.
+- Ignored console errors or failed network requests.
+- Arbitrary sleeps instead of waiting for conditions.
+- Screenshots captured before animations/data loading settle.
+- Selectors coupled to fragile layout instead of accessible names or stable IDs.
+
+## Verification
+
+Before declaring browser work complete, provide:
+
+- URL or local command used.
+- Browser tool used and why.
+- Screenshots, traces, console/network output, or test result.
+- Any untested browsers/devices and residual risk.
+
+## Skill Result Contract
+
+```xml
+<skill_result>
+  <skill>browser-testing-with-devtools</skill>
+  <status>completed|blocked|skipped</status>
+  <artifacts>Screenshot, trace, test file, console/network log, or none</artifacts>
+  <evidence>Commands/tool actions and observed browser result</evidence>
+  <risks>Untested browsers, flaky state, missing app server, or none</risks>
+</skill_result>
+```
+
+## Verification
+
+After browser testing:
+
+- [ ] All console errors are investigated and resolved or documented
+- [ ] Network requests return expected status codes
+- [ ] DOM state matches expected UI state at each step
+- [ ] Performance trace shows acceptable metrics for key flows
+- [ ] Cross-browser testing completed (Chrome, Firefox, Safari)