Agentic Workspace & Platform Engineering

A workspace, not a plugin list

A reference workspace records supported editor and extension versions, approved models and plans, allowed MCP servers or other integrations, build prerequisites, and repository instructions. A new hire can reproduce the approved setup without copying a colleague's undocumented settings. Model output can still vary; the shared configuration is a baseline to test, not a promise of identical behavior.

We work with Cursor, Cline and GitHub Copilot, and can support a mix when different teams have different constraints.

Instruction files, by tool and version

File conventions change between releases, so we check current documentation at the start of every engagement. Today:

• Cursor: project rules live in .cursor/rules, and AGENTS.md is supported for simple cross-tool instructions. The older .cursorrules file is legacy and not what we recommend for new work. See the Cursor rules documentation.
• Cline: a .clinerules directory holds rule files. See the Cline rules documentation.
• GitHub Copilot: repository instructions go in .github/copilot-instructions.md.

Architecture rules and boundaries

Good rules are specific and checkable by a human: services in /billing may not import from /identity internals; all database access goes through the repository layer; new HTTP handlers need an input schema and an authorization test. We write these from your actual architecture decision records, not from a template, and keep them short enough that the model attends to them.

Be clear about what this achieves. Rules are guidance. A model can ignore or misapply them, and they are not a security boundary. What enforces a boundary is the tooling around it: import-lint rules or dependency-cruiser configs failing CI, CODEOWNERS requiring review, and credentials scoped so an agent cannot reach what it should not.

Permissions and containment

Agents that run commands or edit many files need explicit limits. We configure isolated development credentials, restricted tool access and separate working branches. Production access is denied by default; even read-only configuration can contain secrets. Exceptions need an approved purpose, scoped credentials and a review trail. Test the restrictions outside the model rather than relying on a prompt to enforce them.

Engagement shapes

• Reference workspace for one team, delivered as a template repository your platform group can fork.
• Audit of an existing setup: rule files, extension sprawl, permissions and secrets exposure, with a ranked fix list.
• Platform integration: rules distribution, version pinning and update process owned by your internal developer-platform team.

Related work

Rules work best when engineers know how to review against them: AI strategy and developer enablement. Rules need a backstop in the pipeline: automated quality and security guardrails. For non-engineer prompt-to-app tools, read our overview of vibe coding platforms. To scope a pilot, get in touch.