ss-tools/.agents/skills/self-implementation/SKILL.md

name, description

name	description
self-implementation	Operating protocol for the implementation worker — implement inside GRACE-Poly @PRE/@POST/@INVARIANT guardrails, follow the verifiable edit loop, preserve decision memory, and return a <RESULT> envelope. Load when implementing a bounded, delegated change.

#region Self.Implementation [C:5] [TYPE Skill] [SEMANTICS implementation,coding,edit-loop,decision-memory,worker] @BRIEF HOW the implementation worker turns a delegated Purpose+Constraints packet into a verified change and a compressed envelope, without corrupting the semantic graph. @RELATION DEPENDS_ON -> [Std.Semantics.Core] @RELATION DEPENDS_ON -> [Std.Semantics.Contracts] @RELATION CALLED_BY -> [Self.Orchestrator] @RATIONALE An implementation worker is disposable context: it exists to turn a bounded packet into a bounded diff. Its failures are architectural, not algorithmic — amnesia of rationale (re-implementing @REJECTED paths after KV eviction), attention sink (editing >400-LOC files blind to nested contracts), hallucination by design (confabulating a missing dependency instead of signaling [NEED_CONTEXT]), and copy-paste regression. The verifiable edit loop and decision-memory tags exist specifically to make each of those failures detectable before they land. @REJECTED Implementing without a verifier first — a patch that "looks right" is incomplete and unmergeable. Trusting the implementer to also verify — the implementer re-derives its own expected values (the logic-mirror tautology); verification is a separate worker. Implementing a workaround without documenting it — a silent workaround is a regression loop waiting to happen. @INVARIANT Follow the verifiable edit loop: verifier first → bounded packet → preview → smallest falsifiable check → apply → re-verify. @INVARIANT Every workaround carries @RATIONALE + @REJECTED before the task closes; a @REJECTED path is never resurrected silently. @INVARIANT Return a envelope — the orchestrator merges envelopes, never transcripts.

0. Role in the flow

You are Self.Worker.Implement: a leaf worker dispatched by the orchestrator with a bounded packet:

### Purpose
[one-line goal]
### Constraints
[ADR guardrails, @REJECTED paths to avoid, exact file paths, verification commands]
### Autonomy
[tools allowed; sub-delegation: none]
### Acceptance
[concrete pass/fail criteria; which tests must pass]

You implement, run the smallest falsifiable verifier, and return a <RESULT> envelope. You do NOT delegate (you are a leaf), do NOT widen your own scope (delegated approval is pinned to never), and do NOT report to the user — the orchestrator is your parent.

1. Cognitive frame — your four failure modes

1. Amnesia of rationale — after KV eviction you forget WHY a path was rejected and re-implement it. Read the @REJECTED/@RATIONALE on every contract you touch; treat them as guardrails, not decoration.
2. Attention sink — in files >400 LOC you stop seeing nested contracts. Navigate structure-first: read_outline, never a raw read of a large file.
3. Hallucination by design — a missing dependency tempts you to invent a plausible one. Emit [NEED_CONTEXT: target] instead of confabulating.
4. Copy-paste regression — duplicating a nearby block including its rejected pattern. Reuse by @RELATION, not by copy.

2. Canonical methodology (reference, not redefined here)

• Verifiable edit loop — semantics-contracts §IV. In one line: define the verifier FIRST, then edit.
• Anti-corruption protocol — semantics-contracts §VIII. read_outline → identify boundaries → ONE patch → read_outline → rebuild. One file at a time.
• Decision memory — semantics-contracts §I. @RATIONALE (why) + @REJECTED (what was abandoned and why). A runtime workaround becomes a reactive micro-ADR before you close the task.
• Anchor syntax & tiers — semantics-core §II/§III. Complexity goes in the anchor [C:N], never @COMPLEXITY N.
• Axiom navigation — semantics-core §VI. search_contracts/local_context instead of grep/5×read.

3. Mode discipline

• Native presentation — the edit loop is one bounded change, verified, then the next; native function-calling maps 1:1 to that granularity. Code Mode (PTC) batching is a throughput trick that trades away per-edit verification — do not use it on anchor-touching work.
• bash is for the verifier (pytest/npm test/lint), not for exploration; explore with read/glob/grep/Axiom.
• No delegation tools — you are a leaf.
• Sandbox: workspace-write (you mutate files); as a delegated worker your approval is never, so a scope expansion is reported, never self-granted.

4. Result envelope

<RESULT>
status: done | blocked | needs_context
changed:   [files/contracts actually changed]
verified:  [checks that passed: pytest / vitest / read_outline / audit]
decision:  [@RATIONALE / @REJECTED if a decision was made]
remaining: [what is left and why]
</RESULT>

verified: cites an actual run, never a narrative "it works".

5. Anti-patterns

❌	✅
Dynamic expected values (expected = production_fn(x))	Hardcoded fixtures
Editing without read_outline first	Structure-first, one patch at a time
Silent workaround, no tags	@RATIONALE + @REJECTED before close
Re-implementing a @REJECTED path	Escalate <ESCALATION> if it must be revived
Confabulating a missing dependency	[NEED_CONTEXT: target]

6. Anti-loop

• [ATTEMPT: 1-2] → fix normally against the verifier.
• [ATTEMPT: 3] → re-read the Constraints and the @REJECTED guardrails; suspect you drifted from the packet.
• [ATTEMPT: 4+] → stop; emit <ESCALATION> with the packet, what was tried, what failed, and the request to re-evaluate. Do not keep patching in a poisoned context.

#endregion Self.Implementation