using-bigpowers
One-time bootstrap that introduces the bigpowers skills system, the PMBOK lifecycle arc, and tells you which skill to call first for your situation. Use when starting with bigpowers for the first time, when user asks "where do I start?", or when the skills system needs to be explained.
- License 许可
- MIT
- 最近更新
- 2026-11-10
- Stars
- ★ 289
- Forks
- 24
01 前言 Front Matter
- name
- using-bigpowers
- model
- sonnet
- description
- One-time bootstrap that introduces the bigpowers skills system, the PMBOK lifecycle arc, and tells you which skill to call first for your situation. Use when starting with bigpowers for the first time, when user asks "where do I start?", or when the skills system needs to be explained.
03 SKILL.md 正文
Using bigpowers
HARD GATE — HARD GATE — This skill is the entry point. Do NOT skip it when onboarding new users or starting a new session. It establishes the bigpowers methodology, lifecycle phases, and conventions.
Welcome to bigpowers — a lifecycle of agent skills for production-ready, TDD-driven software by solo developers. The live catalog and its count are generated in SKILL-INDEX.md; never hardcode the number here.
Install
npx bigpowers setup # one-shot setup
npm install -g bigpowers # global install
bigpowers setup # sync skills + link to your tools
From source: git clone → bash scripts/install.sh. Package: bigpowers on npm.
Reach tools: Cline — native AGENTS.md reader (no extension). Aider — opt-in .aider.conf.yml with read: AGENTS.md (Aider-AI/aider). Codex CLI — optional .codex/config.toml via seed-conventions; global ~/.codex/AGENTS.md from install.sh.
What bigpowers is
A curated set of skills organized around the PMBOK developer lifecycle. Each skill does one thing. Skills reference each other by name only — low coupling, high cohesion. All written output goes to specs/ at your project root.
The lifecycle at a glance
See orchestrate-project for the canonical 6-phase lifecycle.
BOOTSTRAP using-bigpowers (this skill, first time only)
↓
DISCOVER survey-context → research-first → elaborate-spec
↓
DESIGN model-domain / define-language / grill-me / deepen-architecture / design-interface
↓
PLAN scope-work → slice-tasks → plan-work / plan-refactor
↓
INITIATE kickoff-branch → guard-git / hook-commits / seed-conventions
↓
SPIKE? spike-prototype → (feeds back to plan-work)
↓
EXECUTE develop-tdd + enforce-first ←→ delegate-task / dispatch-agents / execute-plan
↓
VERIFY run-evals → verify-work
↓
HARDEN wire-observability (any phase)
↓
BUG? investigate-bug → diagnose-root → validate-fix
↓
REVIEW audit-code → request-review → respond-review
↓
INTEGRATE commit-message → release-branch
↓
SUSTAIN inspect-quality / organize-workspace (ongoing)
UTILITY terse-mode / craft-skill / edit-document (any phase)
Where to start
| Your situation | First skill to call |
|---|---|
| Greenfield project, nothing set up | seed-conventions |
| Existing project, new task | survey-context |
| Vague idea that needs shaping | elaborate-spec |
| Plan exists, ready to implement | kickoff-branch → develop-tdd |
| Bug to fix | investigate-bug |
| Code ready for review | audit-code |
| Shipping a feature | commit-message → release-branch |
| Solo dev, PRs feel heavy | Enable profiles/solo-git.md → specs/WORKFLOW-solo-git.md → land via scripts/land-branch.sh |
Solo Git profile
If you work alone and do not want PR ceremony every task:
- Read profiles/solo-git.md.
- Register with
compose-workflow→specs/WORKFLOW-solo-git.md. - Ship with
release-branchin solo-local mode (land-branch.sh), notgh pr create.
You still use worktrees, protected main, and verification gates — only the integrate step changes.
YAML cockpit and dashboard
Operational source of truth:
specs/state.yaml— session, active epic/story, handoffspecs/release-plan.yaml— release index and epic listspecs/epics/eNN-*.yaml— stories and tasks withverifyspecs/execution-status.yaml— done/pending per story
Start the HTTP dashboard with visual-dashboard → GET /api/status?projectDir=<abs> and GET /cockpit.html for a read-only PM view.
Key conventions
- specs/ is your memory. All domain docs, plans, and investigation outputs go in
specs/at your project root. - Integrate: team default is
gh pr(team-pr); solo profile usesland-branch.sh. Never create GitHub issues from skills — use local Markdown files instead. - One skill, one thing. If you're unsure which skill to call, call
survey-context— it reads your current state and recommends the next step. - verify: every step. Every epic task must have
verify: <runnable command>. Evidence over claims. - The full catalog is auto-generated. See
SKILL-INDEX.md; find skills withsearch-skills.
After this
Call survey-context to read your project's current state and get a personalized recommendation for where to go next.
<!-- story: e03s02 -->
04 同仓库更多 Skills
skill-verify-fail-open-fixture
Negative-path fixture for run-skill-verify.sh — must never PASS.
negative-path
暂无简介
write-document
Write, organize, and sync high-integrity technical documents using the BMAD methodology. Ensures every document is Bold, Minimal, Actionable, and Durable. Use when creating architectural docs, technical guides, or organizing the specs/ directory.
wire-observability
Add structured JSON logging, observability commands, and idempotent setup scripts to a project. Use when a project needs production-readiness instrumentation, when user wants structured logging, or as a production-readiness gate at any phase of development.
wire-ci
CI pipeline setup with bundled, forge-neutral templates and local validation. Detects the forge from the git remote, generates workflows for supported forges, and skips honestly for the rest. The CI equivalent of wire-observability.
visual-dashboard
Start a browser-based dashboard that visualizes architecture, implementation plans, and project status. Persists artifacts in .bigpowers/dashboard/. Reads specs/state.yaml, release-plan.yaml, epics, and planning-status via HTTP API or opencode panel.