Token导航 LogoToken导航TokenDH.com
研究检索敏感数据github未标认证来源可访问clear审计异常

12-factor-apps12 要素应用程序

Agent Skill

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

总安装

1,576

周安装

67

GitHub Stars

54

下载量

552
CodexClaudeCursorGemini CLI

安装说明

本站只整理中文说明和来源信息,不托管安装包,也不代用户安装。

GitHub

来源数

3

许可证

MIT

最后核验

2026-05-01

来源状态

来源可访问

安装方式

通过对话安装

复制提示词发给支持本地命令或 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

简介

编制执行摘要表

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

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

适合场景

01

用户想查找某类 Agent Skill 时

02

需要根据任务场景推荐可安装能力包时

03

需要对比不同来源的安装命令和来源信息时

04

需要参考平台分布和安装热度时

能力概览

能力 1

按任务关键词查找相关 Skills

能力 2

展示可复制的安装命令

能力 3

保留来源站点、仓库和原始说明,方便继续核验

能力 4

补充不同宿主或平台的使用分布数据

能力 5

展示第三方安全扫描或审计结果

安装后应在对应宿主中按原始 README 的触发条件使用;具体调用方式请以来源页面和 README 为准。

平台分布

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、环境变量或敏感配置,应进入高风险复核队列,默认不自动发布。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。来源安全扫描存在 warning/failed 结果,不能写成本站确认安全。

来源信息

继续浏览同类 Skills