docs: add target-system responsibility boundary

[YOMXXX]

Summary

• Adds a target-system responsibility boundary check to writing-plans
• Adds execution guidance for inference/derivation/helper logic in executing-plans
• Adds implementer prompt guidance to avoid silently substituting for target-system capabilities
• Adds a reviewer checklist item for hidden development-time inference/helper logic
• Adds a deterministic shell contract test

Refs #1096.
Related: #895, #1098.

Why this shape

This is a small guardrail against a common agentic-development failure: the development agent makes a patch pass by carrying responsibilities that should have been explicitly modeled in the target system. The PR does not introduce a new skill or workflow; it adds the boundary at planning, execution, and review points where the mistake can happen.

Test plan

• bash tests/claude-code/test-target-system-boundary-contract.sh
• bash -n tests/claude-code/test-target-system-boundary-contract.sh
• git diff --check HEAD~1 HEAD

Notes

No generated docs/superpowers/specs/* or docs/superpowers/plans/* files are included in this PR.

[obra]

The underlying #1096 concern is legitimate, but I need more before this can be evaluated:

1. A concrete session where this bit you (or @SZnine, whose issue you're addressing). The PR body argues the failure mode in general terms but doesn't include a real example. What was the plan? What did the implementer agent do? What target-system responsibility did it silently absorb? Without a specific case, neither the "before" behavior nor the "after" behavior is testable.

2. Before/after evals showing the new wording changes behavior. This PR adds prose to four carefully-tuned skill files at once (writing-plans, executing-plans, implementer-prompt.md, code-reviewer.md). That's a wide blast radius. Skill-content changes need adversarial pressure-testing per writing-skills — RED (current skills let an implementer absorb the responsibility from your example) and GREEN (the updated skills make the implementer flag it instead). The "Rigor" checkboxes are unchecked.

3. The test you added is grep-based, not behavioral. test-target-system-boundary-contract.sh checks that the literal strings the PR added appear in the files. It can never fail unless someone deletes those lines. A real test would run the updated implementer-prompt against the example plan from Add problem-solving skills from amplifier patterns #1, and assert the implementer returns DONE_WITH_CONCERNS or NEEDS_CONTEXT instead of silently implementing the helper.

Separately on scope: even with evidence, I'd want to see this proven on the smallest possible surface first (probably just implementer-prompt.md) before fanning the same prose out to four files. Once we know the wording works, propagating it to the planning and review skills is a cheap follow-up.

Happy to revisit with a concrete session + evals.

— Claude Opus 4.7, Claude Code 2.1.150

[YOMXXX]

Reviewer-facing status update:

Current open PRs from me are now only:

• docs: add target-system responsibility boundary #1620 — target-system responsibility boundary
• docs: add context-frugal resume contract #1621 — context-frugal resume contract

I am not asking for re-review of #1620 in its current shape. The review bar is clear:

• provide a concrete session where a development agent silently absorbed a target-system responsibility
• add RED/GREEN behavioral eval evidence showing the wording changes behavior
• shrink the first slice, likely to subagent-driven-development/implementer-prompt.md only, before touching planning/execution/review surfaces

Next step on this PR is either a narrower revision with a concrete reproducible case and behavioral evidence, or closing it if I cannot produce that evidence.

No generated docs/superpowers/specs/* or docs/superpowers/plans/* files are part of this PR.

[YOMXXX]

Closing this rather than asking for re-review without the evidence requested. The review feedback is valid: this needs a concrete session plus RED/GREEN behavioral evals, and the first slice should be narrowed to the smallest surface, likely implementer-prompt.md only. I do not have that evidence ready, and I do not want this PR to keep occupying reviewer attention in its current shape. No generated docs/superpowers/specs/* or docs/superpowers/plans/* files were part of this PR.