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.
## 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
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
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
- anything the plan explicitly mandates that the review rubric treats as a
defect (a test that asserts nothing, verbatim duplication of a logic block)
Present everything you find to your human partner as one batched question —
each finding beside the plan text that mandates it, asking which governs —
before execution begins, not one interrupt per discovery mid-plan. If the
scan is clean, proceed without comment. The review loop remains the net for
conflicts that only emerge from implementation.
The scan's output is a table, not a verdict. One row for every pair of tasks
that share a file or an interface: the two tasks, what one produces against
what the other consumes, and what you found. One row for every task: whether
its own text agrees with itself — the tests it specifies against the code it
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