Rules Commands

Rules allow you to teach PostQode your preferred ways of working, architecture styles, code conventions, and communication preferences.

PostQode supports two rule scopes: Local Rules (/newrule) and Global Rules (/globalrule).

---

Rule Scopes

1. Local Rules (/newrule)

• Location: .postqode/rules/ directory at the root of your workspace.
• Scope: Only applies to the active project/workspace.
• Use Case: Project-specific architecture patterns, chosen libraries, directory layouts, and project constraints.

2. Global Rules (/globalrule)

• Location: ~/Documents/PostQode/Rules/ directory.
• Scope: Applies to all workspaces and projects loaded by PostQode.
• Use Case: General coding style preferences (e.g. indentation, naming conventions), verbose/concise communication preferences, general prompting strategies, or preferred testing strategies that you use across all your coding projects.

---

Using the Rules Commands

When you want to establish rules during a session, you can run the slash commands:

• Trigger: Type /newrule or /globalrule in the chat.
• Process: PostQode will analyze your current conversation history and ask you clarifying questions about your preferences. It will then generate a structured markdown rule file.
• Review: You will get a chance to review the generated rules.
• Save: Once you approve, the markdown rule file is created in the respective directory.

warning

PostQode will NOT overwrite or alter existing rule files when creating new rules. If you need to edit an existing rule, you can modify the markdown file directly.

---

Rule File Structure

Rule files are plain markdown files (with a .md extension) saved with succinct, hyphenated names (e.g., project-preferences.md, global-coding-standards.md). They must follow a structured format:

## Brief overview
[Brief description of the rules, outlining whether they are project-specific or global]

## Communication style
- [Preferred response format, verbosity level, etc.]

## Development workflow
- [Commands to run, PR conventions, deployment checklists]

## Coding best practices
- [Coding conventions, directory structure, language version features]

## Project context (or Global preferences)
- [Specific libraries, databases, API designs, or cross-project conventions]

## Other guidelines
- [Testing libraries, comment verbosity, etc.]

---

Best Practices for Rules

• Be Specific: Do not invent preferences or make broad assumptions. Keep rules specific to patterns discussed or actually preferred in your development flow.
• Keep it Concise: Rules should not be a verbose recollection of past conversations, but rather a clean checklist of instructions that PostQode can easily reference.
• Use hyphens for filenames: Use hyphens (-) instead of underscores (_) for file names (e.g., react-typescript-standards.md).
• Do not use restricted names: The rule filename cannot be default-postqodeignore.md, which is a reserved file for ignored paths.