docs(recommend-dont-menu,project-discipline): drop stale superpowers references (sovereignty)
- recommend-dont-menu v0.1.0 -> v0.1.1: description no longer names superpowers:brainstorming - project-discipline v0.1.1 -> v0.1.2: vendor-default paths (docs/superpowers/*) removed from description, rule-1 list, concrete consequences, why-this-exists - zero superpowers refs left in live skill bodies; lint 0/0; ~/.claude/skills synced
This commit is contained in:
@@ -1,12 +1,11 @@
|
||||
---
|
||||
name: project-discipline
|
||||
author: ours
|
||||
version: 0.1.1
|
||||
version: 0.1.2
|
||||
description: >
|
||||
Codifies five cross-project discipline rules: (1) project CLAUDE.md /
|
||||
.wiki/CLAUDE.md / .tasks/ override defaults from any other skill (specs
|
||||
go to .wiki/concepts/, not docs/superpowers/specs/; tasks to .tasks/,
|
||||
not docs/superpowers/plans/); (2) all work on master/main, no feature
|
||||
go to .wiki/concepts/, tasks to .tasks/); (2) all work on master/main, no feature
|
||||
branches without explicit user approval; (3) bump semver on every edit
|
||||
of versioned artifacts (SKILL.md frontmatter, package.json,
|
||||
pyproject.toml) per MAJOR/MINOR/PATCH rules, recorded in commit message;
|
||||
@@ -33,7 +32,7 @@ The skill itself takes no actions and has no external side-effects. It instructs
|
||||
|
||||
## Rule 1 — Project conventions override skill defaults
|
||||
|
||||
Before applying defaults from any other skill (superpowers, frontend-design, mcp-builder, etc.), read in this order:
|
||||
Before applying defaults from any other skill (frontend-design, mcp-builder, etc.), read in this order:
|
||||
|
||||
1. `CLAUDE.md` in the project root.
|
||||
2. `.wiki/CLAUDE.md` (if it exists).
|
||||
@@ -43,8 +42,8 @@ Any path, format, or workflow explicitly stated in those files **overrides the s
|
||||
|
||||
Concrete consequences:
|
||||
|
||||
- **Specs / design documents** go to `.wiki/concepts/<topic>-design.md`, **not** `docs/superpowers/specs/`.
|
||||
- **Task tracking / implementation plans** go to `.tasks/<slug>.md` plus a board entry in `.tasks/STATUS.md` (the `using-tasks` format), **not** `docs/superpowers/plans/` or any inline-in-chat plan format.
|
||||
- **Specs / design documents** go to `.wiki/concepts/<topic>-design.md`.
|
||||
- **Task tracking / implementation plans** go to `.tasks/<slug>.md` plus a board entry in `.tasks/STATUS.md` (the `using-tasks` format).
|
||||
- **Frontmatter, naming conventions, log format** — as described in the project's `.wiki/CLAUDE.md`.
|
||||
|
||||
If no convention is stated explicitly — fall back to the skill default.
|
||||
@@ -135,6 +134,6 @@ The skill **does not**:
|
||||
|
||||
## Why this exists
|
||||
|
||||
In a tightly-disciplined repo (`skills`) the four rules already hold by accident — the agent reads `.wiki/CLAUDE.md`, knows specs go to `.wiki/concepts/`, knows to bump `version:`, knows not to push without confirmation. In **other** projects of the same user, that discipline does not transfer: the agent uses `superpowers`' default `docs/superpowers/specs/`, branches on a whim, forgets `version:` bumps, and pushes without asking. This skill makes the discipline explicit and portable.
|
||||
In a tightly-disciplined repo (`skills`) the four rules already hold by accident — the agent reads `.wiki/CLAUDE.md`, knows specs go to `.wiki/concepts/`, knows to bump `version:`, knows not to push without confirmation. In **other** projects of the same user, that discipline does not transfer: the agent falls back to vendor-default paths (`docs/specs/`, `docs/plans/`), branches on a whim, forgets `version:` bumps, and pushes without asking. This skill makes the discipline explicit and portable.
|
||||
|
||||
Full design rationale (why one skill instead of four, why a skill instead of inline `CLAUDE.md` lines, scope of each rule, push-permission mechanism choice) lives in `.wiki/concepts/project-discipline-design.md` (in this repo; in other projects bootstrapped from this repo, the design lives in `skills`).
|
||||
|
||||
@@ -1,12 +1,12 @@
|
||||
---
|
||||
name: recommend-dont-menu
|
||||
author: ours
|
||||
version: 0.1.0
|
||||
version: 0.1.1
|
||||
description: >
|
||||
Use during design discussions, brainstorming, architecture reviews, or any
|
||||
"what should we do" question — give one argued recommendation with explicit
|
||||
trade-offs, not a multiple-choice menu. Override of superpowers:brainstorming
|
||||
default. Works on any agent — pure response-style rule, no tool mappings needed.
|
||||
trade-offs, not a multiple-choice menu. Replaces the default multiple-choice
|
||||
brainstorming pattern. Works on any agent — pure response-style rule, no tool mappings needed.
|
||||
---
|
||||
|
||||
# recommend-dont-menu
|
||||
|
||||
Reference in New Issue
Block a user