Run any Skill in Manus with one click

$pwd:

orbitant-12-factor

Name: Orbitant 12 Factor
Author: weorbitant

// Use when checking if a repo follows 12-factor app principles — config stored in env vars (not hardcoded), dependency lockfiles present, CI pipeline separation, structured logging to stdout, or dev/prod environment parity. Activates when someone asks about 12-factor compliance, deployment readiness, or config management practices in a Node.js or Python project. Also trigger when someone notices hardcoded localhost URLs, missing .env.example, or asks "is this deploy-ready?" — even without mentioning 12-factor explicitly.

Run Skill in Manus

$ git log --oneline --stat

stars:3

forks:0

updated:April 28, 2026 at 07:11

File Explorer

2 files

SKILL.md

readonly

name	orbitant-12-factor
description	Use when checking if a repo follows 12-factor app principles — config stored in env vars (not hardcoded), dependency lockfiles present, CI pipeline separation, structured logging to stdout, or dev/prod environment parity. Activates when someone asks about 12-factor compliance, deployment readiness, or config management practices in a Node.js or Python project. Also trigger when someone notices hardcoded localhost URLs, missing .env.example, or asks "is this deploy-ready?" — even without mentioning 12-factor explicitly.
version	0.1.0
license	MIT
metadata	{"author":"orbitant","tags":"engineering, audit, 12-factor, config, deployment, ci, logging"}

Overview

Audits the statically-verifiable subset of 12-factor app compliance. Only factors observable from the repo are scored — runtime factors are listed as "not checked" with an explanation.

When to Use

Assessing deployment readiness of a new project
Checking config management practices (hardcoded URLs, missing .env.example)
Reviewing CI pipeline separation
Running a section audit after /orbitant-engineering:ground-control flagged 12-factor issues

How to Run

Load the reference standards:

@plugins/orbitant-engineering/skills/12-factor/references/12-factor.md

Detect the stack first:

ls package.json requirements.txt pyproject.toml 2>/dev/null

Then run checks for all statically-verifiable factors. Note which factors were skipped and why.

Output Format

## 12-Factor Compliance   {rating}

### Passing
- II. Dependencies: lockfile present (package-lock.json), versions pinned
- V. Build/release/run: CI pipeline defined (.github/workflows/)

### Failing
- III. Config: hardcoded URLs found in source
  Finding: "http://localhost:3000" in src/api/client.js:8
  Recommendation: move to process.env.API_URL, add to .env.example

### Not checked (requires runtime)
- Factors I, IV, VI, VII, VIII, IX, XII
  Reason: not observable from static repo analysis

Rating: ⚠️ Partial

Ratings: ❌ Not compliant / ⚠️ Partial / ✅ Good / 🚀 Fully observable compliance

See references/12-factor.md for full criteria and excluded factors explanation.

related-skills.json

same repository

orbitant-blog-post-create.md

from "weorbitant/orbitant-os"

Content generation skill for the Orbitant engineering blog. Activates when creating a blog post in Spanish from raw input — a Knowledge Sharing transcript, Slack thread, meeting notes, workshop draft, or bullet outline. Produces a structured, SEO-optimised article that matches Orbitant's narrative, tone, and content cluster strategy. Trigger on: "crear blog post", "redactar artículo", "convierte esto en un post", "blog post para Orbitant", "write a blog post", "turn this into an article". Also trigger when the user shares a long transcript, KS notes, or a Slack discussion about a technical decision — even if they don't explicitly say "blog post". When in doubt, ask if they want this turned into a post.

2026-05-223

orbitant-release-notes.md

from "weorbitant/orbitant-os"

Drafts structured, publication-ready release notes from git history. Activates when: creating releases, documenting version changes, drafting changelogs, or preparing release announcements. Use even when user just says "generate changelog", "what changed since last release", "help me write release notes", "prepare a release", or "I bumped the version". Also triggers after version bumps in plugin.json.

2026-05-213

orbitant-goal-alignment.md

from "weorbitant/orbitant-os"

Scores items against quarterly rocks from rocks.yaml. Activates during triage, task ranking, meeting prep, and scheduling. Flags drift when time allocation mismatches stated priorities.

2026-05-123

orbitant-graceful-degradation.md

from "weorbitant/orbitant-os"

Checks MCP servers and config files before any chief-of-staff command. Ensures no command hard-fails — always proceeds with available sources. Auto-activates on every command.

2026-05-123

orbitant-voice-drafting.md

from "weorbitant/orbitant-os"

Writes drafts in the user's voice using voice.md for tone and style. Activates during /triage, /crm, or any "draft an email/message" request. Never sends without confirmation.

2026-05-123

orbitant-debrief.md

from "weorbitant/orbitant-os"

Use at the end of a Claude Code session to capture project-specific friction as proposed CLAUDE.md edits. Triggered by /debrief (no args) to scan the full session, or /debrief <hint> to focus on a specific area (e.g., /debrief the API naming convention thing). Returning "session looks clean" with no proposals is a first-class outcome, not a fallback. Triggers on: "/debrief", "debrief the session", "wrap up this session", "what did we learn", "any rules to capture", "should we update CLAUDE.md".

2026-05-063

package.json

"author": "weorbitant"

"repository": "weorbitant/orbitant-os"

View GitHub Repository View Creator Repositories

$ install --global

$ download --local

Run Skill in Manus

$ useful --forSOC

Software DevelopersComputer and Mathematical Occupations15-1252L4

name	orbitant-12-factor
description	Use when checking if a repo follows 12-factor app principles — config stored in env vars (not hardcoded), dependency lockfiles present, CI pipeline separation, structured logging to stdout, or dev/prod environment parity. Activates when someone asks about 12-factor compliance, deployment readiness, or config management practices in a Node.js or Python project. Also trigger when someone notices hardcoded localhost URLs, missing .env.example, or asks "is this deploy-ready?" — even without mentioning 12-factor explicitly.
version	0.1.0
license	MIT
metadata	{"author":"orbitant","tags":"engineering, audit, 12-factor, config, deployment, ci, logging"}

Overview

Audits the statically-verifiable subset of 12-factor app compliance. Only factors observable from the repo are scored — runtime factors are listed as "not checked" with an explanation.

When to Use

Assessing deployment readiness of a new project
Checking config management practices (hardcoded URLs, missing .env.example)
Reviewing CI pipeline separation
Running a section audit after /orbitant-engineering:ground-control flagged 12-factor issues

How to Run

Load the reference standards:

@plugins/orbitant-engineering/skills/12-factor/references/12-factor.md

Detect the stack first:

ls package.json requirements.txt pyproject.toml 2>/dev/null

Then run checks for all statically-verifiable factors. Note which factors were skipped and why.

Output Format

## 12-Factor Compliance   {rating}

### Passing
- II. Dependencies: lockfile present (package-lock.json), versions pinned
- V. Build/release/run: CI pipeline defined (.github/workflows/)

### Failing
- III. Config: hardcoded URLs found in source
  Finding: "http://localhost:3000" in src/api/client.js:8
  Recommendation: move to process.env.API_URL, add to .env.example

### Not checked (requires runtime)
- Factors I, IV, VI, VII, VIII, IX, XII
  Reason: not observable from static repo analysis

Rating: ⚠️ Partial

Ratings: ❌ Not compliant / ⚠️ Partial / ✅ Good / 🚀 Fully observable compliance

See references/12-factor.md for full criteria and excluded factors explanation.

orbitant-12-factor

Overview

When to Use

How to Run

Output Format

More from this repository

More from this repository

Overview

When to Use

How to Run

Output Format