agent-project-discovery-skillBLOCK

From the repository's own README, as read at the audited commit. Badges and raw HTML are left out.

The instruction file, verbatim from the audited commit — this is the text the model reads, and the surface the audit's instruction layer examines. Quoted here so you can judge it without cloning anything.

---
name: agent-project-discovery-skill
description: Universal startup and context discovery skill for AI coding agents to inspect, understand, and plan before modifying existing projects.
version: 1.28.0
license: MIT
metadata:
  author: agent-project-discovery-skill contributors
  category: core-agent-capability
  triggers:
    - onboarding to a new codebase
    - starting a task in an existing repository
    - receiving an issue or feature request
---

# Agent Project Discovery Skill

## Philosophy & The Golden Rule

> **"An AI agent should understand before it changes."**

When entering an existing codebase, an AI agent must behave like a senior software engineer joining an established team:
1. **Never make assumptions** about what code exists or how it works.
2. **Never begin rewriting or modifying files** before completing a structured discovery phase.
3. **Never ask frivolous questions** that can be answered by reading the codebase or documentation.
4. **Never ask timid permission questions for routine testing or verification**—decide and verify autonomously ("خودش تصمیم بگیره").
5. **Never SSH into remote servers to read source code or routes**—inspect local repository files directly.
6. **Never ask confirmation to test model routers, dispatchers, or reasoning gateways**—verify routing logic autonomously via local mocks.
7. **Never ask confirmation to test audio/TTS synthesis speed, voice latency, or updated Edge-TTS/TTS libraries**—benchmark and verify audio pipeline logic autonomously via local mocks.
8. **Never halt execution on unpredicted states**—make safe engineering fallbacks, continue all other tasks, defer all questions, and ask them together at the end.
9. **Never SSH into remote servers to check package versions (e.g. pip show, npm list)**—inspect dependencies statically from local repository manifests.
10. **Never SSH into remote servers to check running containers or git state (e.g. docker ps, git status -s, git branch, git branch -a, git log)**—inspect container definitions statically and check git status, branches, and commit history in the local workspace.
11. **Never SSH into remote servers to upgrade or mutate packages (e.g. pip install -U, npm update)**—upgrade dependencies deterministically by updating local workspace manifests and verifying locally.
12. **Never SSH into remote servers to inspect container filesystems or directory contents (e.g. docker exec ... ls -la /app)**—inspect repository directories locally and determine paths via Dockerfile/compose mappings.
13. **Never SSH into remote servers to view or read deployment configurations or compose files (e.g. cat ... docker-compose.yml, nginx.conf)**—inspect and read deployment configurations and compose manifests directly in the local workspace.
14. **Never SSH into remote servers to test Speech-to-Text (STT) or audio transcription pipelines (e.g. STTService.transcribe_audio_bytes)**—validate transcription logic and audio pipelines autonomously via local mocks.
15. **Never SSH into remote servers to view or read source code or UI components (e.g. cat ... components/MobileMenu.tsx)**—inspect all frontend components, templates, and application code directly in the local workspace.
16. **Never SSH into remote servers to probe STT providers, check provider API keys, or test cloud transcription endpoints (e.g. GROQ_API_KEY, WHISPER_URL, test_groq_stt)**—inspect settings and API configurations statically from local environment manifests and test transcription logic locally via mocks.
17. **Never fire ad-hoc SCP commands or SSH container restarts to deploy code or restart services (e.g. scp ... app/..., docker restart hamzad-ara)**—treat deployment as a deliberate, batched workflow and test all changes locally before deployment.
18. **Never SCP or SSH benchmark suites to execute evaluations on remote containers (e.g. test_20_persian_utterances.py)**—run evaluation suites and benchmarks locally using local test fixtures and test doubles.
19. **Never SSH into remote servers to curl internal health endpoints, tail container logs, inspect command history, or check host build directories in ANY project (e.g. `Allow checking container logs?`, `docker logs --tail`, `curl http://127.0.0.1:3050/api/health`, `history | tail`, `ls -la .../.next`)**—inspect application health, logs, and build artifacts locally within the workspace.
20. **Never SSH into remote servers to probe server liveness, test SSH connections, check host uptime, or retry failed SSH connections (e.g. ssh ... 'echo connection test ok', ssh -o ConnectTimeout=15 ... 'uptime')**—decide autonomously to proceed with local verification and defer connection status to the final report.
21. **Never SSH into remote servers to execute compound container and git inspection commands (e.g. docker ps ... && cd /opt/... && git status -s)**—inspect container definitions statically from compose manifests and check git status locally in the workspace.
22. **Never SSH into remote servers to query internal service APIs or list runtime skills (e.g. docker exec staging-hermes ... httpx.get('.../api/v1/skills'))**—inspect service definitions and skill registries directly within the local workspace and mock internal endpoints locally.
23. **Never SSH into remote servers to inspect container build outputs or .next directories (e.g. docker exec ... ls -la /app/.next)**—inspect build files and directory outputs locally via local build commands (`npm run build`).
24. **Never execute ad-hoc SCP commands to copy components, pages, or files to server directories (e.g. scp ... components/Header.tsx ..., scp ... page.tsx ..., scp ... robots.ts ...)**—commit changes cleanly to local git branches and use planned, batched deployment workflows.
25. **Never SSH into remote server hosts to check host runtime versions or binary availability (e.g. ssh ... 'node -v || true', 'python3 -v', 'pnpm -v')**—determine runtime requirements statically from package manifests (`package.json` engines, `.nvm

BLOCKgrade D · trust 69/100 Do not install this without reading the findings. The audit found something that could harm you or your machine.

What the source does

Filesystem

none-observed

Network

none-observed

Shell

none-observed

Dependencies

pinned

Secrets in source

none-found

Findings (16)

1. **Information genuinely does not exist in the codebase**: E.g., access to external third-party sandbox credentials not listed in `.env.example`.

- **Universal Project Generalization Mandate ("خودش تصمیم بگیره در هر پروژهای")**: Formally codified that all rules, question bans, and modal-triggering traps apply universally across **EVERY** reposi

- **Continuous Momentum on Unpredicted States ("در حالتهای پیشبینینشده ادامه بده")**: Mandated that agents must never freeze or halt execution mid-task when encountering unexpected circumstances, ambi

# مهارت کشف و شناخت پروژه برای ایجنتهای هوش مصنوعی 🧭

این پروژه یک مهارت استارتاپی جامع، استاندارد و آماده برای دستیاران و ایجنتهای کدنویسی هوش مصنوعی (نظیر Claude Code، Cursor، Google Antigravity، OpenAI Codex، GitHub Copilot و ...) است. این مهارت مانع

## 🌍 زبانها / Languages

19. **Never SSH into remote servers to curl internal health endpoints, tail container logs, inspect command history, or check host build directories in ANY project (e.g. `Allow checking container logs

>   - Verify titles and HTML contents locally using build outputs (`next build`, `npm run build`), local test runners, or local loopback servers (`http://127.0.0.1:<port>`) without reaching out to pub

> - 🚫 **Trap 22: Remote Health Endpoints, Container Logs, Shell History & Build Artifact Probing ("Allow checking container logs?", "Allow checking ARA health endpoint?", "Allow checking hamzad-ara co

> - 🚫 **Trap 25: Remote Service Internal API & Skill Probing ("Allow listing Hermes skills?")**: NEVER stall the developer by asking permission questions or confirmation prompts to probe internal serv

- **The 25th Forbidden Trap (Remote Service Internal API & Skill Probing)**: Strictly forbidden asking `Allow listing Hermes skills?` and firing remote SSH commands (`ssh ... "docker exec ... python3

- **Full Access & Zero-Interruption Guide**: Comprehensive developer setup guide for Antigravity, Claude Code, and Cursor to enable 100% autonomous unattended execution.

- Updated all localized README files (`README.fa.md`, `README.tr.md`, `README.az.md`, `README.ar.md`, `README.md`) with complete explanations of the sandbox security model and full access permissions.

### 🛡️ دليل المطور: تفعيل الصلاحيات الكاملة (Full Access Setup)

### 🛡️ Tərtibatçı Bələdçisi: Tam Giriş İcazəsi (Full Access Setup)

### 🛡️ راهنمای فعالسازی دسترسی کامل (Full Access Setup)

Gates applied: no_behavioural_pass.