Workspace onboarding

Inspect repository context, verify environment configurations, and load governing rules before proposing solutions or running modifications.

Modes

Select an onboarding mode before Step 1:

• Full discovery mode (default). Execute runtime detection, config mapping, and environment reconnaissance for greenfield or unfamiliar workspaces.
• Re-verification mode. Re-check runtime and branch state on existing workspaces without rewriting codebase notes.

Boundary isolation

Workspace onboarding operates strictly in an exploratory and reconnaissance capacity. Never modify application source files, run mutating database migrations, or install global system packages during workspace onboarding.

Workflow

Follow these four steps in sequence.

Step 1. Stack and environment discovery

Identify the active runtime, framework, database, and package managers from files on disk and live runtime commands.

1. Inspect project manifests:
   • For PHP or Laravel projects, read composer.json to verify framework version, packages, and custom scripts.
   • For Node, React, Vue, or Next.js projects, read package.json to check dependencies, Tailwind versions, and test runners.
   • For Python projects, inspect pyproject.toml, Pipfile, or requirements.txt.
2. Inspect environment files with strict priority:
   • Read .env first whenever the file exists on disk. Use .env.example solely as a fallback template when .env is absent.
   • Check DB_CONNECTION, DATABASE_URL, port bindings, and external services in the active .env.
   • Verify database connections through config files or health check endpoints; never assume database credentials or connection state without explicit checks.
3. Validate active runtime database configuration:
   • Run framework introspection commands when available (such as php artisan db:show or php artisan env for Laravel) to verify the live database engine, host, and port.
   • Check test configuration files (such as phpunit.xml) to identify test specific overrides (such as in-memory SQLite) and avoid misclassifying test fixtures as the application database.
4. Record discovered stack properties including runtime version, framework, database driver, test runner, and linter.

Completion criterion. Verify and record the runtime version, framework, database engine, and tooling inventory directly from active environment files or live CLI commands.

Step 2. Rule discovery and binding

Locate and read the applicable project guidelines and behavioral constraints.

1. Set RULE_FILE to the first existing path in this exact order:
   • .agents/rules/AGENTS.md
   • .agents/skills/AGENTS.md
   • AGENTS.md
   • CODEBASE.md
   • CLAUDE.md
   • $HOME/.config/agents/AGENTS.md
2. If no path exists, record Rules: none and continue.
3. If multiple paths exist, bind only RULE_FILE and report lower-priority files as ignored.
4. Bind rule constraints to the current session:
   • Adopt the persona, tone, and language defined in the discovered rules immediately from turn 1.
   • Respect boundaries on file manipulation and tool usage.
5. Resolve conflicts between rule files and runtime facts:
   • If assertions in discovered rule files contradict live runtime manifests or database introspection from Step 1, treat live runtime as ground truth.
   • Adopt the live configuration and note the documentation drift in the onboarding synthesis line.

Completion criterion. Governing rule file identified and its constraints applied to the current context.

Step 3. Unslop baseline calibration

Activate core unslop constraints across all human-facing responses.

1. Enforce zero filler openings. Do not use greeting tokens like "Halo", "Tentu", "Siap", or polite padding.
2. Ban em dashes, en dashes, and hyphens acting as dashes. Use commas, periods, or separate sentences.
3. Restrict colons to introducing lists, tables, or code blocks. Never use colons as connectors in the middle of sentences or as pseudo-labels.
4. Consult the full vocabulary substitution table in unslop only when generating detailed documentation, reviews, or prose.

Completion criterion. Response draft verified to contain zero filler phrases and zero dash defects.

Step 4. Onboarding synthesis line

Deliver a single substantive verification statement before proceeding to task execution.

Format the status line using this syntax:

[Stack: <framework> <version> | DB: <driver> | Tooling: <test_runner>, <linter> | Rules: <governing_file>]

Follow immediately with the substantive technical answer or the next concrete investigation step. Never output empty confirmation filler.

Completion criterion. Exactly one dense status bracket output followed directly by task execution.

Quick audit checklist