simple-one-shot

name	simple-one-shot
description	Use when a user wants a small, complete, real, boring one-shot app solution or a dry spec for one, especially vanilla HTML/CSS/JavaScript plus minimal ASP.NET Core Web API interview-style tasks.

Simple One Shot

Build or specify small full-stack applications as lean production-ish code, not demo code.

Use this skill when the user asks for:

• a one-shot implementation of a small app
• a live-coding-interview-sized full-stack solution
• a prompt/spec that separates simplicity from incompleteness
• a dry spec.md instead of code
• simplification of an app while keeping real behavior end to end

The phrase to preserve in spirit is:

small, complete, real, boring code

Decide The Mode

If the user asks for a dry spec, create or update spec.md.

If the user asks to implement, build the app end to end.

If the user provides a task but does not specify the mode, implement the solution unless the repository context makes that risky or the user is clearly asking for a prompt/spec only.

Dry Spec Mode

Create spec.md with:

1. Task summary
2. Scope and explicit non-goals
3. Backend endpoints and in-memory data shape
4. Frontend files and UI behavior
5. Manual run commands
6. Acceptance checklist

Keep the spec short and executable. Do not turn it into product documentation.

Use this template:

# Spec

## Task

<one paragraph describing the app>

## Scope

- <required behavior>
- <required behavior>

## Non-Goals

- No authentication
- No database unless requested
- No frontend framework or build step
- No stubbed endpoints or fake success behavior

## Backend

- Minimal ASP.NET Core Web API in `Program.cs`
- In-memory data storage
- Real endpoints:
  - `<METHOD> <PATH>`: <behavior>

## Frontend

- `wwwroot/index.html`
- `wwwroot/styles.css`
- `wwwroot/app.js`
- Uses `fetch` against the backend
- Implements the required UI operations end to end

## Run

```sh
dotnet run
```

Then open the URL printed by ASP.NET Core.

## Acceptance

- [ ] <observable behavior works>
- [ ] <observable behavior works>
- [ ] No TODOs, stubs, mocks, placeholder data after startup, or hardcoded success paths

Implementation Mode

Build a working full-stack solution for the user's task.

Constraints:

• Keep the solution intentionally small and readable for a live coding interview.
• Use plain HTML, CSS, and vanilla JavaScript for the frontend.
• Use minimal ASP.NET Core Web API for the backend.
• No frontend framework, no build tooling, no TypeScript.
• No fake data after the app starts unless explicitly required.
• No stubbed endpoints.
• No TODO, placeholder, mock, demo-only, or hardcoded success behavior.
• The app must actually perform the requested operations end to end.

Code style:

• Prefer boring, obvious code over abstractions.
• Use short files and simple names.
• Avoid unnecessary layers like repositories, services, DTO mappers, factories, dependency injection abstractions, or validation frameworks unless the task truly needs them.
• Include only essential error handling.
• Do not add authentication, logging, retry logic, generic helpers, test scaffolding, Docker, OpenAPI customization, or styling extras unless requested.
• Make the frontend easy to manually edit: simple DOM queries, simple event handlers, simple fetch calls.

Backend:

• Use a minimal ASP.NET Core API in Program.cs.
• Store data in memory unless the task requires a database.
• Use simple classes or records.
• Implement real CRUD or business logic as required.
• Serve the frontend from static files when practical.

Frontend:

• Use one index.html, one styles.css, and one app.js.
• Keep CSS modest and readable.
• Use fetch to call the backend.
• The UI should be functional, not fancy.

Output:

• Give exact commands to run it.
• Do not explain general concepts unless needed.

Default ASP.NET Core Shape

For new projects, prefer:

<project>/
|-- Program.cs
|-- <project>.csproj
`-- wwwroot/
    |-- index.html
    |-- styles.css
    `-- app.js

Use app.UseDefaultFiles(); and app.UseStaticFiles(); before mapping API endpoints.

Prefer simple endpoint names:

GET    /api/items
POST   /api/items
PUT    /api/items/{id}
DELETE /api/items/{id}

Use status codes that matter for manual use:

• 200 OK for successful reads and updates
• 201 Created for successful creates
• 204 No Content for successful deletes or simple toggles
• 400 Bad Request for missing or invalid input
• 404 Not Found for missing records

Simplification Review

When asked to review or simplify existing output, remove anything that does not directly support the requested behavior while keeping the app fully working.

Remove:

• decorative architecture
• unused config
• framework-style folders
• defensive code that cannot happen in the current app
• generic helpers with one caller
• extra UI polish
• fake seed data unless requested
• comments that restate obvious code

Keep:

• real endpoint behavior
• real client-server fetch flow
• enough validation to avoid broken state
• exact run commands
• manual editability

Never replace real behavior with stubs, mocks, placeholders, or hardcoded success responses.