95 lines
4.4 KiB
Markdown
95 lines
4.4 KiB
Markdown
---
|
|
name: standards-verification
|
|
description: >-
|
|
Use this skill sparingly when a new major function or feature has been implemented, when the user explicitly asks to verify standards, or as a debugging tool to analyze code issues. Targets only modified or relevant files via git status/diff and evaluates them against the project standards document.
|
|
---
|
|
|
|
# Standards Verification Skill
|
|
|
|
This skill performs targeted architectural and stylistic compliance verification for new or modified code in this repository.
|
|
|
|
> [!IMPORTANT]
|
|
> **Invocation Policy:** Call this skill **sparingly and only when needed**.
|
|
> **Valid Triggers:**
|
|
> 1. A new major function or architectural feature has been implemented.
|
|
> 2. The user asks to call it or requests standards verification.
|
|
> 3. An error, test failure, or regression has occurred, and you are using this skill as a debugging tool to determine where the code diverges from project standards.
|
|
|
|
|
|
---
|
|
|
|
## 1. Targeted Inspection Scope (Not the Whole Codebase)
|
|
|
|
Do **NOT** scan or audit the whole codebase unless specifically requested by the user or strictly necessary for whole-system refactors.
|
|
|
|
Instead, narrow the scope to targeted sections using Git:
|
|
|
|
1. **Check Modified Files:**
|
|
```bash
|
|
git status -s
|
|
```
|
|
2. **Inspect Exact Changes:**
|
|
```bash
|
|
git diff HEAD
|
|
```
|
|
Or for staged changes:
|
|
```bash
|
|
git diff --staged
|
|
```
|
|
3. **Identify Changed Sections:**
|
|
Focus only on the files, functions, templates, or styles touched in the current task.
|
|
|
|
---
|
|
|
|
## 2. Standards Evaluation Workflow
|
|
|
|
To verify compliance, read the dedicated project standards document:
|
|
- Authoritative document: [`.agents/standards.md`](file:///home/venus/code/blog/.agents/standards.md) (or local skill reference: [`references/standards.md`](file:///home/venus/code/blog/.agents/skills/standards-verification/references/standards.md)).
|
|
|
|
Evaluate the targeted changes against the core standard pillars:
|
|
|
|
1. **Design System & CSS Rules:**
|
|
- Are any anti-patterns present? Check for `backdrop-filter`, `box-shadow`, `text-shadow` (other than `none`), gradients, or transitions with delays/curves.
|
|
- Are border radii strictly bounded between `0px` and `4px`?
|
|
- Are colors utilizing CSS custom properties from `tokens.css`?
|
|
- Is styling modularized without inline `<style>` tags?
|
|
|
|
2. **Templating & Eleventy Architecture:**
|
|
- Does post rendering adhere to layout inheritance (`base.njk` -> `post.njk`)?
|
|
- Are collections (`posts`, `tagList`) properly filtered using `isPostPublic`?
|
|
- If a post is marked `hidden`, does the layout emit `<meta name="robots" content="noindex, nofollow">`?
|
|
|
|
3. **Content & Frontmatter Contracts:**
|
|
- Are required frontmatter keys (`title`, `date`, `tags`, `excerpt`) valid and conforming to schema length invariants?
|
|
- Are wikilinks and Obsidian attachments normalized?
|
|
|
|
4. **Server & Security Invariants:**
|
|
- Does `server.js` preserve security headers (`X-Content-Type-Options: nosniff`, `X-Frame-Options: DENY`, `Referrer-Policy: strict-origin-when-cross-origin`)?
|
|
- Is path traversal protection in place for all file-serving and API endpoints?
|
|
|
|
5. **Test-Driven Development (TDD) Invariants:**
|
|
- Were automated test cases written *before* functional code was modified?
|
|
- Are adversarial test cases included (boundary inputs, nulls, invalid configs)?
|
|
- Do all tests pass (`npm test`)?
|
|
|
|
---
|
|
|
|
## 3. Stylistic & Architectural Reporting
|
|
|
|
Compile a structured report highlighting:
|
|
- **Conformant Highlights:** Key standards cleanly satisfied.
|
|
- **Stylistic Issues & Deviations:** Any formatting inconsistencies, unneeded inline styles, or naming anomalies.
|
|
- **Remediation Steps:** Concrete, minimal code adjustments to bring the implementation into full compliance.
|
|
|
|
---
|
|
|
|
## 4. Debugging with Standards Verification
|
|
|
|
When using this skill as a debugging tool to troubleshoot broken builds, failed tests, or runtime bugs:
|
|
|
|
1. **Locate the Error:** Inspect test failure outputs or server logs to isolate the failing component.
|
|
2. **Correlate with Standards:** Compare the problematic implementation against [`.agents/standards.md`](file:///home/venus/code/blog/.agents/standards.md).
|
|
3. **Explain the Discrepancy:** Specifically identify where the code is out of touch with project standards (e.g. missing input guards for `null`, collections bypassing `isPostPublic`, un-sanitized slug paths).
|
|
4. **Suggest Root Cause & Fix:** Suggest why those issues cause an error and provide the targeted fix.
|
|
|