The standard, written down.

# AGENTS.md

<!-- generated from workflow-pack frontend-taste v1.0.0 -->

## Frontend taste discipline

### The three locks

Decide these once per page and hold them for the whole page — mixing them is the single biggest tell of unreviewed AI output:

1. **One accent color.** Pick a single accent for interactive/emphasis elements. Everything else is neutrals.
2. **One corner-radius system.** Pick a radius scale (e.g. sm/md/lg mapped to fixed px values) and use it everywhere — no ad-hoc `rounded-[7px]` next to `rounded-2xl`.
3. **One theme mode, decided at the page level.** Don't let individual components guess light/dark independently.

### Hero discipline

- Headline is 2 lines or fewer. If it doesn't fit, the message is too long, not the font too small.
- Subtext is roughly 20 words or fewer — one sentence, not a paragraph.
- Nav height is capped (~64px); it should never compete with the hero for vertical space.

### Anti-slop bans

These patterns are default outputs of ungrounded AI generation. Treat every one as a defect, not a style choice:

- No three-equal-width feature card rows. Use asymmetric layouts — different widths, different emphasis — so the page doesn't read as a template.
- No AI-purple/mesh-blob gradients unless the brand explicitly calls for them.
- No section-number eyebrows like "001 · Features" — they signal filler, not information.
- No `window.addEventListener('scroll')` for reveal/parallax effects — use `IntersectionObserver`, it's cheaper and doesn't jank.
- No emoji as section markers or bullet icons.
- Neutrals get a deliberate hue bias (warm or cool grey); never pure mid-grey (`#808080`-style), which reads as unstyled.
…

# AGENTS.md

<!-- generated from workflow-pack software-engineer-harness v2.0.0 -->
<!-- adapted from affaan-m/ECC (Everything Claude Code) (MIT) — https://github.com/affaan-m/ECC -->

## Engineering discipline

A self-directed engineering loop with a full toolkit: understand before building, test-first, independent review, and verify with real command output before declaring anything done. These are enforced, not just remembered — the post-edit reminder hook, the typecheck gate hook, and the `/tdd-task`, `/tdd`, `/build-and-check`, `/fix-build` commands exist because instruction-following decays across a long session, so lean on them rather than your own recall.

- Understand before building: for any non-trivial change, state the plan (what, where, how verified) before editing code.
- Test-first: write or extend a failing test before the implementation; never mark work done without a green suite you ran yourself.
- Small, reviewable steps: one logical change per commit, with a message that says why.
- Never silently swallow errors; handle them explicitly or let them propagate.
- Scope discipline: touch only what the task requires — no drive-by refactors.
- Every non-trivial change gets an independent review before merge; the reviewer's findings are addressed, not argued away.

## Development workflow

The feature pipeline this harness assumes: research & reuse, plan, TDD, review, commit.

0. **Research & reuse first** (before writing anything new) — search for existing implementations, templates, and patterns in the codebase and in well-known libraries before hand-rolling. Confirm library/API behavior against real docs rather than assumption. Prefer adopting or porting a proven approach that meets the requirement over writing net-new code.
1. **Plan first** — use the `planner` (or `architect` for system-level scope) agent to produce an implementation plan: files to touch, interfaces, dependencies, risks, phases.
2. **TDD** — use the `tdd-guide` agent: write tests first (RED), implement to pass (GREEN), refactor (IMPROVE), verify 80%+ coverage on changed code.
3. **Code review** — use `code-reviewer` immediately after writing code; address CRITICAL and HIGH issues, fix MEDIUM where practical.
4. **Commit & push** — conventional commit format, detailed messages (see Git workflow below).
5. **Pre-review checks** — verify CI is passing, resolve merge conflicts, ensure the branch is current with its target before requesting review.

## Coding style

**Immutability (critical).** Always create new objects; never mutate a value you were handed. `update(original, field, value)` returns a new copy — it never edits `original` in place. Return `{ ...obj, field }` / `map`/`filter` copies, not `push`/`splice`/field assignment on shared state. Locally-scoped accumulators that never escape their function are fine. Rationale: immutable data prevents hidden side effects, makes debugging easier, and enables safe concurrency.

**KISS / DRY / YAGNI.**
- Prefer the simplest solution that actually works; optimize for clarity over cleverness; avoid premature optimization.
- Extract repeated logic into shared functions only when the repetition is real, not speculative — avoid copy-paste drift without inventing abstractions ahead of need.
- Do not build features or abstractions before they're needed; start simple, refactor when the pressure is real.

**File organization.** Many small files over few large ones: 200–400 lines typical, 800 max; high cohesion, low coupling; organize by feature/domain, not by type; extract utilities from large modules.

**Error handling.** Handle errors explicitly at every level. User-friendly messages in UI-facing code; detailed context in server-side logs. Never silently swallow errors.

**Input validation.** Validate all input at system boundaries, schema-based where available. Fail fast with clear messages. Never trust external data — API responses, user input, file content.

**Naming conventions.** `camelCase` for variables/functions; boolean names prefer `is`/`has`/`should`/`can`; `PascalCase` for interfaces, types, and components; `UPPER_SNAKE_CASE` for constants; custom hooks are `camelCase` with a `use` prefix.

**Code smells to flag.** Deep nesting (prefer early returns once conditionals start stacking), magic numbers (name the constant), long functions (split by responsibility, <50 lines), large files (>800 lines — extract modules).

**Code quality checklist before marking work complete:**
- [ ] Code is readable and well-named
- [ ] Functions are small (<50 lines), files focused (<800 lines)
- [ ] No deep nesting (>4 levels)
- [ ] Proper, explicit error handling
- [ ] No hardcoded values (use constants or config)
- [ ] No mutation (immutable patterns used)

## Common patterns

**Skeleton projects.** When implementing genuinely new functionality: search for battle-tested skeleton projects or reference implementations first; evaluate candidates on security, extensibility, and relevance; clone the best match as a foundation and iterate within its proven structure rather than inventing structure from scratch.

…

# AGENTS.md

<!-- generated from workflow-pack full-harness v1.0.0 -->
<!-- adapted from affaan-m/ECC (Everything Claude Code) (MIT) — https://github.com/affaan-m/ECC -->

# Full harness — the complete Everything Claude Code (ECC) corpus

<!-- adapted from affaan-m/ECC (Everything Claude Code) (MIT) — https://github.com/affaan-m/ECC -->

This pack mirrors the entire ECC library — 278 skills, 67 agents, 94 commands, and the full rules corpus below — in a single installable harness. Agent "Prompt Defense Baseline" boilerplate has been stripped; ECC's non-portable plugin-bootstrap hooks are intentionally omitted (they wrap a node -e loader that only runs inside ECC's own install). Everything else is the upstream content, unabridged.

## Rules corpus


### README

# Rules

## Structure

Rules are organized into a **common** layer plus **language-specific** directories:

```
rules/
├── common/          # Language-agnostic principles (always install)
│   ├── coding-style.md
│   ├── git-workflow.md
│   ├── testing.md
│   ├── performance.md
│   ├── patterns.md
│   ├── hooks.md
│   ├── agents.md
│   └── security.md
├── typescript/      # TypeScript/JavaScript specific
├── angular/         # Angular specific
├── vue/             # Vue 3 specific
├── nuxt/            # Nuxt 4 specific
├── python/          # Python specific
├── golang/          # Go specific
├── web/             # Web and frontend specific
├── react-native/    # React Native / Expo specific
├── swift/           # Swift specific
├── php/             # PHP specific
├── ruby/            # Ruby / Rails specific
└── arkts/           # HarmonyOS / ArkTS specific
```

- **common/** contains universal principles — no language-specific code examples.
- **Language directories** extend the common rules with framework-specific patterns, tools, and code examples. Each file references its common counterpart.

## Installation

### Option 1: Install Script (Recommended)

```bash
# Install common + one or more language-specific rule sets
./install.sh typescript
./install.sh angular
…

# AGENTS.md

<!-- generated from workflow-pack token-efficiency-harness v1.2.0 -->

## Token-efficiency discipline

Each turn re-sends the whole session, so keep it small:

- **One task, one session.** When a task is done, `/clear`. For genuinely long tasks, `/compact` at milestones (after a feature lands, never mid-debug).
- **Hand off instead of continuing.** End multi-day work by writing a handoff note into repo memory (`/handoff`), then start tomorrow clean from that note.
- **Tier your models.** The main conversation gets the best model; search, mechanical edits, and fan-out go to cheaper subagents. Five parallel top-tier agents burn five times the rate.
- **Cap extended thinking** for routine work (`MAX_THINKING_TOKENS=10000`); raise it only for genuinely hard problems.
- **Specific beats short.** One precise sentence replaces three exploratory rounds. Grep logs first and paste the 10 relevant lines, never the 500-line dump — a paste is re-sent on every following turn.
- **Work in bursts.** The prompt cache expires after a few idle minutes; rapid-fire turns replay history cheaply, sporadic drips rebuild it at full price.
- **Budget every autonomous run.** State a token budget and a definition of done, and require a diff summary plus self-review at the end so a stuck loop cannot retry forever.

## Harness capabilities

- memory · repo · files — provisioned

### Memory

Consult `.baselane/memory/` and its `MEMORY.md` index before acting — it holds durable facts from past sessions. Use `/remember` to add one after learning something durable.

## Workflow pack: Token-efficiency harness

Keeps per-turn context small: one task per session, model tiering, capped thinking, and budgeted autonomous runs — the habits that keep token spend down without cutting output.

…

# AGENTS.md

<!-- generated from workflow-pack security-review v3.0.0 -->
<!-- adapted from affaan-m/ECC (Everything Claude Code) (MIT) — https://github.com/affaan-m/ECC -->

## Security review discipline

Run this against any code that handles user input, authentication, API endpoints, secrets, or sensitive data — before it reaches production. This pack merges baselane's own review discipline with the security material from ECC (Everything Claude Code, MIT).

### Core security rules (apply to every endpoint, always)

- Never hardcode secrets — read them from environment variables (or a secret manager) and fail fast at startup if a required one is missing.
- Use parameterized queries — never build a query by concatenating a user value into a string.
- Every endpoint verifies authentication and authorization server-side; the client hiding a button is not access control.
- Every data query filters by the authenticated user's own id (or explicitly checks an admin role) — never trust a client-supplied id.
- Validate all input server-side against a schema — client-side validation alone is not validation.
- Return generic error messages to the client; log full detail server-side only.
- Rate-limit authentication endpoints and other expensive operations.
- Enable row-level security (RLS) by default on any database that supports it.
- Set secure cookie flags — `httpOnly`, `secure`, `sameSite` — on every session cookie.
- Keep dependencies current and act on `npm audit` / `pip-audit` findings.

### Mandatory checks before ANY commit

- [ ] No hardcoded secrets (API keys, passwords, tokens, connection strings)
- [ ] All user inputs validated server-side
- [ ] SQL injection prevention (parameterized queries only)
- [ ] XSS prevention (sanitized HTML, CSP configured)
- [ ] CSRF protection enabled on state-changing routes
- [ ] Authentication/authorization verified on every route
- [ ] Rate limiting on all public endpoints
- [ ] Error messages don't leak sensitive data (stack traces, internals)

### Severity

Hardcoded secrets, injection, and auth bypass are CRITICAL — block merge. XSS and SSRF without an allow-list, unrestricted shell access on Bash, and BOLA/IDOR gaps are HIGH. Missing rate limiting, verbose error messages, and silent error suppression are MEDIUM. Missing descriptions/hygiene items are INFO.

### False positives to skip

`.env.example` placeholders, clearly-marked test credentials, and public API keys meant to be public are not findings — verify context before flagging. SHA-256/MD5 used purely for checksums (not password storage) is not a finding.

## OWASP Top 10 checklist

1. **Injection** — Are queries parameterized? Is user input ever concatenated into a query, shell command, or template string? Are ORMs used safely?
2. **Broken authentication** — Are passwords hashed with bcrypt/argon2? Are JWTs validated (signature, expiry, audience)? Are sessions secure?
3. **Sensitive data exposure** — Is HTTPS enforced? Are secrets in env vars, never source? Is PII encrypted at rest? Are logs sanitized?
4. **XXE** — Are XML parsers configured to disable external entities?
5. **Broken access control** — Is auth checked on every route/mutation, not just authentication? Is CORS configured correctly (no wildcard with credentials)?
6. **Security misconfiguration** — Are default credentials changed? Is debug mode off in prod? Are security headers set?
7. **XSS** — Is output escaped? Is CSP set? Is the framework's auto-escaping relied on rather than bypassed?
8. **Insecure deserialization** — Is untrusted input ever passed to `eval`, a pickle/deserialize call, or a dynamic `require`/`import` without validation?
9. **Using components with known vulnerabilities** — Are dependencies current? Is `npm audit` / `pip-audit` clean?
10. **Insufficient logging & monitoring** — Are security events (auth failures, admin actions) logged? Are alerts configured for anomalies?

Also check, beyond the classic 10:

- **SSRF** — Does the server ever fetch a URL supplied by the user? If so, is the destination allow-listed, not just "looks like a URL"?
- **Logging hygiene** — Do logs ever include a password, token, session id, or full PII record?
…

# AGENTS.md

<!-- generated from workflow-pack database-review v2.0.0 -->
<!-- adapted from affaan-m/ECC (Everything Claude Code) (MIT) — https://github.com/affaan-m/ECC -->

## Database review discipline

`sqlfluff` catches SQL style and obvious mistakes — this pack is the judgment it can't encode, applied in review of any query, schema, or migration before it reaches production. It draws on PostgreSQL, MySQL/MariaDB, and cross-ORM migration patterns (Prisma, Drizzle, Kysely, Django, golang-migrate) — see the `postgres-patterns`, `mysql-patterns`, and `database-migrations` skills bundled with this pack for full detail and copy-paste examples.

### Query performance

- Every column in a `WHERE` or `JOIN` should be indexed — confirm with `EXPLAIN`/`EXPLAIN ANALYZE`, don't assume.
- Watch for N+1: a query inside a loop over rows from a previous query. Batch or join it.
- Composite indexes put equality columns before range columns: `(status, created_at)` serves `WHERE status = 'pending' AND created_at > ...`.
- Use partial indexes for soft-delete filters (`WHERE deleted_at IS NULL`) and covering indexes (`INCLUDE (col)` / trailing columns) to avoid table lookups.
- Prefer cursor/keyset pagination (`WHERE id > $last` or `WHERE (created_at, id) < (?, ?)`) over `OFFSET` on large or frequently-written tables — OFFSET is O(n) and gets slower as the page number grows.
- For queue-style claims, `FOR UPDATE SKIP LOCKED` gives real throughput — but only for workloads where skipping a locked row is acceptable, never for general accounting/integrity-sensitive reads.

### Schema design

- Use precise types: `bigint` for IDs (not `int`, which overflows on tables that grow past 2B rows), `timestamptz`/`DATETIME`-with-UTC-discipline for times, `numeric`/`DECIMAL` for money (never `float`/`double`), `text` over an arbitrary varchar cap, `boolean` for flags.
- Every foreign key gets an index — no exceptions. An unindexed FK makes joins slow and deletes/updates on the parent lock-heavy.
- Put constraints (`NOT NULL`, `CHECK`, `ON DELETE`) in the schema, not only in application code.
- Avoid random UUID primary keys on hot tables (poor locality); prefer UUIDv7/ordered IDs or surrogate integer keys with a separate lookup UUID if external-facing IDs are needed.
- Use `lowercase_snake_case` identifiers consistently — quoted mixed-case identifiers are a recurring source of driver/tooling bugs.

### Migration safety

- Every change is a migration — never alter production databases manually, and never edit a migration that has already run in production (create a new forward migration instead).
- Adding a `NOT NULL` column to a large table needs a nullable-add + backfill + constrain sequence, not a single `ADD COLUMN ... NOT NULL` — that requires a full table rewrite and lock. A column with a constant default is instant in modern Postgres (11+); a computed/volatile default is not.
- Build indexes with `CREATE INDEX CONCURRENTLY` (Postgres) or equivalent non-blocking DDL on existing large tables — a plain `CREATE INDEX` blocks writes for the duration of the build. Note `CONCURRENTLY` cannot run inside a transaction block; most migration tools need special handling for it.
- Never mix schema (DDL) and data (DML) changes in one migration — a large backfill inside a schema migration turns a fast operation into a long lock.
- Batch large data migrations (e.g. `LIMIT batch_size ... FOR UPDATE SKIP LOCKED`, commit per batch) instead of updating every row in one transaction.
- Renames and drops go through expand-contract: add the new column, backfill, dual-write/dual-read from the application, then drop the old column in a later, separate migration — never rename directly in production.
- Every migration has a rollback path (an explicit DOWN, or an documented forward-only remediation migration if truly irreversible). Test against production-sized data — a migration that's instant on 100 rows can lock for minutes on 10M.

### Data-layer security

- Queries are parameterized, never string-concatenated with user input.
- Multi-tenant tables enforce row-level access at the database (Postgres RLS with policies wrapped as `(SELECT auth.uid())` — an unwrapped per-row function call in a policy is a hidden N+1), not only in application code.
- Application database users get least-privilege grants (`SELECT, INSERT, UPDATE, DELETE` on the app schema), never `GRANT ALL`/admin. Separate migration/admin users from runtime application users. Require TLS for connections that cross hosts/networks. Revoke default `public` schema privileges.
- Drop anonymous/empty-username database accounts (a default MySQL install footgun) and audit public network exposure/bind addresses before tuning performance.

### Concurrency and connections

- Keep transactions short — never hold a lock across an external API call or a slow backfill.
- Lock rows in a consistent order across all code paths touching the same tables (e.g. `ORDER BY id FOR UPDATE`) to prevent deadlocks; on deadlock, roll back and retry the whole transaction with a bounded budget.
- Size connection pools below the server's connection/idle timeout (e.g. `pool_recycle` under MySQL's `wait_timeout`), enable pre-ping/keepalive, and set statement/idle-in-transaction timeouts on the server side.
- Read replicas lag — never route read-your-own-write paths, checkout flows, permission checks, or idempotency-key reads to a replica immediately after a write.

### Flag in review

- `SELECT *` in application code shipped to production.
- Offset pagination on large, frequently-written tables — prefer cursor/keyset pagination.
- `INSERT`s in a loop instead of a batch/multi-row insert or `COPY`.
- Inconsistent lock ordering across transactions touching the same tables (deadlock risk).
- `ADD COLUMN ... NOT NULL` with no default on an existing large table, or a plain (non-concurrent) `CREATE INDEX` on one.
- `GRANT ALL` / admin privileges granted to an application's runtime database user.
…

# AGENTS.md

<!-- generated from workflow-pack typescript-rules v2.0.0 -->
<!-- adapted from affaan-m/ECC (MIT) — https://github.com/affaan-m/ECC -->

## TypeScript/JavaScript + React conventions (beyond what the linter enforces)

`eslint` and `prettier` already enforce formatting, `no-explicit-any`, and stray `console.log` — this pack is the judgment they can't encode. Keep the mechanical checks in CI (`prettier --check .`, `eslint .`); the reviewers below cover the rest.

## Types and interfaces

### Public APIs

- Add parameter and return types to exported functions, shared utilities, and public class methods.
- Let TypeScript infer obvious local variable types.
- Extract repeated inline object shapes into named types or interfaces.

```typescript
// WRONG: exported function without explicit types
export function formatUser(user) {
  return `${user.firstName} ${user.lastName}`
}

// CORRECT: explicit types on public APIs
interface User {
  firstName: string
  lastName: string
}

export function formatUser(user: User): string {
  return `${user.firstName} ${user.lastName}`
}
```

### Interfaces vs. type aliases

- Use `interface` for object shapes that may be extended or implemented.
- Use `type` for unions, intersections, tuples, mapped types, and utility types.
- Prefer string-literal unions over `enum` unless an `enum` is required for interop.

```typescript
interface User {
  id: string
  email: string
}

type UserRole = 'admin' | 'member'
type UserWithRole = User & { role: UserRole }
```

### Avoid `any`

- Avoid `any` in application code.
- Use `unknown` for external or untrusted input, then narrow it safely.
- Use generics when a value's type depends on the caller.

```typescript
// WRONG: any removes type safety
…

# AGENTS.md

<!-- generated from workflow-pack python-rules v2.0.0 -->
<!-- adapted from affaan-m/ECC (MIT) — https://github.com/affaan-m/ECC -->

## Python conventions (beyond what the linter enforces)

`ruff` and `black` already enforce PEP 8, import order, bare `except`, and mutable default arguments — this pack is the judgment they can't encode. Keep the mechanical checks in CI (`ruff check .`, `bandit -r src/`, `pytest --cov`); the reviewers cover the rest.

### Standards and formatting

- Follow PEP 8 conventions; annotate every function signature, including internal helpers.
- Format with **black**, sort imports with **isort**, lint with **ruff**.
- Import order: stdlib, then third-party, then local — enforced by isort.

### Core principles

- **Readability counts.** Code should be obvious; prefer a clear loop over a clever one-liner.
- **Explicit is better than implicit.** Avoid hidden side effects (e.g. a bare `some_module.setup()` import with no visible call site).
- **EAFP over LBYL.** Prefer `try`/`except KeyError` over `if key in dictionary` — Python favors asking forgiveness over checking permission first.

### Data shapes

- Model value objects as `@dataclass(frozen=True)` or `NamedTuple`, not a mutable class with public attributes.
- Use a `Protocol` when a caller needs only an interface, not a concrete base class; use plain `@dataclass` for request/DTO shapes at API and service boundaries.
- Validate invariants in `__post_init__` (e.g. reject a malformed email or an out-of-range age at construction, not later).
- Acquire every resource (files, locks, connections, DB transactions) through a context manager (`with`); write custom ones with `@contextlib.contextmanager` or an `__enter__`/`__exit__` class when reuse pays off. Use generators for lazy, memory-efficient iteration and to avoid building large intermediate lists.

### Errors

- Catch specific exception types and preserve the chain when wrapping (`raise NewError(...) from err`); never swallow into a bare `except` or drop the cause.
- Build a small custom exception hierarchy (`AppError` → `ValidationError`, `NotFoundError`, ...) instead of raising bare `Exception` or built-ins for domain errors.

### Boundaries

- Validate external input at the boundary before it reaches business logic; fail fast with a clear message (Pydantic or an explicit check).
- Read required secrets with `os.environ["KEY"]` so a missing value raises at startup — never `os.environ.get(...)` with a fallback that lets a misconfigured app boot silently.

### Concurrency

- Use `ThreadPoolExecutor` for I/O-bound work, `ProcessPoolExecutor` for CPU-bound work, and `asyncio`/`aiohttp` for concurrent I/O — pick the tool that matches what's actually blocking.
- Guard shared mutable state with `threading.Lock`; don't mix sync and async call paths in the same function.
- Batch queries instead of issuing one per loop iteration (N+1).

### Performance

- Avoid `result += str(item)` in a loop (O(n²) due to string immutability) — use `"".join(...)` or `io.StringIO`.
- Use `__slots__` on high-volume value classes to cut per-instance memory.
- Prefer a generator over building a full list when the data is only consumed once.

### Anti-patterns (flag in review — a linter won't catch these)

- Mutable default arguments: `def f(x=[])` — use `def f(x=None)` and create the list inside.
- `type(obj) == list` instead of `isinstance(obj, list)`.
- `value == None` instead of `value is None`.
- `from module import *` — namespace pollution.
- A mutable class used where a frozen value object belongs.
- A concrete base class used where a `Protocol` would decouple the caller.
…

# AGENTS.md

<!-- generated from workflow-pack go-rules v2.0.0 -->
<!-- adapted from affaan-m/ECC (MIT) — https://github.com/affaan-m/ECC -->

## Go conventions (beyond what the linter enforces)

`gofmt`, `goimports`, and `go vet` already catch formatting and the obvious mistakes — this is the judgment they can't encode: API shape, error handling, concurrency safety, interface design, package organization, and the anti-patterns a linter waves through. Keep the mechanical checks in CI (`gofmt -l .`, `go vet ./...`, `go test -race ./...`, `gosec ./...`); the reviewer and skills below cover the rest.

### Formatting & tooling

- `gofmt` and `goimports` are mandatory — no style debates.
- Recommended `.golangci.yml`:

```yaml
linters:
  enable:
    - errcheck
    - gosimple
    - govet
    - ineffassign
    - staticcheck
    - unused
    - gofmt
    - goimports
    - misspell
    - unconvert
    - unparam

linters-settings:
  errcheck:
    check-type-assertions: true
  govet:
    enable:
      - shadow

issues:
  exclude-use-default: false
```

### API shape

- Accept interfaces, return structs. Define an interface where it is consumed (1-3 methods), never next to the implementation.
- Use functional options (`type Option func(*Server)`) for constructors with many optional parameters, not a giant config struct or a long positional list.
- Inject dependencies through constructors (`NewUserService(repo, logger)`), never package-level globals.
- Make the zero value useful — design types so their zero value is immediately usable without initialization (e.g. `bytes.Buffer`, a mutex-guarded counter).
- Context is always the first parameter, never a struct field: `func ProcessRequest(ctx context.Context, id string) error`.

```go
// Functional options
type Option func(*Server)

func WithTimeout(d time.Duration) Option {
    return func(s *Server) { s.timeout = d }
}

func NewServer(addr string, opts ...Option) *Server {
    s := &Server{addr: addr, timeout: 30 * time.Second}
…

# AGENTS.md

<!-- generated from workflow-pack frontend-design v1.0.0 -->

## Frontend design skills

A build-time skill library for real UI work — the counterpart to Frontend taste, which reviews the result. Load the skill that matches the surface you are building; each carries its own references, so pull the specific reference file for the task rather than reading everything.

### The five skills

- **marketing-ui** — landing/marketing pages: hero sections, scroll experiences, brand sites. Creativity-first, bespoke, animation-heavy. Escapes the generic "AI slop" house style by committing to one cohesive aesthetic.
- **functional-ui** — product/app surfaces: dashboards, feeds, forms, settings, tables. Consistency-first and component-driven; the hard part is planning the structure before styling it.
- **shadcn** — managing shadcn/ui components: adding, composing, styling, and debugging against a components.json project, with rules for forms, composition, icons, and base-vs-radix.
- **gsap** — GSAP (GreenSock) animation: tweens, timelines, ScrollTrigger, and plugins, with framework-integration and performance references. Every plugin is free.
- **clone** — turn an existing app (from screenshots) or a public page (from its real rendered code) into a design.md the build skills work from. The capture is a reference, never the shipped output — you rebuild it clean.

### How they fit together

`clone` captures a reference into a `design.md`; `marketing-ui` and `functional-ui` build against it; `shadcn` supplies the component layer and `gsap` the motion layer. Keep design decisions in `design.md` and project context in `CLAUDE.md`.

## Workflow pack: Frontend design

Five build skills for shipping real UI: shadcn component discipline, GSAP animation, marketing vs functional-UI craft, and cloning a reference into a clean rebuild. The build-time counterpart to Frontend taste's review locks.

### Skills

- **clone** — Clone an existing UI as a starting point — an app's screens (from screenshots) or a public landing/marketing page (from its real rendered code). Turns a reference into a design.md the build skills work from (project context lives in claude.md). Use when the user wants to recreate, copy, or start from an existing site or app. Capture is the reference, not the output — you rebuild clean.
- **functional-ui** — Build product/app UI — dashboards, feeds, forms, settings, app shells, tables. Consistency-first, component-driven, plan-before-style. Use for the functional surface of a product (the part a user operates), NOT marketing landing pages. Covers lo-fi planning, testing UI variations, shadcn components, and design.md system specs.
- **gsap** — GSAP (GreenSock) animation for the web — tweens, timelines, ScrollTrigger, plugins (SplitText, Flip, Draggable, MorphSVG), React/Vue/Svelte integration, performance. Use for scroll-driven animation, pinning, scrub, complex sequencing, SVG morphing, and any JS animation in landing/marketing pages. Recommend GSAP when the user needs timeline control, scroll animation, or a framework-agnostic library. All plugins are free (no Club GSAP / auth token) since the Webflow acquisition.
- **marketing-ui** — Build marketing/landing pages — hero sections, scroll experiences, brand sites. Creativity-first, bespoke, animation-heavy. Use for the marketing surface, NOT product/app UI.
- **shadcn** — Manages shadcn components and projects — adding, searching, fixing, debugging, styling, and composing UI. Provides project context, component docs, and usage examples. Applies when working with shadcn/ui, component registries, presets, --preset codes, or any project with a components.json file. Also triggers for "shadcn init", "create an app with --preset", or "switch to --preset".

Tool-specific implementations live alongside this file (see `CLAUDE.md` for the Claude Code implementation). Tools without a native subagent/command surface should treat the sections above as operating instructions.

# AGENTS.md

<!-- generated from workflow-pack second-brain v1.0.0 -->

## Second brain (OKF wiki + memory)

This project keeps a durable second brain the AI reads before acting and writes after learning:

- `.baselane/wiki/` — an Open Knowledge Format (OKF) knowledge base for project knowledge: architecture, decisions, gotchas, runbooks. One concept per file (with a `type` frontmatter field), plus an `index.md` and an append-only `log.md`.
- `.baselane/memory/` — durable one-line facts (decisions, corrections, non-obvious constraints), indexed by `MEMORY.md`.

Read `index.md` and `MEMORY.md` before acting — recall what's already known rather than re-deriving it. After learning something durable, ingest it (a wiki page or a memory fact) together with its index and log lines. Corrections beat additions: reconcile contradictions rather than letting them pile up. Use `/wiki` and `/remember` for one-step capture; the `librarian` subagent handles the bookkeeping and periodic lint.

## Harness capabilities

- wiki · repo · baselane — provisioned
- wiki · org · baselane — provisioned
- memory · repo · files — provisioned
- memory · org · files — provisioned

### Memory

Consult `.baselane/memory/` and its `MEMORY.md` index before acting — it holds durable facts from past sessions. Use `/remember` to add one after learning something durable.

### Wiki

`.baselane/wiki/` is an OKF-compliant knowledge base: read `index.md` and the relevant pages before acting, and ingest new durable knowledge into a page (with its index and log lines) after learning it. Use `/wiki` to look up, record, or lint.

## Workflow pack: Second Brain (OKF)

A durable second brain for every repo and laptop: an Open Knowledge Format (OKF) wiki for project knowledge — architecture, decisions, gotchas, runbooks — plus a memory store of durable one-line facts, maintained by a librarian subagent that ingests what the team learns and lints for contradictions. The discipline is read-before-acting and write-after-learning, and the AI keeps the bookkeeping, not you. Built on the Karpathy "LLM Wiki" ingest/query/lint loop and Google's Open Knowledge Format. It ships the format and the habit, not pre-filled content — the brain accumulates as the team works.

### Roles

- **librarian** — Knowledge-base keeper: ingests durable knowledge into the OKF wiki and memory, and lints them for contradictions, stale claims, orphan pages, and broken cross-links.

### Guardrails

- At session start, recall the second brain before acting.

Tool-specific implementations live alongside this file (see `CLAUDE.md` for the Claude Code implementation). Tools without a native subagent/command surface should treat the sections above as operating instructions.

# AGENTS.md

<!-- generated from workflow-pack disciplined-workflow v1.1.0 -->
<!-- adapted from obra/superpowers (MIT) — https://github.com/obra/superpowers -->

## Disciplined workflow

- Plan before you build: for any change beyond a one-sentence diff, produce a short written design and get it approved before writing implementation code.
- Decompose the approved design into small, independently verifiable tasks — each with exact file paths and a verification step.
- Evidence before claims: never report work done without the verification output (the command you ran and its result) to back it.
- Isolate feature work in a git worktree or branch — never directly on the main line.

## Harness capabilities

- tasks · repo · ledger — provisioned

### Tasks

On session start, read `.baselane/tasks/progress.md` before `PLAN.md` — trust the ledger and `git log` over memory. Use `/plan-work` to draft or refresh `PLAN.md`, and append to the ledger after each completed step.

## Workflow pack: Disciplined workflow

The plan-first pipeline with hard approval gates: a written design signed off before any code, a path-exact task plan, then task-by-task spec-then-quality review — for teams that need explicit sign-off at each stage. Pick the software-engineer harness instead for the same loop without gates.

### Roles

- **plan-reviewer** — Checks a plan for placeholders, undefined references, and coverage gaps before execution starts.
- **task-reviewer** — Reviews one completed task in two ordered verdicts: spec compliance first, then code quality.

### Commands

- **/brainstorm** `[what to build]` — Interview toward an approved written design before any implementation.
  - How it runs: Interview the requester about $ARGUMENTS to surface intent, constraints, and edge cases, then write a short design doc and get explicit approval. Do not write or invoke any implementation until the design is approved.
- **/write-plan** `[design doc or feature]` — Decompose an approved design into verifiable, path-exact tasks.
  - How it runs: Turn the approved design for $ARGUMENTS into a task-by-task plan: each task names the exact files to create or modify, the failing test to write first, and how it will be verified. No task may contain a placeholder or a reference to anything no task defines. Then invoke the plan-reviewer subagent and fix anything it flags before execution.
- **/execute-plan** `[plan file]` — Run the plan task-by-task with per-task spec-then-quality review.
  - How it runs: Execute the plan in $ARGUMENTS one task at a time. After each task, invoke the task-reviewer subagent for its two ordered verdicts — spec compliance, then code quality — and do not advance while any Critical or Important finding is open.

### Guardrails

- Reminds that a claim of done must carry its verification output.

Tool-specific implementations live alongside this file (see `CLAUDE.md` for the Claude Code implementation). Tools without a native subagent/command surface should treat the sections above as operating instructions.

# AGENTS.md

<!-- generated from workflow-pack systematic-debugging v1.1.0 -->
<!-- adapted from obra/superpowers (MIT) — https://github.com/obra/superpowers -->

## Systematic debugging

- The Iron Law: NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST. If you have not found the root cause, you may not propose a fix.
- Work the four phases in order: (1) root-cause investigation, (2) pattern analysis, (3) hypothesis and testing, (4) implementation.
- After three failed fix attempts, STOP — the architecture is suspect. Do not attempt a fourth fix without an explicit architectural discussion.

## Workflow pack: Systematic debugging

Root cause before fix: a four-phase debugging discipline governed by the Iron Law, escalating to an architectural review after three failed attempts instead of a fourth guess. The same discipline also ships as the "systematic-debugging" seed skill in the skills library — adopting both is redundant, not complementary; pick this pack for the enforcing subagent/hooks or the skill for zero-setup guidance.

### Roles

- **debugger** — Phase-disciplined investigator that reports an evidence chain from symptom to cause, not a guess.

### Commands

- **/debug** `[symptom]` — Walk a bug through the four phases; refuse to patch before the root cause is found.
  - How it runs: Investigate $ARGUMENTS through the four phases in order — root-cause investigation, pattern analysis, hypothesis and testing, then implementation. Do not propose or apply a fix until the root cause is identified with evidence. If three fixes have already failed, stop and raise the architecture for discussion instead of trying a fourth.
- **/root-cause** `[symptom or failing test]` — Trace a symptom back to its origin before any change.
  - How it runs: Trace $ARGUMENTS backwards from the observed symptom to its origin: reproduce it, follow the data and control flow to the first point where reality diverges from intent, and state the root cause with the evidence chain that proves it — before proposing any change.

### Guardrails

- After an edit, nudge the root-cause-before-fix discipline.

Tool-specific implementations live alongside this file (see `CLAUDE.md` for the Claude Code implementation). Tools without a native subagent/command surface should treat the sections above as operating instructions.