Nick Vigilante
ba64724f8a
Closes DOCS-332. ## Summary Add `docs/.style/content-guidelines.md` as the canonical source of truth for what belongs in Coder's docs and what doesn't. Slim `.claude/skills/doc-check/SKILL.md` and reconcile `.claude/docs/DOCS_STYLE_GUIDE.md` so they defer to that canonical file. One-line pointer added from root `AGENTS.md`. ## Problem DOCS-332 cataloged five gaps in the doc-check skill and its sibling AI-facing docs: 1. Two style guides overlapping and contradicting each other on bold and italic conventions. 2. The SKILL had a single "do not comment" class (auto-generated CLI docs); everything else was inferred. Source of sticky-comment noise. 3. Premium signaling split across two files (`(Premium)` H1 suffix in SKILL, `"state": ["premium"]` manifest entry in DOCS_STYLE_GUIDE). 4. The no-emdash rule lived in root `AGENTS.md` and DOCS_STYLE_GUIDE but not in the SKILL. 5. The redirects-live-in-`coder/coder.com:redirects.json` rule lived only in DOCS_STYLE_GUIDE. In parallel, a cross-repo content guidance discussion (June 2026) produced a canonical "what belongs in the docs" document in Notion that disagreed with the existing GitHub guidance in three places: screenshots, "proactive documentation," and in-docs troubleshooting. ## Fix **New canonical file**: `docs/.style/content-guidelines.md`. Translates the canonical content guidance into the repo: - Diátaxis framing. - "Documentation lands with the change" rule with three corollaries (docs in same PR; no docs for unconfirmed features; multi-PR launch exception, present tense, never as a promise). - 7-step quick decision checklist. - "What belongs / what doesn't / routing table" structure. - Screenshot policy: only when the topic would be confusing without it; PHI/PII, secrets, minimal surface area, alt text required. - Premium signaling requires both H1 suffix and `"state": ["premium"]` in `docs/manifest.json`. - Redirects must be added to `coder/coder.com:redirects.json`, never `docs/_redirects`. - Verify-against-code rule with exact RBAC names and full API paths. - Terraform exception for minimal teaching examples. **Slim `.claude/skills/doc-check/SKILL.md`**: defers scope and routing to `docs/.style/content-guidelines.md`. Adds an explicit "What not to comment on" list (Gap 2) covering internal refactors, test-only changes, CI/tooling, dep bumps, and pure code reorganizations. Closes Gaps 3, 4, and 5 in the same pass. **Reconcile `.claude/docs/DOCS_STYLE_GUIDE.md`**: removes the image-driven documentation pattern, the placeholder-screenshot workflow, the "proactive documentation" pattern, and the in-docs troubleshooting H3 pattern. Each is replaced with a short pointer to the canonical guidelines. Prose, formatting, and structural conventions remain; this file continues to cover those. **`AGENTS.md`**: one-line pointer added to the navigation section and the read-when-relevant list. ## What's explicitly out of scope - **Gap 1** (bold and italic reconciliation): deferred to DOCS-186, which will redirect the human-facing `docs/about/contributing/documentation.md` to `docs/.style/style-guide.md` once DOCS-180 lands. - **Prose-rule migration** to `docs/.style/style-guide.md`: handled by DOCS-180. - **doc-check workflow comment-format changes**: deferred (Phase 2 work). - **redirect-suggestion behavior in doc-check**: tracked as DOCS-359. - **Historical predictive-content sweep across `docs/`**: tracked as DOCS-358. ## Known CI notes - This PR will trigger `docs-preview`, which posts a comment with a deep link to the first added Markdown file. The link will 404 because `docs/.style/**` files are not added to `docs/manifest.json` and shouldn't be (the directory is contributor-facing, not published). DOCS-180 negates `docs/.style/**` in the `docs-preview` workflow; once that lands the papercut goes away. Safe to ignore the comment on this PR. - `deploy-docs` will run on merge but is manifest-driven: since `docs/.style/**` files are not in `docs/manifest.json`, the surgical Algolia indexer will skip them and no full Vercel rebuild fires. - `doc-check` will run on this PR; the diff has no user-facing product change, so it should report no documentation impact. ## Review This change is documentation-only and does not modify product code or CI checks in any meaningful way. Per standing instructions this requires a human review; the `/coder-agents-review` bot is **not** triggered. <details> <summary>Implementation plan and decision log</summary> ### Decisions made during scoping 1. **Option B (consolidate)** for DOCS-332: a single canonical content-guidance file instead of distributing fixes back into the existing sibling files. 2. **File location**: `docs/.style/content-guidelines.md`. The rules apply to both humans and AI, so an AI-prefixed naming scheme would mislead. `docs/.style/` is contributor-facing and not published to coder.com per the DOCS-180 convention. 3. **Independent merge**: this PR does not block on DOCS-180. The README in `docs/.style/` is a minimal stub that should merge cleanly with the DOCS-180 README. 4. **Canonical-source model**: GitHub becomes canonical for docs content guidance. The cross-repo source page will be rewritten to point at this file as a follow-up. ### Conflicts resolved | Topic | Old GitHub guidance | New canonical | |----------------|---------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------| | Screenshots | Image-driven sections; placeholders welcome | Use only when topic confusing without; 4 rules (no PHI or PII, no secrets, minimal surface area, alt text) | | Timelessness | "Proactive Documentation" pattern (write ahead, reference PR number) | "Documentation lands with the change" plus 3 corollaries; predictive language banned | | Troubleshooting| In-docs H3 pattern | Routes to Support KB (Pilon); embedded widget under investigation | ### Pre-mortem - **`docs-preview` dead link**: known papercut documented in the CI notes above. - **`deploy-docs` over-fire**: addressed by manifest-driven exclusion; the surgical indexer skips non-manifest paths. - **Merge conflict with DOCS-180 `docs/.style/README.md`**: expected to be small and mechanical. Both PRs introduce the same directory and a "What lives here" table; the merge is "combine the rows". - **Merge conflict with DOCS-186**: none expected. DOCS-186 changes `docs/about/contributing/documentation.md`, which this PR does not touch. ### Follow-up tickets filed - **DOCS-358**: Sweep `docs/` for predictive or proactive content that violates the "docs land with the change" rule. - **DOCS-359**: doc-check suggests `redirects.json` entries on doc renames and moves. </details> --- *Generated via Coder Agents.*
About
Coder is a self-hosted platform for running AI coding agents and cloud development environments on infrastructure you control. It works with any cloud, IDE, OS, Git provider, and IDP.
Coder Workspaces
Coder Workspaces are cloud development environments defined with Terraform, connected through a secure Wireguard tunnel, and automatically shut down when not in use. Agents and developers share the same workspace infrastructure.
- Defined in Terraform: Templates describe the infrastructure for each workspace, from EC2 VMs and Kubernetes Pods to Docker containers.
- Any architecture and OS: Support ARM and x86-64 across Windows, Linux, and macOS from a single deployment.
- Managed by admins: Platform teams create and maintain templates that enforce approved images, resource limits, and security policies.
- Accessed from any IDE: Connect through VS Code, JetBrains, Cursor, a web terminal, remote desktop, or SSH.
- Automatic shutdown: Idle workspaces stop automatically to reduce cloud spend, and restart in seconds when needed.
Coder Agents
Coder Agents is a native AI coding agent built into Coder. The agent loop runs in the Coder control plane on your infrastructure, not in the workspace and not in a vendor's cloud. Developers interact with agents through the web UI or the REST API for programmatic and CI-driven workflows.
- Self-hosted agent loop: The control plane handles planning, model calls, and tool dispatch. Workspaces have zero AI awareness.
- No API keys in workspaces: LLM credentials stay in the control plane.
- Any model: Anthropic, OpenAI, Google, Bedrock, or self-hosted endpoints. Switching is a configuration change.
- Governance and cost controls: Centralized model approval, per-user spend limits, and audit logging.
- Open source and inspectable: The full platform is available to audit and extend.
IDE support
You can use:
-
Any Web IDE, such as
- code-server
- JetBrains Projector
- Jupyter
- And others
-
Your existing remote development environment:
-
A file sync such as Mutagen
Why remote development
Provisioning consistent development environments for a large engineering team is difficult. Each developer has preferences for operating systems, editors, and toolchains, and ensuring a reliable build environment across all of them is a maintenance burden. A missed step during onboarding or an unsupported local configuration can cost hours of debugging.
Remote development solves this by moving the environment off the developer's machine and into managed infrastructure. The developer's laptop becomes a portal into the actual compute where work happens. If a device is lost or replaced, access is simply revoked; no source code or credentials are stored locally.
This approach provides:
- Speed: Server-grade hardware accelerates builds, tests, and large workloads without requiring expensive local machines.
- Consistency: Infrastructure tools such as Terraform, nix, Docker, and Dev Containers produce identical environments for every developer.
- Security: Source code stays on private servers. Users and groups are managed through SSO and RBAC.
- Compatibility: Workspaces share infrastructure configurations with staging and production, reducing configuration drift.
- Accessibility: Browser-based IDEs and remote IDE extensions let developers work from any device, including lightweight laptops, Chromebooks, and tablets.
Read more on the Coder blog, the Slack engineering blog, or from Alex Ellis at OpenFaaS.
Why Coder
The key difference between Coder and other platforms is that the entire system, agent loop, control plane, model routing, and workspace provisioning, runs on infrastructure you control.
For agents, this means platform teams can:
- Run the entire agent loop on their infrastructure, with no SaaS dependency for orchestration.
- Define MCP servers, skills, and system prompts centrally so every agent session starts with the same tools, policies, and context.
- Keep LLM credentials out of workspaces entirely.
- Tie every agent action to an authenticated user identity.
- Support air-gapped and restricted-network deployments with self-hosted models.
For workspaces, this means admins can:
- Support any architecture (ARM, x86-64) and operating system (Windows, Linux, macOS).
- Modify pod/container specs, such as adding disks, managing network policies, or setting/updating environment variables.
- Use VM or dedicated workspaces, developing with Kernel features (no container knowledge required).
- Enable persistent workspaces, which are like local machines, but faster and hosted by a cloud service.
Pricing
Coder is free and open source under the GNU Affero General Public License v3.0. All developer productivity features are included in the open source version. A Premium license is available for enhanced support and custom deployments.
How Coder works
Coder workspaces are represented with Terraform, but you do not need to know Terraform to get started. The Coder Registry provides production-ready templates for AWS EC2, Azure, Google Cloud, Kubernetes, and other providers.
Providers and compute environments
Workspaces can include more than just compute. Terraform can add storage buckets, secrets, sidecars, and other resources.
See the templates documentation for details.
What Coder is not
-
Coder is not an infrastructure as code (IaC) platform.
- Terraform is the first IaC provisioner in Coder, allowing Coder admins to define Terraform resources as Coder workspaces.
-
Coder is not a DevOps/CI platform.
- Coder workspaces can be configured to follow best practices for cloud-service-based workloads, but Coder is not responsible for how you define or deploy the software you write.
-
Coder is not an online IDE.
- Coder supports common editors, such as VS Code, vim, and JetBrains, all over HTTPS or SSH.
-
Coder is not a collaboration platform.
- You can use Git with your favorite Git platform and dedicated IDE extensions for pull requests, code reviews, and pair programming.
-
Coder is not a SaaS/fully-managed offering.
- Coder is a self-hosted solution. You must host Coder in a private data center or on a cloud service, such as AWS, Azure, or GCP.