home / skills / ladderchaos / tora-skills / fullstack-dev

fullstack-dev skill

/fullstack-dev

This skill coordinates changes across contracts and frontend, updates SDKs and types, and ensures synchronized builds and artifacts end-to-end.

npx playbooks add skill ladderchaos/tora-skills --skill fullstack-dev

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
2.2 KB
---
name: fullstack-dev
description: Full-stack development context for coordinating changes across contracts and frontend. Use this skill when changes span both backend contracts and frontend code, requiring synchronized updates across the stack.
---

# Full-Stack Development

Context for coordinating changes across contracts, frontend, and shared packages.

## When This Skill Activates

- Changes spanning contracts AND frontend
- SDK or shared type updates
- Deployment artifact synchronization
- ABI changes affecting frontend
- End-to-end feature implementation

## Scope

- Smart contracts (Solidity, Anchor)
- Frontend applications (React, Next.js)
- Shared SDKs and type packages
- Deployment configurations

## Key Practices

1. **Coordinate changes** across contracts and frontend
2. **Update SDK** when contract interfaces change
3. Run **both** contract tests AND frontend build
4. Sync deployment artifacts after contract changes

## Configuration Guidelines

- Use config files for all UI text and constants
- Never hardcode strings in components
- Validate configs before build

## File Naming & Versioning

- **Canonical Names Only**: Use `Market.sol`, NOT `MarketV10.sol`
- **Single Active Version**: Never keep `V1.ts` and `V2.ts` side-by-side
- **Archiving**: Move old code to `archive/` or trust Git history

## Common Workflows

### After Contract Changes

```bash
# Build and test contracts
forge build && forge test

# Sync ABIs to frontend
./sync-deployments.sh  # or equivalent

# Rebuild frontend
cd apps/web && npm run build
```

### After Frontend Changes

```bash
cd apps/web
npm run build
npm run dev
```

### Full Build

```bash
pnpm install
pnpm build
```

## Key Integration Points

- **SDK package** - ABIs exported from contracts
- **Deployment configs** - Contract addresses per chain
- **Shared types** - TypeScript types matching contract structs

## Sync Checklist

After contract changes:
- [ ] ABIs regenerated
- [ ] Frontend config updated
- [ ] Types regenerated
- [ ] Frontend builds successfully
- [ ] E2E tests pass

## Related Skills

- `solidity-dev` - Contract development, gas optimization, security scanning
- `frontend-dev` - UI implementation and styling

Overview

This skill provides a coordinated full-stack development context for changes that span smart contracts, shared SDKs/types, and frontend applications. Use it to ensure synchronized updates, reliable builds, and consistent deployment artifacts across the stack. It emphasizes practical steps for validating interfaces, regenerating artifacts, and running both contract and frontend tests.

How this skill works

The skill inspects change scope to determine when updates affect contracts and frontend code together, prompting a cross-stack workflow. It enforces regeneration of ABIs and types, synchronization of deployment configs, and running contract tests plus frontend builds to catch integration issues early. It provides checklists and concrete commands to standardize the process.

When to use it

  • When a contract interface (ABI) or struct changes and frontend types or SDKs must be updated
  • When adding features that require coordinated backend contracts and UI implementation
  • When SDK or shared type packages are modified and consumers need synchronized releases
  • When deployment addresses, chain configs, or artifacts change and must be reflected in the frontend
  • Before a release that requires end-to-end validation across contracts and web apps

Best practices

  • Coordinate changes across teams and update SDKs immediately after modifying contracts
  • Regenerate ABIs and TypeScript types as part of the same PR that changes contracts
  • Keep canonical file names and a single active version per component; archive old versions
  • Do not hardcode UI strings or constants; use config files and validate them before build
  • Run contract tests and a full frontend build plus E2E tests before merging

Example use cases

  • A solidity struct changes, requiring TypeScript types and frontend form updates to match
  • Deploying a contract upgrade that changes addresses; sync deployment configs and rebuild the app
  • Publishing an updated SDK package that exposes new helper functions for the frontend
  • Implementing a new end-to-end feature that touches contracts, SDKs, and multiple frontend routes

FAQ

What commands should I run after changing contracts?

Build and test contracts, regenerate ABIs, sync deployment artifacts to the frontend, then rebuild the frontend and run E2E tests.

How should I handle versioning when interfaces change?

Use canonical names, keep only a single active version, and move deprecated code to an archive or rely on VCS history.