Compare commits

..

2 Commits

Author SHA1 Message Date
Jesse Vincent
61f669ebc9 fix(sdd): preflight emits its pairwise checks as a ledger table and rules on what it surfaces
The pre-Task-1 conflict scan currently permits 'the scan is clean' with
no evidence the scan happened — mined sessions show controllers skipping
straight to dispatch and plan conflicts surfacing mid-execution as
blocking questions. Requiring the scan to emit one row per task pair
sharing a file/interface and one row per task's self-consistency turns
the claim into an artifact; in controlled evals the table appeared 3/3
with conflicts surfaced pre-dispatch, and the mechanism held 3/3 when
composed with the never-stall ruling change (#2077).

Claude-Session: https://claude.ai/code/session_0185AJr98gHx5EmwqNeft4Sy
2026-08-03 09:03:05 -07:00
Jesse Vincent
bb2a34b2a0 docs: remove the "We're Hiring" section from the README
The community engineer role has a candidate on trial, so the posting no
longer needs to be at the top of the README.
2026-07-27 11:43:14 -07:00
3 changed files with 13 additions and 97 deletions

View File

@@ -3,12 +3,6 @@
Superpowers is a complete software development methodology for your coding agents, built on top of a set of composable skills and some initial instructions that make sure your agent uses them. Superpowers is a complete software development methodology for your coding agents, built on top of a set of composable skills and some initial instructions that make sure your agent uses them.
## We're Hiring!
We're hiring someone to help out full time with Superpowers community and code work.
You can read about the job at https://primeradiant.com/jobs/superpowers-community-engineer/
If this sounds like someone you know, definitely send them our way.
## Quickstart ## Quickstart
Give your agent Superpowers: [Claude Code](#claude-code), [Antigravity](#antigravity), [Codex App](#codex-app), [Codex CLI](#codex-cli), [Cursor](#cursor), [Factory Droid](#factory-droid), [Gemini CLI](#gemini-cli), [GitHub Copilot CLI](#github-copilot-cli), [Kimi Code](#kimi-code), [OpenCode](#opencode), [Pi](#pi). Give your agent Superpowers: [Claude Code](#claude-code), [Antigravity](#antigravity), [Codex App](#codex-app), [Codex CLI](#codex-cli), [Cursor](#cursor), [Factory Droid](#factory-droid), [Gemini CLI](#gemini-cli), [GitHub Copilot CLI](#github-copilot-cli), [Kimi Code](#kimi-code), [OpenCode](#opencode), [Pi](#pi).

View File

@@ -1,85 +0,0 @@
# Releasing to the Codex portal
How to package a Superpowers release as the zip artifact OpenAI's Codex
plugin portal expects, and what to check before handing it over.
This is distinct from the older flow of syncing files into a fork of
`openai/plugins` and opening a PR, which
`scripts/sync-to-codex-plugin.sh` still implements — see the distribution
table in [porting-to-a-new-harness.md](porting-to-a-new-harness.md). The portal
artifact is a standalone, rootless archive: `.codex-plugin/`, `assets/`,
`skills/`, `README.md`, `LICENSE`, and `CODE_OF_CONDUCT.md` sit at the
archive root. Hooks, tests, docs, scripts, and other harnesses' manifests
are deliberately not shipped.
## Prerequisite: the OpenAI metadata source
Each packaged skill must carry `skills/<name>/agents/openai.yaml`. That
metadata is OpenAI-owned — it does not live in this repo — so the packaging
script seeds it from a prior official package. By default it looks for, in
order:
1. `../_tmp/sup-codex-packaging/superpowers/` (an unpacked package)
2. `../_tmp/sup-codex-packaging/superpowers.zip`
3. `../_tmp/sup-codex-packaging/superpowers.tar.gz`
or pass `--metadata-source <dir|.zip|.tar.gz>` explicitly.
If you have no prior package on disk, extract one from `openai/plugins`
(the upstream repo still carries the plugin, including the metadata):
```bash
# from a clone with an `upstream` remote pointing at github.com/openai/plugins
git fetch upstream
mkdir -p ../_tmp/sup-codex-packaging/superpowers
git archive upstream/main -- plugins/superpowers |
tar -x --strip-components 2 -C ../_tmp/sup-codex-packaging/superpowers
```
**New skills fail the build.** The script requires one `openai.yaml` per
skill directory; otherwise it prints `Missing OpenAI agent metadata for
skill: <name>` for each gap and dies with `metadata source is incomplete`.
If a release adds a skill, there is no metadata for it yet;
you need an updated official package (or metadata added upstream in
`openai/plugins`) before you can package. Don't hand-invent the yaml.
## Build the archive
From a clean working tree, package the release tag:
```bash
scripts/package-codex-plugin.sh --ref vX.X.X
```
The script reads the version from `.codex-plugin/plugin.json` (bumped by
`scripts/bump-version.sh`, so it matches the release tag), stages the tree
from the git ref — never from the working copy — and writes
`../_tmp/sup-codex-packaging/superpowers-VERSION.zip`, printing entry
count, skill count, and a SHA-256. Timestamps and file order are pinned so
rebuilding the same ref reproduces the same archive.
Useful flags: `--output PATH`, `--format zip|tar.gz`, `--allow-dirty`
(archive still comes from `--ref`), `--keep-stage` (inspect the staging
dir). `--help` has the full list.
## Verify
The script already refuses archives containing source-only paths and
mismatched metadata counts. Sanity-check the result anyway:
```bash
unzip -Z1 ../_tmp/sup-codex-packaging/superpowers-X.X.X.zip | head
unzip -Z1 ../_tmp/sup-codex-packaging/superpowers-X.X.X.zip | grep -c 'agents/openai.yaml'
unzip -p ../_tmp/sup-codex-packaging/superpowers-X.X.X.zip .codex-plugin/plugin.json | jq -r .version
```
Expect: rootless top-level entries (`.codex-plugin/`, `assets/`,
`skills/`), one `openai.yaml` per skill, and the release version.
The script itself is covered by `tests/codex/test-package-codex-plugin.sh`.
## Upload
Upload the zip through OpenAI's Codex plugin portal. This is a manual step
outside this repo; record the SHA-256 the script printed so the uploaded
artifact can be matched to the build.

View File

@@ -142,17 +142,24 @@ a ledger file, not only in todos.
Read the plan once, note its context and Global Constraints, and create a Read the plan once, note its context and Global Constraints, and create a
todo per task. todo per task.
Before dispatching Task 1, scan the plan once for conflicts: Before dispatching Task 1, scan the plan once for conflicts, writing down
what you checked as you check it:
- tasks that contradict each other or the plan's Global Constraints - tasks that contradict each other or the plan's Global Constraints
- anything the plan explicitly mandates that the review rubric treats as a - anything the plan explicitly mandates that the review rubric treats as a
defect (a test that asserts nothing, verbatim duplication of a logic block) defect (a test that asserts nothing, verbatim duplication of a logic block)
Present everything you find to your human partner as one batched question — The scan's output is a table, not a verdict. One row for every pair of tasks
each finding beside the plan text that mandates it, asking which governs — that share a file or an interface: the two tasks, what one produces against
before execution begins, not one interrupt per discovery mid-plan. If the what the other consumes, and what you found. One row for every task: whether
scan is clean, proceed without comment. The review loop remains the net for its own text agrees with itself — the tests it specifies against the code it
conflicts that only emerge from implementation. specifies, the files it creates against the files it later touches. "The scan
is clean" without those rows is not a scan you ran.
Write the table to the ledger. Rule on each conflict it surfaces — the spec
is the binding authority, the plan is its argument — record the ruling beside
its row, and dispatch Task 1. The review loop remains the net for conflicts
that only emerge from implementation.
## Model Selection ## Model Selection