52 lines
1.6 KiB
Markdown
52 lines
1.6 KiB
Markdown
# Rule `agent-docs/` Template
|
|
|
|
Use this structure for Markdown files inside `agent-docs/` when the document's main job is to govern behavior: rules, policy, constraints, decision criteria, or workflow guidance.
|
|
|
|
## Recommended Shape
|
|
|
|
```md
|
|
# <Document Title>
|
|
|
|
<Opening statement: what this doc governs, when it applies, and that it must be followed in scope.>
|
|
|
|
## Applies To
|
|
|
|
- <specific task or document types>
|
|
|
|
## Does Not Apply To
|
|
|
|
- <out-of-scope task or document types>
|
|
|
|
## Authority
|
|
|
|
- <source of truth: owning doc, repository path, command, or code area>
|
|
|
|
## <Rule Section>
|
|
|
|
- <instructions>
|
|
|
|
## Edge Cases
|
|
|
|
- <exceptions, ambiguous cases, or branch conditions>
|
|
|
|
## Failure Modes
|
|
|
|
- <what usually goes wrong and how to recover>
|
|
|
|
## Checklist
|
|
|
|
- <validation questions>
|
|
```
|
|
|
|
## Notes
|
|
|
|
- Make the scope explicit.
|
|
- Keep the document responsible for one topic.
|
|
- Use semantic filenames and headings.
|
|
- Write for maintainers. State actions, constraints, and decision criteria directly.
|
|
- If the document references repository files, write repository-relative paths in backticks, not Markdown links or machine-local absolute filesystem paths.
|
|
- State the user or maintainer decision directly: what to do, what to avoid, and how to choose.
|
|
- Add `Authority` when the rule depends on a repository fact, owning document, or other source of truth that later reviews must verify.
|
|
- Add `Edge Cases` and `Failure Modes` when the workflow is easy to misapply or the scope boundary is easy to misunderstand.
|
|
- Prefer linking to inventories, examples, or narrower child docs instead of embedding long registries inline.
|