implement-982e54 — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited implement-982e54 (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
<!-- codex: tool-name mapping applied. See .codex/scripts/session-start.sh -->
Start with instruction reads. After this entry point loads, your next tool calls read the three shared protocols below and the selected mode procedure. Do not batch them with repository searches or source/document reads. Reading only this SKILL.md does not open investigation. Complete the profile-loading checkpoint before investigation, tests or edits; only the declared bounded predicate routing below may inspect content earlier. A filename-only scope operation is not that checkpoint.
implement/ subdirectory (e.g., ../../profiles/k8s/implement/), its index.md lists per-task gotchas the skill must consult BEFORE writing. See Step 2.Two modes, determined automatically: plan mode when the user references a docs/feat/wip feature or task number; standalone mode otherwise (bug fix, GitHub issue, one-off change). When ambiguous, ask.
Both modes share the same execution core (Step 2 onward) — instruction loading, investigation and change context, implementation, verification, review.
After each execution + review cycle, verify all outputs:
$kk:review-code — which owns indexing its own kk:review-findings)kk:project-conventions (skip if none established)tasks.md updated to doneIndexing ownership: Review skills ($kk:review-code, $kk:review-spec) index their own findings. This skill only indexes kk:project-conventions for non-obvious patterns discovered during implementation. Do NOT duplicate review indexing here.
By default, review checkpoints use isolated mode ($kk:review-code:isolated, $kk:review-spec:isolated). This is mandatory because the implementing session has authorship bias — the same model that wrote the code produces weaker reviews of it. Isolated mode spawns an independent sub-agent with no prior exposure to the implementation.
The user can override at any checkpoint ("use standard review for this one") to fall back to in-session $kk:review-code.
Mandatory order — instructions before action. The flow below is strictly sequential. Load this skill, the selected mode procedure, shared protocols and every resolved profile instruction before source/requirement investigation, edits (including task-status edits), tests or implementation decisions. Entry procedures collect minimal task/file metadata solely to select scope and profile guidance; they do not analyze requirement prose. After basic instructions load, the sole early-content exception is routing for a declared detection or conditional-load predicate: inspect at most approximately 16 KiB per candidate file, log the predicate/path, and conservatively load an instruction when its conditional is undecidable within that bound. Routing permits no behavioral analysis, full-diff read, findings, edits or tests.
Phases: load basic instructions and scope metadata → detect profiles and load their content → investigate requirements/source and establish change context → implement and verify → refresh evidence and review → assess completion. Detailed investigation has one entry point in Step 2; mode entry procedures do not duplicate it.
Read the shared protocols in Conventions, determine mode (see §Modes), then read the appropriate mode file and follow its entry procedure:
After completing the mode's entry procedure, continue with Step 2.
Scope routing returns filenames/metadata only. For symbol lookup use a filename-only search (Grep with output_mode: files_with_matches, or rg -l), never matching source lines. In plan mode extract only the task headings/status/dependency/target-path fields specified by the mode procedure; do not use a full Read/cat of tasks.md as metadata, even when it is short. If a target is unclear, route a conservative file list rather than investigating it early.
shared-profile-detection.md against candidate target filenames and any diff-so-far, however small the task. Read every Known profiles detection rule in a batch before choosing active profiles. Reconcile the set/count of returned rule-file paths against all expected paths, not the set of matching profiles: a nonmatching rule still must be read, never inferred from an extension. Resolve the plugin root from the loaded skill location (parent of skills/) or the hook-exported root; do not use profile-directory discovery as a substitute for the Known profiles list. For each active profile, read ../../profiles/<name>/implement/index.md; ENOENT means no implement guidance for that profile. Read every always-load, matching and conservatively selected instruction. An index or requested read alone is not a loaded checklist. The next action after those returns is to emit the checkpoint below, naming returned paths and each conditional decision. No investigation may share a call with these instruction reads or precede that checkpoint. A failed/missing read keeps this gate closed; an empty profile set skips content loading, never detection. Instruction-loading checkpoint:
- Shared protocols and selected mode: [returned paths]
- Detection rules: [expected and returned paths reconciled]
- Active profiles and implement instructions: [returned paths; conditional decisions]
- Unread required instructions: [none, or stop and resolve]$kk:dependency-handling before writing the call. Use its lookup cascade and the active profile's overview.md; do not guess signatures or configuration. Revisit this gate if investigation discovers a dependency change.tasks.md, design.md and implementation.md; in standalone mode examine the request and any referenced issue (gh issue view). Search the mode's declared Capy sources for relevant context, even for trivial work. Then read relevant source/current diff, trace affected entry points and unchanged callers through state and response contracts, and reproduce the problem where useful. Apply the shared change-context contract: establish intended outcomes and their authority, preserved behavior, actual scope/baselines and applicable delivery constraints before implementation edits. On resume, compare current repository state with earlier context and supersede stale evidence. If requirement loading or source exploration adds a target or reveals a new profile/conditional, pause that investigation to re-detect and load its guidance before proceeding.Check whether the proposed approach satisfies the requirement and delivery policy. A concrete conflict requires the affected flow, trade-off and smallest viable alternatives before dependent edits; pending future work is no excuse for breaking a current flow. If explicit requirements conflict and no existing accepted decision settles them, record the alternatives as proposals and stop dependent edits until the user resolves the conflict. Do not invent document precedence, label your preferred interpretation an accepted decision, or weaken one requirement merely because the alternative preserves compatibility. Reuse actual accepted decisions and authorization; choices within those requirements create no new approval gate. State a brief approach for non-trivial work. Keep trivial changes proportionate, without irrelevant release gates or duplicate tests.
Check the proposed resolution against a concrete boundary case. For each conflicting condition, compare the outcome it requires with what the alternative would do. If the alternative permits an outcome an explicit condition forbids, it changes that requirement. In particular, replacing an unconditional guarantee/rejection with conditional or best-effort behavior is not merely an interpretation, even when it satisfies another hard requirement. Record that counterexample and wait for an actual user decision before dependent edits; saying the alternative “honors both” or assigning precedence to a document is not authorization.
In plan mode, set the task to in-progress and record observations under its labeled Execution context, following plan-mode.md. Standalone context remains conversational unless material work must be deferred.
$kk:test and load its resolved instructions before running verification; running a test command alone does not execute that skill's workflow. Use relevant focused checks for intended behavior, preserved contracts and applicable compatibility cases. Record commands, actual results, baselines and limits. Green tests support only the scenarios exercised; they do not prove deployment readiness.$kk:review-code in isolated mode (or the registered $kk:review-code:isolated command where available) and follow its full instruction-loading workflow. If the harness has no invocation tool, read that skill's entry point and isolated procedure explicitly. Do not replace it with a direct code-reviewer spawn: the isolated workflow owns both independent-agent and PAL paths, resolved criteria and evidence preparation. Supply the refreshed context and evidence to that workflow, which prepares the same relevant source/historical evidence for both reviewers and handles further evidence requests; do not issue a duplicate PAL review. If the user selected standard review, supply the same factual record to $kk:review-code. Missing specification or deployment evidence narrows conclusions; it does not reduce review to code quality alone.done unless explicit user authorization changes it or accepts an exception; record the source, rationale and prerequisites. Unknown evidence essential to acceptance remains open. An external deployment prerequisite may outlive code completion only when consistent with the agreed contract; describe release readiness as conditional or unknown.Record every deferred material action durably with owner (or explicitly unassigned), reason, concrete next action and verification condition: the current task's Execution context in plan mode; existing tracking or a concise repository-local review note in standalone mode. A final-chat caveat alone is insufficient. Only then mark the plan task done if the contract and all Required Outputs are satisfied; otherwise keep required work open. Do not continue with incomplete outputs.
Follow the iteration procedure in plan-mode.md — move to next task, repeat Steps 1–3.
Follow the completion procedure in plan-mode.md — final validation, documentation, reflection.
STOP executing immediately when:
Ask for the missing decision or capability rather than inventing a requirement. Continue independent authorized work while dependent work waits; ordinary fixable test failures should be corrected and reverified.
Return to Step 1 when:
IMPORTANT! Don't force through blockers — stop and ask.
$kk:dependency-handling, $kk:test, $kk:review-code:isolated) (Plan mode: also when the plan says to do so)~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.