# 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.