AI Tooling

Learn the operating system for AI development

Agents, skills, planning, branching, and quality gates explained as one system for building faster without losing project direction.

Operating model

Plan
01

Shape intent into specs, non-goals, and verification criteria.

Context
02

Load repo rules, architecture notes, and task-specific memory before edits.

Execute
03

Use agents and skills on scoped feature branches with focused checks.

Promote
04

Move through dev, test, and prod only after checks and review.

6 topics found

agentsfoundation

Foundation

What agents are

Agents are tool-using AI workers that can inspect a project, decide which tools to call, make bounded changes, run checks, and iterate toward a defined outcome. Treat them like capable teammates with a clear task contract: they need context, allowed actions, verification requirements, and a stopping point so their speed serves the project instead of drifting away from it.

agentstoolsautonomycontext

Principles

  • Treat agents as bounded executors, not independent owners.
  • Give agents clear inputs, allowed tools, verification gates, and stop conditions.
  • Keep durable project rules outside chat so every agent starts from the same contract.

Steps

  • Define the outcome in one concrete sentence.
  • Load the project contract and only the docs relevant to the task.
  • Let the agent inspect before editing.
  • Require verification output before accepting work.

Avoid

  • Letting the agent infer product direction from a vague prompt.
  • Skipping context load because the change looks small.
  • Accepting a diff without checking the behavior it changes.
skillspractice

Practice

When to build skills

Skills are worth building when the same agent behavior keeps showing up across projects, repos, or teams and the workflow has rules stable enough to document. A good skill packages triggers, constraints, examples, scripts, references, and expected outputs so an agent can repeat the work reliably without rediscovering the process every time.

skillsreusepromptsautomation

Principles

  • Build a skill when the workflow repeats and has stable rules.
  • Keep skill instructions specific enough to prevent drift but short enough to be followed.
  • Prefer scripts and templates inside skills when repetition is mechanical.

Steps

  • Name the workflow the skill owns.
  • Write trigger conditions and non-goals.
  • Add command recipes, references, and example outputs.
  • Test the skill on a real repo task before treating it as standard.

Avoid

planningpractice

Practice

Planning without drift

Planning without drift means turning loose ideas into execution-ready specs before agents start changing the codebase. The plan should preserve product intent through scope, non-goals, acceptance criteria, branch naming, verification gates, and review notes, giving every contributor the same target even when implementation moves quickly.

planningspecsscoperoadmap

Principles

  • Use brainstorms for discovery and specs for execution.
  • Approve scope before implementation begins.
  • Record non-goals as aggressively as goals.

Steps

  • Capture the idea in Plan or the planning source of truth.
  • Promote only clear work into an approved spec.
  • Create a feature branch named after the spec.
  • Verify against acceptance criteria before promotion.

Avoid

  • Treating a brainstorm as an implementation contract.
  • Adding adjacent features while already inside a feature branch.
  • Skipping non-goals because the desired outcome feels obvious.
workfloworchestration

Workflow

Feature to prod cycle

A clean feature-to-prod cycle separates local implementation from integration, staging validation, and production release decisions. Feature branches contain focused work, `dev` absorbs reviewed integration, `test` proves the release candidate, and `prod` becomes the intentional deployment boundary instead of whatever branch happened to build successfully.

branchesdeploymentvercelrelease

Principles

  • Feature branches isolate implementation.
  • `dev` is for integration, `test` is for release validation, and `prod` is the production promotion branch.
  • Production deploys should come from a known release branch, not an arbitrary local state.

Steps

  • Branch from the current integration base with `feature/<slug>`.
  • Open a PR from feature to `dev` after lint, build, and review.
  • Promote `dev` to `test` for staging validation.
  • Promote `test` to `prod` for production deployment.
  • Tag the release or merge back to the long-lived default branch after production is healthy.

Avoid

  • Deploying production directly from a feature branch.
  • Letting `dev`, `test`, and `prod` diverge for long periods.
  • Promoting without rerunning checks at each boundary.
workfloworchestration

Orchestration

Orchestrating large work

Large-scale AI development works when the effort is split into small, independently verifiable slices that share one source of truth. Specs define the target, Brain captures durable discoveries, agents execute scoped branches, and handoffs summarize behavior and risks so parallel work compounds instead of creating incompatible assumptions.

orchestrationmulti-agentsliceshandoff

Principles

  • Split broad work into independently verifiable slices.
  • Give each agent one slice and one source of truth.
  • Use Brain for durable discoveries and Plan for execution scope.

Steps

  • Start from an approved spec.
  • Create slices by boundary, risk, or user-facing workflow.
  • Run agents on separate feature branches when work can conflict.
  • Merge only after checks and a human-readable summary of shipped behavior.

Avoid

  • Parallelizing before the architecture boundary is clear.
  • Letting each agent invent its own acceptance criteria.
  • Using chat history as the only handoff artifact.
qualityorchestration

Quality

Quality gates for AI work

AI-assisted changes need explicit quality gates because fast implementation can hide broken behavior, weak assumptions, or undocumented drift. Baseline lint and build checks catch obvious failures, while browser verification, review, preview deployments, and durable notes make sure the shipped result matches the intended workflow instead of merely compiling.

verificationreviewtestingci

Principles

  • Make the smallest check mandatory and broader checks conditional on risk.
  • Review behavior, not just generated code.
  • Capture failed commands when they reveal repeatable traps.

Steps

  • Run focused checks while implementing.
  • Run the repo baseline gate before review.
  • Use preview deployments for user-facing routes.
  • Promote durable lessons into Brain or docs after closeout.

Avoid

  • Assuming generated code is correct because it compiles.
  • Letting UI changes ship without a browser check.
  • Forgetting to update docs when workflow surfaces change.