Token导航 LogoToken导航

Agent Skill · 研究检索

12-factor-apps(12 要素应用程序)

12-factor-apps 用于查找、检索和筛选相关信息,适合在 Codex、Claude、Cursor、Gemini CLI 中需要根据关键词、任务场景或来源线索快速定位候选结果时使用。可结合来源仓库、安装命令和原始 README 继续核验具体用法。安装前建议确认权限范围、维护状态,以及是否会触发联网、命令执行或文件读写。

12-factor-apps 是研究检索类 Agent Skill,可用宿主为 Codex、Claude、Cursor、Gemini CLI,通过GitHub 仓库获取,权限为接触敏感数据;许可证为 MIT,第三方扫描有未通过项,按安装量在研究检索类的 73,675 个 Skill 里排第 38,307。

总安装 1,576周安装 67GitHub Stars 54下载 552核验 2026-05-01

安装说明

本站只整理中文说明,不托管安装包,也不代用户安装。
GitHub
许可证
MIT

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:12-factor-apps(12 要素应用程序)
来源仓库:https://github.com/existential-birds/beagle
仓库路径:skills/12-factor-apps
安装命令:
npx skills add https://github.com/existential-birds/beagle --skill 12-factor-apps
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。不同来源提供的安装方式可能略有差异;本站展示可直接复制的安装命令,安装前请核对来源页面。

skills.shnpx skills
npx skills add https://github.com/existential-birds/beagle --skill 12-factor-apps

这个 Skill 是做什么的

研究检索类 Skill 主要解决「找资料、核对事实、把来源整理清楚」的问题,通常会让助手先检索再总结。

编制执行摘要表 突出优势和关键差距 建议改进的优先顺序 快速参考:合规性评分 分数 含义 行动 强 全面贯彻原则 维护,小幅优化 部分 一些实施,重大差距 计划的改进 弱 很少或没有实施 路线图的高优先级 何时使用此技能 评估新的 SaaS 应用程序 审查云原生架构决策 审核生产应用程序的可扩展性 规划迁移到云平台 比较应用程序架构 准备容器化/Kubernetes 部署 每周安装量 67 存储库 存在主义鸟类/比格犬 GitHub 之星 54 第一次看到 2026 年 1 月 20 日 安全审计 Gen 代理信任中心失败 套接字通行证 斯尼克失败

来源仓库内路径:skills/12-factor-apps

上手步骤

4 步
  1. 1

    确认自己的宿主工具

    公开资料标注支持 Codex、Claude、Cursor、Gemini CLI;先确认自己用的是其中之一,再按对应工具的 Skills 目录放置。

  2. 2

    拿到安装命令

    可以直接复制的命令是 npx skills add https://github.com/existential-birds/beagle --skill 12-factor-app…;命令里的占位符换成自己的路径或密钥再执行。

  3. 3

    安装后重启宿主

    命令执行完要完全退出宿主工具再打开,让新装的 Skill 被重新扫描到,否则列表里可能看不到。

  4. 4

    按最小权限试用

    它需要接触敏感数据,先在测试目录或测试账号里跑,确认没问题再放到正式项目。

常见问题

6 条

12-factor-apps 怎么安装?

在终端执行 npx skills add https://github.com/existential-birds/beagle --skill 12-factor-apps。装完完全退出宿主工具再打开,让它重新扫描本地 Skill。

12-factor-apps 支持哪些 AI 工具?

公开资料标注支持 Codex、Claude、Cursor、Gemini CLI。其他工具只要能读取本地 Skill 目录,一般也能手动放进去,但要自己确认触发方式是否一致。

12-factor-apps 需要什么权限?

权限级别是接触敏感数据。该 Skill 可能接触密钥、Token、环境变量或敏感配置,应进入高风险复核队列,默认不自动发布。

12-factor-apps 是免费的吗?

来源标注的许可证是 MIT。本站不代收任何费用,也不托管安装包;能否商用、要不要署名,以许可证原文为准。

12-factor-apps 用的人多吗?

公开数据是累计安装 1,576 次,近一周安装 67 次,下载 552 次,GitHub 54 星。这些数字来自第三方目录统计,只能当作热度参考,不代表质量或安全性。

12-factor-apps 安全吗?

第三方扫描有未通过项,风险较高。除非你确认过源码,否则不建议直接安装到常用环境。

值得选的地方和要先想清楚的地方

值得选的地方

  • 同时适配 4 种工具,换客户端不用重新找替代品。
  • 3 个目录同时收录,说明这个 Skill 流传比较广。
  • 许可证明确为 MIT,商用和分发边界好判断。

先想清楚的地方

  • 需要接触敏感数据,装到常用环境前要先评估影响面。
  • 第三方扫描存在提醒项或未通过项,需要人工逐条确认。
  • 第三方目录整理,版本更新和行为细节以来源仓库为准。

适不适合你

更适合

  • 已经在用 Codex,想直接扩展它能力的人。
  • 需要处理研究检索类任务、又不想每次都手写提示词的人。

不太适合

  • 环境里有大量密钥、凭证,不方便给第三方 Skill 读取的人。
  • 需要厂商级技术支持和 SLA 的生产系统。

研究检索类 Skill 对比

6 个同类
Skill总安装GitHub 星权限许可证扫描
find-skills

寻找技能 · Codex、Claude

31,199,81316,486操作浏览器MIT有提醒
self-improving-agent

自我改进 Agent · OpenClaw

16,464,0023,396接触敏感数据MIT-0通过
soultrace

灵魂追踪 · Codex、Claude

7,588,94412需要联网未明确有提醒
self-improving

自我完善 · OpenClaw

6,829,2841,046需要联网MIT-0通过
microsoft-foundry

微软代工厂 · Codex、Claude

6,614,144764调用外部服务未明确有提醒
12-factor-apps

12 要素应用程序 · 本页

1,57654接触敏感数据MIT未通过

按安装量取同分类前几名;数字来自第三方目录统计,只作热度参考,不代表质量结论。

SKILL.md 原文

12-Factor App Compliance Analysis

Reference: The Twelve-Factor App

Overview

The 12-Factor App methodology is a set of best practices for building Software-as-a-Service applications that are:

  • Portable across execution environments
  • Scalable without architectural changes
  • Suitable for continuous deployment
  • Maintainable with minimal friction

Input Parameters

ParameterDescriptionRequired
codebase_pathRoot path of the codebase to analyzeRequired

Analysis Framework

Factor I: Codebase

Principle: One codebase tracked in revision control, many deploys.

Search Patterns:

# Check for version control
ls -la .git 2>/dev/null || ls -la .hg 2>/dev/null

# Check for multiple apps sharing codebase
find . -name "package.json" -o -name "pyproject.toml" -o -name "setup.py" | head -20

# Check for environment-specific code branches
grep -r "if.*production\|if.*development\|if.*staging" --include="*.py" --include="*.js" --include="*.ts"

File Patterns: .git/, package.json, pyproject.toml, deployment configs

Compliance Criteria:

LevelCriteria
StrongSingle Git repo, same codebase for all environments, no env-specific code branches
PartialSingle repo but some environment-specific code paths
WeakMultiple repos for same app or significant code duplication across environments

Anti-patterns:

  • Multiple Git repositories for the same application
  • Environment-specific code branches (if production:...)
  • Different source files for dev vs prod
  • Shared code not extracted to libraries

Factor II: Dependencies

Principle: Explicitly declare and isolate dependencies.

Search Patterns:

# Python dependency files
find . -name "requirements.txt" -o -name "pyproject.toml" -o -name "setup.py" -o -name "Pipfile" -o -name "uv.lock"

# JavaScript/TypeScript dependency files
find . -name "package.json" -o -name "package-lock.json" -o -name "yarn.lock" -o -name "pnpm-lock.yaml"

# Check for system tool assumptions
grep -r "subprocess.*curl\|subprocess.*wget\|os.system.*ffmpeg\|shutil.which" --include="*.py"
grep -r "exec.*curl\|child_process.*curl" --include="*.js" --include="*.ts"

# Docker/container isolation
find . -name "Dockerfile" -o -name "docker-compose*.yml"

File Patterns: **/requirements*.txt, **/package.json, **/*.lock, **/Dockerfile

Compliance Criteria:

LevelCriteria
StrongLock files present, dependency isolation (venv/Docker), no implicit system tools
PartialDependencies declared but no lock files or isolation
WeakDependencies in documentation only, relies on system-installed packages

Anti-patterns:

  • Missing lock files (non-deterministic builds)
  • Assuming system tools (curl, ImageMagick, ffmpeg) are available
  • Different dependency managers in dev vs production
  • No virtual environment or container isolation

Factor III: Config

Principle: Store config in the environment.

Search Patterns:

# Environment variable usage
grep -r "os.environ\|os.getenv\|process.env\|ENV\[" --include="*.py" --include="*.js" --include="*.ts" --include="*.rb"

# Hardcoded credentials (anti-pattern)
grep -r "password.*=.*['\"]" --include="*.py" --include="*.js" --include="*.ts" | grep -v "test\|spec\|example"
grep -r "api_key.*=.*['\"]" --include="*.py" --include="*.js" --include="*.ts" | grep -v "test\|spec\|example"
grep -r "secret.*=.*['\"]" --include="*.py" --include="*.js" --include="*.ts" | grep -v "test\|spec\|example"

# Environment-specific config files (anti-pattern)
find . -name "config.dev.*" -o -name "config.prod.*" -o -name "settings.development.*" -o -name "settings.production.*"

# Database URLs in code
grep -r "postgresql://\|mysql://\|mongodb://\|redis://" --include="*.py" --include="*.js" --include="*.ts" | grep -v ".env\|test\|example"

File Patterns: **/.env*, **/config/*.py, **/settings.py, environment files

Compliance Criteria:

LevelCriteria
StrongAll config via environment variables, no hardcoded secrets, could open-source without leaks
PartialMost config externalized but some hardcoded defaults
WeakHardcoded credentials, environment-specific config files

Anti-patterns:

  • Hardcoded database URLs, API keys, passwords in source
  • Config files like config/production.yml vs config/development.yml
  • Environment grouping (if ENV == 'production':...)
  • Secrets committed to version control

Factor IV: Backing Services

Principle: Treat backing services as attached resources.

Search Patterns:

# Database connection via config
grep -r "DATABASE_URL\|DB_HOST\|REDIS_URL\|CACHE_URL" --include="*.py" --include="*.js" --include="*.ts"

# Service initialization
grep -r "create_engine\|MongoClient\|Redis\|Celery\|boto3" --include="*.py"
grep -r "createPool\|createClient\|new Redis\|S3Client" --include="*.js" --include="*.ts"

# Hardcoded service locations (anti-pattern)
grep -r "localhost:5432\|localhost:6379\|localhost:27017\|127.0.0.1" --include="*.py" --include="*.js" --include="*.ts" | grep -v "test\|spec\|example\|default"

File Patterns: **/database/*.py, **/services/*.py, **/db.py, connection configurations

Compliance Criteria:

LevelCriteria
StrongAll services via URL/connection string in config, swappable without code changes
PartialMost services configurable but some hardcoded defaults
WeakHardcoded service locations, different code paths per environment

Anti-patterns:

  • Hardcoded localhost for services in production code
  • Conditional logic for local vs cloud services (if USE_S3:... else: local_storage)
  • Service-specific code paths based on environment
  • Different drivers for dev vs prod

Factor V: Build, Release, Run

Principle: Strictly separate build and run stages.

Search Patterns:

# Build/deploy configuration
find . -name "Dockerfile" -o -name "Makefile" -o -name "build.sh" -o -name "deploy.sh"
find . -name ".github/workflows/*.yml" -o -name ".gitlab-ci.yml" -o -name "Jenkinsfile"

# Build scripts in package.json
grep -A5 '"scripts"' package.json 2>/dev/null | grep -E "build|start|deploy"

# Check for runtime compilation (anti-pattern)
grep -r "compile\|transpile\|webpack" --include="*.py" | grep -v "test\|build"

File Patterns: **/Dockerfile, **/Makefile, **/.github/workflows/**, CI/CD configs

Compliance Criteria:

LevelCriteria
StrongImmutable releases, clear build/release/run stages, unique release IDs
PartialBuild and run separated but release not immutable
WeakRuntime code modifications, asset compilation at startup

Anti-patterns:

  • Runtime code modifications
  • Asset compilation during application startup
  • Configuration baked into build artifacts
  • No release versioning

Factor VI: Processes

Principle: Execute the app as one or more stateless processes.

Search Patterns:

# Session storage patterns
grep -r "session\|Session" --include="*.py" --include="*.js" --include="*.ts" | head -20

# In-process state (anti-pattern)
grep -r "global.*cache\|process_local\|instance_cache" --include="*.py"
grep -r "global\..*=\|module\.exports\.cache" --include="*.js" --include="*.ts"

# External session stores (good pattern)
grep -r "redis.*session\|memcached.*session\|session.*redis" --include="*.py" --include="*.js" --include="*.ts"

# Sticky session configuration (anti-pattern)
grep -r "sticky.*session\|session.*affinity" --include="*.yml" --include="*.yaml" --include="*.json"

File Patterns: **/middleware/*.py, **/session/*.py, server configurations

Compliance Criteria:

LevelCriteria
StrongStateless processes, all state in external datastores (Redis, DB)
PartialMostly stateless but some in-process caching
WeakSticky sessions, in-process session storage, shared memory state

Anti-patterns:

  • In-process session storage (user_sessions = {})
  • Sticky sessions or session affinity
  • File-based caching between requests
  • Global mutable state shared across requests

Factor VII: Port Binding

Principle: Export services via port binding.

Search Patterns:

# Self-contained port binding
grep -r "app.run\|server.listen\|serve\|uvicorn" --include="*.py"
grep -r "app.listen\|server.listen\|createServer" --include="*.js" --include="*.ts"

# PORT environment variable
grep -r "PORT\|port" --include="*.py" --include="*.js" --include="*.ts" | grep -i "environ\|process.env"

# Webserver as dependency
grep -r "uvicorn\|gunicorn\|flask\|fastapi\|express\|koa\|hapi" package.json pyproject.toml requirements.txt 2>/dev/null

File Patterns: **/main.py, **/server.py, **/app.py, **/index.js

Compliance Criteria:

LevelCriteria
StrongSelf-contained app binds to PORT, webserver is a dependency
PartialPort binding but not configurable via environment
WeakRelies on external webserver container (Apache, Nginx) to provide HTTP

Anti-patterns:

  • Relying on Apache/Nginx/Tomcat to inject webserver functionality
  • Hardcoded port numbers
  • No PORT environment variable support
  • CGI scripts or server modules

Factor VIII: Concurrency

Principle: Scale out via the process model.

Search Patterns:

# Process definitions
find . -name "Procfile" -o -name "process.yml" -o -name ".foreman"

# Multiple entry points
find . -name "worker.py" -o -name "scheduler.py" -o -name "web.py"

# Background job systems
grep -r "celery\|rq\|sidekiq\|bull\|agenda" --include="*.py" --include="*.js" --include="*.ts"
grep -r "Celery\|Worker\|BackgroundJob" --include="*.py" --include="*.js" --include="*.ts"

File Patterns: **/Procfile, **/worker.py, **/scheduler.py, queue configurations

Compliance Criteria:

LevelCriteria
StrongExplicit process types (web, worker, scheduler), horizontal scaling
PartialMultiple process types but not easily scalable
WeakSingle monolithic process, no separation of concerns

Anti-patterns:

  • Single process handling all workloads
  • Hard-coded worker counts in code
  • No separation between web and background processes
  • Vertical scaling only (bigger server, not more processes)

Factor IX: Disposability

Principle: Maximize robustness with fast startup and graceful shutdown.

Search Patterns:

# Signal handlers
grep -r "signal.signal\|SIGTERM\|SIGINT\|atexit" --include="*.py"
grep -r "process.on.*SIGTERM\|process.on.*SIGINT" --include="*.js" --include="*.ts"

# Graceful shutdown
grep -r "graceful.*shutdown\|shutdown_handler\|cleanup" --include="*.py" --include="*.js" --include="*.ts"

# Startup time
grep -r "startup\|initialize\|bootstrap" --include="*.py" --include="*.js" --include="*.ts" | head -20

File Patterns: **/main.py, **/server.py, lifecycle management code

Compliance Criteria:

LevelCriteria
StrongFast startup (<10s), SIGTERM handling, graceful shutdown, jobs returnable to queue
PartialGraceful shutdown but slow startup
WeakNo signal handling, jobs lost on process death, slow startup

Anti-patterns:

  • No SIGTERM/SIGINT handlers
  • Slow startup (>30 seconds)
  • Jobs lost if process crashes
  • No cleanup on shutdown

Factor X: Dev/Prod Parity

Principle: Keep development, staging, and production as similar as possible.

Search Patterns:

# Different services per environment (anti-pattern)
grep -r "if.*development.*sqlite\|if.*production.*postgres" --include="*.py" --include="*.js" --include="*.ts"
grep -r "development.*SQLite\|production.*PostgreSQL" --include="*.py" --include="*.js" --include="*.ts"

# Docker for parity
find . -name "docker-compose*.yml" -o -name "Dockerfile"

# Environment-specific backends
grep -r "USE_LOCAL_\|LOCAL_STORAGE\|MOCK_" --include="*.py" --include="*.js" --include="*.ts"

File Patterns: **/docker-compose*.yml, environment configurations

Compliance Criteria:

LevelCriteria
StrongSame services everywhere (PostgreSQL in dev and prod), containerized
PartialMostly same but some lightweight dev alternatives
WeakSQLite in dev, PostgreSQL in prod; different backing services

Anti-patterns:

  • SQLite for development, PostgreSQL for production
  • In-memory cache in dev, Redis in prod
  • Different service versions across environments
  • "It works on my machine" issues

Factor XI: Logs

Principle: Treat logs as event streams.

Search Patterns:

# Stdout logging
grep -r "print(\|logging.info\|logger.info\|console.log" --include="*.py" --include="*.js" --include="*.ts" | head -20

# File-based logging (anti-pattern)
grep -r "FileHandler\|open.*\.log\|writeFile.*log\|fs.appendFile.*log" --include="*.py" --include="*.js" --include="*.ts"
grep -r "/var/log\|/tmp/.*\.log\|logs/" --include="*.py" --include="*.js" --include="*.ts" | grep -v "test\|example"

# Structured logging
grep -r "structlog\|json_logger\|pino\|winston" --include="*.py" --include="*.js" --include="*.ts"

File Patterns: **/logging.py, **/logger.py, logging configurations

Compliance Criteria:

LevelCriteria
StrongUnbuffered stdout only, structured logging (JSON), no file management
PartialStdout logging but with some file handlers
WeakApplication writes to log files, manages rotation

Anti-patterns:

  • Writing logs to files (FileHandler, open('/var/log/app.log'))
  • Log rotation logic in application code
  • Log archival managed by application
  • Buffered logging

Factor XII: Admin Processes

Principle: Run admin/management tasks as one-off processes.

Search Patterns:

# Management commands
find . -name "manage.py" -o -name "Rakefile" -o -name "artisan"
grep -r "@cli.command\|@click.command\|typer.command" --include="*.py"

# Migration scripts
find . -name "migrations" -type d
find . -name "*migration*.py" -o -name "*migrate*.py"

# Admin scripts with proper isolation
grep -r "bundle exec\|source.*venv\|uv run" --include="*.sh" --include="Makefile"

File Patterns: **/manage.py, **/cli.py, **/migrations/**, admin scripts

Compliance Criteria:

LevelCriteria
StrongAdmin tasks use same dependencies/config, proper isolation, idempotent
PartialAdmin tasks exist but different setup from app
WeakManual database manipulation, scripts without isolation

Anti-patterns:

  • Admin scripts not using app's dependency manager
  • Direct SQL manipulation outside of migrations
  • Admin scripts with hardcoded credentials
  • Non-idempotent migrations

Output Format

Executive Summary Table

| Factor | Status | Notes |
|--------|--------|-------|
| I. Codebase | **Strong/Partial/Weak** | [Key finding] |
| II. Dependencies | **Strong/Partial/Weak** | [Key finding] |
| III. Config | **Strong/Partial/Weak** | [Key finding] |
| IV. Backing Services | **Strong/Partial/Weak** | [Key finding] |
| V. Build/Release/Run | **Strong/Partial/Weak** | [Key finding] |
| VI. Processes | **Strong/Partial/Weak** | [Key finding] |
| VII. Port Binding | **Strong/Partial/Weak** | [Key finding] |
| VIII. Concurrency | **Strong/Partial/Weak** | [Key finding] |
| IX. Disposability | **Strong/Partial/Weak** | [Key finding] |
| X. Dev/Prod Parity | **Strong/Partial/Weak** | [Key finding] |
| XI. Logs | **Strong/Partial/Weak** | [Key finding] |
| XII. Admin Processes | **Strong/Partial/Weak** | [Key finding] |

**Overall**: X Strong, Y Partial, Z Weak

Per-Factor Analysis

For each factor, provide:

  1. Current Implementation

- Evidence with file:line references - Code snippets showing patterns

  1. Compliance Level

- Strong/Partial/Weak with justification

  1. Gaps

- What's missing vs. 12-Factor ideal

  1. Recommendations

- Actionable improvements with code examples


Analysis Workflow

  1. Initial Scan

- Run search patterns for all factors - Identify key files for each factor - Note any existing compliance documentation

  1. Deep Dive (per factor)

- Read identified files - Evaluate against compliance criteria - Document evidence with file paths

  1. Gap Analysis

- Compare current vs. 12-Factor ideal - Identify anti-patterns present - Prioritize by impact

  1. Recommendations

- Provide actionable improvements - Include before/after code examples - Reference best practices

  1. Summary

- Compile executive summary table - Highlight strengths and critical gaps - Suggest priority order for improvements


Quick Reference: Compliance Scoring

ScoreMeaningAction
StrongFully implements principleMaintain, minor optimizations
PartialSome implementation, significant gapsPlanned improvements
WeakMinimal or no implementationHigh priority for roadmap

When to Use This Skill

  • Evaluating new SaaS applications
  • Reviewing cloud-native architecture decisions
  • Auditing production applications for scalability
  • Planning migration to cloud platforms
  • Comparing application architectures
  • Preparing for containerization/Kubernetes deployment

平台分布

Claude Code

27.21%
按下载量换算150

Gemini CLI

23.44%
按下载量换算129

Antigravity

17.39%
按下载量换算96

OpenCode

10.83%
按下载量换算60

Codex

6.86%
按下载量换算38

Cursor

3.07%
按下载量换算17

安全审计

Gen Agent Trust Hub

未通过

Socket

通过

Snyk

未通过

权限和风险

接触敏感数据

该 Skill 可能接触密钥、Token、环境变量或敏感配置,应进入高风险复核队列,默认不自动发布。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。来源安全扫描存在提醒或未通过项,安装前请自行复核。

继续浏览同类 Skills