AGENTS.md

AGENTS.md

@@ -0,0 +1,46 @@
+# Repository Guidelines
+
+## Project Structure & Module Organization
+
+This repository is a documentation and skill-pack workspace for GJB438C/GJB2786 military software engineering guidance.
+
+- `GJB438C-2021_prd_skills/` contains the main skill catalog. Each skill lives in its own directory with a `SKILL.md` file.
+- `GJB438C-2021_prd_skills/index.md` is the navigation entry point and should be updated when skills are added, renamed, or removed.
+- `configs/` stores local API/provider configuration. Treat these files as environment-specific.
+- `test/` contains sample documents used for manual checks, such as `.docx` evaluation reports.
+
+## Build, Test, and Development Commands
+
+There is no compiled build step or package manager manifest in the current repository. Use lightweight checks before submitting changes:
+
+- `rg --files` lists tracked workspace content and helps confirm file placement.
+- `find GJB438C-2021_prd_skills -name SKILL.md | sort` verifies the skill inventory.
+- `git diff --check` detects trailing whitespace and patch formatting issues.
+- `git status --short` reviews changed and untracked files before commit.
+
+## Coding Style & Naming Conventions
+
+Write Markdown in concise, structured sections using `#`, `##`, and bullet lists. Keep skill files named exactly `SKILL.md`; use descriptive directory names in lowercase kebab-case for English skill IDs, or clear Chinese names when the skill concept is Chinese-first. Preserve YAML front matter in skill files:
+
+```markdown
+---
+name: ...
+description: ...
+---
+```
+
+Use UTF-8 for Chinese content. Keep terminology consistent with GJB 438C-2021 and GJB 2786 references.
+
+## Testing Guidelines
+
+Testing is primarily document validation. For every skill change, open the edited `SKILL.md` and confirm the trigger conditions, execution steps, and output expectations are clear. When adding a skill, update `index.md` and verify the relative link works, for example `new-skill/SKILL.md`.
+
+## Commit & Pull Request Guidelines
+
+The current history uses short, imperative commit messages such as `init rep`. Continue with concise summaries, preferably in the form `add skill: <topic>` or `update docs: <topic>`.
+
+Pull requests should include a brief purpose statement, a list of changed skill/config/test files, and any manual validation performed. Link related issues or requirements when available. Include screenshots only when changes affect rendered documentation or generated report output.
+
+## Security & Configuration Tips
+
+Do not commit real API keys, internal endpoints, or customer documents unless explicitly approved. Prefer sanitized examples in `configs/`, and keep backups or local overrides out of version control.