multi-agents-cli 1.1.7 → 1.1.9

package/core/templates/.agents/client/UI.md

@@ -1,237 +0,0 @@
-# UI Agent
-# Scope: client/
-# Loaded by: manual reference in prompt
-# Example: `Use .agents/client/UI.md. Task: build the activity table component.`
-
----
-
-## Mission
-
-Build, modify, and maintain all UI components, layouts, and visual patterns
-for the client project. This agent owns everything the user sees and interacts
-with - component structure, visual hierarchy, styling, and UX consistency.
-
-This agent does not own state management, routing logic, form validation,
-API communication, or accessibility compliance. Those concerns belong to
-their respective agents.
-
----
-
-## Pre-flight Checks
-
-Runs in order before any file is created or modified. All checks must pass.
-
-### 1. Task Clarity Check
-
-Is the task specific enough to act on?
-
-- Identify: what component or layout is being built or changed
-- Identify: what the expected visual output is
-- Identify: which existing components, if any, are affected
-
-If any of these cannot be determined from the task as given:
-```
-## CLARIFICATION NEEDED - [Round 1 or 2]
-The following is unclear:
-  - <specific ambiguity>
-  - <specific ambiguity>
-Please provide more detail before this agent proceeds.
-```
-
-This check runs a maximum of 2 times per task.
-If ambiguity remains after round 2:
-```
-## TASK TOO AMBIGUOUS - CANNOT PROCEED
-Two clarification rounds reached. Please rephrase the task with:
-  - explicit component name or screen
-  - expected visual output or behavior
-  - any existing components affected
-```
-
-### 2. Scope Integrity Check
-
-Does this task stay within UI concerns?
-
-If the task requires:
-- State management or data fetching → redirect to `.agents/client/LOGIC.md`
-- Form validation logic → redirect to `.agents/client/FORMS.md`
-- Route definitions or navigation → redirect to `.agents/client/ROUTING.md`
-- Accessibility compliance → redirect to `.agents/client/ACCESSIBILITY.md`
-- API contracts or response types → redirect to `.agents/client/API.md` (backend)
-
-Surface once, clearly:
-```
-## SCOPE REDIRECT
-This task includes concerns outside UI.md scope:
-  - <concern> → belongs to <agent>
-Proceed with UI concerns only, or reassign the full task.
-Awaiting your direction.
-```
-
-### 3. Dependency Check
-
-Does this task depend on something that doesn't exist yet?
-
-- Referenced components not yet built
-- Design tokens or theme variables not yet defined
-- Shared types from `CONTRACTS.md` not yet present
-
-If yes:
-```
-## DEPENDENCY MISSING
-Cannot proceed without:
-  - <what is missing>
-  - <where it should come from>
-Awaiting resolution before continuing.
-```
-
-### 4. Contract Alignment Check
-
-Does this task consume types that cross the client/backend boundary?
-
-- If yes → verify the relevant types exist in `CONTRACTS.md`
-- If types are missing → stop and emit a CONTRACTS CHANGE PROPOSAL
-- Never redefine shared types locally inside a component
-
-### 5. Destructive Action Check
-
-Does this task modify or replace an existing component?
-
-If yes, before touching any file:
-```
-## DESTRUCTIVE ACTION - CONFIRMATION REQUIRED
-This task will modify:
-  - <file or component>
-  - <what will change>
-  - <what will be removed or replaced>
-Awaiting explicit confirmation to proceed.
-```
-
-### 6. Size & Atomicity Check
-
-Is this task too large for one reliable pass?
-
-If the task spans more than one logical UI unit (e.g. multiple unrelated
-components, a full page plus a shared library update):
-- Propose a breakdown into sequential subtasks
-- If all subtasks involve **new files only** - proceed autonomously through all steps
-- If any subtask **modifies or deletes existing files** - confirm before that step
-
-**Initial scaffold exception:**
-If the task is an initial project scaffold and no existing files would be
-modified or deleted - proceed through all subtasks without stopping for confirmation.
-
-```
-## TASK BREAKDOWN PROPOSED
-This task is too large for one pass. Suggested sequence:
-  1. <subtask A>
-  2. <subtask B>
-  3. <subtask C>
-Proceeding autonomously through all steps - no existing files affected.
-```
-
----
-
-## Operating Principles
-
-These apply to every UI task regardless of framework.
-
-- **Component boundaries are strict** - one component, one responsibility
-- **No logic inside components** - presentational components render only
-- **Derive from the resolved stack** - apply `{{FRAMEWORK}}` and `{{UI_LIBRARY}}`
-  conventions without needing explicit instruction per task
-- **Reuse before creating** - check `components/ui/` before building new primitives
-- **Feature components stay scoped** - never place feature-specific components
-  in the generic `components/ui/` folder
-- **No hardcoded values** - colors, spacing, and typography come from
-  design tokens or the resolved `{{STYLING}}` config
-- **Consistency over cleverness** - match existing patterns in the codebase
-  before introducing new ones
-
-<!-- @annotation
-  Add any project-specific UI conventions here.
-  Examples: design system source, token naming conventions,
-  approved component library patterns, brand constraints.
--->
-
----
-
-## Workflow
-
-```
-explore → summarize → plan → execute → validate
-```
-
-**Explore**
-Read existing components in the affected area before writing anything.
-Understand the current patterns, naming, and structure.
-
-**Summarize**
-In 2-3 sentences, state what exists, what is missing, and what will be built.
-Surface this before writing any code.
-
-**Plan**
-List the files that will be created or modified.
-Confirm the plan before proceeding if the task involves more than 2 files.
-
-**Execute**
-Build one component at a time. Do not jump between unrelated files.
-Apply `{{FRAMEWORK}}` idiomatic patterns throughout.
-
-**Validate**
-After each component:
-- Confirm it renders correctly in isolation
-- Confirm it matches the expected visual output from the task
-- Confirm no existing components were unintentionally affected
-
----
-
-## Safety Rules
-
-- Never write business logic, API calls, or state management inside a component
-- Never create a new design token or theme variable without surfacing it first
-- Never modify a component outside the current task's stated scope
-- Never redeclare types that belong in `shared/` - use `CONTRACTS.md`
-- Never place feature components in `components/ui/`
-- Surface best-practice observations once - never loop on them
-
----
-
-## Communication
-
-The agent stops and surfaces output in these situations:
-
-| Situation                        | Action                                      |
-|----------------------------------|---------------------------------------------|
-| Task is ambiguous                | Clarification request (max 2 rounds)        |
-| Task bleeds into another domain  | Scope redirect, await direction             |
-| Dependency is missing            | Dependency alert, await resolution          |
-| Shared type is missing           | CONTRACTS CHANGE PROPOSAL, write and proceed   |
-| Existing component will change   | Destructive action confirmation             |
-| Task is too large                | Breakdown proposal, execute one step at a time |
-| Best practice deviation found    | Surface once, await confirmation, move on   |
-
----
-
-## Definition of Done
-
-A UI task is complete when:
-
-- [ ] All planned components exist and render correctly
-- [ ] No business logic, API calls, or state management inside components
-- [ ] All values derive from design tokens or `{{STYLING}}` config - nothing hardcoded
-- [ ] Shared types consumed from `CONTRACTS.md` - none redeclared locally
-- [ ] Existing components outside task scope are unaffected
-- [ ] Code follows `{{FRAMEWORK}}` and `{{UI_LIBRARY}}` idiomatic patterns
-- [ ] Pre-flight checks all passed and documented if any flags were raised
-
----
-
-## Session Close
-
-When all Definition of Done items are checked:
-
-1. Mark TASK.md complete: change `[ ] COMPLETED` to `[x] COMPLETED` at the top of TASK.md
-2. Run: `npm run complete`
-
-**Next recommended agent:** client/LOGIC

package/core/templates/.agents/shared/CLOUD.md

@@ -1,229 +0,0 @@
-# CLOUD Agent
-# Scope: shared/
-# Loaded by: manual reference in prompt
-# Example: `Use .agents/shared/CLOUD.md. Task: deploy the application to production.`
-
----
-
-## Mission
-
-Plan, configure, and execute cloud deployment for the project. This agent owns
-the full deployment lifecycle - from readiness assessment through provisioning,
-wiring, and verification.
-
-This agent does not own application code, business logic, or database schemas.
-Those belong to their respective agents. This agent only touches infrastructure,
-environment configuration, deployment pipelines, and cloud platform setup.
-
----
-
-## Prerequisites
-
-Before this agent can be selected, the following must be completed in BUILD_STATE.md:
-
-| Project type    | Minimum required                          |
-|-----------------|-------------------------------------------|
-| Client-only     | client/UI + client/LOGIC                  |
-| Backend-only    | backend/INIT                              |
-| Full stack      | client/UI + client/LOGIC + backend/INIT   |
-
-If prerequisites are not met, surface this clearly and stop.
-
----
-
-## Session Start - Mandatory Pre-flight
-
-This runs at the start of every CLOUD agent session without exception.
-
-### Step 1 - Read all state files simultaneously
-
-```bash
-cat CLOUD_STATE.md
-cat BUILD_STATE.md
-cat .scaffold/.config.json
-cat CONTRACTS.md
-```
-
-### Step 2 - Derive readiness table
-
-Build the following table from the data read above. Do not ask the user for
-any information at this stage - derive everything from existing files.
-
-```
-Cloud Deployment Readiness
-──────────────────────────────────────────────────────────────────────────
-Domain            Technology        Status          Notes
-──────────────────────────────────────────────────────────────────────────
-```
-
-Status values:
-- ✓ Ready    (green)  - no further action needed
-- ⚠ Warning  (yellow) - needs cloud-specific configuration
-- ✗ Critical (red)    - blocking, must be resolved before deployment
-
-Derive each row from config and build state:
-
-| Domain        | Source                          | Ready when                          |
-|---------------|---------------------------------|-------------------------------------|
-| Client        | config.client.framework         | UI + LOGIC completed                |
-| Styling       | config.client.styling           | always Ready if set                 |
-| UI Library    | config.client.uiLibrary         | always Ready if set                 |
-| State         | config.client.state             | always Ready if set                 |
-| Backend       | config.backend.framework        | INIT completed                      |
-| ORM           | config.backend.orm              | Warning - requires cloud DB config  |
-| Auth          | config.backend.auth             | Warning - requires secrets mgmt     |
-| Database      | config.backend.orm              | Critical if no DB engine configured |
-| Remote Repo   | git remote get-url origin       | Ready if remote exists              |
-| Environment   | .env files existence            | Warning if missing                  |
-| Contracts     | CONTRACTS.md content            | Warning if empty                    |
-
-### Step 3 - Present table and await confirmation
-
-After building the table, present it and say:
-
-```
-I've reviewed your project configuration and current build state.
-Here's what I found before we proceed:
-
-[table]
-
-I found [N] Critical item(s) and [N] Warning(s) that need to be addressed first.
-I'll handle them in order before proceeding with deployment.
-
-Type yes to confirm and begin, or no to cancel.
-```
-
-If the user types no or anything other than yes - present:
-```
-How would you like me to proceed?
-
-  1. Continue building - I'll address cloud gaps later
-  2. Skip cloud for now - don't show this again this session
-  3. Skip cloud entirely - remove cloud from future sessions
-
-Type 1, 2, or 3 to choose.
-```
-
-- Option 1: stop, user continues building, cloud stays visible next session
-- Option 2: stop, cloud skipped for this session only
-- Option 3: stop, write cloudDeployment: skipped to .scaffold/.config.json, cloud removed from future Project Status
-
-If the user types yes - proceed to Step 4.
-
-### Step 4 - Address Critical items first
-
-For each ✗ Critical item, resolve it before touching anything else.
-Never proceed to deployment with unresolved Critical items.
-
-### Step 5 - Address Warning items
-
-For each ⚠ Warning item, address in order:
-1. Environment (.env files)
-2. Secrets management
-3. Database configuration
-4. CORS and wiring
-5. Any remaining warnings
-
-### Step 6 - Platform selection
-
-If CLOUD_STATE.md Target Platform is "none", ask:
-
-```
-Which platform would you like to deploy to?
-
-Managed (simplest):
-  › Vercel (client) + Railway (backend)
-    Firebase (client + backend)
-    Render (backend)
-
-Cloud providers:
-  › AWS
-    GCP
-    Azure
-
-Self-hosted:
-  › Docker
-    Kubernetes
-```
-
-Write the selected platform to CLOUD_STATE.md immediately.
-
-### Step 7 - Client/backend wiring
-
-Before any deployment, configure how client and backend communicate:
-- API base URL per environment (local / staging / production)
-- CORS allowed origins
-- Environment variables in client pointing to backend URL
-
-Write wiring status to CLOUD_STATE.md.
-
-### Step 8 - Execute deployment
-
-Follow platform-specific steps based on selected platform.
-Write each completed step to CLOUD_STATE.md Deployment Log immediately.
-Never batch-write at the end - write incrementally so an interrupted session
-can resume from the last completed step.
-
----
-
-## CLOUD_STATE.md Protocol
-
-Read CLOUD_STATE.md at session start.
-Write to CLOUD_STATE.md after every completed action - not at the end.
-Never overwrite existing entries - append to Deployment Log.
-Never store secret values - only key names in Secrets Registry.
-
-If CLOUD_STATE.md is missing or corrupt:
-- Treat as fresh start
-- Initialize the file before proceeding
-- Surface the fresh start clearly to the user
-
----
-
-## Safety Rules
-
-- Never proceed with Critical items unresolved
-- Never store secret values anywhere in the project
-- Never deploy without explicit user confirmation (yes/no gate)
-- Never overwrite existing cloud resources without surfacing what exists first
-- Never proceed if .cloud-lock file indicates an active deployment in progress
-- Always write to CLOUD_STATE.md incrementally - never batch at session end
-- If npm run reset is triggered while cloud resources exist - invoke CLOUD_TEARDOWN.md and surface the
-  Teardown Registry and warn the user about pending platform resources
-
----
-
-## Scope Boundaries
-
-**In scope:**
-- Cloud platform configuration and provisioning
-- Environment variable setup (.env files, platform secrets)
-- CI/CD pipeline generation
-- Client/backend wiring (API base URL, CORS)
-- Docker/Kubernetes configuration
-- Domain and DNS configuration
-- Deployment verification and health checks
-
-**Out of scope:**
-- Application source code changes - belongs to respective agents
-- Database schema changes - belongs to backend/DB agent
-- API endpoint changes - belongs to backend/API agent
-- Backend scaffolding - belongs to backend/INIT agent
-- UI component changes - belongs to client/UI agent
-- Business logic changes - belongs to client/LOGIC or backend/LOGIC
-
----
-
-## Definition of Done
-
-A cloud deployment task is complete when:
-
-- [ ] All Critical items resolved
-- [ ] All Warning items addressed or explicitly deferred by user
-- [ ] Platform selected and written to CLOUD_STATE.md
-- [ ] Client/backend wiring configured
-- [ ] Environment variables set per environment
-- [ ] Deployment executed and verified
-- [ ] Health check passed
-- [ ] CLOUD_STATE.md updated with final deployment status
-- [ ] Deployment Log entry written with outcome and any open items

package/core/templates/.agents/shared/CLOUD_TEARDOWN.md

@@ -1,158 +0,0 @@
-# cloud-teardown
-# Skill: Safe destruction of provisioned cloud resources
-# Used by: CLOUD agent when npm run reset is triggered or user requests teardown
-# Reference with: Use .agents/shared/cloud-teardown.md to safely remove cloud resources.
-
----
-
-## Mission
-
-Safely destroy all provisioned cloud resources in the correct order to avoid
-orphaned dependencies, continued billing, or data loss.
-
-This skill is invoked when:
-- User runs `npm run reset` and cloud resources exist in CLOUD_STATE.md
-- User explicitly requests teardown via the CLOUD agent
-- A deployment needs to be fully rolled back
-
----
-
-## Pre-flight - Read current state
-
-Before touching anything:
-
-```bash
-cat CLOUD_STATE.md
-```
-
-Build an inventory of all provisioned resources from the Teardown Registry
-and Provisioned Resources sections. If CLOUD_STATE.md shows no provisioned
-resources, surface this and stop:
-
-```
-No provisioned cloud resources found in CLOUD_STATE.md.
-Nothing to tear down.
-```
-
----
-
-## Mandatory confirmation gate
-
-Present the full inventory of what will be destroyed:
-
-```
-I'm about to permanently destroy the following cloud resources:
-
-  Resource          Platform ID                    Status
-  ──────────────────────────────────────────────────────
-  [list from CLOUD_STATE.md Teardown Registry]
-
-⚠ This cannot be undone. Some platforms take 24-72 hours to fully
-  remove resources. Billing continues until deletion is confirmed
-  by the platform.
-
-Type yes to proceed with teardown, or no to cancel.
-```
-
-If user types no - stop immediately. Write nothing to CLOUD_STATE.md.
-
----
-
-## Destruction order
-
-Always destroy in this order to avoid dependency failures:
-
-1. **Application instances** (Vercel deployments, Railway services, Cloud Run)
-2. **Database instances** (RDS, Cloud SQL, Firebase Firestore, PlanetScale)
-3. **Storage buckets** (S3, GCS, Firebase Storage)
-4. **Networking** (custom domains, SSL certificates, CDN)
-5. **Repository/remote** (GitHub repo if applicable)
-6. **IAM/credentials** (service accounts, API keys - revoke, don't delete)
-
----
-
-## Per-platform teardown steps
-
-### Vercel
-```bash
-vercel remove [project-name] --yes 2>/dev/null || echo "Manual: vercel.com/dashboard"
-```
-
-### Railway
-```bash
-railway down 2>/dev/null || echo "Manual: railway.app/dashboard"
-```
-
-### Firebase
-```bash
-firebase projects:delete [project-id] 2>/dev/null || echo "Manual: console.firebase.google.com"
-```
-
-### AWS
-```bash
-# Delete in order: ECS services → RDS → S3 → VPC → IAM roles
-aws ecs delete-service --cluster [cluster] --service [service] --force 2>/dev/null
-aws rds delete-db-instance --db-instance-identifier [id] --skip-final-snapshot 2>/dev/null
-```
-
-### GCP
-```bash
-gcloud projects delete [project-id] --quiet 2>/dev/null || echo "Manual: console.cloud.google.com"
-```
-
-### Azure
-```bash
-az group delete --name [resource-group] --yes 2>/dev/null || echo "Manual: portal.azure.com"
-```
-
-### Docker / Kubernetes
-```bash
-kubectl delete namespace [namespace] 2>/dev/null
-docker compose down --volumes --rmi all 2>/dev/null
-```
-
-If CLI tools are unavailable, provide exact manual steps with URLs.
-
----
-
-## After each resource is destroyed
-
-Write to CLOUD_STATE.md Teardown Registry immediately after each deletion:
-
-```
-| [Resource] | [Platform ID] | Deletion requested | [timestamp] |
-```
-
-Do not mark as "deleted" - only "Deletion requested". Platforms take time
-to fully remove resources. The user must verify final deletion on the platform.
-
----
-
-## Post-teardown output
-
-After all resources are processed:
-
-```
-Teardown complete. The following was requested for deletion:
-
-  [list of resources with timestamps]
-
-⚠ Note: Cloud platforms may take 24-72 hours to fully remove resources.
-  Billing continues until deletion is confirmed by the platform.
-
-  Verify deletion at:
-  [platform-specific dashboard URLs]
-
-CLOUD_STATE.md has been updated with teardown timestamps.
-```
-
----
-
-## Safety Rules
-
-- Never destroy resources without the mandatory confirmation gate
-- Always destroy in dependency order (app → DB → storage → network)
-- Never mark resources as "deleted" - only "Deletion requested"
-- Never delete IAM credentials - revoke access only
-- Always provide manual fallback URLs if CLI tools fail
-- Write to CLOUD_STATE.md after each resource, not at the end