Nextcode

Nextcode is a monorepo for building AI-first applications and the tooling around them. The goal is not just to ship apps, but to define a better way to structure vibe-coded software: clear boundaries, reusable primitives, strong conventions, and a workflow that stays understandable as the codebase grows.

This repository is for teams that want to ship code-generation, code-review, agent, and automation experiences from a single codebase without turning the project into a pile of one-off scripts.

The monorepo can include:

• End-user applications for AI coding workflows
• Shared packages for prompts, agents, SDKs, UI, config, and infrastructure helpers
• Internal tools for testing, evaluation, and observability
• Prototype apps and experimental features that can graduate into shared packages
• Documentation that explains how the system is meant to be extended

The exact structure may evolve, but the repo should stay organized around these layers:

apps/
	web/
	api/
	desktop/
packages/
	agent-core/
	prompts/
	ui/
	config/
	sdk/
tools/
	scripts/
	generators/
	evals/
docs/

Typical responsibilities:

• apps/ contains deployable products and surfaces
• packages/ contains reusable code shared across apps
• tools/ contains repo automation, generators, and maintenance scripts
• docs/ contains design notes, architecture docs, and runbooks

Recommended package categories:

• agent-* for agent runtime, orchestration, and tool execution
• prompt-* for prompt libraries, templates, and prompt versioning
• ui-* for shared interfaces and design primitives
• sdk-* for typed client libraries and integrations
• config-* for lint, build, test, and environment conventions

• Keep shared logic in packages, not copied across apps
• Prefer small, composable modules over large framework-specific abstractions
• Make agent behavior explicit, typed, and testable
• Treat prompts, tool schemas, and workflows as versioned product code
• Keep developer experience fast: simple setup, clear scripts, predictable conventions
• Build for reviewability, not just for generation speed
• Optimize for clarity after the first AI-generated pass

If the workspace already has a package manager and build setup, install dependencies and start the relevant app or tool from the root.

install dependencies
run the main development command
open the app or service you want to work on

Replace those commands with the repo-specific scripts once the package manager and task runner are added.

When adding or changing an app, follow this order:

1. Define the problem and the user-facing outcome.
2. Identify the smallest package that should own the new behavior.
3. Add or update the prompt, agent, or tool contract before wiring UI.
4. Implement the app surface as a thin composition layer.
5. Validate the behavior with tests, evals, or a repeatable manual check.

This keeps the repo from drifting into app-specific duplication and makes AI-generated changes easier to reason about later.

1. Make changes in the smallest package or app that owns the behavior.
2. Keep shared code generic and avoid app-specific coupling.
3. Add or update tests alongside behavior changes.
4. Verify the affected app, package, or automation path before merging.
5. Prefer reusable abstractions only after a pattern appears more than once.

• Use clear package boundaries and avoid circular dependencies
• Name packages by responsibility, not implementation detail
• Keep configuration centralized where possible
• Prefer typed APIs for prompts, tool calls, and agent contracts
• Document any non-obvious automation, especially around code generation or deployment
• Keep prompts, evals, and generated artifacts alongside the code they influence
• Make the default path easy, and the advanced path explicit

When introducing a new app or package:

• Decide whether it belongs in apps/ or packages/
• Define its public API and ownership early
• Add scripts, tests, and linting support from the start
• Update this README if the repo structure changes in a meaningful way
• Add a short example or template if the new piece is meant to be reused
• Capture any agent-specific assumptions in docs instead of tribal knowledge

Contributions should be small, reviewable, and scoped to one concern at a time. If a change affects shared behavior, update the relevant package docs or examples so downstream apps stay consistent.

See LICENSE for the terms that apply to this repository.