@ghostbyte/agent-docs-kit 0.0.0-stage → 4.0.2
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/LICENSE +21 -0
- package/README.md +82 -2
- package/bin/agent-docs.mjs +8 -0
- package/content/catalog.json +196 -0
- package/content/engineering/01-query-performance.md +48 -0
- package/content/engineering/02-networking-fundamentals.md +48 -0
- package/content/engineering/03-rate-limiting-algorithms.md +48 -0
- package/content/engineering/04-production-debugging.md +48 -0
- package/content/engineering/05-code-review-practices.md +48 -0
- package/content/engineering/06-data-modeling.md +48 -0
- package/content/engineering/07-cloud-cost-saving.md +48 -0
- package/content/engineering/08-testing-types.md +48 -0
- package/content/engineering/09-message-queues.md +48 -0
- package/content/engineering/full-reference.md +144 -0
- package/content/security/01-design-architecture.md +39 -0
- package/content/security/02-local-development.md +41 -0
- package/content/security/03-database-backend.md +46 -0
- package/content/security/04-api-layer.md +51 -0
- package/content/security/05-frontend-ui.md +44 -0
- package/content/security/06-application-security-testing.md +48 -0
- package/content/security/07-cicd-release-engineering.md +41 -0
- package/content/security/08-cloud-infrastructure.md +45 -0
- package/content/security/09-edge-cdn-dns.md +44 -0
- package/content/security/10-release-rollout.md +41 -0
- package/content/security/11-post-release-monitoring-ir.md +43 -0
- package/content/security/12-ongoing-operations.md +52 -0
- package/content/security/full-reference.md +3173 -0
- package/docs/ARCHITECTURE.md +107 -0
- package/docs/CONTENT_MAINTENANCE.md +9 -0
- package/docs/GITHUB_AND_NPM_SETUP.md +112 -0
- package/docs/PURPOSE.md +23 -0
- package/docs/RELEASE_PROCESS.md +22 -0
- package/docs/SECURITY_MODEL.md +9 -0
- package/package.json +57 -4
- package/skills/manage-project-quality/SKILL.md +78 -0
- package/skills/manage-project-quality/agents/openai.yaml +4 -0
- package/skills/manage-project-quality/assets/documentation-report.md +12 -0
- package/skills/manage-project-quality/assets/engineering-report.md +13 -0
- package/skills/manage-project-quality/assets/security-report.md +18 -0
- package/skills/manage-project-quality/references/documentation-governance.md +39 -0
- package/skills/manage-project-quality/references/engineering-01-query-performance.md +48 -0
- package/skills/manage-project-quality/references/engineering-02-networking-fundamentals.md +48 -0
- package/skills/manage-project-quality/references/engineering-03-rate-limiting-algorithms.md +48 -0
- package/skills/manage-project-quality/references/engineering-04-production-debugging.md +48 -0
- package/skills/manage-project-quality/references/engineering-05-code-review-practices.md +48 -0
- package/skills/manage-project-quality/references/engineering-06-data-modeling.md +48 -0
- package/skills/manage-project-quality/references/engineering-07-cloud-cost-saving.md +48 -0
- package/skills/manage-project-quality/references/engineering-08-testing-types.md +48 -0
- package/skills/manage-project-quality/references/engineering-09-message-queues.md +48 -0
- package/skills/manage-project-quality/references/engineering-full-reference.md +144 -0
- package/skills/manage-project-quality/references/engineering-protocol.md +23 -0
- package/skills/manage-project-quality/references/evidence-and-reporting.md +19 -0
- package/skills/manage-project-quality/references/security-01-design-architecture.md +39 -0
- package/skills/manage-project-quality/references/security-02-local-development.md +41 -0
- package/skills/manage-project-quality/references/security-03-database-backend.md +46 -0
- package/skills/manage-project-quality/references/security-04-api-layer.md +51 -0
- package/skills/manage-project-quality/references/security-05-frontend-ui.md +44 -0
- package/skills/manage-project-quality/references/security-06-application-security-testing.md +48 -0
- package/skills/manage-project-quality/references/security-07-cicd-release-engineering.md +41 -0
- package/skills/manage-project-quality/references/security-08-cloud-infrastructure.md +45 -0
- package/skills/manage-project-quality/references/security-09-edge-cdn-dns.md +44 -0
- package/skills/manage-project-quality/references/security-10-release-rollout.md +41 -0
- package/skills/manage-project-quality/references/security-11-post-release-monitoring-ir.md +43 -0
- package/skills/manage-project-quality/references/security-12-ongoing-operations.md +52 -0
- package/skills/manage-project-quality/references/security-full-reference.md +3173 -0
- package/skills/manage-project-quality/references/security-protocol.md +22 -0
- package/skills/manage-project-quality/scripts/check-report.mjs +23 -0
- package/src/api/index.mjs +4 -0
- package/src/cli/arguments.mjs +30 -0
- package/src/cli/help.mjs +24 -0
- package/src/cli/main.mjs +65 -0
- package/src/commands/audit.mjs +49 -0
- package/src/commands/doctor.mjs +12 -0
- package/src/commands/list.mjs +11 -0
- package/src/commands/setup.mjs +42 -0
- package/src/commands/skill.mjs +14 -0
- package/src/commands/validate.mjs +20 -0
- package/src/core/catalog.mjs +19 -0
- package/src/core/files.mjs +42 -0
- package/src/core/paths.mjs +5 -0
|
@@ -0,0 +1,107 @@
|
|
|
1
|
+
# Architecture and file structure
|
|
2
|
+
|
|
3
|
+
The repository separates executable behavior, canonical reference content, the installable skill, project templates, maintainer automation, tests, and the static website.
|
|
4
|
+
|
|
5
|
+
```text
|
|
6
|
+
Agent_Docs_Kit/
|
|
7
|
+
├─ .github/
|
|
8
|
+
│ └─ workflows/
|
|
9
|
+
│ ├─ ci.yml # tests, validation, package smoke check
|
|
10
|
+
│ ├─ pages.yml # GitHub Pages build and deployment
|
|
11
|
+
│ └─ publish-npm.yml # npm trusted-publishing release
|
|
12
|
+
├─ bin/
|
|
13
|
+
│ └─ agent-docs.mjs # npm executable entry point
|
|
14
|
+
├─ src/
|
|
15
|
+
│ ├─ api/
|
|
16
|
+
│ │ └─ index.mjs # programmatic public exports
|
|
17
|
+
│ ├─ cli/
|
|
18
|
+
│ │ ├─ arguments.mjs # option and positional parsing
|
|
19
|
+
│ │ ├─ help.mjs # command reference
|
|
20
|
+
│ │ └─ main.mjs # direct-command and menu router
|
|
21
|
+
│ ├─ commands/
|
|
22
|
+
│ │ ├─ audit.mjs # docs/security report creation
|
|
23
|
+
│ │ ├─ doctor.mjs # prerequisite checks
|
|
24
|
+
│ │ ├─ list.mjs # phase/topic discovery
|
|
25
|
+
│ │ ├─ setup.mjs # project docs scaffold
|
|
26
|
+
│ │ ├─ skill.mjs # explicit skill installation
|
|
27
|
+
│ │ └─ validate.mjs # package integrity checks
|
|
28
|
+
│ └─ core/
|
|
29
|
+
│ ├─ catalog.mjs # canonical catalog loader
|
|
30
|
+
│ ├─ files.mjs # safe write/copy primitives
|
|
31
|
+
│ └─ paths.mjs # package-relative resolution
|
|
32
|
+
├─ content/
|
|
33
|
+
│ ├─ catalog.json # phase/topic IDs, slugs, sources
|
|
34
|
+
│ ├─ security/
|
|
35
|
+
│ │ ├─ 01-design-architecture.md
|
|
36
|
+
│ │ ├─ ... # phases 02–11
|
|
37
|
+
│ │ ├─ 12-ongoing-operations.md
|
|
38
|
+
│ │ └─ full-reference.md # deep lookup; not loaded by default
|
|
39
|
+
│ └─ engineering/
|
|
40
|
+
│ ├─ 01-query-performance.md
|
|
41
|
+
│ ├─ ... # topics 02–08
|
|
42
|
+
│ ├─ 09-message-queues.md
|
|
43
|
+
│ └─ full-reference.md
|
|
44
|
+
├─ skills/
|
|
45
|
+
│ └─ manage-project-quality/
|
|
46
|
+
│ ├─ agents/
|
|
47
|
+
│ │ └─ openai.yaml # skill UI metadata
|
|
48
|
+
│ ├─ assets/
|
|
49
|
+
│ │ ├─ documentation-report.md
|
|
50
|
+
│ │ ├─ engineering-report.md
|
|
51
|
+
│ │ └─ security-report.md
|
|
52
|
+
│ ├─ references/
|
|
53
|
+
│ │ ├─ documentation-governance.md
|
|
54
|
+
│ │ ├─ engineering-protocol.md
|
|
55
|
+
│ │ ├─ evidence-and-reporting.md
|
|
56
|
+
│ │ ├─ security-protocol.md
|
|
57
|
+
│ │ ├─ security-01-....md # 12 progressive phase files
|
|
58
|
+
│ │ └─ engineering-01-....md # 9 progressive topic files
|
|
59
|
+
│ ├─ scripts/
|
|
60
|
+
│ │ └─ check-report.mjs
|
|
61
|
+
│ └─ SKILL.md # concise routing instructions
|
|
62
|
+
├─ scripts/
|
|
63
|
+
│ ├─ build-site.mjs
|
|
64
|
+
│ ├─ build-skill.mjs
|
|
65
|
+
│ └─ validate-content.mjs
|
|
66
|
+
├─ site/
|
|
67
|
+
│ ├─ index.html
|
|
68
|
+
│ └─ styles.css
|
|
69
|
+
├─ tests/
|
|
70
|
+
│ ├─ cli.test.mjs
|
|
71
|
+
│ └─ content.test.mjs
|
|
72
|
+
├─ build/ # generated, ignored
|
|
73
|
+
│ └─ site/
|
|
74
|
+
├─ docs/
|
|
75
|
+
│ ├─ ARCHITECTURE.md
|
|
76
|
+
│ ├─ GITHUB_AND_NPM_SETUP.md
|
|
77
|
+
│ ├─ PURPOSE.md
|
|
78
|
+
│ ├─ RELEASE_PROCESS.md
|
|
79
|
+
│ └─ SECURITY_MODEL.md
|
|
80
|
+
├─ docs/archive/
|
|
81
|
+
│ └─ AGENT_DOCS_KIT_v3.2.md # retained legacy compiled edition
|
|
82
|
+
├─ LICENSE
|
|
83
|
+
├─ README.md
|
|
84
|
+
└─ package.json
|
|
85
|
+
```
|
|
86
|
+
|
|
87
|
+
## Installed project structure
|
|
88
|
+
|
|
89
|
+
`agent-docs setup` creates only the starting documents needed to establish ownership and navigation:
|
|
90
|
+
|
|
91
|
+
```text
|
|
92
|
+
.agent-docs/config.json
|
|
93
|
+
docs/
|
|
94
|
+
├─ README.md
|
|
95
|
+
├─ 01-system/overview.md
|
|
96
|
+
├─ 02-project/README.md
|
|
97
|
+
├─ 03-development/
|
|
98
|
+
│ └─ engineering-reviews/
|
|
99
|
+
├─ 04-testing/
|
|
100
|
+
│ ├─ security-audits/
|
|
101
|
+
│ └─ evidence/
|
|
102
|
+
├─ 05-operations/README.md
|
|
103
|
+
├─ 06-future-enhancements/README.md
|
|
104
|
+
└─ archive/README.md
|
|
105
|
+
```
|
|
106
|
+
|
|
107
|
+
The CLI creates audit reports beneath this tree. It does not copy the entire reference library into each consumer project.
|
|
@@ -0,0 +1,9 @@
|
|
|
1
|
+
# Content maintenance
|
|
2
|
+
|
|
3
|
+
The files under `content/` are canonical. Run `npm run build` after changing them so the installable skill receives the same progressive references.
|
|
4
|
+
|
|
5
|
+
Review security guidance at least quarterly and after material changes to major standards, threat models, supported platforms, or tooling. Record the source and review date in the changed content or pull request. Verify external claims against primary sources.
|
|
6
|
+
|
|
7
|
+
Review engineering topics when supported runtimes, architectural assumptions, or operational scale change. Keep recommendations contextual and avoid presenting preferences as universal rules.
|
|
8
|
+
|
|
9
|
+
Before release, run the content validator. It checks catalog/source consistency and common encoding corruption. A human review is still required for technical accuracy and link freshness.
|
|
@@ -0,0 +1,112 @@
|
|
|
1
|
+
# GitHub and npm setup
|
|
2
|
+
|
|
3
|
+
These commands assume the GitHub owner is `ghostbyte1014`, the repository is `Agent_Docs_Kit`, and the npm package is owned by the separate npm account `ghostbyte` at `@ghostbyte/agent-docs-kit`.
|
|
4
|
+
|
|
5
|
+
## 1. Validate locally
|
|
6
|
+
|
|
7
|
+
On Windows PowerShell, use `npm.cmd` if execution policy blocks `npm.ps1`:
|
|
8
|
+
|
|
9
|
+
```powershell
|
|
10
|
+
npm.cmd install
|
|
11
|
+
npm.cmd test
|
|
12
|
+
npm.cmd run validate
|
|
13
|
+
npm.cmd run build
|
|
14
|
+
npm.cmd pack --dry-run
|
|
15
|
+
```
|
|
16
|
+
|
|
17
|
+
## 2. Create and push the GitHub repository
|
|
18
|
+
|
|
19
|
+
With GitHub CLI:
|
|
20
|
+
|
|
21
|
+
```powershell
|
|
22
|
+
git add .
|
|
23
|
+
git commit -m "feat: unify Agent Docs and Quality Kit"
|
|
24
|
+
gh auth login
|
|
25
|
+
gh repo create ghostbyte1014/Agent_Docs_Kit --public --source . --remote origin --push
|
|
26
|
+
```
|
|
27
|
+
|
|
28
|
+
If `origin` already exists, inspect it before changing anything:
|
|
29
|
+
|
|
30
|
+
```powershell
|
|
31
|
+
git remote -v
|
|
32
|
+
git push -u origin main
|
|
33
|
+
```
|
|
34
|
+
|
|
35
|
+
The web alternative is to create an empty repository on GitHub, then run:
|
|
36
|
+
|
|
37
|
+
```powershell
|
|
38
|
+
git remote add origin https://github.com/ghostbyte1014/Agent_Docs_Kit.git
|
|
39
|
+
git branch -M main
|
|
40
|
+
git push -u origin main
|
|
41
|
+
```
|
|
42
|
+
|
|
43
|
+
Do not add a second README, license, or `.gitignore` when creating the remote because this local repository already has them.
|
|
44
|
+
|
|
45
|
+
## 3. Enable GitHub Pages
|
|
46
|
+
|
|
47
|
+
The `pages.yml` workflow builds `build/site` and deploys it. In GitHub, open **Settings → Pages** and select **GitHub Actions** as the source. Then run the workflow or push to `main`.
|
|
48
|
+
|
|
49
|
+
With GitHub CLI/API after the first push:
|
|
50
|
+
|
|
51
|
+
```powershell
|
|
52
|
+
gh api --method POST repos/ghostbyte1014/Agent_Docs_Kit/pages -f build_type=workflow
|
|
53
|
+
gh workflow run pages.yml
|
|
54
|
+
gh run watch
|
|
55
|
+
```
|
|
56
|
+
|
|
57
|
+
If Pages already exists with another source, use:
|
|
58
|
+
|
|
59
|
+
```powershell
|
|
60
|
+
gh api --method PUT repos/ghostbyte1014/Agent_Docs_Kit/pages -f build_type=workflow
|
|
61
|
+
```
|
|
62
|
+
|
|
63
|
+
## 4. Prepare npm
|
|
64
|
+
|
|
65
|
+
Sign in to the npm account named `ghostbyte`, which owns the `@ghostbyte` personal scope. Confirm package access and authentication:
|
|
66
|
+
|
|
67
|
+
```powershell
|
|
68
|
+
npm.cmd view @ghostbyte/agent-docs-kit name version
|
|
69
|
+
npm.cmd login
|
|
70
|
+
npm.cmd whoami
|
|
71
|
+
```
|
|
72
|
+
|
|
73
|
+
An npm `E404` from `view` usually means no public package currently exists under that exact name; it does not prove that the signed-in account owns the scope.
|
|
74
|
+
|
|
75
|
+
## 5. Publish the first version
|
|
76
|
+
|
|
77
|
+
Review the archive before publishing:
|
|
78
|
+
|
|
79
|
+
```powershell
|
|
80
|
+
npm.cmd pack --dry-run
|
|
81
|
+
npm.cmd publish --access public
|
|
82
|
+
```
|
|
83
|
+
|
|
84
|
+
The first publication establishes the package. Test it from a disposable directory:
|
|
85
|
+
|
|
86
|
+
```powershell
|
|
87
|
+
npx --yes @ghostbyte/agent-docs-kit@latest --help
|
|
88
|
+
npx --yes @ghostbyte/agent-docs-kit@latest setup --dry-run
|
|
89
|
+
```
|
|
90
|
+
|
|
91
|
+
## 6. Configure trusted publishing
|
|
92
|
+
|
|
93
|
+
In npm package settings, add a trusted publisher for GitHub Actions with these values:
|
|
94
|
+
|
|
95
|
+
| Field | Value |
|
|
96
|
+
|---|---|
|
|
97
|
+
| Organization or user | `ghostbyte1014` |
|
|
98
|
+
| Repository | `Agent_Docs_Kit` |
|
|
99
|
+
| Workflow filename | `publish-npm.yml` |
|
|
100
|
+
| Environment name | Leave blank |
|
|
101
|
+
| Allowed actions | Allow direct `npm publish` |
|
|
102
|
+
|
|
103
|
+
No npm token or GitHub environment is required. The workflow is restricted to this GitHub repository and workflow through OIDC.
|
|
104
|
+
|
|
105
|
+
After that, commit your changes, increment the npm version, and push to `main`. The push automatically validates and publishes the new version. No long-lived `NPM_TOKEN` is required.
|
|
106
|
+
|
|
107
|
+
```powershell
|
|
108
|
+
npm.cmd version patch
|
|
109
|
+
git push --follow-tags
|
|
110
|
+
```
|
|
111
|
+
|
|
112
|
+
Use `npm.cmd version minor` for a backward-compatible feature and `npm.cmd version major` for a breaking change. Never reuse an existing npm version: registry versions are immutable. Use `npm deprecate` for a bad release and publish a corrected version.
|
package/docs/PURPOSE.md
ADDED
|
@@ -0,0 +1,23 @@
|
|
|
1
|
+
# Purpose and boundaries
|
|
2
|
+
|
|
3
|
+
Agent Docs & Quality Kit is a library and command-line interface for establishing repeatable project-quality practices. It unifies three related activities without pretending they have the same consequences.
|
|
4
|
+
|
|
5
|
+
## Documentation
|
|
6
|
+
|
|
7
|
+
The documentation workflow preserves project memory. It creates a predictable place for system facts, current scope, decisions, development records, test evidence, operations, future proposals, and superseded material. Its audit detects gaps and drift.
|
|
8
|
+
|
|
9
|
+
Documentation is not a security boundary. A statement such as “change freeze is on” is a collaboration policy until a hook, branch rule, or CI check enforces it.
|
|
10
|
+
|
|
11
|
+
## Security
|
|
12
|
+
|
|
13
|
+
The security workflow assesses controls that protect confidentiality, integrity, availability, and privacy. It requires evidence for every verdict and distinguishes a real pass from an unverified condition. Critical and High failures are release blockers by default.
|
|
14
|
+
|
|
15
|
+
Passive repository review is safe to start. Active testing of a running service, cloud account, network, credential, or production environment requires explicit authorization for the exact target.
|
|
16
|
+
|
|
17
|
+
## Engineering
|
|
18
|
+
|
|
19
|
+
The engineering workflow reviews practices that influence maintainability, reliability, performance, testability, operability, and cost. Its recommendations are contextual and normally non-blocking. A finding that is actually a vulnerability, correctness defect, or data-loss risk is reported separately with the appropriate urgency.
|
|
20
|
+
|
|
21
|
+
## Interaction styles
|
|
22
|
+
|
|
23
|
+
`standard` produces concise findings and actions. `learning` adds why a control matters and a practical example. Both modes use the same evidence rules and verdicts.
|
|
@@ -0,0 +1,22 @@
|
|
|
1
|
+
# Release process
|
|
2
|
+
|
|
3
|
+
Published npm versions are immutable. A push can publish a new version, but it cannot replace the contents of an existing version.
|
|
4
|
+
|
|
5
|
+
1. Update canonical content and run `npm run build` to refresh progressive skill references and the site.
|
|
6
|
+
2. Run `npm test`, `npm run validate`, and `npm pack --dry-run`.
|
|
7
|
+
3. Confirm the package archive contains no credentials, local reports, nested repositories, or generated consumer data.
|
|
8
|
+
4. Commit the package changes locally.
|
|
9
|
+
5. Update the version with `npm version patch`, `minor`, or `major` according to compatibility.
|
|
10
|
+
6. Push the commit and tag. A push to `main` runs `.github/workflows/publish-npm.yml` and publishes the new version through npm trusted publishing.
|
|
11
|
+
7. Verify `npx --yes @ghostbyte/agent-docs-kit@<version> --help` from a clean directory.
|
|
12
|
+
|
|
13
|
+
```powershell
|
|
14
|
+
git add -A
|
|
15
|
+
git commit -m "feat: describe the update"
|
|
16
|
+
npm.cmd version patch
|
|
17
|
+
git push --follow-tags
|
|
18
|
+
```
|
|
19
|
+
|
|
20
|
+
Use `minor` for a backward-compatible feature and `major` for a breaking change. A GitHub Release is optional and does not control npm publication.
|
|
21
|
+
|
|
22
|
+
The first release was published manually because the package had to exist before its trusted publisher could be configured. If a pushed version already exists, the workflow validates the project and safely skips publication; increment the version before pushing package changes that should reach npm.
|
|
@@ -0,0 +1,9 @@
|
|
|
1
|
+
# Security model
|
|
2
|
+
|
|
3
|
+
The CLI is inert on installation: `package.json` defines no `preinstall`, `install`, or `postinstall` script. Explicit commands are required to create files.
|
|
4
|
+
|
|
5
|
+
Project setup skips existing files by default. `--force` is required to replace files owned by a command, and `--dry-run` previews writes. The package does not install Git hooks automatically, execute network scans, read credentials, or contact a telemetry service.
|
|
6
|
+
|
|
7
|
+
Audit reports begin as `Unverified`. The tool scaffolds the review; it does not claim that generated text proves a control. Agents and reviewers must attach repository paths, line numbers, reproducible command output, or authorized external evidence.
|
|
8
|
+
|
|
9
|
+
Publishing uses npm provenance through GitHub trusted publishing when configured. Protect the GitHub release environment, require reviews as appropriate, and never store a long-lived npm token when OIDC is available.
|
package/package.json
CHANGED
|
@@ -1,6 +1,59 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@ghostbyte/agent-docs-kit",
|
|
3
|
-
"version": "
|
|
4
|
-
"
|
|
5
|
-
"
|
|
6
|
-
|
|
3
|
+
"version": "4.0.2",
|
|
4
|
+
"description": "Documentation governance, evidence-based security audits, and engineering-quality reviews for software projects.",
|
|
5
|
+
"type": "module",
|
|
6
|
+
"bin": {
|
|
7
|
+
"agent-docs": "bin/agent-docs.mjs"
|
|
8
|
+
},
|
|
9
|
+
"exports": {
|
|
10
|
+
".": "./src/api/index.mjs"
|
|
11
|
+
},
|
|
12
|
+
"files": [
|
|
13
|
+
"bin/",
|
|
14
|
+
"src/",
|
|
15
|
+
"content/",
|
|
16
|
+
"templates/",
|
|
17
|
+
"skills/",
|
|
18
|
+
"docs/",
|
|
19
|
+
"README.md",
|
|
20
|
+
"LICENSE"
|
|
21
|
+
],
|
|
22
|
+
"scripts": {
|
|
23
|
+
"build": "node scripts/build-site.mjs && node scripts/build-skill.mjs",
|
|
24
|
+
"site:preview": "node scripts/preview-site.mjs",
|
|
25
|
+
"doctor": "node bin/agent-docs.mjs doctor",
|
|
26
|
+
"test": "node --test",
|
|
27
|
+
"validate": "node scripts/validate-content.mjs && node bin/agent-docs.mjs validate",
|
|
28
|
+
"prepublishOnly": "npm run build && npm test && npm run validate"
|
|
29
|
+
},
|
|
30
|
+
"engines": {
|
|
31
|
+
"node": ">=20"
|
|
32
|
+
},
|
|
33
|
+
"keywords": [
|
|
34
|
+
"ai-agent",
|
|
35
|
+
"documentation",
|
|
36
|
+
"security-audit",
|
|
37
|
+
"engineering-review",
|
|
38
|
+
"quality"
|
|
39
|
+
],
|
|
40
|
+
"repository": {
|
|
41
|
+
"type": "git",
|
|
42
|
+
"url": "git+https://github.com/ghostbyte1014/Agent_Docs_Kit.git"
|
|
43
|
+
},
|
|
44
|
+
"homepage": "https://ghostbyte1014.github.io/Agent_Docs_Kit/",
|
|
45
|
+
"bugs": {
|
|
46
|
+
"url": "https://github.com/ghostbyte1014/Agent_Docs_Kit/issues"
|
|
47
|
+
},
|
|
48
|
+
"license": "MIT",
|
|
49
|
+
"author": "ghostbyte1014",
|
|
50
|
+
"publishConfig": {
|
|
51
|
+
"access": "public",
|
|
52
|
+
"registry": "https://registry.npmjs.org/"
|
|
53
|
+
},
|
|
54
|
+
"main": "serve.js",
|
|
55
|
+
"directories": {
|
|
56
|
+
"doc": "docs",
|
|
57
|
+
"test": "tests"
|
|
58
|
+
}
|
|
59
|
+
}
|
|
@@ -0,0 +1,78 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: manage-project-quality
|
|
3
|
+
description: Set up and audit project documentation, perform evidence-based security reviews, or assess engineering practices. Use when asked to create or repair a docs structure, check documentation drift, conduct a security gate or phase audit, review engineering quality, generate audit evidence, or explain Agent Docs & Quality Kit results in standard or learning mode.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Manage Project Quality
|
|
7
|
+
|
|
8
|
+
Choose exactly one primary workflow for the request: documentation governance, security assurance, or engineering review. Combine workflows only when the user explicitly requests a broader quality pass.
|
|
9
|
+
|
|
10
|
+
## Establish the operating context
|
|
11
|
+
|
|
12
|
+
1. Inspect the repository, its local instructions, and the files relevant to the request.
|
|
13
|
+
2. State the target, scope, exclusions, and interaction style before changing files.
|
|
14
|
+
3. Use `standard` style by default. Use `learning` style when the user asks to learn; explain why each important control matters without inflating routine output.
|
|
15
|
+
4. Preview file creation or replacement. Preserve unrelated user changes and do not overwrite an existing report unless explicitly authorized.
|
|
16
|
+
5. Cite repository evidence with paths and line numbers. Use command output or external-system evidence when a file cannot establish the result.
|
|
17
|
+
|
|
18
|
+
## Route the request
|
|
19
|
+
|
|
20
|
+
### Documentation governance
|
|
21
|
+
|
|
22
|
+
Read [references/documentation-governance.md](references/documentation-governance.md). Use it to establish a navigable documentation structure, identify stale or missing material, separate current scope from future ideas, and preserve decision/change history.
|
|
23
|
+
|
|
24
|
+
Documentation controls are governance aids, not an infallible technical lock. Report whether evidence supports the stated process; never claim that Markdown alone enforces agent behavior.
|
|
25
|
+
|
|
26
|
+
### Security assurance
|
|
27
|
+
|
|
28
|
+
Read [references/security-protocol.md](references/security-protocol.md), [references/evidence-and-reporting.md](references/evidence-and-reporting.md), and only the selected phase references below.
|
|
29
|
+
|
|
30
|
+
Passive source and configuration review may proceed within the user-provided repository. Before scanning a live target, sending crafted traffic, exercising credentials, changing cloud resources, or running any potentially disruptive test, obtain explicit authorization for the exact target and prefer a non-production environment.
|
|
31
|
+
|
|
32
|
+
Use only `Pass`, `Fail`, `Unverified`, or `N/A`. A missing observable is `Unverified`, not `Pass` or `N/A`. Treat unresolved Critical or High failures as release blockers unless an accountable owner records a time-bounded exception.
|
|
33
|
+
|
|
34
|
+
### Engineering review
|
|
35
|
+
|
|
36
|
+
Read [references/engineering-protocol.md](references/engineering-protocol.md), [references/evidence-and-reporting.md](references/evidence-and-reporting.md), and only the selected topic references below.
|
|
37
|
+
|
|
38
|
+
Use `Applied`, `Partial`, `Recommended`, `Unverified`, or `N/A`. Engineering recommendations are normally advisory. Clearly separate them from security gates, correctness defects, and release blockers.
|
|
39
|
+
|
|
40
|
+
## Security phase references
|
|
41
|
+
|
|
42
|
+
- [01 Design & Architecture](references/security-01-design-architecture.md)
|
|
43
|
+
- [02 Local Development](references/security-02-local-development.md)
|
|
44
|
+
- [03 Database & Backend](references/security-03-database-backend.md)
|
|
45
|
+
- [04 API Layer](references/security-04-api-layer.md)
|
|
46
|
+
- [05 Frontend & UI](references/security-05-frontend-ui.md)
|
|
47
|
+
- [06 Application Security Testing](references/security-06-application-security-testing.md)
|
|
48
|
+
- [07 CI/CD & Release Engineering](references/security-07-cicd-release-engineering.md)
|
|
49
|
+
- [08 Cloud Infrastructure](references/security-08-cloud-infrastructure.md)
|
|
50
|
+
- [09 Edge, CDN & DNS](references/security-09-edge-cdn-dns.md)
|
|
51
|
+
- [10 Release & Rollout](references/security-10-release-rollout.md)
|
|
52
|
+
- [11 Post-release Monitoring & Incident Response](references/security-11-post-release-monitoring-ir.md)
|
|
53
|
+
- [12 Ongoing Operations](references/security-12-ongoing-operations.md)
|
|
54
|
+
- [Full security reference](references/security-full-reference.md): search by heading or control name; do not load the entire file unless the user requests a full audit.
|
|
55
|
+
|
|
56
|
+
## Engineering topic references
|
|
57
|
+
|
|
58
|
+
- [01 Query Performance](references/engineering-01-query-performance.md)
|
|
59
|
+
- [02 Networking Fundamentals](references/engineering-02-networking-fundamentals.md)
|
|
60
|
+
- [03 Rate Limiting Algorithms](references/engineering-03-rate-limiting-algorithms.md)
|
|
61
|
+
- [04 Production Debugging](references/engineering-04-production-debugging.md)
|
|
62
|
+
- [05 Code Review Practices](references/engineering-05-code-review-practices.md)
|
|
63
|
+
- [06 Data Modeling](references/engineering-06-data-modeling.md)
|
|
64
|
+
- [07 Cloud Cost Saving](references/engineering-07-cloud-cost-saving.md)
|
|
65
|
+
- [08 Testing Types](references/engineering-08-testing-types.md)
|
|
66
|
+
- [09 Message Queues](references/engineering-09-message-queues.md)
|
|
67
|
+
- [Full engineering reference](references/engineering-full-reference.md): use only for cross-topic review.
|
|
68
|
+
|
|
69
|
+
## Produce the result
|
|
70
|
+
|
|
71
|
+
1. Record scope, date, reviewer, interaction style, and evidence limitations.
|
|
72
|
+
2. Assign a status only after collecting evidence.
|
|
73
|
+
3. Rank findings by impact and confidence. Separate observed facts from inference.
|
|
74
|
+
4. Give a concrete remediation, owner, and verification step for each actionable finding.
|
|
75
|
+
5. Summarize blockers first, then non-blocking improvements, then unverified items.
|
|
76
|
+
6. Never expose secrets in output. Redact tokens, credentials, personal data, and sensitive endpoints.
|
|
77
|
+
|
|
78
|
+
Use [assets/security-report.md](assets/security-report.md), [assets/engineering-report.md](assets/engineering-report.md), or [assets/documentation-report.md](assets/documentation-report.md) when writing a report. Run `node scripts/check-report.mjs <report>` to catch invalid statuses and findings without evidence.
|
|
@@ -0,0 +1,12 @@
|
|
|
1
|
+
# Documentation audit: {{scope}}
|
|
2
|
+
|
|
3
|
+
- Date: {{date}}
|
|
4
|
+
- Reviewer: {{reviewer}}
|
|
5
|
+
|
|
6
|
+
| Document or rule | Status | Evidence | Required update |
|
|
7
|
+
|---|---|---|---|
|
|
8
|
+
| | Unverified | | |
|
|
9
|
+
|
|
10
|
+
## Missing or conflicting authorities
|
|
11
|
+
|
|
12
|
+
Record gaps, duplicate sources of truth, stale content, and broken navigation.
|
|
@@ -0,0 +1,13 @@
|
|
|
1
|
+
# Engineering review: {{scope}}
|
|
2
|
+
|
|
3
|
+
- Date: {{date}}
|
|
4
|
+
- Reviewer: {{reviewer}}
|
|
5
|
+
- Overall status: Unverified
|
|
6
|
+
|
|
7
|
+
| Practice | Status | Evidence | Impact | Recommendation / verification |
|
|
8
|
+
|---|---|---|---|---|
|
|
9
|
+
| | Unverified | | | |
|
|
10
|
+
|
|
11
|
+
## Priority recommendations
|
|
12
|
+
|
|
13
|
+
Record the highest-value improvements and their expected tradeoffs.
|
|
@@ -0,0 +1,18 @@
|
|
|
1
|
+
# Security audit: {{scope}}
|
|
2
|
+
|
|
3
|
+
- Date: {{date}}
|
|
4
|
+
- Reviewer: {{reviewer}}
|
|
5
|
+
- Authorized target: {{target}}
|
|
6
|
+
- Overall status: Unverified
|
|
7
|
+
|
|
8
|
+
| Control | Severity | Status | Evidence | Remediation / verification |
|
|
9
|
+
|---|---|---|---|---|
|
|
10
|
+
| | | Unverified | | |
|
|
11
|
+
|
|
12
|
+
## Release blockers
|
|
13
|
+
|
|
14
|
+
None established yet.
|
|
15
|
+
|
|
16
|
+
## Limitations and exceptions
|
|
17
|
+
|
|
18
|
+
Record unavailable external evidence and approved, time-bounded risk exceptions.
|
|
@@ -0,0 +1,39 @@
|
|
|
1
|
+
# Documentation governance
|
|
2
|
+
|
|
3
|
+
## Purpose
|
|
4
|
+
|
|
5
|
+
Documentation governance keeps project intent, implementation facts, decisions, and operating knowledge findable and current. It reduces context loss for humans and agents. It does not, by itself, prevent repository mutation.
|
|
6
|
+
|
|
7
|
+
## Recommended project layout
|
|
8
|
+
|
|
9
|
+
```text
|
|
10
|
+
.agent-docs/
|
|
11
|
+
config.json
|
|
12
|
+
docs/
|
|
13
|
+
README.md
|
|
14
|
+
01-system/
|
|
15
|
+
02-project/
|
|
16
|
+
03-development/
|
|
17
|
+
audits/
|
|
18
|
+
engineering-reviews/
|
|
19
|
+
04-testing/
|
|
20
|
+
security-audits/
|
|
21
|
+
evidence/
|
|
22
|
+
05-operations/
|
|
23
|
+
06-future-enhancements/
|
|
24
|
+
archive/
|
|
25
|
+
```
|
|
26
|
+
|
|
27
|
+
Keep the layout proportional to the project. Do not create empty documents merely to satisfy a tree. Every index must describe what belongs beneath it and identify authoritative documents.
|
|
28
|
+
|
|
29
|
+
## Audit sequence
|
|
30
|
+
|
|
31
|
+
1. Locate local instructions and the documentation index.
|
|
32
|
+
2. Compare claimed behavior with code, configuration, tests, and deployment files.
|
|
33
|
+
3. Find broken links, duplicate authorities, stale dates, unresolved placeholders, and undocumented operational dependencies.
|
|
34
|
+
4. Classify each document as `Current`, `Needs update`, `Reference`, or `Archived`.
|
|
35
|
+
5. Propose the smallest repair that restores a single clear source of truth.
|
|
36
|
+
|
|
37
|
+
## Change records
|
|
38
|
+
|
|
39
|
+
Record what changed, why it changed, files affected, validation performed, and approval when required by the project. Prefer commit-linked records. Treat a “change freeze” as a declared collaboration policy unless a technical hook or CI rule actually enforces it.
|
|
@@ -0,0 +1,48 @@
|
|
|
1
|
+
# Query Performance & Slow Query Diagnosis
|
|
2
|
+
|
|
3
|
+
# Engineering Topic 1: Query Performance & Slow Query Diagnosis
|
|
4
|
+
|
|
5
|
+
**When to run this:** When a query, endpoint, or report is running slower than expected, or before shipping a new query against a table that will grow.
|
|
6
|
+
|
|
7
|
+
**Goal of this pass:** Work through the standard diagnostic order for a slow query instead of guessing at fixes — read the plan first, fix the cheapest thing, and don't reach for denormalization until indexing is exhausted.
|
|
8
|
+
|
|
9
|
+
## Files in this folder
|
|
10
|
+
|
|
11
|
+
| File | Purpose |
|
|
12
|
+
|---|---|
|
|
13
|
+
| `CHECKLIST.md` | The reference list of concepts for this topic — what each one is, why it matters, and the self-check question to ask. Doesn't get filled in; copy `RESULTS_TEMPLATE.md` to record a real pass. |
|
|
14
|
+
| `RESULTS_TEMPLATE.md` | Fillable version of the same list, with a Status column and notes. Copy this file per pass (e.g. `RESULTS_2026-08-29.md`) so history isn't overwritten. |
|
|
15
|
+
|
|
16
|
+
Full source list lives in `../ENGINEERING_REFERENCE.md`. Unlike
|
|
17
|
+
`../../security-gate/phases/`, this is knowledge/practice review, not pass/fail security
|
|
18
|
+
testing — there's no severity rating, and "Fail" isn't the right framing.
|
|
19
|
+
Use the Status options in `RESULTS_TEMPLATE.md` instead: Applied, Partial,
|
|
20
|
+
Should adopt, or Not applicable.
|
|
21
|
+
|
|
22
|
+
## Wrap-up
|
|
23
|
+
|
|
24
|
+
- This isn't a gate — nothing here blocks a release the way
|
|
25
|
+
Critical/High security items in `../../security-gate/phases/` do.
|
|
26
|
+
- Total concepts in this topic: 10
|
|
27
|
+
- Useful as an onboarding read-through, a periodic self-audit, or context
|
|
28
|
+
to hand an agent before it reviews related code.
|
|
29
|
+
|
|
30
|
+
---
|
|
31
|
+
|
|
32
|
+
# Concepts — Topic 1: Query Performance & Slow Query Diagnosis
|
|
33
|
+
|
|
34
|
+
Reference list only — no status column. Use `RESULTS_TEMPLATE.md` in
|
|
35
|
+
this same folder to actually record a pass.
|
|
36
|
+
|
|
37
|
+
| # | Concept | Why it matters | Self-check |
|
|
38
|
+
|---|---|---|---|
|
|
39
|
+
| 1 | Start with the explain plan | Reveals whether the DB is scanning, sorting, or joining in a way that doesn't match intent — guessing at fixes without this wastes time. | Have you run EXPLAIN (or EXPLAIN ANALYZE) on the slow query and read where the time actually goes? |
|
|
40
|
+
| 2 | Add the missing index | Full table scans get linearly worse as data grows; the right index turns O(n) into O(log n). | Does the WHERE/JOIN/ORDER BY column set have a supporting index? |
|
|
41
|
+
| 3 | Stop selecting * | Pulling unused columns wastes I/O and network, and can defeat a covering index. | Does the query request only the columns actually used downstream? |
|
|
42
|
+
| 4 | Fix N+1 queries | One query per row in a loop turns a single request into hundreds; batching/joining collapses it back to one or few. | Does any code path issue a query inside a loop over another query's results? |
|
|
43
|
+
| 5 | Use a covering index | An index that includes all selected columns lets the DB answer from the index alone, skipping the table lookup. | For hot read queries, does the index include every column the query selects? |
|
|
44
|
+
| 6 | Cache repeated queries | Identical, expensive, low-volatility queries don't need to hit the DB every time. | Are the same expensive read queries re-run frequently with unchanged results, and if so, are they cached? |
|
|
45
|
+
| 7 | Prune partitions | Partition pruning lets the DB skip irrelevant partitions entirely instead of scanning the whole table. | For large time-series/partitioned tables, does the query filter on the partition key so pruning can kick in? |
|
|
46
|
+
| 8 | Denormalize for reads | Trading write complexity/redundancy for fewer joins can be the right call once indexing alone isn't enough. | Has indexing been exhausted before reaching for denormalization, and is the redundancy kept in sync deliberately? |
|
|
47
|
+
| 9 | Batch your writes | Many small write round-trips cost more in overhead than one larger batched write. | Are writes that happen together (e.g. in a loop or transaction) batched instead of issued one at a time? |
|
|
48
|
+
| 10 | Update table statistics | A stale planner (out-of-date row-count/distribution stats) can pick a bad plan even with the right indexes present. | Are table statistics refreshed on a schedule (ANALYZE / equivalent), especially after large data changes? |
|
|
@@ -0,0 +1,48 @@
|
|
|
1
|
+
# Networking Fundamentals
|
|
2
|
+
|
|
3
|
+
# Engineering Topic 2: Networking Fundamentals
|
|
4
|
+
|
|
5
|
+
**When to run this:** When debugging connectivity, latency, or TLS issues, or before making infra decisions (load balancer, CDN, multi-region) that depend on understanding the network path.
|
|
6
|
+
|
|
7
|
+
**Goal of this pass:** Confirm the team can reason about what happens between a client request and a server response — not memorize trivia, but recognize which layer a given production issue actually lives in.
|
|
8
|
+
|
|
9
|
+
## Files in this folder
|
|
10
|
+
|
|
11
|
+
| File | Purpose |
|
|
12
|
+
|---|---|
|
|
13
|
+
| `CHECKLIST.md` | The reference list of concepts for this topic — what each one is, why it matters, and the self-check question to ask. Doesn't get filled in; copy `RESULTS_TEMPLATE.md` to record a real pass. |
|
|
14
|
+
| `RESULTS_TEMPLATE.md` | Fillable version of the same list, with a Status column and notes. Copy this file per pass (e.g. `RESULTS_2026-08-29.md`) so history isn't overwritten. |
|
|
15
|
+
|
|
16
|
+
Full source list lives in `../ENGINEERING_REFERENCE.md`. Unlike
|
|
17
|
+
`../../security-gate/phases/`, this is knowledge/practice review, not pass/fail security
|
|
18
|
+
testing — there's no severity rating, and "Fail" isn't the right framing.
|
|
19
|
+
Use the Status options in `RESULTS_TEMPLATE.md` instead: Applied, Partial,
|
|
20
|
+
Should adopt, or Not applicable.
|
|
21
|
+
|
|
22
|
+
## Wrap-up
|
|
23
|
+
|
|
24
|
+
- This isn't a gate — nothing here blocks a release the way
|
|
25
|
+
Critical/High security items in `../../security-gate/phases/` do.
|
|
26
|
+
- Total concepts in this topic: 10
|
|
27
|
+
- Useful as an onboarding read-through, a periodic self-audit, or context
|
|
28
|
+
to hand an agent before it reviews related code.
|
|
29
|
+
|
|
30
|
+
---
|
|
31
|
+
|
|
32
|
+
# Concepts — Topic 2: Networking Fundamentals
|
|
33
|
+
|
|
34
|
+
Reference list only — no status column. Use `RESULTS_TEMPLATE.md` in
|
|
35
|
+
this same folder to actually record a pass.
|
|
36
|
+
|
|
37
|
+
| # | Concept | Why it matters | Self-check |
|
|
38
|
+
|---|---|---|---|
|
|
39
|
+
| 1 | DNS resolution | Wrong TTLs or stale records cause outages/slow failover that look like application bugs. | Do you know your DNS TTLs and what happens on a DNS provider outage or a failed cutover? |
|
|
40
|
+
| 2 | TCP handshake | SYN/SYN-ACK/ACK latency adds to every new connection; connection reuse avoids paying it repeatedly. | Are connections being reused (keep-alive/pooling) where the handshake cost matters? |
|
|
41
|
+
| 3 | TLS handshake | Adds round trips and CPU cost on top of TCP; session resumption and TLS version choice affect both. | Is TLS session resumption enabled, and is the minimum TLS version intentionally set? |
|
|
42
|
+
| 4 | NAT | Explains why a server sees one client IP for many real users, and why some P2P/inbound-connection patterns don't work as expected. | Does any rate-limiting or per-client logic depend on client IP, and does it account for NAT'd clients sharing an IP? |
|
|
43
|
+
| 5 | Load balancer types | L4 vs L7 balancers differ in what they can inspect and route on (raw TCP vs HTTP headers/paths). | Does the current load balancer type actually support the routing/health-check behavior the app needs? |
|
|
44
|
+
| 6 | CDN edge caching | Wrong cache-control headers cause either stale content served for too long or origin overload from no caching at all. | Are cache-control/CDN cache-key rules deliberately set per route, not left at CDN defaults? |
|
|
45
|
+
| 7 | Packet loss & retransmit | Retransmits show up as latency and timeouts that look application-side but are actually network-layer. | When debugging intermittent slowness, has packet loss been ruled out before blaming application code? |
|
|
46
|
+
| 8 | MTU / fragmentation | Oversized packets get fragmented or dropped, which shows up as weird partial-failure behavior, especially over VPNs/tunnels. | Has MTU mismatch been considered for any VPN, tunnel, or container network path in play? |
|
|
47
|
+
| 9 | Keep-alive | Persistent connections avoid the handshake cost per request but tie up server resources if left open too long. | Are keep-alive timeouts tuned deliberately on both client and server, not left at framework defaults? |
|
|
48
|
+
| 10 | BGP routing | Explains internet-scale outages and route leaks — usually outside your control, but recognizable when it's the actual cause. | When a broad, upstream-looking outage occurs, is BGP/routing considered as a possible cause rather than assumed to be your infra? |
|