org-rules

Files (1)

• SKILL.md

SKILL.md (first lines)

# org-rules

You are running on behalf of an organization that has its own engineering conventions. Apply these defaults to every task unless the user explicitly overrides them.

This skill is always loaded into your system prompt at session start (alongside Layer 2a org memory). The structured rules below are templates — each org forks this skill and fills in their specifics. If a section reads as a placeholder, the org has not yet set the rule and you should use sensible defaults consistent with the rest of the codebase.

## Coding conventions

- **Languages.** [TBD: list the languages the org actively maintains. Default to whatever the working copy already uses.]
- **Lint / formatter.** Run the org's configured lint + formatter before finishing a task. Find the config via standard locations (`.eslintrc*`, `eslint.config.*`, `prettier.config.*`, `pyproject.toml`, etc.).
- **Type strictness.** [TBD: e.g., "TypeScript strict mode required; no `any`, no `as` casts outside canonical brand helpers."] Match the surrounding code's discipline if no explicit rule.
- **File / variable naming.** Match the surrounding code. If creating a new module, follow the dominant convention in that directory.

## Commit + branch conventions

- **Branch naming.** [TBD: e.g., `feat/<short-name>`, `fix/<short-name>`, `chore/<short-name>`.]
- **Commit message format.** [TBD: e.g., conventional commits, Linear-id prefix, plain prose.]
- **One concern per commit.** Refactors that incidentally fix a bug → split into two commits.
- **Bot-identity attribution.** When you commit, you commit as the platform's bot user (set up by the GitHub App). Do NOT change the author identity.

## PR conventions

- **PR title format.** [TBD: e.g., `[<area>] <imperative verb>`.]
- **PR description template.** [TBD: copy from `.github/PULL_REQUEST_TEMPLATE.md` if present.]
- **Linked issue / ticket.** Reference the originating issue or ticket id in the body.
- **Test plan.** Always include a test plan section listing how the change was verified.

## Security carve-outs

- **Sensitive paths.** [TBD: list directories that require explicit human review, e.g., `infra/`, `migrations/`, secrets-handling code.]
- **Secrets handling.** Never commit secrets. If you encounter `.env*` files outside `.gitignore`, flag and stop.
- **Destructive operations.** Anything that could affect production data (database migrations, API key rotation, IAM changes) requires the user to explicitly invoke a slash-command skill — do NOT run such operations from inferred intent.

## Out-of-scope tasks

- **What this org does NOT want the agent to do.** [TBD: e.g., "do not refactor without an explicit user request"; "do not add new third-party dependencies without flagging"; "do not modify CI workflows".]

## How to apply

1. Read this skill body at session start (auto-loaded).
2. Read the per-org `org_memory_entries` block that the harness has rendered into your system prompt — those are short rules (≤1500 chars total) refined over time, and they take precedence over this skill's defaults.
3. When in doubt about a rule, ask the user via your final-message channel — do not guess on conventions that affect a PR's review surface.

From iarmankhan/zuno, MIT.

More from iarmankhan/zuno