Skip to content

AGENTS.md

Latest commit

 

History

History
59 lines (43 loc) · 4.47 KB

AGENTS.md

File metadata and controls

59 lines (43 loc) · 4.47 KB

DataConnect

DataConnect is software that enables users to interact with the Vana protocol. Analogous to an email client. This app is the reference implementation. NOT a protocol participant (not registered on-chain). It may bundle a Personal Server; in that case the Personal Server (not the client) is the protocol participant and must be registered on-chain.

Architecture (Source of Truth)

Start here (core docs): docs/260121-data-portability-protocol-spec.md, docs/architecture.md, docs/260325-grant-connect-flow-architecture.md.

DataConnect is the protocol client: it runs connectors, orchestrates grants, and configures the Personal Server (the on-chain participant). Grant flow inputs are canonical in the URL (sessionId, secret, scopes), never location.state.

Doc index (preferred for knowledge)

[Doc Index]|root: ./docs |IMPORTANT: Prefer retrieval-led reasoning over pre-training-led reasoning |docs:{260121-data-portability-protocol-spec.md,architecture.md,260325-grant-connect-flow-architecture.md,browser-packaging-options.md,privy-js-sdk-documentation.md}

Agent guidance

Always‑on rules

  • Prefer retrieval‑led reasoning for project‑specific knowledge.
  • Don’t overwrite comments; don’t change styles/classes unless asked.
  • Prefer minimal patches over full-file rewrites when feasible; this keeps outputs smaller, reduces token usage in debug loops, and makes changes easier to review. Keep context scoped to the relevant file, function, and failure, and avoid regenerating entire files unless a full rewrite is clearly justified.
  • When I report a bug, do not start with a fix. First reproduce the bug and add the smallest failing test for the reported behavior when feasible. Then have subagents propose fixes, and accept a fix only when that reproducing test passes.
  • Commit only when asked; never push; stage explicit paths only (no git add ., -A, -u, git commit -a); run relevant tests before commit.
  • For all commit actions, follow .agents/skills/commit-discipline/SKILL.md exactly.
  • For links/actions that open URLs or local file/folder paths, use shared helpers in src/lib/open-resource.ts and src/lib/tauri-paths.ts; avoid inline runtime/OS branching in page components.
  • For routes in src/pages/*, keep index.tsx as entry/composition (params, guards, wiring) and move side effects/async orchestration into a page-local hook (use-<page>-*.ts).
  • If behavior branches by runtime capability (for example Tauri vs browser), add at least one test per branch before commit.

UI component gate

When the user message contains UI gate and the change touches JSX (.tsx files or JSX in React components), the agent must:

  1. Read .cursor/skills/ui-component-audit/SKILL.md before making edits.
  2. Restate 2-4 concrete rules from that skill that will be applied in the current change.
  3. Proceed with edits only after completing steps 1-2.

If no JSX is touched, ignore this gate. If the gate is requested and the skill was not read first, stop and ask for confirmation before continuing.

Skills (JIT only)

Use skills only when the task matches; explore the code first.

  • React code: explore project, then invoke vercel‑react‑best‑practices.
  • Doc creation: follow .cursor/skills/doc-creation when creating/moving docs.
  • CSS: invoke css skill when writing/adjusting CSS (non‑Tailwind).
  • Tailwind: invoke tailwind skill when writing/adjusting Tailwind classes.
  • ShadCN import: invoke tailwind-shadcn-adaptation for primitives.
  • ShadCN semantics: invoke shadcn-primitives-wrappers for product wrappers.
  • UI audit: invoke ui-component-audit when asked to audit/fix UI implementation.
  • Text usage edits: when changing usage of src/components/typography/text.tsx, read ui-component-audit first (soft default; use judgment).
  • Testing: invoke react-testing when writing/running tests or before commit.
  • Linear: invoke linear skill when asked to create/update tickets or statuses.
  • Commit messages: invoke conventional-commits when creating, reviewing, or fixing commit messages.
  • Patch-first debugging: invoke patch-first-debugging for normal bug fixes, regressions, or surgical code changes where the main need is narrow scope, minimal diffs, and targeted verification.
  • Test-fix harnesses: invoke test-fix-loop when the user wants a constrained failing-test repair loop, minimal-patch harness, or automated test-fix workflow; use this for loop orchestration, not ordinary bug fixing.
  • Committing: invoke committing skill only when user explicitly asks to commit.