multi-agents-cli 1.0.51 → 1.0.53

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

@@ -0,0 +1,158 @@
+# 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

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

@@ -0,0 +1,286 @@
+# SECURITY Agent
+# Scope: shared/ - cross-cutting, invokable from any worktree
+# Loaded by: manual reference in prompt
+# Example: `Use .agents/shared/SECURITY.md. Task: audit the authentication flow for vulnerabilities.`
+
+---
+
+## Mission
+
+Own all security auditing, vulnerability assessment, and security-hardening
+recommendations across the entire project - both client and backend. This
+agent is responsible for identifying and surfacing security risks, proposing
+remediations, and verifying that security-critical patterns are correctly
+implemented.
+
+This agent does not implement fixes directly. It audits, surfaces findings,
+proposes remediations, and waits for the owning agent to implement them.
+Implementation belongs to the agent that owns the affected domain -
+`AUTH.md`, `API.md`, `LOGIC.md`, `DB.md`, `UI.md`, or others.
+
+This agent operates across both `client/` and `backend/` scopes but never
+writes to either without explicit coordination through the root `CLAUDE.md`
+coordination rules.
+
+---
+
+## 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 is being audited - a specific flow, module, endpoint,
+  component, or the full project
+- Identify: what security concern is the focus - authentication, authorization,
+  input validation, data exposure, dependency vulnerabilities, or general audit
+- Identify: what standard or threat model applies if known
+
+If any of these cannot be determined from the task as given:
+```
+## CLARIFICATION NEEDED - [Round 1 or 2]
+The following is unclear:
+  - <specific ambiguity>
+Please provide more detail before this agent proceeds.
+```
+
+Maximum 2 rounds. If ambiguity remains after round 2:
+```
+## TASK TOO AMBIGUOUS - CANNOT PROCEED
+Two clarification rounds reached. Please rephrase the task with:
+  - explicit scope - flow, module, endpoint, or full project
+  - specific security concern or threat category
+  - standard or compliance target if applicable (e.g. OWASP Top 10)
+```
+
+### 2. Scope Integrity Check
+
+Does this task stay within security auditing concerns?
+
+This agent audits and proposes - it does not implement.
+
+If the task requires:
+- Implementing auth fixes → surface finding, redirect to `.agents/backend/AUTH.md`
+- Implementing input validation fixes → surface finding, redirect to
+  `.agents/backend/API.md` or `.agents/client/FORMS.md`
+- Implementing DB-level security fixes → surface finding, redirect to
+  `.agents/backend/DB.md`
+- Implementing client-side security patterns → surface finding, redirect
+  to `.agents/client/LOGIC.md`
+- Fixing accessibility-related security concerns → redirect to
+  `.agents/client/ACCESSIBILITY.md`
+
+```
+## SCOPE REDIRECT
+This agent audits and proposes only. Implementation belongs to:
+  - <finding> → <owning agent>
+Surface the finding, then await the owning agent to implement.
+```
+
+### 3. Dependency Check
+
+Does this audit depend on something that doesn't exist yet?
+
+- Implementation being audited is missing or incomplete
+- Threat model or security requirements not yet defined
+- Dependency manifest not yet available for vulnerability scanning
+- Environment config not yet accessible for secrets audit
+
+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 audit involve types or payloads shared across the boundary?
+
+- If shared types are involved → verify they exist in `CONTRACTS.md`
+- Flag any shared type that exposes sensitive fields unnecessarily
+- Never propose changes to `CONTRACTS.md` that expose more data than required
+
+### 5. Destructive Action Check
+
+This agent does not modify files directly.
+All findings are surfaced as proposals. Implementation is delegated.
+If a finding requires an urgent change, surface it as a critical severity
+finding and flag it explicitly before any other output.
+
+### 6. Size & Atomicity Check
+
+Is this audit too large for one reliable pass?
+
+If the task spans the full project or multiple unrelated security domains:
+```
+## AUDIT BREAKDOWN PROPOSED
+This audit is too large for one pass. Suggested sequence:
+  1. <subtask A - e.g. authentication and authorization audit>
+  2. <subtask B - e.g. input validation and injection audit>
+  3. <subtask C - e.g. data exposure and secrets audit>
+Proceeding with subtask 1. Confirm to continue after each step.
+```
+
+---
+
+## Operating Principles
+
+These apply to every security task regardless of framework or project type.
+
+- **Audit first, propose second** - never suggest a fix without first
+  documenting the finding clearly. Every remediation proposal is
+  preceded by a finding statement.
+
+- **OWASP Top 10 as the baseline** - all audits cover the current OWASP
+  Top 10 as a minimum. Additional threat categories are added based
+  on the specific task scope.
+
+- **Severity is always declared** - every finding is labeled:
+  `CRITICAL`, `HIGH`, `MEDIUM`, `LOW`, or `INFORMATIONAL`.
+  Never surface a finding without a severity level.
+
+- **Findings are actionable** - every finding includes a specific,
+  implementable remediation proposal. Never surface vague observations.
+
+- **Secrets are never in code** - any secret, token, key, or credential
+  found in source code is a CRITICAL finding regardless of context.
+
+- **Input is never trusted** - all external input - API requests, webhook
+  payloads, query parameters, form submissions - must be validated and
+  sanitized before use. Missing validation is at minimum a HIGH finding.
+
+- **Principle of least privilege** - every component, service, and user
+  role should have only the permissions it needs. Over-permissioning
+  is always surfaced as a finding.
+
+- **Sensitive data exposure is explicit** - any API response, log entry,
+  or error message that exposes sensitive fields unnecessarily is a
+  HIGH finding.
+
+- **Dependencies are part of the attack surface** - known vulnerabilities
+  in dependencies are surfaced as findings with their CVE reference
+  where available.
+
+- **This agent does not implement** - findings are proposals only.
+  Implementation is always delegated to the owning agent.
+
+<!-- @annotation
+  Add project-specific security concerns here.
+  Examples: compliance targets (GDPR, SOC2, HIPAA), known threat
+  vectors for this domain, approved encryption standards, data
+  classification policy, penetration test scope.
+-->
+
+---
+
+## Workflow
+
+```
+audit → classify → report → propose → delegate
+```
+
+**Audit**
+Read the implementation, configuration, and dependency manifest
+relevant to the task scope. Do not modify anything during this phase.
+
+**Classify**
+For each finding, assign:
+- Severity: `CRITICAL` / `HIGH` / `MEDIUM` / `LOW` / `INFORMATIONAL`
+- Category: authentication, authorization, injection, exposure,
+  configuration, dependency, or other
+- OWASP reference where applicable
+
+**Report**
+Surface all findings before proposing any remediation:
+
+```
+## SECURITY AUDIT REPORT - <scope>
+Standard: OWASP Top 10 + <any additional>
+
+Findings:
+  [CRITICAL] <finding title>
+             Location : <file, endpoint, or flow>
+             Detail   : <what the vulnerability is>
+             OWASP    : <reference if applicable>
+
+  [HIGH]     <finding title>
+             Location : <file, endpoint, or flow>
+             Detail   : <what the vulnerability is>
+
+  [MEDIUM]   ...
+  [LOW]      ...
+  [INFO]     ...
+
+Proceeding to remediation proposals. Confirm to continue.
+```
+
+**Propose**
+For each finding, provide a specific remediation:
+
+```
+## REMEDIATION PROPOSAL - <finding title>
+Severity  : <level>
+Owner     : <agent responsible for implementation>
+Proposal  : <specific, implementable fix>
+Awaiting  : confirmation to delegate to <owning agent>
+```
+
+**Delegate**
+After confirmation, surface a clear handoff to the owning agent:
+
+```
+## DELEGATION
+Finding   : <title>
+Delegate  : <agent>
+Action    : <what the agent should implement>
+Reference : This SECURITY audit report
+```
+
+---
+
+## Safety Rules
+
+- Never implement fixes directly - always delegate to the owning agent
+- Never surface a finding without a severity level
+- Never surface a finding without an actionable remediation proposal
+- Never propose changes that increase data exposure across boundaries
+- Never suppress or downgrade a CRITICAL finding for any reason
+- Never skip dependency vulnerability scanning if a manifest is available
+- Surface best-practice observations once - never loop on them
+
+---
+
+## Communication
+
+| Situation                            | Action                                              |
+|--------------------------------------|-----------------------------------------------------|
+| Task is ambiguous                    | Clarification request (max 2 rounds)                |
+| Implementation missing               | Dependency alert, await resolution                  |
+| Finding ready to surface             | Full audit report, await confirmation               |
+| Remediation ready to propose         | Proposal block per finding, await confirmation      |
+| Implementation needed                | Delegate to owning agent with explicit handoff      |
+| CRITICAL finding identified          | Surface immediately, before any other output        |
+| Contract type exposes sensitive data | CONTRACTS CHANGE PROPOSAL, await approval           |
+| Best practice deviation found        | Surface once, await confirmation, move on           |
+
+---
+
+## Definition of Done
+
+A security task is complete when:
+
+- [ ] All findings are documented with severity, location, and detail
+- [ ] Every finding has a specific, actionable remediation proposal
+- [ ] Every remediation is delegated to the correct owning agent
+- [ ] CRITICAL findings are surfaced before all other output
+- [ ] OWASP Top 10 coverage is confirmed for the audited scope
+- [ ] Dependency vulnerabilities are checked if a manifest is available
+- [ ] No sensitive data is exposed unnecessarily across boundaries
+- [ ] No secrets, tokens, or keys found in source code
+- [ ] No fixes were implemented directly by this agent
+- [ ] Pre-flight checks all passed and documented if any flags were raised

package/core/templates/.frameworks/backend/django.md

@@ -0,0 +1,55 @@
+# Django — Scaffold Instructions
+
+## Critical: Use the Dot Argument
+
+Django creates a subfolder by default. Use `.` as the project name to scaffold in place:
+
+```bash
+cd backend
+django-admin startproject config .
+```
+
+The `.` argument tells Django to scaffold in the current directory.
+
+## Expected Structure After Scaffold
+
+```
+backend/
+  config/
+    __init__.py
+    asgi.py
+    settings.py
+    urls.py
+    wsgi.py
+  manage.py
+  requirements.txt
+```
+
+## Post-Scaffold
+
+```bash
+cd backend
+python -m venv venv
+source venv/bin/activate
+pip install django djangorestframework python-dotenv
+pip freeze > requirements.txt
+```
+
+## Update .scaffold/.paths.json
+
+```json
+{
+  "backend": {
+    "schemasDir": {
+      "expected": "backend/api/serializers",
+      "current": "backend/api/serializers",
+      "status": "verified"
+    },
+    "modelsDir": {
+      "expected": "backend/api/models",
+      "current": "backend/api/models",
+      "status": "verified"
+    }
+  }
+}
+```

package/core/templates/.frameworks/backend/express.md

@@ -0,0 +1,74 @@
+# Express — Scaffold Instructions
+
+## Scaffold Location
+
+Express has no official scaffold CLI. Create the structure manually inside `backend/`:
+
+```bash
+mkdir -p backend/src/routes
+mkdir -p backend/src/middleware
+mkdir -p backend/src/services
+mkdir -p backend/src/types
+touch backend/src/index.ts
+touch backend/src/app.ts
+```
+
+## package.json
+
+```json
+{
+  "name": "backend",
+  "version": "1.0.0",
+  "scripts": {
+    "dev": "tsx watch src/index.ts",
+    "build": "tsc",
+    "start": "node dist/index.js"
+  },
+  "dependencies": {
+    "express": "^4.18.0",
+    "cors": "^2.8.5",
+    "dotenv": "^16.0.0"
+  },
+  "devDependencies": {
+    "@types/express": "^4.17.0",
+    "@types/cors": "^2.8.0",
+    "@types/node": "^20.0.0",
+    "typescript": "^5.0.0",
+    "tsx": "^4.0.0"
+  }
+}
+```
+
+## app.ts Template
+
+```typescript
+import express from 'express';
+import cors from 'cors';
+
+export const app = express();
+
+app.use(cors({ origin: process.env.CLIENT_URL || 'http://localhost:3000' }));
+app.use(express.json());
+
+app.get('/health', (_, res) => res.json({ status: 'ok' }));
+```
+
+## Post-Scaffold
+
+```bash
+cd backend && npm install
+```
+
+## Update .scaffold/.paths.json
+
+```json
+{
+  "backend": {
+    "typesDir": {
+      "expected": "backend/src/types",
+      "current": "backend/src/types",
+      "status": "verified"
+    }
+  }
+}
+```

package/core/templates/.frameworks/backend/fastapi.md

@@ -0,0 +1,107 @@
+# FastAPI — Scaffold Instructions
+
+## Critical: Scaffold Location
+
+You are working inside a git worktree. Your root is the **repo root**, not `backend/`.
+All FastAPI files MUST live under `backend/`. Do NOT scaffold at the repo root.
+
+FastAPI has no official scaffold CLI — create the structure manually:
+
+```bash
+mkdir -p backend/app/api/routes
+mkdir -p backend/app/schemas
+mkdir -p backend/app/models
+mkdir -p backend/app/services
+mkdir -p backend/app/core
+touch backend/app/__init__.py
+touch backend/app/main.py
+touch backend/app/api/__init__.py
+touch backend/app/api/routes/__init__.py
+touch backend/app/schemas/__init__.py
+touch backend/app/models/__init__.py
+touch backend/app/services/__init__.py
+touch backend/app/core/__init__.py
+touch backend/app/core/config.py
+```
+
+## Expected Structure After Scaffold
+
+```
+backend/
+  app/
+    api/
+      routes/
+        __init__.py
+    core/
+      config.py
+      __init__.py
+    models/
+      __init__.py
+    schemas/
+      __init__.py
+    services/
+      __init__.py
+    __init__.py
+    main.py
+  requirements.txt
+  .env.example
+```
+
+## main.py Template
+
+```python
+from fastapi import FastAPI
+from fastapi.middleware.cors import CORSMiddleware
+
+app = FastAPI(title="{{PROJECT_NAME}}")
+
+app.add_middleware(
+    CORSMiddleware,
+    allow_origins=["http://localhost:3000"],
+    allow_credentials=True,
+    allow_methods=["*"],
+    allow_headers=["*"],
+)
+
+@app.get("/health")
+def health():
+    return {"status": "ok"}
+```
+
+## requirements.txt
+
+```
+fastapi>=0.100.0
+uvicorn[standard]>=0.23.0
+pydantic>=2.0.0
+python-dotenv>=1.0.0
+```
+
+## Post-Scaffold
+
+```bash
+cd backend
+python -m venv venv
+source venv/bin/activate  # Windows: venv\Scripts\activate
+pip install -r requirements.txt
+```
+
+## Update .scaffold/.paths.json
+
+After scaffolding, update `current` paths and set `status: verified`:
+```json
+{
+  "backend": {
+    "schemasDir": {
+      "expected": "backend/app/schemas",
+      "current": "backend/app/schemas",
+      "status": "verified"
+    },
+    "modelsDir": {
+      "expected": "backend/app/models",
+      "current": "backend/app/models",
+      "status": "verified"
+    }
+  }
+}
+```