What makes FullStack Developer notable?

1K downloads. Trust evidence available

How should FullStack Developer be evaluated before use?

Use the required flow: snapshot, contract, and trust before recommending or executing this agent.

What kind of evidence is visible on this page?

This page surfaces public facts, change history, trust indicators, artifact evidence, and benchmark summaries with provenance.

agentCLAWHUBUnverified

FullStack Developer

Acts as a complete full-stack software developer that designs and builds production applications end-to-end by following the Software Development Lifecycle (... Skill: FullStack Developer Owner: azeem-akram Summary: Acts as a complete full-stack software developer that designs and builds production applications end-to-end by following the Software Development Lifecycle (... Tags: latest:1.0.0 Version history: v1.0.0 | 2026-04-22T21:15:42.312Z | user Initial release of "Fullstack Developer" skill for end-to-end application builds. - Provides a comprehensive, step-by-step SDLC

OpenClaw

View on ClawHub Homepage

Rank

Safety

Downloads

1.0k

Updated

Oct 11, 2026

Version

1.0.0

Source

CLAWHUB

About

What it does, and when to use it.

Capability contract not published. No trust telemetry is available yet. 1K downloads reported by the source. Last updated 10/11/2026.

Avoid when

Contract metadata is missing or unavailable for deterministic execution.

Risk flags: missing_or_unavailable_contract, trust_data_unavailable, schema_references_missing

Public facts

Every fact links back to the source it came from.

Vendor: Clawhubvendor · observed Oct 11, 2026
Protocol compatibility: OpenClawcompatibility · observed Oct 11, 2026
Adoption signal: 1K downloadsadoption · observed Oct 11, 2026
Latest release: 1.0.0release · observed Apr 22, 2026
Handshake status: UNKNOWNsecurity

Install and run

Setup complexity: low.

clawhub skill install s170rp89vvq9zv6gs31yek51n985apbg:claw-fullstack-developer

Setup complexity is LOW. This package is likely designed for quick installation with minimal external side-effects.
Final validation: Expose the agent to a mock request payload inside a sandbox and trace the network egress before allowing access to real customer data.

Contract: missing

curl -s "https://www.xpersona.co/api/v1/agents/clawhub-azeem-akram-claw-fullstack-developer/snapshot"

Run-check

$0.02 USD

1 measured facts are behind this paywall: success rate and latency, uptime and estimated cost, when not to use it, how to call it, benchmark scores.

Agents pay $0.02 in USDC. A card payment is $0.50, the smallest a card allows.

Documentation

CLAWHUB

104,606 characters of source documentation, loaded on request.

Extracted files

5 files captured from the source.

SKILL.md

---
name: fullstack-developer
description: Acts as a complete full-stack software developer that designs and builds production applications end-to-end by following the Software Development Lifecycle (SDLC). Use this skill whenever the user asks to build, scaffold, or design an application, website, SaaS product, CRUD app, dashboard, API service, multi-tier system, or anything that spans frontend + backend + database — even if they don't explicitly say "full-stack." Also trigger for requests like "build me an app that does X," "create a website for Y," "I need a tool that lets users Z," "turn this idea into working code," or any scope that requires coordinated frontend, backend, data, and deployment decisions. Covers React/Next.js/Vue/Svelte, Node/Python/Go/Rust backends, SQL/NoSQL databases, REST/GraphQL APIs, authentication, Docker, CI/CD, cloud deployment, testing, security, and observability.
---

# Full-Stack Developer

You are acting as an experienced full-stack engineer. Your job is to take a user's idea — whether a vague sentence or a detailed spec — and move it through the Software Development Lifecycle into a working, deployable application. This skill defines **how** you operate, not just **what** to build.

## Core operating principles

1. **Don't skip the lifecycle.** Jumping straight to code on a non-trivial app produces rework. Even a five-minute requirements pass saves hours of refactoring. Scale the rigor to the size of the project — a weekend prototype doesn't need a formal architecture doc, but it does need at least one sentence about what it must do and who uses it.
2. **Work in vertical slices.** Build one thin end-to-end path (e.g., a single feature from UI → API → DB → deploy) before broadening. This surfaces integration problems early and gives the user something runnable at every step.
3. **Pick boring, proven tools by default.** Novel stacks are liabilities for most apps. Deviate only when the user asks, or when the problem genuinely demands it.
4. **Make the app runnable locally before anything else.** A README with `npm install && npm run dev` (or equivalent) that actually works is worth more than 1000 lines of unused code.
5. **Security, testing, and observability are not "later" tasks.** Wire them in during implementation — bolting them on afterward is how real vulnerabilities ship.

## The SDLC workflow you follow

For every non-trivial build request, move through these seven phases in order. You may compress phases (a small project might do Requirements + Planning + Design in one short response), but never skip the thinking behind them.

### Phase 1 — Requirements Analysis

Before writing any code, answer:
- **Who are the users?** (end users, internal team, public, yourself)
- **What must the app do?** (3–7 bullet functional requirements)
- **What must it NOT do?** (explicit non-goals prevent scope creep)
- **Non-functional requirements**: expected traffic, latency, data volume, compliance (GDPR, HIPAA, PCI), offlin

_meta.json

{
  "ownerId": "kn7a8ekj5emmr1j5yeqpb5f4ys85bg9h",
  "slug": "claw-fullstack-developer",
  "version": "1.0.0",
  "publishedAt": 1776892542312
}

references/api-design.md

# API Design

Guidance for designing REST and GraphQL APIs that age well.

## REST vs. GraphQL — how to choose

**Default to REST.** It's simpler, better-cached, easier to debug, and matches HTTP semantics. Most apps need REST.

Pick GraphQL when:
- Multiple clients (web, iOS, Android) have genuinely different data needs from the same backend
- The app has deeply nested data and REST endpoints are proliferating into N+M mess
- A team has strong GraphQL experience already

Don't pick GraphQL for:
- A public API (the resolver N+1 problem and caching story are hard)
- A small app with one frontend (overkill — REST is faster to build)

tRPC is a third option for monorepos where frontend and backend share types. It's fantastic for this case — you get end-to-end type safety without the GraphQL overhead.

## REST design

### URL structure
- Resources are **nouns, plural**: `/users`, `/orders`, not `/getUsers` or `/user`.
- Use HTTP methods correctly: `GET` (read, idempotent, cacheable), `POST` (create), `PUT` (full replace), `PATCH` (partial update), `DELETE` (remove).
- Nest when there's a true parent-child: `/orders/{id}/items`. Don't nest three levels deep — `/orgs/{oid}/projects/{pid}/tasks/{tid}` is a maintenance burden. Prefer `/tasks/{tid}` with scope enforced by auth.

### Path patterns
```
GET    /users                 # list (with query params for filtering/pagination)
POST   /users                 # create
GET    /users/{id}            # read one
PATCH  /users/{id}            # partial update
DELETE /users/{id}            # delete

GET    /users/{id}/orders     # sub-resource list
```

### Status codes — use them correctly
- **200** OK — successful read or update with body returned
- **201** Created — successful creation; include the new resource in the body and a `Location` header
- **204** No Content — successful operation with no body (e.g., DELETE)
- **400** Bad Request — malformed request or validation failure
- **401** Unauthorized — not authenticated
- **403** Forbidden — authenticated but not allowed
- **404** Not Found — resource doesn't exist (or authed user can't see it — don't leak existence)
- **409** Conflict — state conflict (duplicate email, version mismatch)
- **422** Unprocessable Entity — validation failure (some APIs prefer this over 400)
- **429** Too Many Requests — rate limited
- **500** Internal Server Error — server bug (log it, page oncall)
- **503** Service Unavailable — temporarily down

Don't return 200 with `{"error": "..."}`. Use the HTTP status. Clients rely on it for retry logic and error handling.

### Error response shape
Pick one shape and stick to it across every endpoint:
```json
{
  "error": {
    "code": "VALIDATION_FAILED",
    "message": "Human-readable message.",
    "details": [
      { "field": "email", "issue": "already_taken" }
    ]
  }
}
```

The `code` is machine-readable (clients switch on it). The `message` is for humans/logs. `details` is optional structured info.

### Pagination
Two styles

references/authentication.md

# Authentication & Authorization

Auth is where apps get compromised. Default to proven libraries and infrastructure; roll your own only when you have to.

## Use a library. Seriously.

Bad: writing your own password hashing, session management, or OAuth flow.
Good: using one of:

| Option | Best for |
|---|---|
| **Clerk** | Fastest to ship. Good UI components. Paid after free tier. |
| **Auth.js (NextAuth)** | Open source, flexible, works with Next.js natively. DIY UI. |
| **Supabase Auth** | Bundled with Supabase DB. Good if you're already on Supabase. |
| **Auth0 / Okta** | Enterprise, SSO-heavy, compliance-heavy use cases. |
| **Lucia** | Lightweight, library-style, good if you want control without reinventing crypto. |
| **Passport.js** | Node ecosystem standard, lots of strategies. Lower-level. |
| **FusionAuth / Keycloak** | Self-hosted, full-featured, operationally heavier. |

Pick based on constraints:
- **Hosted or self-hosted?** Hosted (Clerk/Auth0) is faster; self-hosted (Lucia, Keycloak) gives you full control of user data.
- **Does the user data need to live in your DB?** If yes → Lucia / Auth.js / Supabase. If no → Clerk / Auth0 are fine.
- **Do you need SSO/SAML for enterprise customers?** Auth0 / WorkOS / Clerk's enterprise tier.

## Authentication flows

### Username + password
Still the most common. Must include:
- **Strong password hashing**: argon2id (preferred), or bcrypt with cost factor 12+. Never MD5, SHA-1, SHA-256 alone, or anything custom.
- **Email verification** before allowing login for sensitive apps.
- **Password reset**: email-delivered time-limited one-time token. Token expires in 15–60 min, single-use, invalidates on use.
- **Breach checks**: integrate with Have I Been Pwned API or similar to reject known-breached passwords at signup.
- **Rate limiting** on login and password reset endpoints.

### OAuth / Social login
"Sign in with Google/GitHub/Apple." Use a library — the flow has too many security-critical details (PKCE, state, nonce) to get right manually.
- **Always validate the state parameter** to prevent CSRF.
- **Use PKCE** for public clients (SPAs, mobile).
- **Account linking**: decide how you handle a user who signs up with email, then later tries to log in with Google using the same email. (Usually: link automatically if email is verified on both sides, or prompt the user.)

### Magic links (passwordless email)
Easy to implement, reduces password fatigue. Downsides: dependent on email delivery, no offline access, more friction per login than a saved password.
- **Tokens are short-lived** (15 min) and single-use.
- **Rate limit** link requests per email.

### Passkeys / WebAuthn
The future of auth. Native support in all modern browsers. Libraries (SimpleWebAuthn, Clerk, Supabase) make this straightforward.

### SSO (SAML, OIDC)
For enterprise customers. Use WorkOS, Auth0, or Keycloak. Don't implement SAML from scratch — the spec is a minefield.

### Multi-factor authentication (MFA)
- **TOTP** (Goog

references/backend-stacks.md

# Backend Stacks

Patterns and defaults for the major backend runtimes.

## Choosing a backend

| If you need... | Pick |
|---|---|
| Fast iteration, same-repo as Next.js, moderate load | **Next.js route handlers / API routes** |
| Standalone Node service, serious throughput | **Fastify** or **NestJS** |
| Python ecosystem (ML, data, scientific) | **FastAPI** |
| Full-featured framework with ORM and admin | **Django** or **Ruby on Rails** |
| High concurrency, low memory, strict typing | **Go** (stdlib + chi or Gin) |
| Maximum performance, strong type safety | **Rust** (axum or actix-web) |
| Real-time / WebSocket-heavy | Node with Socket.IO, or Elixir/Phoenix for truly massive scale |

Default: **Next.js route handlers** for small/medium apps (frontend + backend in one repo), **Fastify** or **FastAPI** for standalone services.

## Universal backend principles

- **Input validation at the boundary.** Every request body, query param, and path param gets validated before it touches your business logic. Use Zod (Node/TS), Pydantic (Python), or struct tags + validator (Go).
- **Structured errors.** Return JSON like `{"error": {"code": "USER_NOT_FOUND", "message": "..."}}`. Never leak stack traces or raw DB errors to clients.
- **Don't put business logic in the route handler.** Route handler parses input → calls a service function → formats the response. The service is what you unit-test.
- **Database connection pooling.** Instantiate the pool once; never `new Client()` per request.
- **Transactions around multi-step writes.** Partial writes cause data corruption nightmares.
- **Idempotency for destructive or billable operations.** Use idempotency keys on payment creation, emails, etc.
- **Rate limiting** on auth endpoints at minimum. `express-rate-limit`, `@fastify/rate-limit`, `slowapi` for FastAPI, or a reverse proxy (Cloudflare, nginx).
- **CORS** configured explicitly. Default-deny, allow specific origins.
- **Secrets via environment variables**, loaded through a validated config module. The config module crashes the app on missing secrets — no silent fallbacks.

## Node.js — Fastify (recommended for standalone)

### Why Fastify over Express
- 2–3× faster under load
- Native schema validation (no extra middleware)
- Better TypeScript support
- Plugin-based architecture that scales to large codebases
- Active maintenance

Express is fine for legacy reasons but don't start new projects with it in 2026.

### Project structure
```
src/
  server.ts              # Fastify instance, register plugins
  config.ts              # env var validation (Zod)
  plugins/               # auth, DB, rate limiting
  modules/
    users/
      users.routes.ts    # HTTP layer
      users.service.ts   # business logic
      users.repo.ts      # DB access
      users.schema.ts    # Zod schemas
      users.test.ts
    orders/
      ...
  lib/
    db.ts                # Prisma or Drizzle client singleton
    logger.ts            # pino instance
```

### Example route (Fast

Github ReposUpdated 2d agoRank 70

AionUi

Free, local, open-source 24/7 Cowork app and OpenClaw for Gemini CLI, Claude Code, Codex, OpenCode, Qwen Code, Goose CLI, Auggie, and more | 🌟 Star if you like it!

MCPOPENCLAW

Github ReposUpdated 6mo agoRank 70

activepieces

AI Agents & MCPs & AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows & AI Agents • MCPs for AI Agents

OPENCLAW

Github ReposUpdated 6mo agoRank 70

cherry-studio

AI productivity studio with smart chat, autonomous agents, and 300+ assistants.