mirror of
https://github.com/obra/superpowers.git
synced 2026-09-05 13:15:37 +00:00
Compare commits
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
a45ede8ddc |
@@ -9,7 +9,7 @@
|
|||||||
{
|
{
|
||||||
"name": "superpowers",
|
"name": "superpowers",
|
||||||
"description": "Core skills library for Claude Code: TDD, debugging, collaboration patterns, and proven techniques",
|
"description": "Core skills library for Claude Code: TDD, debugging, collaboration patterns, and proven techniques",
|
||||||
"version": "6.3.0",
|
"version": "6.2.0",
|
||||||
"source": "./",
|
"source": "./",
|
||||||
"author": {
|
"author": {
|
||||||
"name": "Jesse Vincent",
|
"name": "Jesse Vincent",
|
||||||
|
|||||||
@@ -1,7 +1,7 @@
|
|||||||
{
|
{
|
||||||
"name": "superpowers",
|
"name": "superpowers",
|
||||||
"description": "Core skills library for Claude Code: TDD, debugging, collaboration patterns, and proven techniques",
|
"description": "Core skills library for Claude Code: TDD, debugging, collaboration patterns, and proven techniques",
|
||||||
"version": "6.3.0",
|
"version": "6.2.0",
|
||||||
"author": {
|
"author": {
|
||||||
"name": "Jesse Vincent",
|
"name": "Jesse Vincent",
|
||||||
"email": "jesse@fsck.com"
|
"email": "jesse@fsck.com"
|
||||||
|
|||||||
@@ -1,6 +1,6 @@
|
|||||||
{
|
{
|
||||||
"name": "superpowers",
|
"name": "superpowers",
|
||||||
"version": "6.3.0",
|
"version": "6.2.0",
|
||||||
"description": "An agentic skills framework & software development methodology that works: planning, TDD, debugging, and collaboration workflows.",
|
"description": "An agentic skills framework & software development methodology that works: planning, TDD, debugging, and collaboration workflows.",
|
||||||
"author": {
|
"author": {
|
||||||
"name": "Jesse Vincent",
|
"name": "Jesse Vincent",
|
||||||
|
|||||||
@@ -2,7 +2,7 @@
|
|||||||
"name": "superpowers",
|
"name": "superpowers",
|
||||||
"displayName": "Superpowers",
|
"displayName": "Superpowers",
|
||||||
"description": "Core skills library: TDD, debugging, collaboration patterns, and proven techniques",
|
"description": "Core skills library: TDD, debugging, collaboration patterns, and proven techniques",
|
||||||
"version": "6.3.0",
|
"version": "6.2.0",
|
||||||
"author": {
|
"author": {
|
||||||
"name": "Jesse Vincent",
|
"name": "Jesse Vincent",
|
||||||
"email": "jesse@fsck.com"
|
"email": "jesse@fsck.com"
|
||||||
|
|||||||
@@ -1,6 +1,6 @@
|
|||||||
{
|
{
|
||||||
"name": "superpowers",
|
"name": "superpowers",
|
||||||
"version": "6.3.0",
|
"version": "6.2.0",
|
||||||
"description": "An agentic skills framework & software development methodology that works: planning, TDD, debugging, and collaboration workflows.",
|
"description": "An agentic skills framework & software development methodology that works: planning, TDD, debugging, and collaboration workflows.",
|
||||||
"author": {
|
"author": {
|
||||||
"name": "Jesse Vincent",
|
"name": "Jesse Vincent",
|
||||||
|
|||||||
@@ -1,5 +1,5 @@
|
|||||||
name: superpowers
|
name: superpowers
|
||||||
version: 6.3.0
|
version: 6.2.0
|
||||||
description: Superpowers skills and workflow bootstrap for Hermes Agent
|
description: Superpowers skills and workflow bootstrap for Hermes Agent
|
||||||
author: obra
|
author: obra
|
||||||
provides_hooks:
|
provides_hooks:
|
||||||
|
|||||||
@@ -1,6 +1,6 @@
|
|||||||
{
|
{
|
||||||
"name": "superpowers",
|
"name": "superpowers",
|
||||||
"version": "6.3.0",
|
"version": "6.2.0",
|
||||||
"description": "An agentic skills framework and software development methodology.",
|
"description": "An agentic skills framework and software development methodology.",
|
||||||
"author": {
|
"author": {
|
||||||
"name": "Jesse Vincent",
|
"name": "Jesse Vincent",
|
||||||
|
|||||||
+107
-109
@@ -1,130 +1,128 @@
|
|||||||
# Prime Radiant Community Code of Conduct
|
# Contributor Covenant Code of Conduct
|
||||||
|
|
||||||
## Our Pledge
|
## Our Pledge
|
||||||
|
|
||||||
We pledge to make our community welcoming, safe, and equitable for all.
|
We as members, contributors, and leaders pledge to make participation in our
|
||||||
|
community a harassment-free experience for everyone, regardless of age, body
|
||||||
|
size, visible or invisible disability, ethnicity, sex characteristics, gender
|
||||||
|
identity and expression, level of experience, education, socio-economic status,
|
||||||
|
nationality, personal appearance, race, religion, or sexual identity
|
||||||
|
and orientation.
|
||||||
|
|
||||||
We are committed to fostering an environment that respects and promotes the dignity, rights, and contributions of all individuals, regardless of characteristics including race, ethnicity, caste, color, age, physical characteristics, neurodiversity, disability, sex or gender, gender identity or expression, sexual orientation, language, philosophy or religion, national or social origin, socio-economic position, level of education, or other status. The same privileges of participation are extended to everyone who participates in good faith and in accordance with this Covenant.
|
We pledge to act and interact in ways that contribute to an open, welcoming,
|
||||||
|
diverse, inclusive, and healthy community.
|
||||||
|
|
||||||
The guidelines within and enforcement of the Prime Radiant Community Code of Conduct apply equally to everyone participating in the Prime Radiant community, including members of the Prime Radiant team.
|
## Our Standards
|
||||||
|
|
||||||
## Encouraged Behaviors
|
Examples of behavior that contributes to a positive environment for our
|
||||||
|
community include:
|
||||||
|
|
||||||
While acknowledging differences in social norms, we all strive to meet our community's expectations for positive behavior. We also understand that our words and actions may be interpreted differently than we intend based on culture, background, or native language.
|
* Demonstrating empathy and kindness toward other people
|
||||||
|
* Being respectful of differing opinions, viewpoints, and experiences
|
||||||
|
* Giving and gracefully accepting constructive feedback
|
||||||
|
* Accepting responsibility and apologizing to those affected by our mistakes,
|
||||||
|
and learning from the experience
|
||||||
|
* Focusing on what is best not just for us as individuals, but for the
|
||||||
|
overall community
|
||||||
|
|
||||||
With these considerations in mind, we agree to behave mindfully toward each other and act in ways that center our shared values, including:
|
Examples of unacceptable behavior include:
|
||||||
|
|
||||||
1. Respecting the **purpose of our community**, our activities, and our ways of gathering.
|
* The use of sexualized language or imagery, and sexual attention or
|
||||||
2. Engaging **kindly and honestly** with others.
|
advances of any kind
|
||||||
3. Respecting **different viewpoints** and experiences.
|
* Trolling, insulting or derogatory comments, and personal or political attacks
|
||||||
4. **Taking responsibility** for our actions and contributions.
|
* Public or private harassment
|
||||||
5. Gracefully giving and accepting **constructive feedback**.
|
* Publishing others' private information, such as a physical or email
|
||||||
6. Committing to **repairing harm** when it occurs.
|
address, without their explicit permission
|
||||||
7. Behaving in other ways that promote and sustain the **well-being of our community**.
|
* Other conduct which could reasonably be considered inappropriate in a
|
||||||
|
professional setting
|
||||||
|
|
||||||
## Restricted Behaviors
|
## Enforcement Responsibilities
|
||||||
|
|
||||||
We agree to restrict the following behaviors in our community. Instances, threats, and promotion of these behaviors are violations of this Code of Conduct.
|
Community leaders are responsible for clarifying and enforcing our standards of
|
||||||
|
acceptable behavior and will take appropriate and fair corrective action in
|
||||||
|
response to any behavior that they deem inappropriate, threatening, offensive,
|
||||||
|
or harmful.
|
||||||
|
|
||||||
1. **Harassment.** Violating explicitly expressed boundaries or engaging in unnecessary personal attention after any clear request to stop.
|
Community leaders have the right and responsibility to remove, edit, or reject
|
||||||
2. **Character attacks.** Making insulting, demeaning, or pejorative comments directed at a community member or group of people.
|
comments, commits, code, wiki edits, issues, and other contributions that are
|
||||||
3. **Inciting conflict.** Deliberately engaging in discussions meant to cause arguments or a hostile environment.
|
not aligned to this Code of Conduct, and will communicate reasons for moderation
|
||||||
4. **Stereotyping or discrimination.** Characterizing anyone’s personality or behavior on the basis of immutable identities or traits.
|
decisions when appropriate.
|
||||||
5. **Sexualization.** Behaving in a way that would generally be considered inappropriately intimate in the context or purpose of the community.
|
|
||||||
6. **Violating confidentiality.** Sharing or acting on someone's personal or private information without their permission.
|
|
||||||
7. **Endangerment.** Causing, encouraging, or threatening violence or other harm toward any person or group.
|
|
||||||
8. Behaving in other ways that **threaten the well-being** of our community.
|
|
||||||
|
|
||||||
### Other Restrictions
|
|
||||||
|
|
||||||
1. **Divisive topics.** Discussing inflammatory topics that are unrelated to the community as a whole.
|
|
||||||
2. **Offensive content.** Any text or image that is offensive or violates any of the other restricted behaviors, including as part of a username, profile, status, avatar, or other publicly displayed identifier.
|
|
||||||
3. **Misleading identity.** Impersonating someone else for any reason, misrepresenting yourself as associated with Prime Radiant or any company, or pretending to be someone else to evade enforcement actions.
|
|
||||||
4. **Failing to credit sources.** Not properly crediting the sources of content you contribute, or representing work created by someone else as your own.
|
|
||||||
5. **Advertising and promotional materials.** Sharing marketing or other commercial content, invite links, or irrelevant self-promotion, as well as buying, trading, or asking for donations.
|
|
||||||
6. **Spam posts.** Spamming, including, but not limited to, posting a flood of messages in a short period of time, irrelevant content, or excessive links.
|
|
||||||
7. **Unsolicited mentions and direct messages.** Engaging in harassment by excessively mentioning someone by username or replying, or direct messaging someone without explicit invitation.
|
|
||||||
8. **Irresponsible communication.** Failing to responsibly present content which includes, links, or describes any other restricted behaviors.
|
|
||||||
9. Other conduct that could reasonably be considered **unprofessional** or **inappropriate**.
|
|
||||||
|
|
||||||
## Reporting an Issue
|
|
||||||
|
|
||||||
Tensions can occur between community members even when they are trying their best to collaborate. Not every conflict represents a code of conduct violation, and this Code of Conduct reinforces encouraged behaviors and norms that can help avoid conflicts and minimize harm. You are welcome to report concerns, even if they seem minor, as they can be helpful in identifying patterns of behavior that may not be concerning in isolation, but when viewed collectively may be more significant.
|
|
||||||
|
|
||||||
When an incident does occur, it is important to report it promptly. To report a possible violation anywhere in the community, email [conduct@primeradiant.com](mailto:conduct@primeradiant.com). On the Prime Radiant Discord server, you can mention `@moderators` in a public channel, or report via a support ticket, created through the `#support-ticket` channel. In the event that you need to report a member of the Prime Radiant team, you can contact Kattni at [kattni@primeradiant.com](mailto:kattni@primeradiant.com) or Drew at [drew@primeradiant.com](mailto:drew@primeradiant.com).
|
|
||||||
|
|
||||||
Community Moderators take reports of violations seriously and will make every effort to respond in a timely manner. They will investigate all reports of code of conduct violations, reviewing messages, logs, and recordings, or interviewing witnesses and other participants. Community Moderators will keep investigation and enforcement actions as transparent as possible while prioritizing safety and confidentiality. In order to honor these values, enforcement actions are carried out in private with the involved parties, but communicating to the whole community may be part of a mutually agreed upon resolution. If moderators determine that a public statement needs to be made, the identities of all victims and reporters will remain confidential unless those individuals instruct otherwise.
|
|
||||||
|
|
||||||
In your report, please include:
|
|
||||||
|
|
||||||
- **Your contact info** so the team can get in touch with you if they need to follow up.
|
|
||||||
- **Names (real, nicknames, or pseudonyms) of any individuals involved.** If there were other witnesses besides you, please try to include them as well.
|
|
||||||
- **When and where the incident occurred.** Please be as specific as possible.
|
|
||||||
- **Your account of what occurred.** If there is a publicly available record (e.g. a Discord or GitHub message) please include a link.
|
|
||||||
- **Any extra context** you believe existed for the incident.
|
|
||||||
- **If you believe this incident is ongoing.**
|
|
||||||
- **If you believe any member of the team has a conflict of interest** in adjudicating the incident.
|
|
||||||
- **What, if any, corrective response** you believe would be appropriate.
|
|
||||||
- **Any other information** you believe the team should have.
|
|
||||||
|
|
||||||
Moderators are obligated to maintain confidentiality with regard to the reporter and details of an incident.
|
|
||||||
|
|
||||||
## Report Followup
|
|
||||||
|
|
||||||
You will receive a response acknowledging receipt of your report within 24 business hours.
|
|
||||||
|
|
||||||
If a member of the team is one of the named parties, they will not be included in any discussions, and will not be provided with any confidential details from the reporter.
|
|
||||||
|
|
||||||
If anyone on the moderation team believes they have a conflict of interest in adjudicating on a reported issue, they will inform the other team members, and recuse themselves from any discussion about the issue. Following this declaration, they will not be provided with any confidential details from the reporter.
|
|
||||||
|
|
||||||
The team will immediately review the incident and determine:
|
|
||||||
|
|
||||||
- What happened.
|
|
||||||
- Whether this event constitutes a code of conduct violation.
|
|
||||||
- Who the reported person is.
|
|
||||||
- Whether this is an ongoing situation, or if there is a threat to anyone's physical safety.
|
|
||||||
|
|
||||||
If this is determined to be an ongoing incident or a threat to physical safety, the team's immediate priority will be to protect everyone involved. This means they may delay an official response until they believe that the situation has concluded and that everyone is physically safe.
|
|
||||||
|
|
||||||
The moderation team will respond within one week to the person who filed the report with either a resolution or an explanation of why the situation is not yet resolved.
|
|
||||||
|
|
||||||
Once the team has determined their final action, they'll contact the reporter to let them know what action (if any) they'll be taking. They'll take into account feedback from the reporter on the appropriateness of the response, but do not guarantee they'll act on it.
|
|
||||||
|
|
||||||
Finally, to maintain transparency in the reporting and enforcement process, whenever possible, a public transparency report of the incident will be made. A public report may not be made if the specifics of the incident do not allow the team to preserve anonymity, or if there is potential for ongoing harm.
|
|
||||||
|
|
||||||
## Addressing and Repairing Harm
|
|
||||||
|
|
||||||
If an investigation by the Community Moderators finds that this Code of Conduct has been violated, the following enforcement ladder may be used to determine how best to repair harm, based on the incident's impact on the individuals involved and the community as a whole. Depending on the severity of a violation, lower rungs on the ladder may be skipped.
|
|
||||||
|
|
||||||
1) Warning
|
|
||||||
1) Event: A violation involving a single incident or series of incidents.
|
|
||||||
2) Consequence: A private, written warning from the Community Moderators.
|
|
||||||
3) Repair: Examples of repair include a private written apology, acknowledgement of responsibility, and seeking clarification on expectations.
|
|
||||||
2) Temporarily Limited Activities
|
|
||||||
1) Event: A repeated incidence of a violation that previously resulted in a warning, or the first incidence of a more serious violation.
|
|
||||||
2) Consequence: A private, written warning with a time-limited cooldown period designed to underscore the seriousness of the situation and give the community members involved time to process the incident. The cooldown period may be limited to particular communication channels or interactions with particular community members.
|
|
||||||
3) Repair: Examples of repair may include making an apology, using the cooldown period to reflect on actions and impact, and being thoughtful about re-entering community spaces after the period is over.
|
|
||||||
3) Temporary Suspension
|
|
||||||
1) Event: A pattern of repeated violation which the Community Moderators have tried to address with warnings, or a single serious violation.
|
|
||||||
2) Consequence: A private written warning with conditions for return from suspension. In general, temporary suspensions give the person being suspended time to reflect upon their behavior and possible corrective actions.
|
|
||||||
3) Repair: Examples of repair include respecting the spirit of the suspension, meeting the specified conditions for return, and being thoughtful about how to reintegrate with the community when the suspension is lifted.
|
|
||||||
4) Permanent Ban
|
|
||||||
1) Event: A pattern of repeated code of conduct violations that other steps on the ladder have failed to resolve, or a violation so serious that the Community Moderators determine there is no way to keep the community safe with this person as a member.
|
|
||||||
2) Consequence: Access to all community spaces, tools, and communication channels is removed. In general, permanent bans should be rarely used, should have strong reasoning behind them, and should only be resorted to if working through other remedies has failed to change the behavior.
|
|
||||||
3) Repair: There is no possible repair in cases of this severity.
|
|
||||||
|
|
||||||
This enforcement ladder is intended as a guideline. It does not limit the ability of Community Managers to use their discretion and judgment, in keeping with the best interests of our community.
|
|
||||||
|
|
||||||
## Scope
|
## Scope
|
||||||
|
|
||||||
This Code of Conduct applies within all community spaces, including GitHub and the Prime Radiant Discord server. It also applies when an individual is officially representing the community in public or other spaces. Examples of representing the community include using an official email address, posting via an official social media account, or acting as an appointed representative at an online or offline event.
|
This Code of Conduct applies within all community spaces, and also applies when
|
||||||
|
an individual is officially representing the community in public spaces.
|
||||||
|
Examples of representing our community include using an official e-mail address,
|
||||||
|
posting via an official social media account, or acting as an appointed
|
||||||
|
representative at an online or offline event.
|
||||||
|
|
||||||
Behavior outside of official Prime Radiant spaces may also be considered as supporting evidence for a report if that behavior establishes a pattern, or represents a potential risk to the Prime Radiant community.
|
## Enforcement
|
||||||
|
|
||||||
|
Instances of abusive, harassing, or otherwise unacceptable behavior may be
|
||||||
|
reported to the community leaders responsible for enforcement at
|
||||||
|
jesse@primeradiant.com.
|
||||||
|
All complaints will be reviewed and investigated promptly and fairly.
|
||||||
|
|
||||||
|
All community leaders are obligated to respect the privacy and security of the
|
||||||
|
reporter of any incident.
|
||||||
|
|
||||||
|
## Enforcement Guidelines
|
||||||
|
|
||||||
|
Community leaders will follow these Community Impact Guidelines in determining
|
||||||
|
the consequences for any action they deem in violation of this Code of Conduct:
|
||||||
|
|
||||||
|
### 1. Correction
|
||||||
|
|
||||||
|
**Community Impact**: Use of inappropriate language or other behavior deemed
|
||||||
|
unprofessional or unwelcome in the community.
|
||||||
|
|
||||||
|
**Consequence**: A private, written warning from community leaders, providing
|
||||||
|
clarity around the nature of the violation and an explanation of why the
|
||||||
|
behavior was inappropriate. A public apology may be requested.
|
||||||
|
|
||||||
|
### 2. Warning
|
||||||
|
|
||||||
|
**Community Impact**: A violation through a single incident or series
|
||||||
|
of actions.
|
||||||
|
|
||||||
|
**Consequence**: A warning with consequences for continued behavior. No
|
||||||
|
interaction with the people involved, including unsolicited interaction with
|
||||||
|
those enforcing the Code of Conduct, for a specified period of time. This
|
||||||
|
includes avoiding interactions in community spaces as well as external channels
|
||||||
|
like social media. Violating these terms may lead to a temporary or
|
||||||
|
permanent ban.
|
||||||
|
|
||||||
|
### 3. Temporary Ban
|
||||||
|
|
||||||
|
**Community Impact**: A serious violation of community standards, including
|
||||||
|
sustained inappropriate behavior.
|
||||||
|
|
||||||
|
**Consequence**: A temporary ban from any sort of interaction or public
|
||||||
|
communication with the community for a specified period of time. No public or
|
||||||
|
private interaction with the people involved, including unsolicited interaction
|
||||||
|
with those enforcing the Code of Conduct, is allowed during this period.
|
||||||
|
Violating these terms may lead to a permanent ban.
|
||||||
|
|
||||||
|
### 4. Permanent Ban
|
||||||
|
|
||||||
|
**Community Impact**: Demonstrating a pattern of violation of community
|
||||||
|
standards, including sustained inappropriate behavior, harassment of an
|
||||||
|
individual, or aggression toward or disparagement of classes of individuals.
|
||||||
|
|
||||||
|
**Consequence**: A permanent ban from any sort of public interaction within
|
||||||
|
the community.
|
||||||
|
|
||||||
## Attribution
|
## Attribution
|
||||||
|
|
||||||
This Code of Conduct is adapted from the Contributor Covenant, version 3.0, permanently available at [https://www.contributor-covenant.org/version/3/0/](https://www.contributor-covenant.org/version/3/0/).
|
This Code of Conduct is adapted from the [Contributor Covenant][homepage],
|
||||||
|
version 2.0, available at
|
||||||
|
https://www.contributor-covenant.org/version/2/0/code_of_conduct.html.
|
||||||
|
|
||||||
Contributor Covenant is stewarded by the Organization for Ethical Source and licensed under CC BY-SA 4.0. To view a copy of this license, visit [https://creativecommons.org/licenses/by-sa/4.0/](https://creativecommons.org/licenses/by-sa/4.0/)
|
Community Impact Guidelines were inspired by [Mozilla's code of conduct
|
||||||
|
enforcement ladder](https://github.com/mozilla/diversity).
|
||||||
|
|
||||||
For answers to common questions about Contributor Covenant, see the FAQ at [https://www.contributor-covenant.org/faq](https://www.contributor-covenant.org/faq). Translations are provided at [https://www.contributor-covenant.org/translations](https://www.contributor-covenant.org/translations). Additional enforcement and community guideline resources can be found at [https://www.contributor-covenant.org/resources](https://www.contributor-covenant.org/resources). The enforcement ladder was inspired by the work of [Mozilla’s code of conduct team](https://github.com/mozilla/inclusion).
|
[homepage]: https://www.contributor-covenant.org
|
||||||
|
|
||||||
|
For answers to common questions about this code of conduct, see the FAQ at
|
||||||
|
https://www.contributor-covenant.org/faq. Translations are available at
|
||||||
|
https://www.contributor-covenant.org/translations.
|
||||||
|
|||||||
@@ -1,44 +1,5 @@
|
|||||||
# Superpowers Release Notes
|
# Superpowers Release Notes
|
||||||
|
|
||||||
## v6.3.0 (2026-08-12)
|
|
||||||
|
|
||||||
### Harness Support
|
|
||||||
|
|
||||||
- **Devin CLI**: `devin plugins install obra/superpowers` now works, and skills auto-trigger at session start. (#1995)
|
|
||||||
- **Hermes Agent**: install from a git clone; skills register with Hermes' native loader and the bootstrap loads on the first turn. (#1922, #2025)
|
|
||||||
- **Grok Build CLI** added to the install docs. (#1919)
|
|
||||||
|
|
||||||
### Brainstorming
|
|
||||||
|
|
||||||
- **Ceremony now scales to the task.** Requests are classified as spike, bounded, or architectural; small tasks skip the two-document ritual. Every path still stops for your approval before implementation. (#2063)
|
|
||||||
|
|
||||||
### Subagent-Driven Development
|
|
||||||
|
|
||||||
- **Controllers no longer stall on plan conflicts.** Non-catastrophic conflicts and ambiguities get a recorded ruling and work continues; only destructive or irreversible actions still stop for a human. One donated session had sat blocked for almost nine hours on a question the controller could have decided. (#2077)
|
|
||||||
- **The pre-dispatch conflict scan records its checks in the ledger** instead of just asserting the plan is clean. (#2080)
|
|
||||||
- **Small same-shape tasks batch into one dispatch**, cutting subagent cost sharply on micro-task plans; batch reviews verify every file in the brief made it into the diff. (#2078)
|
|
||||||
- **Implementers and reviewers may not spawn their own subagents**, which was producing duplicate reviews. (#2059)
|
|
||||||
- **Plans carry a `Spec:` pointer** and SDD reads the spec at setup, so plan conflicts get resolved against the design instead of guessed at. (#2086)
|
|
||||||
- Reviewers re-read evidence they find illegible instead of re-running the test suite (#2089), and circuit-breaker rulings now show up in the Finish report.
|
|
||||||
|
|
||||||
### Codex
|
|
||||||
|
|
||||||
- Subagent waits are event-driven instead of poll-heavy, spawns pin model and reasoning effort explicitly, and the multi-agent reference is corrected against Codex source. (#2060, #2061, #2062)
|
|
||||||
|
|
||||||
### Finishing a Development Branch
|
|
||||||
|
|
||||||
- **Worktree removal no longer destroys untracked files.** When `git worktree remove` refuses because the tree holds uncommitted work, the skill stops, names the files, and asks — instead of reaching for `--force`. (#2016, #1223, #2024)
|
|
||||||
|
|
||||||
### Fixes
|
|
||||||
|
|
||||||
- `render-graphs.js` in writing-skills works on Windows.
|
|
||||||
- Corrected Copilot CLI backgrounding guidance for Windows. (#1929, #2006)
|
|
||||||
- `bump-version.sh` covers the Hermes manifest.
|
|
||||||
|
|
||||||
### Documentation
|
|
||||||
|
|
||||||
- README: added a table of contents and reorganized Getting Started.
|
|
||||||
|
|
||||||
## v6.2.0 (2026-07-23)
|
## v6.2.0 (2026-07-23)
|
||||||
|
|
||||||
### Subagent-Driven Development
|
### Subagent-Driven Development
|
||||||
|
|||||||
@@ -1,6 +1,6 @@
|
|||||||
{
|
{
|
||||||
"name": "superpowers",
|
"name": "superpowers",
|
||||||
"description": "Core skills library: TDD, debugging, collaboration patterns, and proven techniques",
|
"description": "Core skills library: TDD, debugging, collaboration patterns, and proven techniques",
|
||||||
"version": "6.3.0",
|
"version": "6.2.0",
|
||||||
"contextFileName": "GEMINI.md"
|
"contextFileName": "GEMINI.md"
|
||||||
}
|
}
|
||||||
|
|||||||
+1
-1
@@ -1,6 +1,6 @@
|
|||||||
{
|
{
|
||||||
"name": "superpowers",
|
"name": "superpowers",
|
||||||
"version": "6.3.0",
|
"version": "6.2.0",
|
||||||
"description": "Superpowers skills and runtime bootstrap for coding agents",
|
"description": "Superpowers skills and runtime bootstrap for coding agents",
|
||||||
"type": "module",
|
"type": "module",
|
||||||
"main": ".opencode/plugins/superpowers.js",
|
"main": ".opencode/plugins/superpowers.js",
|
||||||
|
|||||||
@@ -11,48 +11,12 @@ Start by classifying how much process the request needs, then work
|
|||||||
through your path: understand the context, refine the idea, present a
|
through your path: understand the context, refine the idea, present a
|
||||||
design, and get your human partner's approval.
|
design, and get your human partner's approval.
|
||||||
|
|
||||||
## Establish Shared Understanding
|
|
||||||
|
|
||||||
The outcome of brainstorming is an understanding your human partner can
|
|
||||||
recognize and correct, grounded in what they want to accomplish.
|
|
||||||
|
|
||||||
1. **Discover intent.** Use the request and available context to identify
|
|
||||||
the intended outcome, who it is for, and what success looks like. When
|
|
||||||
that information is missing, ask one focused question about purpose or
|
|
||||||
intended use before proposing features or an approach. Knowing the app
|
|
||||||
genre does not tell you why your partner wants it. Gathering missing
|
|
||||||
requirements does not ask them to authorize the task again.
|
|
||||||
2. **Write back your understanding.** Summarize the intended outcome,
|
|
||||||
relevant constraints, and success criteria in a short note your partner
|
|
||||||
can assess. Separate what they said from assumptions. Invite correction
|
|
||||||
and incorporate their answer before treating this as the design brief.
|
|
||||||
3. **Carry intent into the design.** Preserve the agreed understanding in
|
|
||||||
the selected path's design artifact: the written spec for architectural
|
|
||||||
work, or the in-chat design/probe for bounded work and spikes. Check
|
|
||||||
proposed features and technical choices against that understanding.
|
|
||||||
|
|
||||||
When the request already supplies the purpose and constraints, reflect
|
|
||||||
that understanding instead of asking the same questions again. Keep the
|
|
||||||
note concise; its accuracy and the opportunity to correct it matter.
|
|
||||||
|
|
||||||
<HARD-GATE>
|
<HARD-GATE>
|
||||||
Before taking any implementation action, including invoking an
|
Do NOT invoke any implementation skill, write any code, scaffold any
|
||||||
implementation skill, writing product code, scaffolding, installing
|
project, or take any implementation action until you have told your
|
||||||
product dependencies, or creating an external project, complete the
|
human partner what you intend and they have approved it. This applies
|
||||||
selected path's prerequisites:
|
to EVERY task on EVERY path below — the ceremony scales with the task;
|
||||||
|
the approval gate never does.
|
||||||
- Spike: the human partner approves the question and probe.
|
|
||||||
- Bounded: the human partner approves the short in-chat design.
|
|
||||||
- Architectural: the human partner reviews and approves the written spec,
|
|
||||||
then reviews the written implementation plan and selects its execution
|
|
||||||
method. Conversational design approval only permits writing the spec;
|
|
||||||
written-spec approval only permits invoking writing-plans.
|
|
||||||
|
|
||||||
A reply approves the stage actually presented. Approval of an idea or
|
|
||||||
feature scope does not approve artifacts that do not exist yet. Resume
|
|
||||||
at the earliest incomplete stage; do not turn one approval into permission
|
|
||||||
to skip the rest of the selected path. Read-only project exploration is
|
|
||||||
allowed while those prerequisites remain incomplete.
|
|
||||||
</HARD-GATE>
|
</HARD-GATE>
|
||||||
|
|
||||||
## Three Paths
|
## Three Paths
|
||||||
@@ -89,17 +53,18 @@ stop, say so, and step up. Nothing downgrades mid-task.
|
|||||||
|
|
||||||
## Anti-Pattern: "Too Simple To Need Approval"
|
## Anti-Pattern: "Too Simple To Need Approval"
|
||||||
|
|
||||||
Every path ends with your human partner approving the required design
|
Every path ends with your human partner approving your intent before
|
||||||
before implementation. A bounded change may need only two sentences in
|
implementation. A todo list, a single-function utility, a config
|
||||||
chat. A new todo-list project is architectural and requires the written
|
change — the design may be two sentences in chat, but you MUST present
|
||||||
spec and planning handoffs. Scale the artifact to the selected path;
|
it and get approval. "Simple" tasks are where unexamined assumptions
|
||||||
complete that path's reviews before implementation.
|
cause the most wasted work. What scales with simplicity is the
|
||||||
|
artifact, never the approval.
|
||||||
|
|
||||||
## Red Flags
|
## Red Flags
|
||||||
|
|
||||||
| Thought | Reality |
|
| Thought | Reality |
|
||||||
|---------|---------|
|
|---------|---------|
|
||||||
| "This is too simple to need a design" | Follow the selected path: a bounded change gets a short chat design; an architectural change gets the written spec and planning handoffs. |
|
| "This is too simple to need a design" | Simple means a short design, not no design. Two sentences in chat, then approval. |
|
||||||
| "I'll call it bounded and skip the spec" | Reaching for a label to skip work IS the doubt — take the heavier path. |
|
| "I'll call it bounded and skip the spec" | Reaching for a label to skip work IS the doubt — take the heavier path. |
|
||||||
| "It's bounded and the design is obvious — I'll start while they read it" | The gate is the approval, not the design's length. Present, then stop until you hear yes. |
|
| "It's bounded and the design is obvious — I'll start while they read it" | The gate is the approval, not the design's length. Present, then stop until you hear yes. |
|
||||||
| "I understand this kind of app, so it's bounded" | Bounded measures the repo, not your familiarity. A new project has no existing flow — it is architectural. |
|
| "I understand this kind of app, so it's bounded" | Bounded measures the repo, not your familiarity. A new project has no existing flow — it is architectural. |
|
||||||
|
|||||||
@@ -182,6 +182,16 @@ Confirm:
|
|||||||
|
|
||||||
**Other tests fail?** Fix now.
|
**Other tests fail?** Fix now.
|
||||||
|
|
||||||
|
**"Other tests" means the project's suite, not just your file.** A
|
||||||
|
green run of the test you wrote is not a green suite. Before you call
|
||||||
|
the change done, run the project's test command (bare `pytest`,
|
||||||
|
`npm test`, `cargo test` — whatever the repo uses) even when your task
|
||||||
|
named only one test file. A scope statement in your task bounds the
|
||||||
|
deliverable, not your verification. Any failure that run shows —
|
||||||
|
including one you didn't cause — goes in your report by name; a red
|
||||||
|
test you watched scroll past and didn't mention is a report falsified
|
||||||
|
by omission.
|
||||||
|
|
||||||
### REFACTOR - Clean Up
|
### REFACTOR - Clean Up
|
||||||
|
|
||||||
After green only:
|
After green only:
|
||||||
|
|||||||
@@ -152,25 +152,15 @@ If you find issues, fix them inline. No need to re-review — just fix and move
|
|||||||
|
|
||||||
## Execution Handoff
|
## Execution Handoff
|
||||||
|
|
||||||
After saving and self-reviewing the plan, link it for your human partner
|
After saving the plan, offer execution choice:
|
||||||
to read. If they have already explicitly supplied an execution method, ask
|
|
||||||
them to review the plan and confirm it captures what they want; wait for that
|
|
||||||
review before implementation, then use the preserved method. Otherwise, ask
|
|
||||||
them to review the plan and choose an execution method before implementation.
|
|
||||||
|
|
||||||
**When no execution method has already been supplied:**
|
**"Plan complete and saved to `docs/superpowers/plans/<filename>.md`. Two execution options:**
|
||||||
|
|
||||||
**"Plan complete and saved to `docs/superpowers/plans/<filename>.md`. Please review the plan. Two execution options:**
|
|
||||||
|
|
||||||
**1. Subagent-Driven (recommended)** - I dispatch a fresh subagent per task, review between tasks, fast iteration
|
**1. Subagent-Driven (recommended)** - I dispatch a fresh subagent per task, review between tasks, fast iteration
|
||||||
|
|
||||||
**2. Inline Execution** - Execute tasks in this session using executing-plans, batch execution with checkpoints
|
**2. Inline Execution** - Execute tasks in this session using executing-plans, batch execution with checkpoints
|
||||||
|
|
||||||
**Does the plan capture what you want, and which approach should we use?"**
|
**Which approach?"**
|
||||||
|
|
||||||
**When an execution method has already been supplied:**
|
|
||||||
|
|
||||||
**"Plan complete and saved to `docs/superpowers/plans/<filename>.md`. Please review the plan. Does it capture what you want?"**
|
|
||||||
|
|
||||||
**If Subagent-Driven chosen:**
|
**If Subagent-Driven chosen:**
|
||||||
- **REQUIRED SUB-SKILL:** Use superpowers:subagent-driven-development
|
- **REQUIRED SUB-SKILL:** Use superpowers:subagent-driven-development
|
||||||
|
|||||||
Reference in New Issue
Block a user