@event4u/agent-config 1.9.1

package/.agent-src/skills/estimate-ticket/SKILL.md

@@ -0,0 +1,186 @@
+---
+name: "estimate-ticket"
+description: "Estimate a Jira/Linear ticket — 'estimate PROJ-123', 'wie groß ist das?', 'should we split this?' — size + risk + split + uncertainty, sibling of /refine-ticket, close-prompt."
+personas:
+  - developer
+  - senior-engineer
+  - product-owner
+  - stakeholder
+  - critical-challenger
+  - ai-agent
+source: package
+execution:
+  type: assisted
+  handler: internal
+  allowed_tools: []
+---
+
+# Estimate Ticket
+
+> Sibling of `/refine-ticket`. Takes the same input, returns **size**,
+> **risk**, **split recommendation**, and **uncertainty** — nothing
+> else. Separate from refinement so each stays sharp. Output is
+> copyable; write-back is user-gated.
+
+## When to use
+
+- Sprint planning: "how big is PROJ-123?"
+- Scope sanity: "should we split this?"
+- Confidence check: "do we actually understand this ticket?"
+- German: "wie groß ist das Ticket?", "sollen wir das splitten?",
+  "ist das ein Spike-Kandidat?"
+
+## When NOT to use (near-misses)
+
+| Phrasing | Route to |
+|---|---|
+| "refine the ticket" / "tighten AC" | `/refine-ticket` (sibling) |
+| "plan this feature" | `/feature-plan` (downstream) |
+| "is this a duplicate?" | `validate-feature-fit` (sub-skill) |
+| "threat-model this" | `threat-modeling` (sub-skill) |
+| "investigate this bug" | `/bug-investigate` |
+
+`/estimate-ticket` does **not** rewrite the ticket. If the ticket is
+too vague to estimate, output says so and routes to `/refine-ticket`.
+
+## Inputs
+
+Same four paths as `/refine-ticket` (delegates to `jira-ticket` loader):
+ticket key, branch-name detection, pasted text, URL.
+
+## Procedure
+
+### 1. Load ticket
+
+Delegate to `jira-ticket` §1-3 (key / URL / branch → Jira API fetch,
+summary + description + AC + comments). For pasted text: parse markdown.
+
+### 2. Inspect estimability
+
+Before producing numbers, check:
+
+- Is the outcome observable (AC bullets concrete)?
+- Is the scope one behavior, or bundled?
+- Are external dependencies (APIs, teams, migrations) named?
+- Is there a rollback plan implied?
+
+If the ticket scores low on estimability (vague AC, no out-of-scope,
+no mention of dependencies), set `uncertainty = Underspecified` and
+emit a single-line redirect to `/refine-ticket` at the top of the output.
+
+### 3. Apply sizing heuristics
+
+Score across four axes; each axis contributes to the final size:
+
+| Axis | Signals |
+|---|---|
+| **Surface area** | # of files / modules / layers touched |
+| **Unknowns** | # of "figure out", "investigate", "tbd" phrases |
+| **Coordination** | external teams, cross-service calls, migrations |
+| **Testing cost** | integration tests needed, manual verification steps |
+
+Map the combined score to `S` / `M` / `L` / `XL`:
+
+- **S** — single file / single layer / fully understood / unit tests suffice
+- **M** — 2-4 files / one service boundary / one unknown / some integration tests
+- **L** — multiple modules / cross-layer / 2+ unknowns / migrations or data changes
+- **XL** — multi-service / 3+ unknowns / coordination with another team — always recommend split
+
+### 4. Apply personas
+
+Same Core-6 as refine-ticket. Each voice produces one sentence focused
+on **their sizing concern**, not general feedback:
+
+- **Developer** — "implementation size feels X because Y"
+- **Senior Engineer** — "blast radius is X; hidden cost is Z"
+- **Product Owner** — "value is X; can we deliver value incrementally?"
+- **Stakeholder** — "timeline fit: X; drop-dead date risk: Y"
+- **Critical Challenger** — "this estimate is wrong because Z"
+- **AI Agent** — "automatable parts: X; manual parts: Y"
+
+`--personas=+qa` adds QA: "test surface is X; regression risk is Y".
+
+### 5. Synthesize + close-prompt
+
+Produce the four-section output (template below). After rendering,
+emit the close-prompt.
+
+## Output template
+
+````markdown
+## Estimate
+
+- **Size:** S / M / L / XL
+- **Risk:** Low / Medium / High
+- **Split:** No / Yes → <split points>
+- **Uncertainty:** High-confidence / Needs-spike / Underspecified
+
+## Sizing rationale
+
+<2-4 bullets citing the four axes — surface area, unknowns,
+coordination, testing cost — each with evidence from the ticket>
+
+## Split points (only if Split: Yes)
+
+1. <first slice — deliverable on its own>
+2. <second slice — deliverable on its own>
+3. …
+
+## Persona voices (sizing-focused)
+
+- **Developer** — <one sentence>
+- **Senior Engineer** — <one sentence>
+- **Product Owner** — <one sentence>
+- **Stakeholder** — <one sentence>
+- **Critical Challenger** — <one sentence>
+- **AI Agent** — <one sentence>
+- **[qa]** — *(only when `--personas=+qa`)* <one sentence>
+````
+
+Wrap the **Estimate** section in a copyable markdown block so it can
+be pasted into Jira / sprint tooling verbatim.
+
+## Close-prompt (mandatory final step)
+
+```
+> Next action for this estimate:
+>
+> 1. Comment on Jira — I'll post the estimate as a comment
+> 2. Set story points — I'll set the Story Points field (if your size maps: S=2, M=3, L=5, XL=8)
+> 3. Nothing — I'll handle it myself / take it to planning
+```
+
+Options 1 and 2 require `jira-ticket` write permissions; degrade to
+copy-paste instructions if missing.
+
+## Output format
+
+1. **Estimate** block with four fields (size, risk, split, uncertainty), wrapped in a copyable markdown block.
+2. **Sizing rationale** — 2-4 bullets, each citing one of the four axes with evidence from the ticket.
+3. **Split points** section — only when `Split: Yes`; numbered list of independently-deliverable slices.
+4. **Persona voices** — one sentence per persona from the active set, **sizing-focused** (not general feedback).
+5. **Close-prompt** — exactly three numbered options (comment / set points / nothing); no fourth option in v1.
+
+## Gotcha
+
+- Estimators default to optimism. Every size must cite evidence for at least one of the four axes — not "feels like M".
+- `Underspecified` is not a safe default. Use it only when estimability actually fails; otherwise pick a size and state the risk.
+- `Split: Yes` without concrete split points is useless. Name the slices or drop the recommendation.
+- Persona voices drift into general feedback. Each sentence must be about **sizing** — developer talks implementation size, stakeholder talks timeline fit, etc.
+- Story-point mapping (`S=2 / M=3 / L=5 / XL=8`) is the default; projects may override — do NOT hardcode their scale into this skill.
+
+## Do NOT
+
+- Do NOT rewrite the ticket — that's `/refine-ticket`. If the ticket needs rewriting, emit the redirect line and stop.
+- Do NOT write to Jira in v1 — copy-paste + close-prompt, same contract as `/refine-ticket`.
+- Do NOT chain into `/feature-plan` automatically — separate invocations by design.
+- Do NOT produce sizes without rationale — the bullets are mandatory, not optional.
+- Do NOT invent split points that share state with each other — every slice must be independently deliverable.
+
+## See also
+
+- [`refine-ticket`](../refine-ticket/SKILL.md) — sibling; refine first if the ticket is vague
+- [`jira-ticket`](../../commands/jira-ticket.md) — ticket loader
+- [`feature-plan`](../../commands/feature-plan.md) — downstream planning
+- [`road-to-ticket-refinement.md`](../../../agents/roadmaps/road-to-ticket-refinement.md) — governing roadmap
+- [`artifact-drafting-protocol`](../../rules/artifact-drafting-protocol.md) — drafting protocol

package/.agent-src/skills/estimate-ticket/evals/output-schema.yml

@@ -0,0 +1,20 @@
+# Output-schema contract for `estimate-ticket`.
+#
+# Locks the frozen three-section shape of the `## Output template`
+# block so refactors cannot silently drift the estimate output away
+# from what consumers copy-paste into Jira / sprint tooling. Enforced
+# by `scripts/skill_linter.py` (`lint_output_schema`) — a drift is a
+# hard error.
+#
+# `Split points` is intentionally omitted — it is conditional on
+# `Split: Yes` and not part of the always-present base shape.
+#
+# Governed by: road-to-trigger-evals.md Phase 3.5 (originally deferred
+# from archive/road-to-ticket-refinement.md Phase 1 per Q26).
+
+version: 1
+
+required_headers:
+  - "Estimate"
+  - "Sizing rationale"
+  - "Persona voices (sizing-focused)"

package/.agent-src/skills/estimate-ticket/evals/triggers.json

@@ -0,0 +1,18 @@
+{
+  "skill": "estimate-ticket",
+  "version": 1,
+  "should_trigger": [
+    "estimate PROJ-123",
+    "how big is this ticket?",
+    "should we split this?",
+    "wie groß ist das Ticket?",
+    "sollen wir das splitten?"
+  ],
+  "should_not_trigger": [
+    "refine this ticket",
+    "plan this feature",
+    "is PROJ-123 a duplicate of anything we already have?",
+    "threat-model this change",
+    "investigate this bug"
+  ]
+}

package/.agent-src/skills/fe-design/SKILL.md

@@ -0,0 +1,223 @@
+---
+name: fe-design
+description: "Use when designing frontend interfaces — component architecture, layout patterns, form design, table patterns, responsive strategies, and UX principles for Blade/Livewire/Flux/Tailwind."
+source: package
+---
+
+# Frontend Design Skill
+
+## When to use
+
+Use this skill when:
+- Planning a new page or feature UI before implementing
+- Choosing between component patterns (modal vs. inline, table vs. cards)
+- Designing forms with complex validation or multi-step flows
+- Making responsive design decisions
+- Reviewing UI for accessibility and usability
+- Deciding how to structure Livewire components
+
+## Procedure: Design a frontend interface
+
+1. **Understand requirements** — What data is shown? What actions are available? Who is the user?
+2. **Choose technology** — Pick from the project stack (see table below).
+3. **Design layout** — Mobile-first, component-based, consistent spacing.
+4. **Implement** — Build with Blade components, Livewire for interactivity, Flux for UI primitives.
+5. **Verify** — Check accessibility (labels, focus, contrast), responsive behavior, loading states.
+
+This project uses a server-rendered stack:
+
+| Layer | Technology | Skill |
+|---|---|---|
+| Templates | Laravel Blade | `blade-ui` |
+| Interactivity | Livewire 3 | `livewire` |
+| Component library | Flux (by Laravel) | `flux` |
+| Styling | Tailwind CSS | `tailwind` |
+| Icons | Heroicons / custom | — |
+
+**Key principle:** Server-first. Use Livewire for interactivity. Avoid JavaScript unless Livewire can't handle it (e.g., drag-and-drop, complex animations).
+
+## Component Architecture
+
+### Page structure
+
+```
+Page (Blade layout)
+├── Header (Blade partial)
+├── Navigation (Livewire — active state)
+├── Content area
+│   ├── Page heading + actions (Blade)
+│   ├── Filters (Livewire — reactive)
+│   ├── Data display (Livewire — table/cards)
+│   └── Pagination (Livewire)
+└── Footer (Blade partial)
+```
+
+### When to use what
+
+| Pattern | When | Example |
+|---|---|---|
+| **Blade partial** | Static content, no interactivity | Header, footer, static info |
+| **Blade component** | Reusable UI element, props only | Button, badge, card shell |
+| **Livewire component** | Needs server interaction or state | Forms, tables, filters |
+| **Flux component** | Standard UI element from library | Modal, dropdown, input, toast |
+| **Alpine.js** | Client-only micro-interaction | Toggle, accordion, clipboard |
+
+### Component granularity
+
+- **One Livewire component per concern** — don't build mega-components
+- **Compose with Blade components** inside Livewire for reusable UI pieces
+- **Use Flux for standard elements** — don't rebuild what Flux provides
+- **Extract when used 3+ times** — DRY applies to UI too
+
+## Form Design
+
+### Principles
+
+1. **Labels always visible** — no placeholder-only inputs
+2. **Validation on blur + submit** — immediate feedback, not on every keystroke
+3. **Error messages below the field** — red text, specific message
+4. **Required fields marked** — asterisk (*) or "(required)" label
+5. **Logical grouping** — related fields in sections with headings
+6. **Primary action prominent** — submit button stands out, cancel is secondary
+
+### Layout patterns
+
+| Fields | Layout | When |
+|---|---|---|
+| 1–3 fields | Single column | Simple forms (login, search) |
+| 4–8 fields | Two columns on desktop, single on mobile | Standard CRUD forms |
+| 8+ fields | Sections with headings or tabs/steps | Complex entity forms |
+| Related pairs | Side by side (first/last name, city/zip) | Logically paired fields |
+
+### Multi-step forms
+
+```
+Step indicator (1 — 2 — 3)
+├── Step 1: Basic info     → Next
+├── Step 2: Details        → Back / Next
+└── Step 3: Review + Submit → Back / Submit
+```
+
+- Show progress indicator (step numbers or progress bar)
+- Allow going back without losing data
+- Validate each step before allowing next
+- Show summary on final step
+
+## Table Design
+
+### Principles
+
+1. **Right-align numbers** — easier to compare
+2. **Left-align text** — natural reading direction
+3. **Sortable columns** — click header to sort
+4. **Sticky header** — visible when scrolling long tables
+5. **Row actions** — edit/delete as icon buttons or dropdown menu
+6. **Empty state** — helpful message when no data, not just blank
+
+### Responsive tables
+
+| Screen | Strategy |
+|---|---|
+| Desktop (≥1024px) | Full table with all columns |
+| Tablet (768–1023px) | Hide less important columns |
+| Mobile (<768px) | Card layout or horizontal scroll |
+
+### Pagination
+
+- Default: 25 rows per page
+- Show total count: "Showing 1–25 of 142"
+- Allow page size change (10, 25, 50, 100)
+- Use Livewire pagination (server-side)
+
+## Responsive Strategy
+
+### Breakpoints (Tailwind)
+
+| Prefix | Min width | Target |
+|---|---|---|
+| `sm:` | 640px | Large phones |
+| `md:` | 768px | Tablets |
+| `lg:` | 1024px | Small laptops |
+| `xl:` | 1280px | Desktops |
+| `2xl:` | 1536px | Large screens |
+
+### Mobile-first approach
+
+1. Design for mobile first (default styles)
+2. Add complexity at larger breakpoints
+3. Test at each breakpoint, not just desktop
+
+### Common patterns
+
+| Element | Mobile | Desktop |
+|---|---|---|
+| Navigation | Hamburger menu | Sidebar or top nav |
+| Forms | Single column | Two columns |
+| Tables | Cards or scroll | Full table |
+| Actions | Bottom sheet / FAB | Inline buttons |
+| Filters | Collapsible panel | Sidebar or inline |
+
+## Accessibility (a11y)
+
+### Minimum requirements
+
+- **Color contrast:** 4.5:1 for text, 3:1 for large text (WCAG AA)
+- **Keyboard navigation:** All interactive elements reachable via Tab
+- **Focus indicators:** Visible focus ring on all focusable elements
+- **Alt text:** All meaningful images have descriptive alt text
+- **ARIA labels:** Interactive elements without visible text need `aria-label`
+- **Semantic HTML:** Use `<button>`, `<nav>`, `<main>`, `<form>` — not `<div>` for everything
+
+### Common mistakes
+
+| Mistake | Fix |
+|---|---|
+| `<div onclick>` | Use `<button>` |
+| Color-only status | Add icon or text alongside color |
+| Missing form labels | Add `<label for="...">` |
+| Auto-playing content | Provide pause/stop control |
+| Tiny click targets | Min 44×44px touch target |
+
+## UX Principles
+
+1. **Feedback** — Every action gets a response (toast, loading state, success message)
+2. **Forgiveness** — Undo for destructive actions, confirmation for irreversible ones
+3. **Consistency** — Same patterns for same interactions across the app
+4. **Progressive disclosure** — Show basics first, details on demand
+5. **Loading states** — Skeleton screens or spinners, never blank screens
+6. **Error recovery** — Clear error messages with suggested actions
+
+## Related
+
+- **Skill:** `blade-ui` — Blade template implementation
+- **Skill:** `livewire` — Livewire component implementation
+- **Skill:** `flux` — Flux component library usage
+- **Skill:** `tailwind` — Tailwind CSS utility patterns
+- **Skill:** `dashboard-design` — Monitoring dashboard design (different domain)
+
+
+## Output format
+
+1. Component structure with layout, data flow, and interaction patterns
+2. Responsive behavior for mobile/tablet/desktop breakpoints
+3. Accessibility annotations (ARIA, keyboard navigation)
+
+## Gotcha
+
+- Don't design components without checking existing Flux/Livewire components first — avoid reinventing.
+- The model tends to use raw HTML instead of project component library — always prefer existing components.
+- Mobile-first is not optional — every layout must work on 320px width.
+
+## Do NOT
+
+- Do NOT skip mobile viewport testing.
+- Do NOT use fixed pixel widths for responsive layouts.
+- Do NOT ignore accessibility requirements.
+
+## Auto-trigger keywords
+
+- frontend design
+- component architecture
+- layout
+- form design
+- responsive

package/.agent-src/skills/feature-planning/SKILL.md

@@ -0,0 +1,226 @@
+---
+name: feature-planning
+description: "Use when the user says "plan a feature", "brainstorm", "explore this idea", or wants to go from idea to structured plan and roadmap."
+source: package
+---
+
+# feature-planning
+
+## When to use
+
+Use this skill when:
+- The user has a feature idea they want to explore or plan
+- An existing feature plan needs refinement
+- A feature plan needs to be turned into actionable roadmaps
+
+Do NOT use when:
+- Bug fixes (use `bug-analyzer` skill)
+- Simple, well-understood changes that don't need planning
+
+## Procedure: Plan a feature
+
+1. **Gather requirements** — What problem does this solve? Who benefits? What's the expected outcome?
+2. **Analyze scope** — Which modules, routes, models, services are affected?
+3. **Write the plan** — Create a feature plan document (see template below).
+4. **Verify** — Confirm all affected areas are identified, no missing dependencies.
+
+A **feature plan** captures the "what and why" of a feature:
+- Problem it solves, who benefits, expected outcome
+- Scope, affected modules, technical approach
+- Open questions and decisions
+
+A **roadmap** captures the "how and when" — the step-by-step implementation plan.
+Feature plans and roadmaps are linked but separate concerns.
+
+## File structure
+
+```
+agents/features/                         # Project-wide feature plans
+├── {feature-name}.md
+
+app/Modules/{Module}/agents/features/    # Module-scoped feature plans
+├── {feature-name}.md
+
+.augment/templates/
+└── features.md                          # Feature plan template
+```
+
+Roadmaps generated from features live in `agents/roadmaps/` (or module-level `agents/roadmaps/`).
+
+## Feature lifecycle
+
+### Quick workflow (small features)
+
+```
+Explore → Plan → Refine → Roadmap → Implement
+  ↑                ↑
+  └── iterate ─────┘
+```
+
+| Phase | Command | Output |
+|---|---|---|
+| **Explore** | `/feature-explore` | Brainstorming notes, feasibility check, rough scope |
+| **Plan** | `/feature-plan` | Structured feature doc in `agents/features/` |
+| **Refine** | `/feature-refactor` | Updated feature doc with changes |
+| **Roadmap** | `/feature-roadmap` | Roadmap(s) in `agents/roadmaps/`, linked from feature |
+
+### Full workflow (complex features, 7 phases)
+
+Use the full workflow for features that span multiple files, require architecture decisions,
+or have unclear requirements. Trigger with `/feature-dev`.
+
+```
+Discovery → Exploration → Questions → Architecture → Implementation → Review → Summary
+```
+
+#### Phase 1: Discovery
+- Clarify the feature request — what problem does it solve?
+- Identify constraints, requirements, and affected users.
+- **Understanding Lock (Hard Gate):** Summarize understanding in 5–7 bullets covering:
+  what is being built, why, who it's for, key constraints, explicit non-goals.
+- List all **assumptions** explicitly.
+- **Wait for explicit confirmation before proceeding.** Do NOT design until confirmed.
+
+#### Phase 2: Codebase Exploration
+- Search for similar features in the codebase.
+- Map the architecture and abstractions in the affected area.
+- Identify key files, services, models, routes involved.
+- Present findings with file references.
+
+#### Phase 3: Clarifying Questions
+- Review codebase findings against the feature request.
+- Identify underspecified aspects: edge cases, error handling, integrations, backward compatibility.
+- **Non-functional requirements** — explicitly clarify or propose defaults for:
+  - Performance expectations (response time, throughput)
+  - Scale (users, data volume, concurrent requests)
+  - Security / privacy constraints
+  - Reliability / availability needs
+  - Maintenance and ownership expectations
+- Present all questions in an organized list.
+- **Wait for answers before proceeding.**
+
+#### Phase 4: Architecture Design
+- Design 2-3 implementation approaches with different tradeoffs:
+  - **Minimal changes** — smallest change, maximum reuse.
+  - **Clean architecture** — maintainability, elegant abstractions.
+  - **Pragmatic balance** — speed + quality.
+- Present comparison with pros/cons and a recommendation.
+- **Ask the user which approach to use** (present as numbered options).
+
+#### Phase 5: Implementation
+- **Wait for explicit approval** before starting.
+- Follow chosen architecture from Phase 4.
+- Follow codebase conventions strictly.
+- Track progress via task list or roadmap.
+
+#### Phase 6: Quality Review
+- Review the implementation for:
+  - Simplicity, DRY, elegance.
+  - Bugs and correctness.
+  - Convention adherence.
+- Present findings with severity levels.
+- **Ask what to fix now vs. later.**
+
+#### Phase 7: Summary
+- Summarize what was built, key decisions, files modified.
+- Suggest next steps (tests, documentation, follow-up features).
+- Update roadmap if applicable.
+
+## Decision log
+
+Maintain a running **decision log** throughout the planning process. For each decision:
+- What was decided
+- Alternatives considered
+- Why this option was chosen
+
+Include the decision log in the feature plan file under a `## Decisions` section.
+This ensures future developers (and agents) understand the reasoning, not just the outcome.
+
+## Adversarial self-review
+
+After completing a plan, run the **`adversarial-review`** skill before presenting it.
+Focus on the "Feature plans / Architecture" attack questions. See that skill for the full process.
+
+## Feature plan format
+
+See `.augment/templates/features.md` for the full structure. Key sections:
+
+- **Problem** — What pain point does this solve?
+- **Proposal** — What's the solution?
+- **Scope** — What's in, what's out?
+- **Affected Areas** — Which modules, models, services, routes?
+- **Technical Approach** — High-level architecture decisions
+- **Non-Functional Requirements** — Performance, scale, security, reliability
+- **Decisions** — Decision log with alternatives and reasoning
+- **Open Questions** — Unresolved decisions
+- **Roadmaps** — Links to generated roadmap files
+
+## Integration with other systems
+
+### Sessions
+
+```markdown
+- **Feature:** `agents/features/my-feature.md`
+```
+
+### Roadmaps
+
+Feature plans link to their roadmaps in the `## Roadmaps` section.
+Roadmaps reference their source feature in the `## Context` section.
+
+### Modules
+
+If a feature is scoped to a single module, the feature plan and roadmaps live in the
+module's `agents/` directory:
+- Feature: `app/Modules/{Module}/agents/features/`
+- Roadmaps: `app/Modules/{Module}/agents/roadmaps/`
+
+
+## Behavior rules
+
+### Research before planning
+
+Before creating a feature plan, always:
+1. **Search the codebase** for related code, existing patterns, and affected areas.
+2. **Read module docs** if the feature touches a specific module.
+3. **Check existing features** in `agents/features/` for overlap or dependencies.
+
+### Be collaborative
+
+- **Ask questions** — don't assume requirements.
+- **Challenge scope** — suggest what can be deferred.
+- **Show tradeoffs** — present options with pros/cons.
+- **Validate feasibility** — check if the codebase supports the approach.
+
+### Keep it navigational
+
+Feature plans are decision documents, not implementation guides.
+Implementation details belong in roadmaps.
+
+## Output format
+
+1. Feature plan document following the template structure
+2. Decision log with rationale for key choices
+3. Implementation roadmap with ordered tasks
+
+## Auto-trigger keywords
+
+- feature planning
+- feature exploration
+- feature roadmap
+- requirements
+
+## Gotcha
+
+- Don't plan features without understanding the business context — ask the user before assuming.
+- The model tends to over-engineer plans — start with the simplest viable solution.
+- A plan without acceptance criteria is incomplete — always define what "done" means.
+- Don't create plans for features that already exist — search the codebase first.
+
+## Do NOT
+
+- Do NOT create feature plans without user input — always collaborate.
+- Do NOT skip codebase research — always check what exists.
+- Do NOT put implementation steps in the feature plan — that's the roadmap's job.
+- Do NOT commit or push without permission.
+- Do NOT duplicate information from `AGENTS.md` or module docs.