47 lines
2.6 KiB
Markdown
47 lines
2.6 KiB
Markdown
|
# 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.
|