nous-quick-execute

nous:quick-execute

Core Principle

Quick execution is not sloppy execution. It skips saved planning artifacts, not role boundaries, verification, or safety gates.

When To Use

• quick:ui, quick:be, or quick:db is invoked.
• The request is small, concrete, and can be completed in one focused pass.
• The user wants immediate implementation rather than a reusable NOUS plan.

When To Refuse Quick Mode

Stop and propose the matching planner when the request has unclear scope, multiple domains, schema risk, auth/security risk, deployment risk, or more than 3 coherent implementation tasks.

Planner fallback:

• UI -> nous:ui-plan or nous:ui-ultra-plan for pixel-perfect work.
• BE -> nous:be-plan.
• DB -> nous:db-plan.

Domain Loading

UI Quick

Apply frontend-design. If the prompt asks for pixel-perfect, premium, visual polish, or Refactoring UI, also apply frontend-design-skill-ultra.

Owns: UI code, component structure, visual hierarchy, responsive states, accessibility, frontend validation. Do not plan backend or DB work.

BE Quick

Apply nous-be-plan boundaries inline. Use test-driven-development for behavior changes, systematic-debugging for failures, and verification-before-completion before reporting success.

Owns: API/service/domain logic, backend validation, error handling, and backend tests. Do not change schemas unless user explicitly confirms DB scope.

DB Quick

Apply nous-db-plan boundaries inline. Treat destructive or irreversible data changes as hard-stop decisions. Use reversible migrations, rollback notes, and verification queries.

Owns: schema, indexes, migrations, query shape, integrity checks. Do not change backend/API behavior except minimal compile/test fixes needed for the DB change.

Quick Workflow

1. Resolve domain: ui, be, or db.
2. Restate the exact quick objective in one sentence.
3. Check scope: if too large or cross-domain, stop and propose the planner.
4. Inspect only the files needed for the domain.
5. Execute the smallest safe change.
6. Run focused verification; for behavior changes use TDD where practical.
7. Run verification-before-completion before claiming success.
8. Report files changed, evidence, blockers, and any follow-up plan needed.

Safety Gates

• No quick execution without a concrete objective.
• No cross-domain creep; adjacent work goes to planner fallback.
• No DB destructive operation without explicit confirmation.
• No success claim without fresh verification evidence.
• No broad refactor in quick mode.

Output Contract

## Quick Domain
## Objective
## Scope Check
## Changes Made
## Verification Evidence
## Blockers
## Follow-Up Plan Needed