csh
/
playbook
1
1
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

📦 deps(skills): sync superpowers
Update Third-party Superpowers / Update thirdparty/skill snapshot (push) Successful in 1m25s Details

This commit is contained in:
ci[bot] 2026-03-17 08:54:00 +00:00
parent 84bcefab73
commit a56d75be38
9 changed files with 89 additions and 56 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
codex/skills/brainstorming/SKILL.md
View File

@ -27,7 +27,7 @@ You MUST create a task for each of these items and complete them in order:
4. **Propose 2-3 approaches** — with trade-offs and your recommendation 4. **Propose 2-3 approaches** — with trade-offs and your recommendation
5. **Present design** — in sections scaled to their complexity, get user approval after each section 5. **Present design** — in sections scaled to their complexity, get user approval after each section
6. **Write design doc** — save to `docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md` and commit 6. **Write design doc** — save to `docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md` and commit
7. **Spec review loop** — dispatch spec-document-reviewer subagent with precisely crafted review context (never your session history); fix issues and re-dispatch until approved (max 5 iterations, then surface to human) 7. **Spec review loop** — dispatch spec-document-reviewer subagent with precisely crafted review context (never your session history); fix issues and re-dispatch until approved (max 3 iterations, then surface to human)
8. **User reviews written spec** — ask user to review the spec file before proceeding 8. **User reviews written spec** — ask user to review the spec file before proceeding
9. **Transition to implementation** — invoke writing-plans skill to create implementation plan 9. **Transition to implementation** — invoke writing-plans skill to create implementation plan
@ -121,7 +121,7 @@ After writing the spec document:
1. Dispatch spec-document-reviewer subagent (see spec-document-reviewer-prompt.md) 1. Dispatch spec-document-reviewer subagent (see spec-document-reviewer-prompt.md)
2. If Issues Found: fix, re-dispatch, repeat until Approved 2. If Issues Found: fix, re-dispatch, repeat until Approved
3. If loop exceeds 5 iterations, surface to human for guidance 3. If loop exceeds 3 iterations, surface to human for guidance
**User Review Gate:** **User Review Gate:**
After the spec review loop passes, ask the user to review the written spec before proceeding: After the spec review loop passes, ask the user to review the written spec before proceeding:

2
codex/skills/brainstorming/scripts/server.js
View File

@ -94,7 +94,7 @@ const WAITING_PAGE = `<!DOCTYPE html>
h1 { color: #333; } p { color: #666; }</style> h1 { color: #333; } p { color: #666; }</style>
</head> </head>
<body><h1>Brainstorm Companion</h1> <body><h1>Brainstorm Companion</h1>
<p>Waiting for Claude to push a screen...</p></body></html>`; <p>Waiting for the agent to push a screen...</p></body></html>`;
const frameTemplate = fs.readFileSync(path.join(__dirname, 'frame-template.html'), 'utf-8'); const frameTemplate = fs.readFileSync(path.join(__dirname, 'frame-template.html'), 'utf-8');
const helperScript = fs.readFileSync(path.join(__dirname, 'helper.js'), 'utf-8'); const helperScript = fs.readFileSync(path.join(__dirname, 'helper.js'), 'utf-8');

12
codex/skills/brainstorming/scripts/start-server.sh
View File

@ -1,4 +1,4 @@
#!/bin/bash #!/usr/bin/env bash
# Start the brainstorm server and output connection info # Start the brainstorm server and output connection info
# Usage: start-server.sh [--project-dir <path>] [--host <bind-host>] [--url-host <display-host>] [--foreground] [--background] # Usage: start-server.sh [--project-dir <path>] [--host <bind-host>] [--url-host <display-host>] [--foreground] [--background]
# #
@ -64,6 +64,16 @@ if [[ -n "${CODEX_CI:-}" && "$FOREGROUND" != "true" && "$FORCE_BACKGROUND" != "t
FOREGROUND="true" FOREGROUND="true"
fi fi
# Windows/Git Bash reaps nohup background processes. Auto-foreground when detected.
if [[ "$FOREGROUND" != "true" && "$FORCE_BACKGROUND" != "true" ]]; then
case "${OSTYPE:-}" in
msys*|cygwin*|mingw*) FOREGROUND="true" ;;
esac
if [[ -n "${MSYSTEM:-}" ]]; then
FOREGROUND="true"
fi
fi
# Generate unique session directory # Generate unique session directory
SESSION_ID="$$-$(date +%s)" SESSION_ID="$$-$(date +%s)"

28
codex/skills/brainstorming/scripts/stop-server.sh
View File

@ -1,4 +1,4 @@
#!/bin/bash #!/usr/bin/env bash
# Stop the brainstorm server and clean up # Stop the brainstorm server and clean up
# Usage: stop-server.sh <screen_dir> # Usage: stop-server.sh <screen_dir>
# #
@ -17,7 +17,31 @@ PID_FILE="${SCREEN_DIR}/.server.pid"
if [[ -f "$PID_FILE" ]]; then if [[ -f "$PID_FILE" ]]; then
pid=$(cat "$PID_FILE") pid=$(cat "$PID_FILE")
kill "$pid" 2>/dev/null
# Try to stop gracefully, fallback to force if still alive
kill "$pid" 2>/dev/null || true
# Wait for graceful shutdown (up to ~2s)
for i in {1..20}; do
if ! kill -0 "$pid" 2>/dev/null; then
break
fi
sleep 0.1
done
# If still running, escalate to SIGKILL
if kill -0 "$pid" 2>/dev/null; then
kill -9 "$pid" 2>/dev/null || true
# Give SIGKILL a moment to take effect
sleep 0.1
fi
if kill -0 "$pid" 2>/dev/null; then
echo '{"status": "failed", "error": "process still running"}'
exit 1
fi
rm -f "$PID_FILE" "${SCREEN_DIR}/.server.log" rm -f "$PID_FILE" "${SCREEN_DIR}/.server.log"
# Only delete ephemeral /tmp directories # Only delete ephemeral /tmp directories

27
codex/skills/brainstorming/spec-document-reviewer-prompt.md
View File

@ -19,32 +19,31 @@ Task tool (general-purpose):
| Category | What to Look For | | Category | What to Look For |
|----------|------------------| |----------|------------------|
| Completeness | TODOs, placeholders, "TBD", incomplete sections | | Completeness | TODOs, placeholders, "TBD", incomplete sections |
| Coverage | Missing error handling, edge cases, integration points |
| Consistency | Internal contradictions, conflicting requirements | | Consistency | Internal contradictions, conflicting requirements |
| Clarity | Ambiguous requirements | | Clarity | Requirements ambiguous enough to cause someone to build the wrong thing |
| YAGNI | Unrequested features, over-engineering |
| Scope | Focused enough for a single plan — not covering multiple independent subsystems | | Scope | Focused enough for a single plan — not covering multiple independent subsystems |
| Architecture | Units with clear boundaries, well-defined interfaces, independently understandable and testable | | YAGNI | Unrequested features, over-engineering |
## CRITICAL ## Calibration
Look especially hard for: **Only flag issues that would cause real problems during implementation planning.**
- Any TODO markers or placeholder text A missing section, a contradiction, or a requirement so ambiguous it could be
- Sections saying "to be defined later" or "will spec when X is done" interpreted two different ways — those are issues. Minor wording improvements,
- Sections noticeably less detailed than others stylistic preferences, and "sections less detailed than others" are not.
- Units that lack clear boundaries or interfaces — can you understand what each unit does without reading its internals?
Approve unless there are serious gaps that would lead to a flawed plan.
## Output Format ## Output Format
## Spec Review ## Spec Review
**Status:** ✅ Approved | ❌ Issues Found **Status:** Approved | Issues Found
**Issues (if any):** **Issues (if any):**
- [Section X]: [specific issue] - [why it matters] - [Section X]: [specific issue] - [why it matters for planning]
**Recommendations (advisory):** **Recommendations (advisory, do not block approval):**
- [suggestions that don't block approval] - [suggestions for improvement]
``` ```
**Reviewer returns:** Status, Issues (if any), Recommendations **Reviewer returns:** Status, Issues (if any), Recommendations

8
codex/skills/brainstorming/visual-companion.md
View File

@ -61,6 +61,14 @@ scripts/start-server.sh --project-dir /path/to/project
scripts/start-server.sh --project-dir /path/to/project scripts/start-server.sh --project-dir /path/to/project
``` ```
**Windows (Git Bash / CMD / PowerShell):**
```bash
# Windows/Git Bash reaps nohup background processes. The script auto-detects
# this via OSTYPE/MSYSTEM and switches to foreground mode automatically.
# No extra flags needed — all Windows shells route through Git Bash.
scripts/start-server.sh --project-dir /path/to/project
```
**Gemini CLI:** **Gemini CLI:**
```bash ```bash
# Use --foreground and set is_background: true on your shell tool call # Use --foreground and set is_background: true on your shell tool call

4
codex/skills/using-superpowers/references/codex-tools.md
View File

@ -13,13 +13,13 @@ Skills use Claude Code tool names. When you encounter these in a skill, use your
| `Read`, `Write`, `Edit` (files) | Use your native file tools | | `Read`, `Write`, `Edit` (files) | Use your native file tools |
| `Bash` (run commands) | Use your native shell tools | | `Bash` (run commands) | Use your native shell tools |
## Subagent dispatch requires collab ## Subagent dispatch requires multi-agent support
Add to your Codex config (`~/.codex/config.toml`): Add to your Codex config (`~/.codex/config.toml`):
```toml ```toml
[features] [features]
collab = true multi_agent = true
``` ```
This enables `spawn_agent`, `wait`, and `close_agent` for skills like `dispatching-parallel-agents` and `subagent-driven-development`. This enables `spawn_agent`, `wait`, and `close_agent` for skills like `dispatching-parallel-agents` and `subagent-driven-development`.

19
codex/skills/writing-plans/SKILL.md
View File

@ -112,22 +112,17 @@ git commit -m "feat: add specific feature"
## Plan Review Loop ## Plan Review Loop
After completing each chunk of the plan: After writing the complete plan:
1. Dispatch plan-document-reviewer subagent (see plan-document-reviewer-prompt.md) with precisely crafted review context — never your session history. This keeps the reviewer focused on the plan, not your thought process. 1. Dispatch a single plan-document-reviewer subagent (see plan-document-reviewer-prompt.md) with precisely crafted review context — never your session history. This keeps the reviewer focused on the plan, not your thought process.
- Provide: chunk content, path to spec document - Provide: path to the plan document, path to spec document
2. If ❌ Issues Found: 2. If ❌ Issues Found: fix the issues, re-dispatch reviewer for the whole plan
- Fix the issues in the chunk 3. If ✅ Approved: proceed to execution handoff
- Re-dispatch reviewer for that chunk
- Repeat until ✅ Approved
3. If ✅ Approved: proceed to next chunk (or execution handoff if last chunk)
**Chunk boundaries:** Use `## Chunk N: <name>` headings to delimit chunks. Each chunk should be ≤1000 lines and logically self-contained.
**Review loop guidance:** **Review loop guidance:**
- Same agent that wrote the plan fixes it (preserves context) - Same agent that wrote the plan fixes it (preserves context)
- If loop exceeds 5 iterations, surface to human for guidance - If loop exceeds 3 iterations, surface to human for guidance
- Reviewers are advisory - explain disagreements if you believe feedback is incorrect - Reviewers are advisory — explain disagreements if you believe feedback is incorrect
## Execution Handoff ## Execution Handoff

41
codex/skills/writing-plans/plan-document-reviewer-prompt.md
View File

@ -2,17 +2,17 @@
Use this template when dispatching a plan document reviewer subagent. Use this template when dispatching a plan document reviewer subagent.
**Purpose:** Verify the plan chunk is complete, matches the spec, and has proper task decomposition. **Purpose:** Verify the plan is complete, matches the spec, and has proper task decomposition.
**Dispatch after:** Each plan chunk is written **Dispatch after:** The complete plan is written.
``` ```
Task tool (general-purpose): Task tool (general-purpose):
description: "Review plan chunk N" description: "Review plan document"
prompt: | prompt: |
You are a plan document reviewer. Verify this plan chunk is complete and ready for implementation. You are a plan document reviewer. Verify this plan is complete and ready for implementation.
**Plan chunk to review:** [PLAN_FILE_PATH] - Chunk N only **Plan to review:** [PLAN_FILE_PATH]
**Spec for reference:** [SPEC_FILE_PATH] **Spec for reference:** [SPEC_FILE_PATH]
## What to Check ## What to Check
@ -20,33 +20,30 @@ Task tool (general-purpose):
| Category | What to Look For | | Category | What to Look For |
|----------|------------------| |----------|------------------|
| Completeness | TODOs, placeholders, incomplete tasks, missing steps | | Completeness | TODOs, placeholders, incomplete tasks, missing steps |
| Spec Alignment | Chunk covers relevant spec requirements, no scope creep | | Spec Alignment | Plan covers spec requirements, no major scope creep |
| Task Decomposition | Tasks atomic, clear boundaries, steps actionable | | Task Decomposition | Tasks have clear boundaries, steps are actionable |
| File Structure | Files have clear single responsibilities, split by responsibility not layer | | Buildability | Could an engineer follow this plan without getting stuck? |
| File Size | Would any new or modified file likely grow large enough to be hard to reason about as a whole? |
| Task Syntax | Checkbox syntax (`- [ ]`) on steps for tracking |
| Chunk Size | Each chunk under 1000 lines |
## CRITICAL ## Calibration
Look especially hard for: **Only flag issues that would cause real problems during implementation.**
- Any TODO markers or placeholder text An implementer building the wrong thing or getting stuck is an issue.
- Steps that say "similar to X" without actual content Minor wording, stylistic preferences, and "nice to have" suggestions are not.
- Incomplete task definitions
- Missing verification steps or expected outputs Approve unless there are serious gaps — missing requirements from the spec,
- Files planned to hold multiple responsibilities or likely to grow unwieldy contradictory steps, placeholder content, or tasks so vague they can't be acted on.
## Output Format ## Output Format
## Plan Review - Chunk N ## Plan Review
**Status:** Approved | Issues Found **Status:** Approved | Issues Found
**Issues (if any):** **Issues (if any):**
- [Task X, Step Y]: [specific issue] - [why it matters] - [Task X, Step Y]: [specific issue] - [why it matters for implementation]
**Recommendations (advisory):** **Recommendations (advisory, do not block approval):**
- [suggestions that don't block approval] - [suggestions for improvement]
``` ```
**Reviewer returns:** Status, Issues (if any), Recommendations **Reviewer returns:** Status, Issues (if any), Recommendations