用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt;运行前请先检查来源。
npx skills add https://github.com/carrot-foundation/methodology-rules --skill rule-rule-processors命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地?可下载 SkillsMP 当前能够提供的文件。
正在显示 SKILL.md
基于 SOC 职业分类
| name | rule-rule-processors |
| description | Rule mapping for rule-processors |
Apply this rule whenever work touches:
libs/methodologies/**/*.tsRule processors are the core units of methodology evaluation. Each processor validates a specific aspect of a document against Bold methodology requirements.
Every rule processor must contain the following files:
{rule-name}/
├── {rule-name}.processor.ts # Core logic
├── {rule-name}.lambda.ts # Lambda handler (thin wrapper)
├── {rule-name}.processor.spec.ts # Unit tests
├── {rule-name}.lambda.e2e.spec.ts # E2E tests
├── {rule-name}.test-cases.ts # Shared test data
├── {rule-name}.helpers.ts # Stateless helpers (optional)
├── {rule-name}.constants.ts # Result-comment templates and thresholds (optional)
├── index.ts # Public exports
├── project.json # Nx project config
└── vitest.config.ts # Vitest config
Stateless functions belong in {rule-name}.helpers.ts rather than as private methods on the processor class. Use arrow-const syntax (export const myHelper = (...) => ...), matching the existing helper-file convention. Result-comment templates and threshold constants live in {rule-name}.constants.ts and can compose small phrase-builder helpers to keep variants in sync.
Always use the CLI tool to create new rules:
# Create a new rule
pnpm create-rule vehicle-validation mass-id "Validates vehicle data"
# Apply the rule to a methodology
pnpm apply-methodology-rule carbon-organic geolocation-precision mass-id
Processors extend ParentDocumentRuleProcessor<RuleSubject> and implement evaluateResult():
import { ParentDocumentRuleProcessor } from '@carrot-fndn/shared/rule';
import type { RuleSubject } from '@carrot-fndn/shared/rule';
export class VehicleValidationProcessor extends ParentDocumentRuleProcessor<RuleSubject> {
protected override evaluateResult(subject: RuleSubject): RuleOutput {
// Business logic here
}
}
Define reusable test data in {rule-name}.test-cases.ts:
import { stubRuleInput } from '@carrot-fndn/shared/testing';
export const validInput = stubRuleInput({
// override only what this rule cares about
});
export const invalidInput = stubRuleInput({
// data that should cause the rule to fail
});
Both *.spec.ts and *.e2e.spec.ts files should import from the test-cases file to keep assertions consistent.