[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6KBCAXK5GKDV9TVH2FQHVWM":3,"skill-same:01M6KBCAXK5GKDV9TVH2FQHVWM":67},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":24,"linkOnly":25,"markdownContent":26,"markdownBody":27,"frontMatter":28,"refName":29,"commitSha":30,"skillDirectory":31,"forksCount":32,"repositoryHtmlUrl":33,"repositoryHomepageUrl":6,"ownerHtmlUrl":34,"ownerBlogUrl":35,"ownerDescription":6,"updatedAt":36,"install":37,"resources":50},"01M6KBCAXK5GKDV9TVH2FQHVWM","env-secrets-manager",null,"Env & Secrets Manager","afaizalam2003\u002FMaster-claude-skill","afaizalam2003","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F222019359?v=4","01M6K8F2XNT0HKBPF00JQ78SV3","Faiz Alam","01M6K8F31EBXAPER0EG8R9HTR5",3,"MIT","https:\u002F\u002Fgithub.com\u002Fafaizalam2003\u002FMaster-claude-skill\u002Fblob\u002Fmain\u002Fengineering\u002Fenv-secrets-manager\u002FSKILL.md",[],[19,20,21,22,23],"secrets","env secrets manager","env","secrets manager","manager","2026-11-10 10:12:30",false,"---\nname: \"env-secrets-manager\"\ndescription: \"Env & Secrets Manager\"\n---\n\n# Env & Secrets Manager\n\n**Tier:** POWERFUL\n**Category:** Engineering\n**Domain:** Security \u002F DevOps \u002F Configuration Management\n\n---\n\n## Overview\n\nManage environment-variable hygiene and secrets safety across local development and production workflows. This skill focuses on practical auditing, drift awareness, and rotation readiness.\n\n## Core Capabilities\n\n- `.env` and `.env.example` lifecycle guidance\n- Secret leak detection for repository working trees\n- Severity-based findings for likely credentials\n- Operational pointers for rotation and containment\n- Integration-ready outputs for CI checks\n\n---\n\n## When to Use\n\n- Before pushing commits that touched env\u002Fconfig files\n- During security audits and incident triage\n- When onboarding contributors who need safe env conventions\n- When validating that no obvious secrets are hardcoded\n\n---\n\n## Quick Start\n\n```bash\n# Scan a repository for likely secret leaks\npython3 scripts\u002Fenv_auditor.py \u002Fpath\u002Fto\u002Frepo\n\n# JSON output for CI pipelines\npython3 scripts\u002Fenv_auditor.py \u002Fpath\u002Fto\u002Frepo --json\n```\n\n---\n\n## Recommended Workflow\n\n1. Run `scripts\u002Fenv_auditor.py` on the repository root.\n2. Prioritize `critical` and `high` findings first.\n3. Rotate real credentials and remove exposed values.\n4. Update `.env.example` and `.gitignore` as needed.\n5. Add or tighten pre-commit\u002FCI secret scanning gates.\n\n---\n\n## Reference Docs\n\n- `references\u002Fvalidation-detection-rotation.md`\n- `references\u002Fsecret-patterns.md`\n\n---\n\n## Common Pitfalls\n\n- Committing real values in `.env.example`\n- Rotating one system but missing downstream consumers\n- Logging secrets during debugging or incident response\n- Treating suspected leaks as low urgency without validation\n\n## Best Practices\n\n1. Use a secret manager as the production source of truth.\n2. Keep dev env files local and gitignored.\n3. Enforce detection in CI before merge.\n4. Re-test application paths immediately after credential rotation.\n\n---\n\n## Cloud Secret Store Integration\n\nProduction applications should never read secrets from `.env` files or environment variables baked into container images. Use a dedicated secret store instead.\n\n### Provider Comparison\n\n| Provider | Best For | Key Feature |\n|----------|----------|-------------|\n| **HashiCorp Vault** | Multi-cloud \u002F hybrid | Dynamic secrets, policy engine, pluggable backends |\n| **AWS Secrets Manager** | AWS-native workloads | Native Lambda\u002FECS\u002FEKS integration, automatic RDS rotation |\n| **Azure Key Vault** | Azure-native workloads | Managed HSM, Azure AD RBAC, certificate management |\n| **GCP Secret Manager** | GCP-native workloads | IAM-based access, automatic replication, versioning |\n\n### Selection Guidance\n\n- **Single cloud provider** — use the cloud-native secret manager. It integrates tightly with IAM, reduces operational overhead, and costs less than self-hosting.\n- **Multi-cloud or hybrid** — use HashiCorp Vault. It provides a uniform API across environments and supports dynamic secret generation (database credentials, cloud IAM keys) that expire automatically.\n- **Kubernetes-heavy** — combine External Secrets Operator with any backend above to sync secrets into K8s `Secret` objects without hardcoding.\n\n### Application Access Patterns\n\n1. **SDK\u002FAPI pull** — application fetches secret at startup or on-demand via provider SDK.\n2. **Sidecar injection** — a sidecar container (e.g., Vault Agent) writes secrets to a shared volume or injects them as environment variables.\n3. **Init container** — a Kubernetes init container fetches secrets before the main container starts.\n4. **CSI driver** — secrets mount as a filesystem volume via the Secrets Store CSI Driver.\n\n> **Cross-reference:** See `engineering\u002Fsecrets-vault-manager` for production vault infrastructure patterns, HA deployment, and disaster recovery procedures.\n\n---\n\n## Secret Rotation Workflow\n\nStale secrets are a liability. Rotation ensures that even if a credential leaks, its useful lifetime is bounded.\n\n### Phase 1: Detection\n\n- Track secret creation and expiry dates in your secret store metadata.\n- Set alerts at 30, 14, and 7 days before expiry.\n- Use `scripts\u002Fenv_auditor.py` to flag secrets with no recorded rotation date.\n\n### Phase 2: Rotation\n\n1. **Generate** a new credential (API key, database password, certificate).\n2. **Deploy** the new credential to all consumers (apps, services, pipelines) in parallel.\n3. **Verify** each consumer can authenticate using the new credential.\n4. **Revoke** the old credential only after all consumers are confirmed healthy.\n5. **Update** metadata with the new rotation timestamp and next rotation date.\n\n### Phase 3: Automation\n\n- **AWS Secrets Manager** — use built-in Lambda-based rotation for RDS, Redshift, and DocumentDB.\n- **HashiCorp Vault** — configure dynamic secrets with TTLs; credentials are generated on-demand and auto-expire.\n- **Azure Key Vault** — use Event Grid notifications to trigger rotation functions.\n- **GCP Secret Manager** — use Pub\u002FSub notifications tied to Cloud Functions for rotation logic.\n\n### Emergency Rotation Checklist\n\nWhen a secret is confirmed leaked:\n\n1. **Immediately revoke** the compromised credential at the provider level.\n2. Generate and deploy a replacement credential to all consumers.\n3. Audit access logs for unauthorized usage during the exposure window.\n4. Scan git history, CI logs, and artifact registries for the leaked value.\n5. File an incident report documenting scope, timeline, and remediation steps.\n6. Review and tighten detection controls to prevent recurrence.\n\n---\n\n## CI\u002FCD Secret Injection\n\nSecrets in CI\u002FCD pipelines require careful handling to avoid exposure in logs, artifacts, or pull request contexts.\n\n### GitHub Actions\n\n- Use **repository secrets** or **environment secrets** via `${{ secrets.SECRET_NAME }}`.\n- Prefer **OIDC federation** (`aws-actions\u002Fconfigure-aws-credentials` with `role-to-assume`) over long-lived access keys.\n- Environment secrets with required reviewers add approval gates for production deployments.\n- GitHub automatically masks secrets in logs, but avoid `echo` or `toJSON()` on secret values.\n\n### GitLab CI\n\n- Store secrets as **CI\u002FCD variables** with the `masked` and `protected` flags enabled.\n- Use **HashiCorp Vault integration** (`secrets:vault`) for dynamic secret injection without storing values in GitLab.\n- Scope variables to specific environments (`production`, `staging`) to enforce least privilege.\n\n### Universal Patterns\n\n- **Never echo or print** secret values in pipeline output, even for debugging.\n- **Use short-lived tokens** (OIDC, STS AssumeRole) instead of static credentials wherever possible.\n- **Restrict PR access** — do not expose secrets to pipelines triggered by forks or untrusted branches.\n- **Rotate CI secrets** on the same schedule as application secrets; pipeline credentials are attack vectors too.\n- **Audit pipeline logs** periodically for accidental secret exposure that masking may have missed.\n\n---\n\n## Pre-Commit Secret Detection\n\nCatching secrets before they reach version control is the most cost-effective defense. Two leading tools cover this space.\n\n### gitleaks\n\n```toml\n# .gitleaks.toml — minimal configuration\n[extend]\nuseDefault = true\n\n[[rules]]\nid = \"custom-internal-token\"\ndescription = \"Internal service token pattern\"\nregex = '''INTERNAL_TOKEN_[A-Za-z0-9]{32}'''\nsecretGroup = 0\n```\n\n- Install: `brew install gitleaks` or download from GitHub releases.\n- Pre-commit hook: `gitleaks git --pre-commit --staged`\n- Baseline scanning: `gitleaks detect --source . --report-path gitleaks-report.json`\n- Manage false positives in `.gitleaksignore` (one fingerprint per line).\n\n### detect-secrets\n\n```bash\n# Generate baseline\ndetect-secrets scan --all-files > .secrets.baseline\n\n# Pre-commit hook (via pre-commit framework)\n# .pre-commit-config.yaml\nrepos:\n  - repo: https:\u002F\u002Fgithub.com\u002FYelp\u002Fdetect-secrets\n    rev: v1.5.0\n    hooks:\n      - id: detect-secrets\n        args: ['--baseline', '.secrets.baseline']\n```\n\n- Supports **custom plugins** for organization-specific patterns.\n- Audit workflow: `detect-secrets audit .secrets.baseline` interactively marks true\u002Ffalse positives.\n\n### False Positive Management\n\n- Maintain `.gitleaksignore` or `.secrets.baseline` in version control so the whole team shares exclusions.\n- Review false positive lists during security audits — patterns may mask real leaks over time.\n- Prefer tightening regex patterns over broadly ignoring files.\n\n---\n\n## Audit Logging\n\nKnowing who accessed which secret and when is critical for incident investigation and compliance.\n\n### Cloud-Native Audit Trails\n\n| Provider | Service | What It Captures |\n|----------|---------|-----------------|\n| **AWS** | CloudTrail | Every `GetSecretValue`, `DescribeSecret`, `RotateSecret` API call |\n| **Azure** | Activity Log + Diagnostic Logs | Key Vault access events, including caller identity and IP |\n| **GCP** | Cloud Audit Logs | Data access logs for Secret Manager with principal and timestamp |\n| **Vault** | Audit Backend | Full request\u002Fresponse logging (file, syslog, or socket backend) |\n\n### Alerting Strategy\n\n- Alert on **access from unknown IP ranges** or service accounts outside the expected set.\n- Alert on **bulk secret reads** (more than N secrets accessed within a time window).\n- Alert on **access outside deployment windows** when no CI\u002FCD pipeline is running.\n- Feed audit logs into your SIEM (Splunk, Datadog, Elastic) for correlation with other security events.\n- Review audit logs quarterly as part of access recertification.\n\n---\n\n## Cross-References\n\nThis skill covers env hygiene and secret detection. For deeper coverage of related domains, see:\n\n| Skill | Path | Relationship |\n|-------|------|-------------|\n| **Secrets Vault Manager** | `engineering\u002Fsecrets-vault-manager` | Production vault infrastructure, HA deployment, DR |\n| **Senior SecOps** | `engineering\u002Fsenior-secops` | Security operations perspective, incident response |\n| **CI\u002FCD Pipeline Builder** | `engineering\u002Fci-cd-pipeline-builder` | Pipeline architecture, secret injection patterns |\n| **Infrastructure as Code** | `engineering\u002Finfrastructure-as-code` | Terraform\u002FPulumi secret backend configuration |\n| **Container Orchestration** | `engineering\u002Fcontainer-orchestration` | Kubernetes secret mounting, sealed secrets |\n","# Env & Secrets Manager\n\n**Tier:** POWERFUL\n**Category:** Engineering\n**Domain:** Security \u002F DevOps \u002F Configuration Management\n\n---\n\n## Overview\n\nManage environment-variable hygiene and secrets safety across local development and production workflows. This skill focuses on practical auditing, drift awareness, and rotation readiness.\n\n## Core Capabilities\n\n- `.env` and `.env.example` lifecycle guidance\n- Secret leak detection for repository working trees\n- Severity-based findings for likely credentials\n- Operational pointers for rotation and containment\n- Integration-ready outputs for CI checks\n\n---\n\n## When to Use\n\n- Before pushing commits that touched env\u002Fconfig files\n- During security audits and incident triage\n- When onboarding contributors who need safe env conventions\n- When validating that no obvious secrets are hardcoded\n\n---\n\n## Quick Start\n\n```bash\n# Scan a repository for likely secret leaks\npython3 scripts\u002Fenv_auditor.py \u002Fpath\u002Fto\u002Frepo\n\n# JSON output for CI pipelines\npython3 scripts\u002Fenv_auditor.py \u002Fpath\u002Fto\u002Frepo --json\n```\n\n---\n\n## Recommended Workflow\n\n1. Run `scripts\u002Fenv_auditor.py` on the repository root.\n2. Prioritize `critical` and `high` findings first.\n3. Rotate real credentials and remove exposed values.\n4. Update `.env.example` and `.gitignore` as needed.\n5. Add or tighten pre-commit\u002FCI secret scanning gates.\n\n---\n\n## Reference Docs\n\n- `references\u002Fvalidation-detection-rotation.md`\n- `references\u002Fsecret-patterns.md`\n\n---\n\n## Common Pitfalls\n\n- Committing real values in `.env.example`\n- Rotating one system but missing downstream consumers\n- Logging secrets during debugging or incident response\n- Treating suspected leaks as low urgency without validation\n\n## Best Practices\n\n1. Use a secret manager as the production source of truth.\n2. Keep dev env files local and gitignored.\n3. Enforce detection in CI before merge.\n4. Re-test application paths immediately after credential rotation.\n\n---\n\n## Cloud Secret Store Integration\n\nProduction applications should never read secrets from `.env` files or environment variables baked into container images. Use a dedicated secret store instead.\n\n### Provider Comparison\n\n| Provider | Best For | Key Feature |\n|----------|----------|-------------|\n| **HashiCorp Vault** | Multi-cloud \u002F hybrid | Dynamic secrets, policy engine, pluggable backends |\n| **AWS Secrets Manager** | AWS-native workloads | Native Lambda\u002FECS\u002FEKS integration, automatic RDS rotation |\n| **Azure Key Vault** | Azure-native workloads | Managed HSM, Azure AD RBAC, certificate management |\n| **GCP Secret Manager** | GCP-native workloads | IAM-based access, automatic replication, versioning |\n\n### Selection Guidance\n\n- **Single cloud provider** — use the cloud-native secret manager. It integrates tightly with IAM, reduces operational overhead, and costs less than self-hosting.\n- **Multi-cloud or hybrid** — use HashiCorp Vault. It provides a uniform API across environments and supports dynamic secret generation (database credentials, cloud IAM keys) that expire automatically.\n- **Kubernetes-heavy** — combine External Secrets Operator with any backend above to sync secrets into K8s `Secret` objects without hardcoding.\n\n### Application Access Patterns\n\n1. **SDK\u002FAPI pull** — application fetches secret at startup or on-demand via provider SDK.\n2. **Sidecar injection** — a sidecar container (e.g., Vault Agent) writes secrets to a shared volume or injects them as environment variables.\n3. **Init container** — a Kubernetes init container fetches secrets before the main container starts.\n4. **CSI driver** — secrets mount as a filesystem volume via the Secrets Store CSI Driver.\n\n> **Cross-reference:** See `engineering\u002Fsecrets-vault-manager` for production vault infrastructure patterns, HA deployment, and disaster recovery procedures.\n\n---\n\n## Secret Rotation Workflow\n\nStale secrets are a liability. Rotation ensures that even if a credential leaks, its useful lifetime is bounded.\n\n### Phase 1: Detection\n\n- Track secret creation and expiry dates in your secret store metadata.\n- Set alerts at 30, 14, and 7 days before expiry.\n- Use `scripts\u002Fenv_auditor.py` to flag secrets with no recorded rotation date.\n\n### Phase 2: Rotation\n\n1. **Generate** a new credential (API key, database password, certificate).\n2. **Deploy** the new credential to all consumers (apps, services, pipelines) in parallel.\n3. **Verify** each consumer can authenticate using the new credential.\n4. **Revoke** the old credential only after all consumers are confirmed healthy.\n5. **Update** metadata with the new rotation timestamp and next rotation date.\n\n### Phase 3: Automation\n\n- **AWS Secrets Manager** — use built-in Lambda-based rotation for RDS, Redshift, and DocumentDB.\n- **HashiCorp Vault** — configure dynamic secrets with TTLs; credentials are generated on-demand and auto-expire.\n- **Azure Key Vault** — use Event Grid notifications to trigger rotation functions.\n- **GCP Secret Manager** — use Pub\u002FSub notifications tied to Cloud Functions for rotation logic.\n\n### Emergency Rotation Checklist\n\nWhen a secret is confirmed leaked:\n\n1. **Immediately revoke** the compromised credential at the provider level.\n2. Generate and deploy a replacement credential to all consumers.\n3. Audit access logs for unauthorized usage during the exposure window.\n4. Scan git history, CI logs, and artifact registries for the leaked value.\n5. File an incident report documenting scope, timeline, and remediation steps.\n6. Review and tighten detection controls to prevent recurrence.\n\n---\n\n## CI\u002FCD Secret Injection\n\nSecrets in CI\u002FCD pipelines require careful handling to avoid exposure in logs, artifacts, or pull request contexts.\n\n### GitHub Actions\n\n- Use **repository secrets** or **environment secrets** via `${{ secrets.SECRET_NAME }}`.\n- Prefer **OIDC federation** (`aws-actions\u002Fconfigure-aws-credentials` with `role-to-assume`) over long-lived access keys.\n- Environment secrets with required reviewers add approval gates for production deployments.\n- GitHub automatically masks secrets in logs, but avoid `echo` or `toJSON()` on secret values.\n\n### GitLab CI\n\n- Store secrets as **CI\u002FCD variables** with the `masked` and `protected` flags enabled.\n- Use **HashiCorp Vault integration** (`secrets:vault`) for dynamic secret injection without storing values in GitLab.\n- Scope variables to specific environments (`production`, `staging`) to enforce least privilege.\n\n### Universal Patterns\n\n- **Never echo or print** secret values in pipeline output, even for debugging.\n- **Use short-lived tokens** (OIDC, STS AssumeRole) instead of static credentials wherever possible.\n- **Restrict PR access** — do not expose secrets to pipelines triggered by forks or untrusted branches.\n- **Rotate CI secrets** on the same schedule as application secrets; pipeline credentials are attack vectors too.\n- **Audit pipeline logs** periodically for accidental secret exposure that masking may have missed.\n\n---\n\n## Pre-Commit Secret Detection\n\nCatching secrets before they reach version control is the most cost-effective defense. Two leading tools cover this space.\n\n### gitleaks\n\n```toml\n# .gitleaks.toml — minimal configuration\n[extend]\nuseDefault = true\n\n[[rules]]\nid = \"custom-internal-token\"\ndescription = \"Internal service token pattern\"\nregex = '''INTERNAL_TOKEN_[A-Za-z0-9]{32}'''\nsecretGroup = 0\n```\n\n- Install: `brew install gitleaks` or download from GitHub releases.\n- Pre-commit hook: `gitleaks git --pre-commit --staged`\n- Baseline scanning: `gitleaks detect --source . --report-path gitleaks-report.json`\n- Manage false positives in `.gitleaksignore` (one fingerprint per line).\n\n### detect-secrets\n\n```bash\n# Generate baseline\ndetect-secrets scan --all-files > .secrets.baseline\n\n# Pre-commit hook (via pre-commit framework)\n# .pre-commit-config.yaml\nrepos:\n  - repo: https:\u002F\u002Fgithub.com\u002FYelp\u002Fdetect-secrets\n    rev: v1.5.0\n    hooks:\n      - id: detect-secrets\n        args: ['--baseline', '.secrets.baseline']\n```\n\n- Supports **custom plugins** for organization-specific patterns.\n- Audit workflow: `detect-secrets audit .secrets.baseline` interactively marks true\u002Ffalse positives.\n\n### False Positive Management\n\n- Maintain `.gitleaksignore` or `.secrets.baseline` in version control so the whole team shares exclusions.\n- Review false positive lists during security audits — patterns may mask real leaks over time.\n- Prefer tightening regex patterns over broadly ignoring files.\n\n---\n\n## Audit Logging\n\nKnowing who accessed which secret and when is critical for incident investigation and compliance.\n\n### Cloud-Native Audit Trails\n\n| Provider | Service | What It Captures |\n|----------|---------|-----------------|\n| **AWS** | CloudTrail | Every `GetSecretValue`, `DescribeSecret`, `RotateSecret` API call |\n| **Azure** | Activity Log + Diagnostic Logs | Key Vault access events, including caller identity and IP |\n| **GCP** | Cloud Audit Logs | Data access logs for Secret Manager with principal and timestamp |\n| **Vault** | Audit Backend | Full request\u002Fresponse logging (file, syslog, or socket backend) |\n\n### Alerting Strategy\n\n- Alert on **access from unknown IP ranges** or service accounts outside the expected set.\n- Alert on **bulk secret reads** (more than N secrets accessed within a time window).\n- Alert on **access outside deployment windows** when no CI\u002FCD pipeline is running.\n- Feed audit logs into your SIEM (Splunk, Datadog, Elastic) for correlation with other security events.\n- Review audit logs quarterly as part of access recertification.\n\n---\n\n## Cross-References\n\nThis skill covers env hygiene and secret detection. For deeper coverage of related domains, see:\n\n| Skill | Path | Relationship |\n|-------|------|-------------|\n| **Secrets Vault Manager** | `engineering\u002Fsecrets-vault-manager` | Production vault infrastructure, HA deployment, DR |\n| **Senior SecOps** | `engineering\u002Fsenior-secops` | Security operations perspective, incident response |\n| **CI\u002FCD Pipeline Builder** | `engineering\u002Fci-cd-pipeline-builder` | Pipeline architecture, secret injection patterns |\n| **Infrastructure as Code** | `engineering\u002Finfrastructure-as-code` | Terraform\u002FPulumi secret backend configuration |\n| **Container Orchestration** | `engineering\u002Fcontainer-orchestration` | Kubernetes secret mounting, sealed secrets |\n",{"name":5,"description":7},"main","0b48cbb0e6d5be6ff68c0f6b28bc0c65ee21c4a1","engineering\u002Fenv-secrets-manager",2,"https:\u002F\u002Fgithub.com\u002Fafaizalam2003\u002FMaster-claude-skill","https:\u002F\u002Fgithub.com\u002Fafaizalam2003","https:\u002F\u002Fwww.linkedin.com\u002Fin\u002Fmdfaizalam2003\u002F","2026-04-01 04:35:43",{"source":8,"skillName":5,"commands":38,"prompt":48,"zipAvailable":49},[39,42,45],{"tool":40,"command":41},"npx","npx skills add afaizalam2003\u002FMaster-claude-skill --skill env-secrets-manager",{"tool":43,"command":44},"bunx","bunx skills add afaizalam2003\u002FMaster-claude-skill --skill env-secrets-manager",{"tool":46,"command":47},"pnpm","pnpm dlx skills add afaizalam2003\u002FMaster-claude-skill --skill env-secrets-manager","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fafaizalam2003\u002FMaster-claude-skill\u002Fblob\u002Fmain\u002Fengineering\u002Fenv-secrets-manager\u002FSKILL.md",true,[51,57,61],{"path":52,"resourceType":53,"resourceTypeDesc":54,"sizeBytes":55,"sourceHtmlUrl":56},"references\u002Fsecret-patterns.md","REFERENCE","参考文档",1140,"https:\u002F\u002Fgithub.com\u002Fafaizalam2003\u002FMaster-claude-skill\u002Fblob\u002Fmain\u002Fengineering\u002Fenv-secrets-manager\u002Freferences\u002Fsecret-patterns.md",{"path":58,"resourceType":53,"resourceTypeDesc":54,"sizeBytes":59,"sourceHtmlUrl":60},"references\u002Fvalidation-detection-rotation.md",9457,"https:\u002F\u002Fgithub.com\u002Fafaizalam2003\u002FMaster-claude-skill\u002Fblob\u002Fmain\u002Fengineering\u002Fenv-secrets-manager\u002Freferences\u002Fvalidation-detection-rotation.md",{"path":62,"resourceType":63,"resourceTypeDesc":64,"sizeBytes":65,"sourceHtmlUrl":66},"scripts\u002Fenv_auditor.py","SCRIPT","脚本",4482,"https:\u002F\u002Fgithub.com\u002Fafaizalam2003\u002FMaster-claude-skill\u002Fblob\u002Fmain\u002Fengineering\u002Fenv-secrets-manager\u002Fscripts\u002Fenv_auditor.py",[68,100,125,149,181,201],{"skillNo":69,"name":70,"nameZh":6,"description":71,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":72,"categories":73,"keywords":79,"publishedAt":24},"01M6KC4E8MYR9DBAZTAXHKYMMH","soc2-compliance","Use when the user asks to prepare for SOC 2 audits, map Trust Service Criteria, build control matrices, collect audit evidence, perform gap analysis, or assess SOC 2 Type I vs Type II readiness.","https:\u002F\u002Fgithub.com\u002Fafaizalam2003\u002FMaster-claude-skill\u002Fblob\u002Fmain\u002Fra-qm-team\u002Fsoc2-compliance\u002FSKILL.md",[74],{"categoryNo":75,"categoryName":76,"taxonomyType":77,"taxonomyTypeDesc":78},"01JBSEEDCAT000000000000037","律师与法务","PROFESSION","适用职业",[80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99],"compliance","soc2","soc2 compliance","audit evidence","audit","collect","soc","analysis","use","evidence","trust","build","map","control","type","gap","readiness","gap analysis","assess","for",{"skillNo":101,"name":102,"nameZh":6,"description":103,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":104,"categories":105,"keywords":106,"publishedAt":24},"01M6KC461R3GKGZ1TAYHVR1MW9","risk-management-specialist","Medical device risk management specialist implementing ISO 14971 throughout product lifecycle. Provides risk analysis, risk evaluation, risk control, and post-production information analysis. Use when user mentions risk management, ISO 14971, risk analysis, FMEA, fault tree analysis, hazard identification, risk control, risk matrix, benefit-risk analysis, residual risk, risk acceptability, or post-market risk.","https:\u002F\u002Fgithub.com\u002Fafaizalam2003\u002FMaster-claude-skill\u002Fblob\u002Fmain\u002Fra-qm-team\u002Frisk-management-specialist\u002FSKILL.md",[],[107,108,109,110,111,112,113,114,87,88,115,116,117,118,119,120,121,122,123,124],"risk","risk management specialist","management","risk management","risk evaluation","product","Evaluation","lifecycle","risk matrix","iso","medical","iso 14971","identification","information","post-production","tree","matrix","implementing",{"skillNo":126,"name":127,"nameZh":6,"description":128,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":129,"categories":130,"keywords":131,"publishedAt":24},"01M6KC3HF5ZFSSP2NZF68PEPFB","regulatory-affairs-head","Senior Regulatory Affairs Manager for HealthTech and MedTech companies. Prepares FDA 510(k), De Novo, and PMA submission packages; analyzes regulatory pathways for new medical devices; drafts responses to FDA deficiency letters and Notified Body queries; develops CE marking technical documentation under EU MDR 2017\u002F745; coordinates multi-market approval strategies across FDA, EU, Health Canada, PMDA, and NMPA; and maintains regulatory intelligence on evolving standards. Use when users need to plan or execute FDA submissions, navigate 510(k) or PMA approval processes, achieve CE marking, prepare pre-submission meeting materials, write regulatory strategy documents, respond to agency queries, or manage compliance documentation for medical device market access.","https:\u002F\u002Fgithub.com\u002Fafaizalam2003\u002FMaster-claude-skill\u002Fblob\u002Fmain\u002Fra-qm-team\u002Fregulatory-affairs-head\u002FSKILL.md",[],[132,133,134,135,136,137,138,139,140,88,141,142,143,144,145,146,147,148,23,99],"regulatory affairs head","regulatory","head","documents","devices","health","plan","write","strategy","standards","queries","manage","strategies","de","users","respond","medical devices",{"skillNo":150,"name":151,"nameZh":6,"description":152,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":153,"categories":154,"keywords":163,"publishedAt":24},"01M6KC34Z8M1559EY1CXYBJB1A","quality-manager-qms-iso13485","ISO 13485 Quality Management System implementation and maintenance for medical device organizations. Provides QMS design, documentation control, internal auditing, CAPA management, and certification support. Use when working with medical device quality systems, preparing for ISO 13485 audits, managing regulatory compliance documentation, setting up corrective actions, or building audit preparation programs. Useful for quality management, audit preparation, regulatory compliance, medical device documentation, and corrective action workflows.","https:\u002F\u002Fgithub.com\u002Fafaizalam2003\u002FMaster-claude-skill\u002Fblob\u002Fmain\u002Fra-qm-team\u002Fquality-manager-qms-iso13485\u002FSKILL.md",[155,160],{"categoryNo":156,"categoryName":157,"taxonomyType":158,"taxonomyTypeDesc":159},"01JBSEEDCAT000000000000015","视觉设计","SCENARIO","使用场景",{"categoryNo":161,"categoryName":162,"taxonomyType":77,"taxonomyTypeDesc":78},"01JBSEEDCAT000000000000032","设计师",[164,165,23,166,167,168,169,170,171,88,172,173,174,175,176,177,178,179,99,180],"quality manager qms iso13485","quality","design","workflows","validation","actions","certification","system","maintenance","document","systems","records","ISO 13485","organizations","corrective action","internal audit","preparation",{"skillNo":182,"name":183,"nameZh":6,"description":184,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":185,"categories":186,"keywords":188,"publishedAt":24},"01M6KC2FXHBHXYX2ZZ17Y3GDB4","quality-manager-qmr","Senior Quality Manager Responsible Person (QMR) for HealthTech and MedTech companies. Provides quality system governance, management review leadership, regulatory compliance oversight, and quality performance monitoring per ISO 13485 Clause 5.5.2.","https:\u002F\u002Fgithub.com\u002Fafaizalam2003\u002FMaster-claude-skill\u002Fblob\u002Fmain\u002Fra-qm-team\u002Fquality-manager-qmr\u002FSKILL.md",[187],{"categoryNo":75,"categoryName":76,"taxonomyType":77,"taxonomyTypeDesc":78},[189,165,23,190,191,192,193,194,80,195,171,196,133,197,198,199,116,176,99,200],"quality manager qmr","review","policy","performance","governance","monitoring","regulatory compliance","oversight","cost","culture","leadership","person",{"skillNo":202,"name":203,"nameZh":6,"description":204,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":205,"categories":206,"keywords":214,"publishedAt":24},"01M6KC1VRR5JTDBNZANHPS6VR6","quality-documentation-manager","Document control system management for medical device QMS. Covers document numbering, version control, change management, and 21 CFR Part 11 compliance. Use for document control procedures, change control workflow, document numbering, version management, electronic signature compliance, or regulatory documentation review.","https:\u002F\u002Fgithub.com\u002Fafaizalam2003\u002FMaster-claude-skill\u002Fblob\u002Fmain\u002Fra-qm-team\u002Fquality-documentation-manager\u002FSKILL.md",[207,210,213],{"categoryNo":208,"categoryName":209,"taxonomyType":158,"taxonomyTypeDesc":159},"01JBSEEDCAT000000000000002","文档处理",{"categoryNo":211,"categoryName":212,"taxonomyType":158,"taxonomyTypeDesc":159},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":75,"categoryName":76,"taxonomyType":77,"taxonomyTypeDesc":78},[215,216,165,23,190,217,218,84,171,219,220,221,222,223,117,224,225,226,227,99],"documentation","quality documentation manager","workflow","change","change management","list","master","system management","documentation review","cfr","21 cfr part 11","change control","retention"]