instructions: chains of packages - stack-dev writes ## Kette, stack-close names the next link (#205)
CI / verify (push) Successful in 7m41s
CI / pwsh (push) Successful in 2m23s
Release / release (push) Successful in 36s
Release / wiki-mirror (push) Skipped

Files changed:
- CHANGES.md
- VERSION
- instructions/dev/issue-tracking.md
- instructions/dev/stack-close/SKILL.md
- instructions/dev/stack-dev/SKILL.md
- instructions/dev/stack-mode.md

Co-Authored-By: Claude Code <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SnAJ7Z3CpVD3PRbN73QtU2
This commit is contained in:
torbenandClaude Code committed 2026-10-10 08:49:33 +02:00
1 parent 7cfafd75b2
commit 3c80262a05
6 files changed
+90 -5

No files matched your search

+10 -1
View File
@@ -41,13 +41,22 @@ are split that way.
asked in the chat and stays a question in the body until it is answered; it is never settled
by a guess.
**A session that yields more than one package with an order gives each of them a
`## Kette` section** (`instructions/dev/issue-tracking.md` § Chains): the chain's name, the
predecessor, the successor, nothing else. When a package is inserted into an existing chain,
taken out of it or moved within it, the neighbours' sections are corrected in the same
session, and the changelog comment names it. The order stays a planning decision; a real
dependency also gets `status/blocked`.
4. **Name the version part.** Apply the drop-in test in `instructions/dev/version-parts.md`
and write the result into the body. Whether a change is a drop-in replacement has no
mechanical guard, so it is decided here, not at the bump. A change that crosses the
compatibility boundary goes to the user with what breaks, what an instance has to do about
it, and the alternatives, before the body can be ready (version-parts.md step 4).
5. **End the phase at a ready body.** Check the body against
5. **End the phase at a ready body.** First, for every package of a chain this session touched,
read both neighbours' `## Kette` sections and confirm that predecessor and successor point at
each other; repair a one-sided pointer before going on. Then check the body against
`instructions/dev/issue-tracking.md` § Ready to build. If it fails, say which point is open
and stay in this phase. If it passes, recommend one of two ways on, and stop: