القائمة
Audit a generated OS repository for completeness, consistency, and architectural integrity against the 15 design principles and 23-item checklist.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Transplant a skill, command, or capability from one agentic-system repo into another via a 5-phase gated protocol (inventory → import → localize → wire → verify). Use when grafting a feature from an upstream repo that has its own dependencies, platform assumptions, or upstream-specific file references that need adapting before the feature will work in the destination repo. Not for copying a self-contained file — use only when the feature has a dependency footprint and the destination repo has its own conventions the import must respect.
Design multi-dimensional evaluation rubrics with calibrated scales, thresholds, and function-adaptive weights.
Identify who evaluates the user's output, what each audience prioritizes, and where their priorities conflict.
Define the user context model — identity axes, context files, persona variants, and privacy rules for the target OS.
Design compounding feedback loops — what data accumulates, what reads it, and how the system gets smarter with use.
Design the complete skill set for the target OS — each skill's purpose, inputs, process, output format, auto-triggers, and quality checks.
| name | review-os |
| description | Audit a generated OS repository for completeness, consistency, and architectural integrity against the 15 design principles and 23-item checklist. |
/generate-os produces the OS repositoryoutput/[domain]-os/reference/BLUEPRINT.md (master specification — the OS is audited against this)domain-input/ files (as the spec to audit against)reference/architecture-patterns.md (the 15 principles to verify)Check that all expected files exist:
[ ] CLAUDE.md exists and is non-empty
[ ] DATA_CONTRACT.md exists and classifies all files
[ ] README.md exists
[ ] START-HERE.md exists with time estimates
[ ] .claude/skills/ has [N] skill folders (match skill-designs.md count)
[ ] Each skill folder has SKILL.md
[ ] sub-agents/ has [N] files (match sub-agent-designs.md count)
[ ] context-library/ has [N] template files (match identity-model.md count)
[ ] config/ has defaults.md and overrides.md
[ ] cowork-tasks/ has briefing files
[ ] setup/ has installation guide and checklist
[ ] insider-data/ has at minimum an index.md
[ ] batch/ exists (if batch-designs.md was provided)
[ ] modes/ exists (if localization-designs.md was provided)
[ ] backtesting/ exists (if backtesting-library.md was provided)
[ ] templates/ has artifact templates (if artifact-pipeline.md was provided)
Read CLAUDE.md and verify:
[ ] Core philosophy present (3-5 rules)
[ ] Context awareness lists ALL context-library and config files
[ ] Data contract summary present with classification table and Golden Rule
[ ] Skills table lists ALL skills with correct /commands
[ ] Sub-agents table lists ALL sub-agents
[ ] Auto-behaviors section lists ALL trigger chains
[ ] Verification rules present and specific
[ ] Data acquisition rules present (if external data sources exist)
[ ] Empty context detection covers ALL context dependencies
[ ] Configuration precedence stated (overrides > defaults)
[ ] Writing style section present
[ ] Non-negotiable rule appears early and in bold
[ ] Getting started section present
For each SKILL.md:
[ ] Frontmatter has name and description
[ ] "When to Use" section present
[ ] Inputs list auto-loaded files that exist in context-library/
[ ] Process is step-by-step (not a vague description)
[ ] Output format is a concrete template
[ ] Quality checks have "good" AND "bad" examples
[ ] Empty context behavior defined for all required files
[ ] Auto-triggers match what CLAUDE.md declares (dual declaration check)
[ ] Configuration section reads overrides > defaults (if applicable)
[ ] Artifact Output section present (if skill produces non-text output)
[ ] Batch Mode Variant section present (if skill supports batch)
[ ] Data Source Dependencies section present (if skill uses external data)
For each sub-agent:
[ ] Has a vivid persona (not generic "reviewer")
[ ] Triggers after a specific creation skill
[ ] Scoring dimensions DIFFER from the creation skill's process
[ ] "Good review" and "bad review" criteria defined
[ ] Output format includes specific scoring and actionable fixes
[ ] Artifact review capability present (if reviewing non-text output)
Critical check: For each sub-agent, answer: "What does this reviewer catch that the creation skill would miss?"
[ ] DATA_CONTRACT.md exists
[ ] Every persistent file in the OS is classified (user/system/hybrid)
[ ] The Golden Rule is specific and testable
[ ] No skill writes to a user-owned file without explicit user action
[ ] System-managed files are auto-updatable
[ ] Hybrid files have clear append/curate semantics
[ ] Classification matches actual skill behavior
[ ] config/overrides.md is classified as user-owned
[ ] config/defaults.md is classified as system-managed
For each feedback loop:
[ ] Data producer skill exists and writes to a real file
[ ] Data consumer skill exists and reads from the same file
[ ] Degradation behavior defined for 0, 1-2, 3-9, 10+ data points
[ ] Retro skill reads from all accumulating files
[ ] Briefing evolves as data accumulates
If artifact pipelines exist:
[ ] Each artifact type has a declared template in templates/
[ ] Design tokens are centralized (not scattered across skills)
[ ] Render pipeline is step-by-step and specific
[ ] Storage path and naming convention are declared
[ ] Verification criteria exist per artifact format
[ ] Fallback behavior defined for unavailable render tools
[ ] Naming convention is consistent across artifact types
If batch/ directory exists:
[ ] batch/batch-prompt.md is self-contained (no conversation dependency)
[ ] batch/batch-state.tsv has a defined schema
[ ] Status values are documented (pending, completed, failed, etc.)
[ ] Merge process is defined and idempotent
[ ] Lock file mechanism exists
[ ] Concurrency limits are specified
[ ] Resume/retry mechanisms exist
[ ] Workers do not depend on exclusive-access tools without constraints
If external data sources exist:
[ ] Every source has an explicit trust level (1-3)
[ ] Level 3 sources have specific verification steps
[ ] Verification labels are standardized ([VERIFIED], [UNVERIFIED], [STALE])
[ ] Fallback chains exist for critical data paths
[ ] Staleness thresholds are defined per data type
[ ] Kernel's data acquisition rules section matches source definitions
If backtesting/ directory exists:
[ ] backtesting/library.md exists with case index and ordering scheme
[ ] Each case has a subdirectory in backtesting/cases/ with input.md and ground-truth.md
[ ] Input files contain ONLY the blank input (no answers, no ground truth content)
[ ] Ground truth files contain the user's actual delivered output
[ ] Physical isolation enforced: input.md and ground-truth.md are separate files in separate paths
[ ] No content embedding: metadata uses directional references only (filename, not inline content)
[ ] Cross-contamination validation exists: onboarding or ingest step checks for phrase overlap between input and ground truth
[ ] Cold-start test documented: can each backtestable skill produce output from input.md alone?
[ ] Library index declares ordering scheme (date, importance, or outcome)
[ ] At least one skill declares live reference behavior (reads ground truth during generation)
[ ] backtesting/results/ directory exists for system-generated comparison reports
[ ] DATA_CONTRACT.md classifies input.md and ground-truth.md as user-owned
[ ] DATA_CONTRACT.md classifies results/*.md as system-managed
[ ] Onboarding (START-HERE.md or setup/) includes backtesting library setup instructions
[ ] Minimum viable library size is stated (typically 3-5 cases)
[ ] Kernel includes backtesting library section with live reference rules
[ ] Background backtest infrastructure exists: backtest-prompt.md (self-contained worker prompt)
[ ] Background backtest infrastructure exists: backtest-runner.sh (orchestrator with lock file, dry-run, resume)
[ ] Background backtest infrastructure exists: backtest-state.tsv (per-case progress tracking)
[ ] Backtest runner includes pre-flight isolation validation before processing each case
Critical check: For each backtestable skill, verify that its SKILL.md includes a "Backtesting Integration" or "Live Reference" section that reads from the library during generation.
Component Map (Section 2):
[ ] CLAUDE.md (Kernel)
[ ] DATA_CONTRACT.md (Ownership Boundaries)
[ ] context-library/ (State) — 4-7 files
[ ] config/ (Layered Configuration) — defaults + overrides
[ ] .claude/skills/ (Capabilities) — 8-18 skills
[ ] sub-agents/ (Quality Gates) — 2-4 reviewers
[ ] insider-data/ (Reference Knowledge)
[ ] cowork-tasks/ (Automation) — 2-3 part briefing
[ ] templates/ (Scaffolding + Artifact Blueprints)
[ ] setup/ (Onboarding)
[ ] [output-folder]/ (Logs + Artifacts)
[ ] batch/ (Worker Infrastructure) — if applicable
[ ] modes/ (Localized Modes) — if applicable
[ ] backtesting/ (Historical Calibration) — if applicable
Orchestration (Section 4):
[ ] Trigger chains documented for every creation skill (4a)
[ ] Connector map: every context file has readers/writers listed (4b)
[ ] At least 2 compounding loops fully wired (4c)
[ ] Dual declaration: every auto-behavior in BOTH kernel AND skill (4d)
[ ] Data contract enforced at runtime (4e)
[ ] Artifact pipelines wired (4f) — if applicable
[ ] Batch execution model documented (4g) — if applicable
[ ] Trust-layered acquisition documented (4h) — if applicable
[ ] Backtesting library wired (4i) — if applicable
Generation Checklist (Section 8) — all 23 items:
[ ] 1. One kernel file
[ ] 2. User state externalized
[ ] 3. Skills are stateless pure functions
[ ] 4. Every generation skill has adversarial reviewer
[ ] 5. One zero-setup entry point
[ ] 6. Auto-behaviors dual-declared
[ ] 7. Verification mandatory per skill
[ ] 8. Compounding loops exist
[ ] 9. Persona-conditional branching
[ ] 10. Graceful degradation
[ ] 11. Function-adaptive markers
[ ] 12. Scheduled automation
[ ] 13. Dependency table in kernel
[ ] 14. Connector map documented
[ ] 15. Trigger chains documented
[ ] 16. Two-system boundary enforced
[ ] 17. DATA_CONTRACT.md exists classifying every file
[ ] 18. Layered configuration (defaults + overrides)
[ ] 19. Artifact pipelines declared (if applicable)
[ ] 20. External data sources have trust levels (if applicable)
[ ] 21. Batch operations are resumable (if applicable)
[ ] 22. Orthogonal evaluation axes
[ ] 23. Backtesting library (if applicable) — cases, ordering, live reference, onboarding
15 Design Principles (Section 6):
[ ] P1: Separation of identity from capability
[ ] P2: Generation ≠ evaluation
[ ] P3: Declarative orchestration (dual declaration)
[ ] P4: State in flat files
[ ] P5: Compounding feedback loops
[ ] P6: Graceful degradation with quality gates
[ ] P7: Function-adaptive markers
[ ] P8: Zero-setup entry point
[ ] P9: Trust-layered data acquisition (if external data)
[ ] P10: Orthogonal evaluation axes
[ ] P11: Formal data contract
[ ] P12: Resumable idempotent operations (if batch)
[ ] P13: Artifact-as-deliverable (if non-text output)
[ ] P14: Layered configuration inheritance
[ ] P15: Historical backtesting library (if applicable)
Two-System Boundary Check:
[ ] No skill contains hardcoded user data
[ ] No context-library file contains skill logic
[ ] All context-library files ship as empty templates
[ ] Every skill reads user identity from context-library at runtime
[ ] domain-input/ content does NOT leak into the generated OS
[ ] No references to agent-os-factory anywhere in the OS
[ ] The OS has its own onboarding: START-HERE.md, setup/, empty-context messages
[ ] Every file path in CLAUDE.md points to a real file
[ ] Every "auto-loaded" reference in skills points to a real context file
[ ] Every sub-agent trigger references a real skill
[ ] Every auto-behavior's target skill exists
[ ] Briefing references correct file paths for output
[ ] DATA_CONTRACT.md references match actual files
[ ] Batch prompt references match actual context files
# OS Architecture Audit - [Domain] OS
## Summary
- Files checked: [N]
- Issues found: [N] critical, [N] warnings
- Architectural principles: [N]/15 verified
- Checklist items: [N]/23 passed
## Critical Issues (must fix)
1. [Issue]: [where] — [what's wrong] — [how to fix]
## Warnings (should fix)
1. [Issue]: [where] — [what's wrong] — [how to fix]
## Verified
- [list of all checks that passed]
## Recommendation
[READY TO DEPLOY / FIX CRITICAL ISSUES FIRST / NEEDS SIGNIFICANT REWORK]
After the audit, offer to fix any issues found:
Good audit:
Bad audit: