oh-my-customcode 0.12.1 → 0.12.3

package/templates/.codex/skills/audit-agents/SKILL.md

@@ -1,116 +0,0 @@
----
-name: audit-agents
-description: Audit agent dependencies and references
-argument-hint: "[agent-name] [--all] [--fix]"
----
-
-# Audit Agents Skill
-
-Audit agent dependencies to ensure all skill and guide references are valid and symlinks are working.
-
-## Options
-
-```
---all, -a        Audit all agents
---verbose, -v    Show detailed results
---fix            Auto-fix issues (delegates to /fix-refs)
-```
-
-## Workflow
-
-```
-1. Load agent configuration
-   └── Read agent .md file
-
-2. Check skills
-   ├── Skill exists in .codex/skills/
-   └── Skill path is valid
-
-3. Check guides
-   ├── Guide exists in guides/
-   └── Guide path is valid
-
-4. Report results
-```
-
-## Output Format
-
-### Single Agent
-```
-[mgr-supplier:audit lang-golang-expert]
-
-Auditing: lang-golang-expert
-
-Skills:
-  ✓ go-best-practices
-    Path: .codex/skills/go-best-practices/
-    Status: Valid
-
-Guides:
-  ✓ golang
-    Path: guides/golang/
-    Status: Valid
-
-Summary:
-  Skills: 1/1 valid
-  Guides: 1/1 valid
-  Status: HEALTHY
-```
-
-### All Agents
-```
-[mgr-supplier:audit --all]
-
-Auditing all agents...
-
-sw-engineer:
-  ✓ lang-golang-expert      (2/2 deps valid)
-  ✓ lang-python-expert      (2/2 deps valid)
-  ✓ lang-rust-expert        (2/2 deps valid)
-  ✗ lang-kotlin-expert      (1/2 deps valid)
-    └─ Missing: kotlin guide symlink
-
-sw-engineer/backend:
-  ✓ be-fastapi-expert     (2/2 deps valid)
-  ✓ be-springboot-expert  (2/2 deps valid)
-  ✓ be-go-backend-expert  (2/2 deps valid)
-
-infra-engineer:
-  ✓ infra-docker-expert      (2/2 deps valid)
-  ✓ infra-aws-expert         (2/2 deps valid)
-
-Summary:
-  Total agents: 15
-  Healthy: 14
-  Issues: 1
-
-Run "mgr-supplier:fix lang-kotlin-expert" to fix issues.
-```
-
-### Verbose Output
-```
-[mgr-supplier:audit lang-golang-expert --verbose]
-
-Auditing: lang-golang-expert
-
-Configuration:
-  Path: .codex/agents/lang-golang-expert.md
-  Type: sw-engineer
-  Source: internal
-
-Declared Skills:
-  [1] go-best-practices
-      Path: .codex/skills/go-best-practices/
-      Exists: ✓
-
-Declared Guides:
-  [1] golang
-      Path: guides/golang/
-      Exists: ✓
-
-Cross-references:
-  ✓ go-best-practices.used_by includes lang-golang-expert
-  ✓ golang.used_by includes lang-golang-expert
-
-Status: HEALTHY (all checks passed)
-```

package/templates/.codex/skills/aws-best-practices/SKILL.md

@@ -1,280 +0,0 @@
----
-name: aws-best-practices
-description: AWS patterns from Well-Architected Framework
-user-invocable: false
----
-
-## Purpose
-
-Apply AWS patterns for building scalable, secure, and cost-effective cloud infrastructure.
-
-## Well-Architected Framework Pillars
-
-### 1. Operational Excellence
-
-```yaml
-principles:
-  - Perform operations as code
-  - Make frequent, small, reversible changes
-  - Refine operations procedures frequently
-  - Anticipate failure
-  - Learn from all operational failures
-
-practices:
-  - Use CloudFormation/CDK for IaC
-  - Implement CI/CD pipelines
-  - Use CloudWatch for monitoring
-  - Set up alarms and dashboards
-  - Document runbooks
-```
-
-### 2. Security
-
-```yaml
-principles:
-  - Implement strong identity foundation
-  - Enable traceability
-  - Apply security at all layers
-  - Automate security best practices
-  - Protect data in transit and at rest
-  - Keep people away from data
-  - Prepare for security events
-
-iam:
-  - Use least privilege principle
-  - Never use root account for daily tasks
-  - Enable MFA for all users
-  - Use IAM roles for services
-  - Rotate credentials regularly
-
-patterns: |
-  # IAM Policy - Least Privilege
-  {
-    "Version": "2012-10-17",
-    "Statement": [{
-      "Effect": "Allow",
-      "Action": [
-        "s3:GetObject",
-        "s3:PutObject"
-      ],
-      "Resource": "arn:aws:s3:::my-bucket/*",
-      "Condition": {
-        "IpAddress": {
-          "aws:SourceIp": "10.0.0.0/8"
-        }
-      }
-    }]
-  }
-```
-
-### 3. Reliability
-
-```yaml
-principles:
-  - Automatically recover from failure
-  - Test recovery procedures
-  - Scale horizontally
-  - Stop guessing capacity
-  - Manage change through automation
-
-practices:
-  - Multi-AZ deployments
-  - Auto Scaling groups
-  - Health checks and self-healing
-  - Backup and disaster recovery
-  - Loose coupling with queues
-
-patterns:
-  high_availability: |
-    # Multi-AZ RDS
-    - Primary in us-east-1a
-    - Standby in us-east-1b
-    - Read replicas in us-east-1c
-
-  auto_scaling: |
-    # Target tracking scaling
-    - Metric: CPUUtilization
-    - Target: 70%
-    - Min: 2, Max: 10
-```
-
-### 4. Performance Efficiency
-
-```yaml
-principles:
-  - Democratize advanced technologies
-  - Go global in minutes
-  - Use serverless architectures
-  - Experiment more often
-  - Consider mechanical sympathy
-
-compute:
-  - Right-size instances
-  - Use Spot for fault-tolerant workloads
-  - Consider Graviton (ARM) processors
-  - Containerize with ECS/EKS
-
-storage:
-  - Use appropriate storage class
-  - S3 Intelligent-Tiering for variable access
-  - EBS volume types based on IOPS needs
-
-database:
-  - Aurora for MySQL/PostgreSQL
-  - DynamoDB for key-value/document
-  - ElastiCache for caching
-```
-
-### 5. Cost Optimization
-
-```yaml
-principles:
-  - Implement cloud financial management
-  - Adopt consumption model
-  - Measure overall efficiency
-  - Stop spending on undifferentiated heavy lifting
-  - Analyze and attribute expenditure
-
-practices:
-  - Use Reserved Instances/Savings Plans
-  - Right-size resources
-  - Delete unused resources
-  - Use Spot Instances
-  - Implement auto scaling
-
-tools:
-  - AWS Cost Explorer
-  - AWS Budgets
-  - AWS Trusted Advisor
-  - Cost Allocation Tags
-```
-
-### 6. Sustainability
-
-```yaml
-principles:
-  - Understand your impact
-  - Establish sustainability goals
-  - Maximize utilization
-  - Anticipate and adopt more efficient offerings
-  - Use managed services
-  - Reduce downstream impact
-
-practices:
-  - Use efficient instance types (Graviton)
-  - Optimize storage lifecycle
-  - Use serverless where possible
-  - Select regions with lower carbon intensity
-```
-
-## Common Patterns
-
-### VPC Design
-
-```yaml
-pattern: |
-  VPC (10.0.0.0/16)
-  ├── Public Subnets
-  │   ├── us-east-1a: 10.0.1.0/24
-  │   ├── us-east-1b: 10.0.2.0/24
-  │   └── us-east-1c: 10.0.3.0/24
-  ├── Private Subnets (App)
-  │   ├── us-east-1a: 10.0.11.0/24
-  │   ├── us-east-1b: 10.0.12.0/24
-  │   └── us-east-1c: 10.0.13.0/24
-  └── Private Subnets (Data)
-      ├── us-east-1a: 10.0.21.0/24
-      ├── us-east-1b: 10.0.22.0/24
-      └── us-east-1c: 10.0.23.0/24
-
-components:
-  - Internet Gateway (public access)
-  - NAT Gateway (private outbound)
-  - VPC Endpoints (AWS services)
-  - Network ACLs (subnet level)
-  - Security Groups (instance level)
-```
-
-### Three-Tier Architecture
-
-```yaml
-pattern: |
-  [Internet]
-      │
-  [CloudFront]
-      │
-  [ALB] ← Public Subnet
-      │
-  [ECS/EC2] ← Private Subnet (App)
-      │
-  [RDS Multi-AZ] ← Private Subnet (Data)
-
-components:
-  web_tier:
-    - CloudFront for CDN
-    - WAF for protection
-    - ALB for load balancing
-
-  app_tier:
-    - ECS Fargate or EC2
-    - Auto Scaling
-    - ElastiCache
-
-  data_tier:
-    - RDS Multi-AZ
-    - Read Replicas
-    - Automated backups
-```
-
-### Serverless Pattern
-
-```yaml
-pattern: |
-  [API Gateway]
-      │
-  [Lambda] → [DynamoDB]
-      │
-  [SQS] → [Lambda] → [S3]
-
-components:
-  - API Gateway for REST/HTTP APIs
-  - Lambda for compute
-  - DynamoDB for NoSQL
-  - SQS for decoupling
-  - S3 for storage
-  - Step Functions for orchestration
-```
-
-### CI/CD Pipeline
-
-```yaml
-pattern: |
-  [CodeCommit/GitHub]
-      │
-  [CodePipeline]
-      │
-  ├── [CodeBuild] - Build & Test
-  │
-  ├── [ECR] - Container Registry
-  │
-  └── [CodeDeploy/ECS] - Deploy
-
-practices:
-  - Blue/Green deployments
-  - Canary releases
-  - Automated rollback
-  - Infrastructure as Code
-```
-
-## Application
-
-When designing AWS architecture:
-
-1. **Always** follow least privilege for IAM
-2. **Always** use Multi-AZ for production
-3. **Always** encrypt data at rest and in transit
-4. **Prefer** managed services over self-managed
-5. **Implement** monitoring and alerting
-6. **Use** IaC for all infrastructure
-7. **Design** for failure
-8. **Optimize** costs continuously

package/templates/.codex/skills/claude-code-bible/SKILL.md

@@ -1,100 +0,0 @@
----
-name: claude-code-bible
-description: Fetch and verify Codex official documentation from OpenAI canonical sources.
-disable-model-invocation: true
----
-
-# Codex Docs Bible
-
-Official Codex documentation reference management for Codex-native projects.
-
-## Compatibility Note
-
-The command/skill name `claude-code-bible` is kept for backward compatibility.
-Its source policy is Codex-only.
-
-## Purpose
-
-Maintain up-to-date local copies of Codex documentation and validate agent/skill templates against the expected Codex-native conventions.
-
-## Canonical Source Policy
-
-Primary documentation sources:
-
-- `https://developers.openai.com/codex/`
-- `https://developers.openai.com/codex/cli`
-- `https://developers.openai.com/codex/ide`
-- `https://developers.openai.com/codex/cloud`
-- `https://developers.openai.com/codex/cloud/internet-access`
-- `https://developers.openai.com/codex/changelog`
-
-Fallback behavior:
-
-- Each source has an explicit fallback URL chain in `fetch-docs.js`.
-- If a primary URL fails, the script tries fallback URLs in order.
-- Fetch status is written to `fetch-report.json` for auditability.
-
-## Commands
-
-### `/claude-code-bible update`
-
-Fetch Codex docs snapshots from the source policy.
-
-**What it does:**
-
-- Applies fixed canonical source policy from script
-- Fetches pages with redirect support and timeouts
-- Stores snapshots as HTML files
-- Writes `source-policy.json` and `fetch-report.json`
-- Writes `last-updated.txt` for 24-hour cache checks
-
-**Usage:**
-
-```bash
-# Fetch latest docs (skip if cache < 24h)
-node .codex/skills/claude-code-bible/scripts/fetch-docs.js
-
-# Force fetch regardless of cache
-node .codex/skills/claude-code-bible/scripts/fetch-docs.js --force
-
-# Use custom output directory
-node .codex/skills/claude-code-bible/scripts/fetch-docs.js --output /path/to/output
-```
-
-**Default output location:**
-
-```text
-~/.codex/references/codex-docs/
-├── codex-overview.html
-├── codex-cli.html
-├── codex-ide.html
-├── codex-cloud.html
-├── codex-cloud-internet.html
-├── codex-changelog.html
-├── source-policy.json
-├── fetch-report.json
-└── last-updated.txt
-```
-
-### `/claude-code-bible verify`
-
-Validate Codex templates against Codex-native conventions.
-
-**Verification baseline:**
-
-1. **Agent frontmatter** includes `name`, `description`, `model`, `tools`.
-2. **Skill frontmatter** includes `name`, `description`.
-3. **Model profile policy** uses `reasoning | balanced | fast`.
-4. **Path policy** uses `.codex/` and `AGENTS.md` references.
-
-## Integration
-
-- `create-agent`: run verify for new/updated agent output.
-- `update-docs`: refresh docs first, then run verify.
-- `sauron-watch`: include spec-alignment checks in full audit mode.
-
-## Notes
-
-- Fetch is resilient: partial failures are reported without losing successful snapshots.
-- If all sources fail, fetch exits with non-zero status.
-- Recommended cadence: run weekly or before release hardening.