@ryuenn3123/agentic-senior-core 2.0.3 → 2.0.5
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/.agent-context/blueprints/mobile-app.md +21 -21
- package/.agent-context/profiles/platform.md +13 -13
- package/.agent-context/profiles/regulated.md +13 -13
- package/.agent-context/profiles/startup.md +13 -13
- package/.agent-context/review-checklists/frontend-skill-parity.md +28 -28
- package/.agent-context/review-checklists/frontend-usability.md +33 -33
- package/.agent-context/review-checklists/release-operations.md +29 -29
- package/.agent-context/skills/README.md +62 -62
- package/.agent-context/skills/backend/README.md +67 -67
- package/.agent-context/skills/backend/architecture.md +360 -360
- package/.agent-context/skills/backend/compatibility-manifest.json +8 -8
- package/.agent-context/skills/backend/data-access.md +230 -230
- package/.agent-context/skills/backend/errors.md +137 -137
- package/.agent-context/skills/backend/validation.md +116 -116
- package/.agent-context/skills/backend.md +28 -28
- package/.agent-context/skills/cli/README.md +49 -49
- package/.agent-context/skills/cli/compatibility-manifest.json +8 -8
- package/.agent-context/skills/cli/init.md +37 -37
- package/.agent-context/skills/cli/output.md +35 -35
- package/.agent-context/skills/cli/upgrade.md +37 -37
- package/.agent-context/skills/cli.md +28 -28
- package/.agent-context/skills/distribution/README.md +18 -18
- package/.agent-context/skills/distribution/compatibility-manifest.json +8 -8
- package/.agent-context/skills/distribution/compatibility.md +31 -31
- package/.agent-context/skills/distribution/publish.md +36 -36
- package/.agent-context/skills/distribution/rollback.md +31 -31
- package/.agent-context/skills/distribution.md +28 -28
- package/.agent-context/skills/frontend/README.md +35 -35
- package/.agent-context/skills/frontend/accessibility.md +107 -107
- package/.agent-context/skills/frontend/compatibility-manifest.json +8 -8
- package/.agent-context/skills/frontend/motion.md +66 -66
- package/.agent-context/skills/frontend/performance.md +62 -62
- package/.agent-context/skills/frontend/ui-architecture.md +128 -128
- package/.agent-context/skills/frontend.md +29 -29
- package/.agent-context/skills/fullstack/README.md +18 -18
- package/.agent-context/skills/fullstack/compatibility-manifest.json +8 -8
- package/.agent-context/skills/fullstack/contracts.md +52 -52
- package/.agent-context/skills/fullstack/end-to-end.md +41 -41
- package/.agent-context/skills/fullstack/feature-slicing.md +64 -64
- package/.agent-context/skills/fullstack.md +26 -26
- package/.agent-context/skills/index.json +107 -107
- package/.agent-context/skills/review-quality/README.md +18 -18
- package/.agent-context/skills/review-quality/benchmark.md +29 -29
- package/.agent-context/skills/review-quality/compatibility-manifest.json +8 -8
- package/.agent-context/skills/review-quality/planning.md +37 -37
- package/.agent-context/skills/review-quality/security.md +33 -33
- package/.agent-context/skills/review-quality.md +27 -27
- package/.agent-context/stacks/flutter.md +16 -16
- package/.agent-context/stacks/react-native.md +16 -16
- package/.agent-context/state/architecture-map.md +25 -25
- package/.agent-context/state/benchmark-analysis.json +431 -431
- package/.agent-context/state/benchmark-thresholds.json +10 -10
- package/.agent-context/state/benchmark-watchlist.json +19 -19
- package/.agent-context/state/dependency-map.md +32 -32
- package/.agent-context/state/quality-trend-report.json +79 -0
- package/.agent-context/state/skill-platform.json +38 -38
- package/.agent-context/state/token-optimization-benchmark.json +130 -0
- package/.agent-override.md +36 -36
- package/.cursorrules +1 -1
- package/.gemini/instructions.md +21 -97
- package/.github/ISSUE_TEMPLATE/v1.7-frontend-work-item.yml +54 -54
- package/.github/copilot-instructions.md +21 -166
- package/.github/workflows/benchmark-detection.yml +38 -38
- package/.github/workflows/benchmark-intelligence.yml +50 -50
- package/.github/workflows/frontend-usability-gate.yml +36 -36
- package/.github/workflows/release-gate.yml +32 -32
- package/.github/workflows/sbom-compliance.yml +32 -32
- package/.windsurfrules +1 -1
- package/AGENTS.md +28 -181
- package/README.md +368 -346
- package/lib/cli/commands/optimize.mjs +171 -171
- package/lib/cli/compatibility.mjs +124 -124
- package/lib/cli/token-optimization.mjs +275 -275
- package/mcp.json +92 -92
- package/package.json +3 -1
- package/scripts/benchmark-gate.mjs +121 -121
- package/scripts/benchmark-intelligence.mjs +140 -140
- package/scripts/detection-benchmark.mjs +138 -138
- package/scripts/frontend-usability-audit.mjs +87 -87
- package/scripts/generate-sbom.mjs +61 -61
- package/scripts/init-project.ps1 +104 -104
- package/scripts/llm-judge.mjs +664 -664
- package/scripts/quality-trend-report.mjs +289 -0
- package/scripts/release-gate.mjs +259 -204
- package/scripts/skill-tier-policy.mjs +75 -75
- package/scripts/token-optimization-benchmark.mjs +252 -0
- package/scripts/validate.mjs +865 -811
|
@@ -1,65 +1,65 @@
|
|
|
1
|
-
# Feature Slicing
|
|
2
|
-
|
|
3
|
-
Tier: ADVANCE
|
|
4
|
-
|
|
5
|
-
Feature slicing organizes implementation around business capabilities instead of technical file types. A single feature owns its UI, service orchestration, persistence adapters, and tests.
|
|
6
|
-
|
|
7
|
-
## Why It Matters
|
|
8
|
-
|
|
9
|
-
- Improves ownership: one team can ship and maintain a feature end to end.
|
|
10
|
-
- Reduces coupling: changes stay local to one capability.
|
|
11
|
-
- Speeds delivery: less coordination across unrelated folders.
|
|
12
|
-
|
|
13
|
-
## Recommended Layout
|
|
14
|
-
|
|
15
|
-
```text
|
|
16
|
-
src/
|
|
17
|
-
features/
|
|
18
|
-
checkout/
|
|
19
|
-
ui/
|
|
20
|
-
service/
|
|
21
|
-
repository/
|
|
22
|
-
contracts/
|
|
23
|
-
tests/
|
|
24
|
-
index.ts
|
|
25
|
-
orders/
|
|
26
|
-
ui/
|
|
27
|
-
service/
|
|
28
|
-
repository/
|
|
29
|
-
contracts/
|
|
30
|
-
tests/
|
|
31
|
-
index.ts
|
|
32
|
-
```
|
|
33
|
-
|
|
34
|
-
## Module Boundary Rules
|
|
35
|
-
|
|
36
|
-
- Expose only through `index.ts` as the feature public API.
|
|
37
|
-
- Do not import private files across feature folders.
|
|
38
|
-
- Keep shared utilities in a neutral shared module; avoid feature-to-feature deep imports.
|
|
39
|
-
|
|
40
|
-
## Anti-Patterns
|
|
41
|
-
|
|
42
|
-
Bad:
|
|
43
|
-
- `src/components`, `src/services`, `src/repositories` global buckets for all features.
|
|
44
|
-
- Shared folder becoming a dumping ground for feature-specific code.
|
|
45
|
-
- One feature mutating another feature's database entities directly.
|
|
46
|
-
|
|
47
|
-
Good:
|
|
48
|
-
- Feature package exposes explicit use-cases and UI entrypoints.
|
|
49
|
-
- Cross-feature communication uses contracts and events.
|
|
50
|
-
- Shared module limited to stateless primitives and infrastructure adapters.
|
|
51
|
-
|
|
52
|
-
## Integration Workflow
|
|
53
|
-
|
|
54
|
-
1. Define capability and boundary (example: checkout).
|
|
55
|
-
2. Define public API for the feature module.
|
|
56
|
-
3. Implement UI and service logic inside the feature.
|
|
57
|
-
4. Add repository and contract definitions.
|
|
58
|
-
5. Add unit/integration/end-to-end tests within the feature.
|
|
59
|
-
|
|
60
|
-
## Review Checklist
|
|
61
|
-
|
|
62
|
-
- [ ] Feature can be understood without reading unrelated modules.
|
|
63
|
-
- [ ] No deep import across feature boundaries.
|
|
64
|
-
- [ ] Public API is explicit and stable.
|
|
1
|
+
# Feature Slicing
|
|
2
|
+
|
|
3
|
+
Tier: ADVANCE
|
|
4
|
+
|
|
5
|
+
Feature slicing organizes implementation around business capabilities instead of technical file types. A single feature owns its UI, service orchestration, persistence adapters, and tests.
|
|
6
|
+
|
|
7
|
+
## Why It Matters
|
|
8
|
+
|
|
9
|
+
- Improves ownership: one team can ship and maintain a feature end to end.
|
|
10
|
+
- Reduces coupling: changes stay local to one capability.
|
|
11
|
+
- Speeds delivery: less coordination across unrelated folders.
|
|
12
|
+
|
|
13
|
+
## Recommended Layout
|
|
14
|
+
|
|
15
|
+
```text
|
|
16
|
+
src/
|
|
17
|
+
features/
|
|
18
|
+
checkout/
|
|
19
|
+
ui/
|
|
20
|
+
service/
|
|
21
|
+
repository/
|
|
22
|
+
contracts/
|
|
23
|
+
tests/
|
|
24
|
+
index.ts
|
|
25
|
+
orders/
|
|
26
|
+
ui/
|
|
27
|
+
service/
|
|
28
|
+
repository/
|
|
29
|
+
contracts/
|
|
30
|
+
tests/
|
|
31
|
+
index.ts
|
|
32
|
+
```
|
|
33
|
+
|
|
34
|
+
## Module Boundary Rules
|
|
35
|
+
|
|
36
|
+
- Expose only through `index.ts` as the feature public API.
|
|
37
|
+
- Do not import private files across feature folders.
|
|
38
|
+
- Keep shared utilities in a neutral shared module; avoid feature-to-feature deep imports.
|
|
39
|
+
|
|
40
|
+
## Anti-Patterns
|
|
41
|
+
|
|
42
|
+
Bad:
|
|
43
|
+
- `src/components`, `src/services`, `src/repositories` global buckets for all features.
|
|
44
|
+
- Shared folder becoming a dumping ground for feature-specific code.
|
|
45
|
+
- One feature mutating another feature's database entities directly.
|
|
46
|
+
|
|
47
|
+
Good:
|
|
48
|
+
- Feature package exposes explicit use-cases and UI entrypoints.
|
|
49
|
+
- Cross-feature communication uses contracts and events.
|
|
50
|
+
- Shared module limited to stateless primitives and infrastructure adapters.
|
|
51
|
+
|
|
52
|
+
## Integration Workflow
|
|
53
|
+
|
|
54
|
+
1. Define capability and boundary (example: checkout).
|
|
55
|
+
2. Define public API for the feature module.
|
|
56
|
+
3. Implement UI and service logic inside the feature.
|
|
57
|
+
4. Add repository and contract definitions.
|
|
58
|
+
5. Add unit/integration/end-to-end tests within the feature.
|
|
59
|
+
|
|
60
|
+
## Review Checklist
|
|
61
|
+
|
|
62
|
+
- [ ] Feature can be understood without reading unrelated modules.
|
|
63
|
+
- [ ] No deep import across feature boundaries.
|
|
64
|
+
- [ ] Public API is explicit and stable.
|
|
65
65
|
- [ ] Tests live with the feature and cover core behavior.
|
|
@@ -1,27 +1,27 @@
|
|
|
1
|
-
# Fullstack Skill Pack
|
|
2
|
-
|
|
3
|
-
Default tier: `advance`
|
|
4
|
-
|
|
5
|
-
## Purpose
|
|
6
|
-
Coordinate frontend and backend delivery as a single product system.
|
|
7
|
-
|
|
8
|
-
## In Scope
|
|
9
|
-
- Feature slicing across UI and API boundaries
|
|
10
|
-
- Shared validation contracts
|
|
11
|
-
- End-to-end flows and release readiness
|
|
12
|
-
- Performance, accessibility, and observability together
|
|
13
|
-
|
|
14
|
-
## Must-Have Checks
|
|
15
|
-
- Single feature directory with clear public API
|
|
16
|
-
- Frontend and backend contracts aligned
|
|
17
|
-
- End-to-end test coverage for critical paths
|
|
18
|
-
- Release notes explain UX and API impact together
|
|
19
|
-
|
|
20
|
-
## Evidence
|
|
21
|
-
- Feature parity checklist
|
|
22
|
-
- End-to-end test report
|
|
23
|
-
- Contract validation output
|
|
24
|
-
- Release artifact bundle
|
|
25
|
-
|
|
26
|
-
## Fallback
|
|
1
|
+
# Fullstack Skill Pack
|
|
2
|
+
|
|
3
|
+
Default tier: `advance`
|
|
4
|
+
|
|
5
|
+
## Purpose
|
|
6
|
+
Coordinate frontend and backend delivery as a single product system.
|
|
7
|
+
|
|
8
|
+
## In Scope
|
|
9
|
+
- Feature slicing across UI and API boundaries
|
|
10
|
+
- Shared validation contracts
|
|
11
|
+
- End-to-end flows and release readiness
|
|
12
|
+
- Performance, accessibility, and observability together
|
|
13
|
+
|
|
14
|
+
## Must-Have Checks
|
|
15
|
+
- Single feature directory with clear public API
|
|
16
|
+
- Frontend and backend contracts aligned
|
|
17
|
+
- End-to-end test coverage for critical paths
|
|
18
|
+
- Release notes explain UX and API impact together
|
|
19
|
+
|
|
20
|
+
## Evidence
|
|
21
|
+
- Feature parity checklist
|
|
22
|
+
- End-to-end test report
|
|
23
|
+
- Contract validation output
|
|
24
|
+
- Release artifact bundle
|
|
25
|
+
|
|
26
|
+
## Fallback
|
|
27
27
|
- Split delivery only when the feature boundary is explicit and the evidence bundle is still complete.
|
|
@@ -1,107 +1,107 @@
|
|
|
1
|
-
{
|
|
2
|
-
"defaultTier": "advance",
|
|
3
|
-
"tiers": [
|
|
4
|
-
{
|
|
5
|
-
"name": "standard",
|
|
6
|
-
"description": "Compatibility fallback only"
|
|
7
|
-
},
|
|
8
|
-
{
|
|
9
|
-
"name": "advance",
|
|
10
|
-
"description": "Default operating tier"
|
|
11
|
-
},
|
|
12
|
-
{
|
|
13
|
-
"name": "expert",
|
|
14
|
-
"description": "Complex architecture and integration"
|
|
15
|
-
},
|
|
16
|
-
{
|
|
17
|
-
"name": "above",
|
|
18
|
-
"description": "Release-critical enterprise governance"
|
|
19
|
-
}
|
|
20
|
-
],
|
|
21
|
-
"domains": {
|
|
22
|
-
"frontend": {
|
|
23
|
-
"name": "frontend",
|
|
24
|
-
"displayName": "Frontend",
|
|
25
|
-
"description": "Unified frontend delivery covering UI architecture, motion, accessibility, and conversion clarity.",
|
|
26
|
-
"defaultTier": "advance",
|
|
27
|
-
"defaultPackFileName": "frontend.md",
|
|
28
|
-
"evidence": "Frontend usability audit, accessibility checks, and visual regression output.",
|
|
29
|
-
"tierToPackFileNames": {
|
|
30
|
-
"standard": "frontend.md",
|
|
31
|
-
"advance": "frontend.md",
|
|
32
|
-
"expert": "frontend.md",
|
|
33
|
-
"above": "frontend.md"
|
|
34
|
-
}
|
|
35
|
-
},
|
|
36
|
-
"backend": {
|
|
37
|
-
"name": "backend",
|
|
38
|
-
"displayName": "Backend",
|
|
39
|
-
"description": "Backend delivery with strict layer separation, validation, and safe data access.",
|
|
40
|
-
"defaultTier": "advance",
|
|
41
|
-
"defaultPackFileName": "backend.md",
|
|
42
|
-
"evidence": "Unit tests, API contracts, and release gate output.",
|
|
43
|
-
"tierToPackFileNames": {
|
|
44
|
-
"standard": "backend.md",
|
|
45
|
-
"advance": "backend.md",
|
|
46
|
-
"expert": "backend.md",
|
|
47
|
-
"above": "backend.md"
|
|
48
|
-
}
|
|
49
|
-
},
|
|
50
|
-
"fullstack": {
|
|
51
|
-
"name": "fullstack",
|
|
52
|
-
"displayName": "Fullstack",
|
|
53
|
-
"description": "Single-path product delivery across frontend and backend boundaries.",
|
|
54
|
-
"defaultTier": "advance",
|
|
55
|
-
"defaultPackFileName": "fullstack.md",
|
|
56
|
-
"evidence": "End-to-end tests, contract validation, and feature parity review.",
|
|
57
|
-
"tierToPackFileNames": {
|
|
58
|
-
"standard": "fullstack.md",
|
|
59
|
-
"advance": "fullstack.md",
|
|
60
|
-
"expert": "fullstack.md",
|
|
61
|
-
"above": "fullstack.md"
|
|
62
|
-
}
|
|
63
|
-
},
|
|
64
|
-
"cli": {
|
|
65
|
-
"name": "cli",
|
|
66
|
-
"displayName": "CLI",
|
|
67
|
-
"description": "Smart command-line delivery with safe defaults, machine-readable output, and upgrade flows.",
|
|
68
|
-
"defaultTier": "advance",
|
|
69
|
-
"defaultPackFileName": "cli.md",
|
|
70
|
-
"evidence": "CLI smoke tests, dry-run output, and automation-friendly reports.",
|
|
71
|
-
"tierToPackFileNames": {
|
|
72
|
-
"standard": "cli.md",
|
|
73
|
-
"advance": "cli.md",
|
|
74
|
-
"expert": "cli.md",
|
|
75
|
-
"above": "cli.md"
|
|
76
|
-
}
|
|
77
|
-
},
|
|
78
|
-
"distribution": {
|
|
79
|
-
"name": "distribution",
|
|
80
|
-
"displayName": "Distribution",
|
|
81
|
-
"description": "Package safety, rollback, compatibility, and release hygiene.",
|
|
82
|
-
"defaultTier": "expert",
|
|
83
|
-
"defaultPackFileName": "distribution.md",
|
|
84
|
-
"evidence": "Install validation, rollback verification, and publish dry-run logs.",
|
|
85
|
-
"tierToPackFileNames": {
|
|
86
|
-
"standard": "distribution.md",
|
|
87
|
-
"advance": "distribution.md",
|
|
88
|
-
"expert": "distribution.md",
|
|
89
|
-
"above": "distribution.md"
|
|
90
|
-
}
|
|
91
|
-
},
|
|
92
|
-
"review-quality": {
|
|
93
|
-
"name": "review-quality",
|
|
94
|
-
"displayName": "Review Quality",
|
|
95
|
-
"description": "Planning, review, benchmark, and security discipline for every change.",
|
|
96
|
-
"defaultTier": "expert",
|
|
97
|
-
"defaultPackFileName": "review-quality.md",
|
|
98
|
-
"evidence": "PR review output, benchmark report, and security audit results.",
|
|
99
|
-
"tierToPackFileNames": {
|
|
100
|
-
"standard": "review-quality.md",
|
|
101
|
-
"advance": "review-quality.md",
|
|
102
|
-
"expert": "review-quality.md",
|
|
103
|
-
"above": "review-quality.md"
|
|
104
|
-
}
|
|
105
|
-
}
|
|
106
|
-
}
|
|
107
|
-
}
|
|
1
|
+
{
|
|
2
|
+
"defaultTier": "advance",
|
|
3
|
+
"tiers": [
|
|
4
|
+
{
|
|
5
|
+
"name": "standard",
|
|
6
|
+
"description": "Compatibility fallback only"
|
|
7
|
+
},
|
|
8
|
+
{
|
|
9
|
+
"name": "advance",
|
|
10
|
+
"description": "Default operating tier"
|
|
11
|
+
},
|
|
12
|
+
{
|
|
13
|
+
"name": "expert",
|
|
14
|
+
"description": "Complex architecture and integration"
|
|
15
|
+
},
|
|
16
|
+
{
|
|
17
|
+
"name": "above",
|
|
18
|
+
"description": "Release-critical enterprise governance"
|
|
19
|
+
}
|
|
20
|
+
],
|
|
21
|
+
"domains": {
|
|
22
|
+
"frontend": {
|
|
23
|
+
"name": "frontend",
|
|
24
|
+
"displayName": "Frontend",
|
|
25
|
+
"description": "Unified frontend delivery covering UI architecture, motion, accessibility, and conversion clarity.",
|
|
26
|
+
"defaultTier": "advance",
|
|
27
|
+
"defaultPackFileName": "frontend.md",
|
|
28
|
+
"evidence": "Frontend usability audit, accessibility checks, and visual regression output.",
|
|
29
|
+
"tierToPackFileNames": {
|
|
30
|
+
"standard": "frontend.md",
|
|
31
|
+
"advance": "frontend.md",
|
|
32
|
+
"expert": "frontend.md",
|
|
33
|
+
"above": "frontend.md"
|
|
34
|
+
}
|
|
35
|
+
},
|
|
36
|
+
"backend": {
|
|
37
|
+
"name": "backend",
|
|
38
|
+
"displayName": "Backend",
|
|
39
|
+
"description": "Backend delivery with strict layer separation, validation, and safe data access.",
|
|
40
|
+
"defaultTier": "advance",
|
|
41
|
+
"defaultPackFileName": "backend.md",
|
|
42
|
+
"evidence": "Unit tests, API contracts, and release gate output.",
|
|
43
|
+
"tierToPackFileNames": {
|
|
44
|
+
"standard": "backend.md",
|
|
45
|
+
"advance": "backend.md",
|
|
46
|
+
"expert": "backend.md",
|
|
47
|
+
"above": "backend.md"
|
|
48
|
+
}
|
|
49
|
+
},
|
|
50
|
+
"fullstack": {
|
|
51
|
+
"name": "fullstack",
|
|
52
|
+
"displayName": "Fullstack",
|
|
53
|
+
"description": "Single-path product delivery across frontend and backend boundaries.",
|
|
54
|
+
"defaultTier": "advance",
|
|
55
|
+
"defaultPackFileName": "fullstack.md",
|
|
56
|
+
"evidence": "End-to-end tests, contract validation, and feature parity review.",
|
|
57
|
+
"tierToPackFileNames": {
|
|
58
|
+
"standard": "fullstack.md",
|
|
59
|
+
"advance": "fullstack.md",
|
|
60
|
+
"expert": "fullstack.md",
|
|
61
|
+
"above": "fullstack.md"
|
|
62
|
+
}
|
|
63
|
+
},
|
|
64
|
+
"cli": {
|
|
65
|
+
"name": "cli",
|
|
66
|
+
"displayName": "CLI",
|
|
67
|
+
"description": "Smart command-line delivery with safe defaults, machine-readable output, and upgrade flows.",
|
|
68
|
+
"defaultTier": "advance",
|
|
69
|
+
"defaultPackFileName": "cli.md",
|
|
70
|
+
"evidence": "CLI smoke tests, dry-run output, and automation-friendly reports.",
|
|
71
|
+
"tierToPackFileNames": {
|
|
72
|
+
"standard": "cli.md",
|
|
73
|
+
"advance": "cli.md",
|
|
74
|
+
"expert": "cli.md",
|
|
75
|
+
"above": "cli.md"
|
|
76
|
+
}
|
|
77
|
+
},
|
|
78
|
+
"distribution": {
|
|
79
|
+
"name": "distribution",
|
|
80
|
+
"displayName": "Distribution",
|
|
81
|
+
"description": "Package safety, rollback, compatibility, and release hygiene.",
|
|
82
|
+
"defaultTier": "expert",
|
|
83
|
+
"defaultPackFileName": "distribution.md",
|
|
84
|
+
"evidence": "Install validation, rollback verification, and publish dry-run logs.",
|
|
85
|
+
"tierToPackFileNames": {
|
|
86
|
+
"standard": "distribution.md",
|
|
87
|
+
"advance": "distribution.md",
|
|
88
|
+
"expert": "distribution.md",
|
|
89
|
+
"above": "distribution.md"
|
|
90
|
+
}
|
|
91
|
+
},
|
|
92
|
+
"review-quality": {
|
|
93
|
+
"name": "review-quality",
|
|
94
|
+
"displayName": "Review Quality",
|
|
95
|
+
"description": "Planning, review, benchmark, and security discipline for every change.",
|
|
96
|
+
"defaultTier": "expert",
|
|
97
|
+
"defaultPackFileName": "review-quality.md",
|
|
98
|
+
"evidence": "PR review output, benchmark report, and security audit results.",
|
|
99
|
+
"tierToPackFileNames": {
|
|
100
|
+
"standard": "review-quality.md",
|
|
101
|
+
"advance": "review-quality.md",
|
|
102
|
+
"expert": "review-quality.md",
|
|
103
|
+
"above": "review-quality.md"
|
|
104
|
+
}
|
|
105
|
+
}
|
|
106
|
+
}
|
|
107
|
+
}
|
|
@@ -1,19 +1,19 @@
|
|
|
1
|
-
# Review Quality Skills
|
|
2
|
-
|
|
3
|
-
Default tier: `expert`
|
|
4
|
-
|
|
5
|
-
This domain formalizes review quality across planning discipline, security enforcement, and benchmark-driven decision making.
|
|
6
|
-
|
|
7
|
-
## Topics
|
|
8
|
-
- [Planning](planning.md) - Plan quality, scope control, and change strategy
|
|
9
|
-
- [Security](security.md) - Critical vulnerability policy and boundary safeguards
|
|
10
|
-
- [Benchmarking](benchmark.md) - Regression detection and evidence-based comparison
|
|
11
|
-
|
|
12
|
-
## Operating Model
|
|
13
|
-
- Use `expert` for standard review workflows.
|
|
14
|
-
- Escalate to `above` for release-critical or governance-sensitive changes.
|
|
15
|
-
|
|
16
|
-
## Above-Line Additions
|
|
17
|
-
- Security halt protocol for critical findings.
|
|
18
|
-
- Benchmark gate thresholds integrated in CI.
|
|
1
|
+
# Review Quality Skills
|
|
2
|
+
|
|
3
|
+
Default tier: `expert`
|
|
4
|
+
|
|
5
|
+
This domain formalizes review quality across planning discipline, security enforcement, and benchmark-driven decision making.
|
|
6
|
+
|
|
7
|
+
## Topics
|
|
8
|
+
- [Planning](planning.md) - Plan quality, scope control, and change strategy
|
|
9
|
+
- [Security](security.md) - Critical vulnerability policy and boundary safeguards
|
|
10
|
+
- [Benchmarking](benchmark.md) - Regression detection and evidence-based comparison
|
|
11
|
+
|
|
12
|
+
## Operating Model
|
|
13
|
+
- Use `expert` for standard review workflows.
|
|
14
|
+
- Escalate to `above` for release-critical or governance-sensitive changes.
|
|
15
|
+
|
|
16
|
+
## Above-Line Additions
|
|
17
|
+
- Security halt protocol for critical findings.
|
|
18
|
+
- Benchmark gate thresholds integrated in CI.
|
|
19
19
|
- Review evidence bundle for auditability.
|
|
@@ -1,30 +1,30 @@
|
|
|
1
|
-
# Benchmarking
|
|
2
|
-
|
|
3
|
-
Tier: ADVANCE
|
|
4
|
-
|
|
5
|
-
Benchmarking should guide release decisions with measurable evidence rather than anecdotal impressions.
|
|
6
|
-
|
|
7
|
-
## Benchmark Inputs
|
|
8
|
-
|
|
9
|
-
- Baseline benchmark snapshot.
|
|
10
|
-
- Current candidate benchmark output.
|
|
11
|
-
- Threshold policy for acceptable deltas.
|
|
12
|
-
|
|
13
|
-
## Evaluation Rules
|
|
14
|
-
|
|
15
|
-
- Treat regressions above threshold as release blockers.
|
|
16
|
-
- Require owner assignment for all negative deltas.
|
|
17
|
-
- Re-run benchmark after remediation to verify recovery.
|
|
18
|
-
|
|
19
|
-
## Reporting Standard
|
|
20
|
-
|
|
21
|
-
- Include benchmark summary in release bundle.
|
|
22
|
-
- Keep machine-readable JSON output for automation.
|
|
23
|
-
- Track trend over time, not only single-run status.
|
|
24
|
-
|
|
25
|
-
## Review Checklist
|
|
26
|
-
|
|
27
|
-
- [ ] Baseline and current benchmark are comparable.
|
|
28
|
-
- [ ] Threshold policy is applied consistently.
|
|
29
|
-
- [ ] Regressions have owner and due date.
|
|
1
|
+
# Benchmarking
|
|
2
|
+
|
|
3
|
+
Tier: ADVANCE
|
|
4
|
+
|
|
5
|
+
Benchmarking should guide release decisions with measurable evidence rather than anecdotal impressions.
|
|
6
|
+
|
|
7
|
+
## Benchmark Inputs
|
|
8
|
+
|
|
9
|
+
- Baseline benchmark snapshot.
|
|
10
|
+
- Current candidate benchmark output.
|
|
11
|
+
- Threshold policy for acceptable deltas.
|
|
12
|
+
|
|
13
|
+
## Evaluation Rules
|
|
14
|
+
|
|
15
|
+
- Treat regressions above threshold as release blockers.
|
|
16
|
+
- Require owner assignment for all negative deltas.
|
|
17
|
+
- Re-run benchmark after remediation to verify recovery.
|
|
18
|
+
|
|
19
|
+
## Reporting Standard
|
|
20
|
+
|
|
21
|
+
- Include benchmark summary in release bundle.
|
|
22
|
+
- Keep machine-readable JSON output for automation.
|
|
23
|
+
- Track trend over time, not only single-run status.
|
|
24
|
+
|
|
25
|
+
## Review Checklist
|
|
26
|
+
|
|
27
|
+
- [ ] Baseline and current benchmark are comparable.
|
|
28
|
+
- [ ] Threshold policy is applied consistently.
|
|
29
|
+
- [ ] Regressions have owner and due date.
|
|
30
30
|
- [ ] Reports are archived for audit trail.
|
|
@@ -1,8 +1,8 @@
|
|
|
1
|
-
{
|
|
2
|
-
"schemaVersion": "compatibility-manifest-v1",
|
|
3
|
-
"artifactType": "skill-domain",
|
|
4
|
-
"domain": "review-quality",
|
|
5
|
-
"ides": ["cursor", "windsurf", "copilot", "gemini", "claude", "codex", "cline"],
|
|
6
|
-
"nodeMin": "18",
|
|
7
|
-
"platforms": ["windows", "linux", "macos"]
|
|
8
|
-
}
|
|
1
|
+
{
|
|
2
|
+
"schemaVersion": "compatibility-manifest-v1",
|
|
3
|
+
"artifactType": "skill-domain",
|
|
4
|
+
"domain": "review-quality",
|
|
5
|
+
"ides": ["cursor", "windsurf", "copilot", "gemini", "claude", "codex", "cline"],
|
|
6
|
+
"nodeMin": "18",
|
|
7
|
+
"platforms": ["windows", "linux", "macos"]
|
|
8
|
+
}
|
|
@@ -1,38 +1,38 @@
|
|
|
1
|
-
# Planning
|
|
2
|
-
|
|
3
|
-
Tier: EXPERT
|
|
4
|
-
|
|
5
|
-
Planning quality determines implementation quality. Non-trivial work should start with a scoped, testable plan.
|
|
6
|
-
|
|
7
|
-
## Planning Standard
|
|
8
|
-
|
|
9
|
-
- Define objective, scope, and non-goals.
|
|
10
|
-
- Identify architecture boundaries affected.
|
|
11
|
-
- Document risk, rollback, and validation strategy.
|
|
12
|
-
- Break work into reviewable increments.
|
|
13
|
-
|
|
14
|
-
## Required Plan Artifacts
|
|
15
|
-
|
|
16
|
-
- Implementation steps with expected output.
|
|
17
|
-
- File impact map.
|
|
18
|
-
- Test strategy and acceptance criteria.
|
|
19
|
-
- Migration notes if behavior changes.
|
|
20
|
-
|
|
21
|
-
## Scope Control
|
|
22
|
-
|
|
23
|
-
- Avoid unrelated refactors in feature commits.
|
|
24
|
-
- Split high-risk work into isolated checkpoints.
|
|
25
|
-
- Preserve public API compatibility unless explicitly versioned.
|
|
26
|
-
|
|
27
|
-
## Evidence Discipline
|
|
28
|
-
|
|
29
|
-
- Attach command output for validation and test evidence.
|
|
30
|
-
- Keep assumption logs explicit so reviewers can challenge unknowns early.
|
|
31
|
-
- Ensure rollback path is documented before implementation starts.
|
|
32
|
-
|
|
33
|
-
## Review Checklist
|
|
34
|
-
|
|
35
|
-
- [ ] Plan includes explicit success criteria.
|
|
36
|
-
- [ ] Risks and mitigations are documented.
|
|
37
|
-
- [ ] Validation commands are defined.
|
|
1
|
+
# Planning
|
|
2
|
+
|
|
3
|
+
Tier: EXPERT
|
|
4
|
+
|
|
5
|
+
Planning quality determines implementation quality. Non-trivial work should start with a scoped, testable plan.
|
|
6
|
+
|
|
7
|
+
## Planning Standard
|
|
8
|
+
|
|
9
|
+
- Define objective, scope, and non-goals.
|
|
10
|
+
- Identify architecture boundaries affected.
|
|
11
|
+
- Document risk, rollback, and validation strategy.
|
|
12
|
+
- Break work into reviewable increments.
|
|
13
|
+
|
|
14
|
+
## Required Plan Artifacts
|
|
15
|
+
|
|
16
|
+
- Implementation steps with expected output.
|
|
17
|
+
- File impact map.
|
|
18
|
+
- Test strategy and acceptance criteria.
|
|
19
|
+
- Migration notes if behavior changes.
|
|
20
|
+
|
|
21
|
+
## Scope Control
|
|
22
|
+
|
|
23
|
+
- Avoid unrelated refactors in feature commits.
|
|
24
|
+
- Split high-risk work into isolated checkpoints.
|
|
25
|
+
- Preserve public API compatibility unless explicitly versioned.
|
|
26
|
+
|
|
27
|
+
## Evidence Discipline
|
|
28
|
+
|
|
29
|
+
- Attach command output for validation and test evidence.
|
|
30
|
+
- Keep assumption logs explicit so reviewers can challenge unknowns early.
|
|
31
|
+
- Ensure rollback path is documented before implementation starts.
|
|
32
|
+
|
|
33
|
+
## Review Checklist
|
|
34
|
+
|
|
35
|
+
- [ ] Plan includes explicit success criteria.
|
|
36
|
+
- [ ] Risks and mitigations are documented.
|
|
37
|
+
- [ ] Validation commands are defined.
|
|
38
38
|
- [ ] Scope remains aligned with original objective.
|
|
@@ -1,34 +1,34 @@
|
|
|
1
|
-
# Security
|
|
2
|
-
|
|
3
|
-
Tier: EXPERT
|
|
4
|
-
|
|
5
|
-
Security review is a release gate. Critical vulnerabilities must halt feature rollout until resolved.
|
|
6
|
-
|
|
7
|
-
## Security Halt Policy
|
|
8
|
-
|
|
9
|
-
Immediately block release when any of the following are present:
|
|
10
|
-
- Hardcoded credentials or tokens.
|
|
11
|
-
- Injection vulnerabilities (SQL/command/template).
|
|
12
|
-
- Authentication or authorization bypass.
|
|
13
|
-
- Unvalidated external input entering privileged paths.
|
|
14
|
-
|
|
15
|
-
## Boundary Safeguards
|
|
16
|
-
|
|
17
|
-
- Validate external input at transport boundary.
|
|
18
|
-
- Enforce parameterized queries.
|
|
19
|
-
- Limit privilege scope for runtime credentials.
|
|
20
|
-
- Keep secrets in approved secret stores.
|
|
21
|
-
|
|
22
|
-
## Review Expectations
|
|
23
|
-
|
|
24
|
-
- Threat model relevant attack surfaces.
|
|
25
|
-
- Verify dependency vulnerability posture.
|
|
26
|
-
- Confirm error messages do not leak sensitive internals.
|
|
27
|
-
- Confirm audit logs exist for security-sensitive actions.
|
|
28
|
-
|
|
29
|
-
## Review Checklist
|
|
30
|
-
|
|
31
|
-
- [ ] No critical vulnerability remains open.
|
|
32
|
-
- [ ] Input and output boundaries are validated.
|
|
33
|
-
- [ ] Secret handling follows policy.
|
|
1
|
+
# Security
|
|
2
|
+
|
|
3
|
+
Tier: EXPERT
|
|
4
|
+
|
|
5
|
+
Security review is a release gate. Critical vulnerabilities must halt feature rollout until resolved.
|
|
6
|
+
|
|
7
|
+
## Security Halt Policy
|
|
8
|
+
|
|
9
|
+
Immediately block release when any of the following are present:
|
|
10
|
+
- Hardcoded credentials or tokens.
|
|
11
|
+
- Injection vulnerabilities (SQL/command/template).
|
|
12
|
+
- Authentication or authorization bypass.
|
|
13
|
+
- Unvalidated external input entering privileged paths.
|
|
14
|
+
|
|
15
|
+
## Boundary Safeguards
|
|
16
|
+
|
|
17
|
+
- Validate external input at transport boundary.
|
|
18
|
+
- Enforce parameterized queries.
|
|
19
|
+
- Limit privilege scope for runtime credentials.
|
|
20
|
+
- Keep secrets in approved secret stores.
|
|
21
|
+
|
|
22
|
+
## Review Expectations
|
|
23
|
+
|
|
24
|
+
- Threat model relevant attack surfaces.
|
|
25
|
+
- Verify dependency vulnerability posture.
|
|
26
|
+
- Confirm error messages do not leak sensitive internals.
|
|
27
|
+
- Confirm audit logs exist for security-sensitive actions.
|
|
28
|
+
|
|
29
|
+
## Review Checklist
|
|
30
|
+
|
|
31
|
+
- [ ] No critical vulnerability remains open.
|
|
32
|
+
- [ ] Input and output boundaries are validated.
|
|
33
|
+
- [ ] Secret handling follows policy.
|
|
34
34
|
- [ ] Least-privilege access is enforced.
|