Best Practices

These are the practices we’ve refined at Arvore through months of real production usage. They’re opinionated — they reflect what works for us with Repo Hub, Claude Opus 4.6, and Cursor.

Choose the right model

Not all models are equal for development work. Our stack:

• Claude Opus 4.6 for complex tasks — multi-file refactors, architecture decisions, code review, and reasoning across many repos. It’s the most capable model for sustained, multi-step work across large codebases.
• Faster models for quick, scoped tasks — simple bug fixes, test generation, single-file changes. Cheaper and lower latency when the task doesn’t need deep reasoning.

Match the model to the task. Refinement and review benefit from the best model. A quick lint fix doesn’t.

Key insight: the model matters less than the context you give it. Opus 4.6 with poor context produces worse results than a smaller model with excellent context. Repo Hub exists to solve the context problem.

Give the AI the right capabilities

Ad-hoc prompting produces ad-hoc results. The biggest productivity gain isn’t a better model — it’s giving the AI the right capabilities and letting it pull what each task needs:

skills: [refinement, code-review, qa-testing, debugging]

repos:
  - name: api
    tech: nestjs
    skills: [backend-nestjs]
  - name: frontend
    tech: nextjs
    skills: [frontend-nextjs]

The AI pulls the refinement skill to clarify a contract before writing code, the relevant stack skills while implementing, and — when an independent pass helps — spawns a fresh-context subagent that pulls code-review or qa-testing (with real browser automation). No rigid script; the AI applies judgment about what each task needs.

This consistency is what makes “weeks instead of months” possible. Not magic — capabilities the AI can reach for, reliably.

Encode knowledge in skills

The single biggest source of errors in AI-generated code is not knowing the conventions.

An AI that generates a NestJS service without knowing your error handling pattern, your testing conventions, or your database access layer will produce code that works but doesn’t fit.

Skills solve this:

skills/backend-nestjs/SKILL.md
├── Project structure
├── Testing patterns (Vitest, not Jest)
├── Database access (TypeORM conventions)
├── Error handling (custom exception filters)
└── API response format

When the AI works on a repo with skills: [backend-nestjs], the editor surfaces that skill and the AI pulls it before writing code. The result is code that matches your existing codebase from the first attempt.

Write skills for every framework and convention in your stack — and for cross-cutting capabilities like review, testing, and refinement. This is the highest-ROI activity for any team using AI development.

Connect to real infrastructure

An AI that can’t see your database schema is guessing at column names. An AI that can’t see your logs is guessing at error causes.

MCPs remove the guessing:

The debugging skill plus access to Datadog logs lets the AI identify a root cause in minutes instead of hours. The qa-testing skill plus Playwright lets it verify UI changes without manual testing.

Every piece of infrastructure your team uses should be accessible to AI through MCPs.

Review everything

AI writes the code. Humans review it. This is non-negotiable.

Our product engineers spend most of their time on:

1. Product judgment — Does this solve the actual user problem? Are there edge cases the AI missed? Should we do this now, and for which user segment?
2. Architecture decisions — Should we add this dependency? Is this the right abstraction? Will this scale?
3. Code review — Does this implementation match the requirements? Are there security implications? Is the error handling correct?

The code-review skill catches the obvious issues — especially when run in a fresh-context subagent so the review isn’t biased by the implementation reasoning. The human catches the subtle ones. Both are essential.

Train your team

The framework is only as good as the people using it. Product engineers need to know:

• How to write effective refinement docs — Clear requirements produce better code
• When to intervene vs. let the AI run — Not every task needs human input at every step
• How to write and maintain skills — The team’s knowledge should be encoded, not tribal
• How to debug agent behavior — When the AI produces poor output, the fix is usually better context or a sharper skill, not a better one-off prompt

We invest in training because the compound returns are enormous. One engineer who masters the workflow produces more output than five who don’t.

Start small, expand gradually

Don’t try to automate everything on day one.

1. Start with cross-repo context — the .gitignore / .cursorignore pattern
2. Add one or two MCPs — database and browser automation
3. Install a few core skills — refinement, code-review, and your primary framework
4. Expand from there based on what bottlenecks you hit

The full setup (a broad skill library, 19 MCPs, 9 repos) took us months to refine. But the first version — 2 repos, a couple of skills, 2 MCPs — was running in a day.

Get Started →