____ __ ______ ____
/ __ \___ ____/ / /_ __/__ ____ _ / __ \____ _ _____ __________
/ /_/ / _ \/ __ / / / / _ \/ __ `/ / /_/ / __ \ | /| / / _ \/ ___/ ___/
/ _, _/ __/ /_/ / / / / __/ /_/ / / ____/ /_/ / |/ |/ / __/ / (__ )
/_/ |_|\___/\__,_/ /_/ \___/\__,_/ /_/ \____/|__/|__/\___/_/ /____/
Structured software work, with less ceremony and better momentum.
RedTeaPowers is a curated skill library for teams that still want engineering discipline, but do not want to pay for it with slow momentum, endless micro-loops, or document sprawl.
It keeps the useful parts of process:
- work shaping before blind execution
- explicit validation choices
- durable documentation with clear purpose
- disciplined execution, review, and completion
It strips out the parts that usually become drag:
- mandatory
specandplanfor every task - one-problem-one-loop behavior
- silent TDD-by-default assumptions
- vague documentation buckets that absorb everything
RedTeaPowers is opinionated in a few important ways:
- Light by default: start with the smallest safe workflow
- Sharp boundaries:
discuss,guide,spec,plan,reference,change,archiveeach do a different job - Evidence first: success claims require fresh verification
- Batch after clarity: once the mainline is open, same-kind follow-up work should move in stronger passes
- Runtime realism: skills should work after distribution, not only inside the source repo
route -> research if facts are missing -> design only if needed -> plan only if needed -> execute -> verify -> finish
Recommended entry points:
using-redteapowersfor top-level workflow routingshaping-workto choose direct execution, session task tracking, plan, orspec + planresearching-and-collectingwhen the next blocker is missing facts, inventory, or comparison workchoosing-test-strategybefore locking in validationmanaging-project-docswhen deciding what artifact should exist
| Area | Skills |
|---|---|
| Routing and shaping | using-redteapowers, shaping-work, researching-and-collecting, brainstorming |
| Planning and execution | writing-plans, executing-plans, subagent-driven-development |
| Validation and debugging | choosing-test-strategy, test-driven-development, systematic-debugging, verification-before-completion |
| Documentation and migration | managing-project-docs, migrating-project-docs |
| Review and branch flow | requesting-code-review, receiving-code-review, using-git-worktrees, finishing-a-development-branch |
This repo is not a rename. It is a reset of the operating defaults.
| Old tendency | RedTeaPowers default |
|---|---|
brainstorm -> spec -> plan -> execute by habit |
route first, then add only the next layer that materially helps |
| heavy convergence up front | small convergence budget with explicit stop rules |
spec and plan as default document outcomes |
broader taxonomy with guide, discuss, reference, change, archive, and scripts, plus session task tracking in TodoWrite / update_plan |
| silent TDD-first behavior | choose validation first, use TDD only when it actually fits |
| one tiny loop per visible issue | batch same-kind low-risk follow-up work |
| first-slice behavior kept too long | open the topic, then stabilize into efficient delivery |
The repo now treats documentation as a deliberate system, not as generic notes.
Key boundaries:
discussis for pre-execution requirement discussionguideis for stage-level development charter or phased development outlinespecis for approved behavior and boundariesplanis for execution sequencingreferenceis for lookup material and durable technical explanationchangeis written after execution and review close
See:
New modules need a sharper opening move than ordinary feature polish.
Use:
- New Module Development Flow
- New Module Spec Template
- Module Design Record Template
- New Module Plan Template
This reflects the current project rule:
- keep requirements in
discussuntil execution is approved - move approved behavior into
spec - place durable design explanation in
referencewhen it would overcrowd the spec - write
planonly after the module shape is stable enough to execute
The current active package includes:
using-redteapowersshaping-workresearching-and-collectingchoosing-test-strategymanaging-project-docsmigrating-project-docsbrainstormingwriting-plansexecuting-planssubagent-driven-developmentsystematic-debuggingverification-before-completionusing-git-worktreesrequesting-code-reviewreceiving-code-reviewfinishing-a-development-branchtest-driven-development
See:
The repo now separates source-library structure from runtime installation shape.
RedTeaPowers/
├─ skills/ # source skill directories
├─ docs/ # repo-level calibration and reference notes
├─ assets/ # shared presentation assets
├─ README.md
├─ README.zh-CN.md
└─ PACKAGE.md
Inside skills/, each subdirectory is one installable skill:
skills/<skill-name>/
├─ SKILL.md
├─ agents/openai.yaml
├─ references/
└─ scripts/
Clone the repository:
git clone git@github.com:LanceAdd/RedTeaPowers.gitInstall RedTeaPowers as one package by copying the included skill directories from skills/ into your Codex skills directory:
~/.codex/skills
The supported installation unit is the active RedTeaPowers package, not a one-off single skill copy.
PACKAGE.md is useful package documentation, but runtime discovery depends on the installed skill folders being present together.
This matters for how the repo is maintained now:
- source skills live under
skills/ - distributed skills are copied as flat sibling directories into the runtime skills folder
- runtime skill behavior must not depend on repository-root files that will not ship with the selected skill directories
In practice:
- keep runtime references inside the skill itself
- or use sibling-skill relative references that still exist after flat distribution
- install the active package together so sibling-skill references remain valid at runtime
If you are moving from an older superpowers setup, start here:
All project documents should be read and written as UTF-8 text.