Skip to content

Dashecorp Engineering Rig — Shared Workflow

These rules apply to ALL contributors — human developers and AI agents alike.

Branching

  • Branch from main: feature/issue-{N}-short-description
  • Prefixes: feature/, fix/, refactor/, docs/, chore/, ci/, test/
  • Never push directly to main. Always use feature branches and PRs.

Commits

Conventional commits required:

Prefix When
feat: New feature
fix: Bug fix
refactor: Code restructure, no behavior change
docs: Documentation only
chore: Maintenance, deps, config
test: Tests only
ci: CI/CD changes

Format: type(scope): description — e.g. feat(auth): add OAuth2 login

Documentation

All docs use markdown with YAML frontmatter:

---
title: "Short title"
description: "One-line description"
type: "infrastructure | architecture | standard | guide | reference"
queries: ["search queries this doc answers"]
updated: "YYYY-MM-DD"
---

Rules: - PRs that change behavior MUST include doc updates - Docs live in docs/ directory. READMEs at repo root. - Tables over paragraphs, code blocks for commands. Concise, no fluff. - Update the updated field when modifying docs.

Full spec: docs/documentation-standard.md

Pull Requests

  • One PR per issue. Reference with Closes #N.
  • Squash merge to main.
  • Wait for CI + review before merging.
  • PR title: conventional commit format, under 70 characters.

Review Expectations

Every PR is checked for:

  1. Correctness — does the code do what the issue asks?
  2. Security — OWASP top 10, no secrets in code
  3. Tests — adequate coverage for changes
  4. Docs — updated if behavior changed, valid frontmatter
  5. Commits — conventional format

Blocking issues: security, bugs, broken tests, missing docs. Non-blocking: style, naming, minor improvements.

Security

  • Never expose secrets (passwords, tokens, API keys) in output, commits, or logs.
  • Never install third-party code without security review.
  • All repos must remain private.
  • Pipe secrets from Bitwarden or env vars — never as visible arguments.

Multi-Repo Work

When a task spans multiple repos:

  1. Create a tracking issue in the primary repo.
  2. Reference it from related issues in other repos: See {org}/{repo}#{N}.
  3. Branch each repo independently with the same issue reference.
  4. PR each repo independently, link PRs in descriptions.
  5. Merge in dependency order (shared libs first, consumers last).

Available Tools (MCP Servers)

Tier Servers Available to
Core github, rig-memory Everyone (human + agent)
Human bitwarden, appstoreconnect, playwright, cloudflare, discord, revenuecat, infra-health, telegram, pushbullet-sms, totp, context-layer, deadline-tracker, submission-checklist Workstation only
Agent github (app token), advisor K8s cluster only

Repo Structure

Each managed repo should have:

AGENTS.md          # Import shared rules + repo-specific build/test/arch
docs/              # Documentation with YAML frontmatter
README.md          # Project overview with frontmatter