Install
$ agentstack add skill-jed-tech-spar-kit-spar-retain ✓ scanned · ✓ verified, works with Claude Code, Cursor, and more.
Security review
✓ PassedNo issues found. Passed automated security review. · v0.1.0 How review works →
- ✓ Prompt-injection patterns
- ✓ Secret / credential exfiltration
- ✓ Dangerous shell & filesystem operations
- ✓ Untrusted network calls
- ✓ Known-malicious package signatures
What it can access
- ✓ Network access No
- ✓ Filesystem access No
- ✓ Shell / process execution No
- ✓ Environment & secrets No
- ✓ Dynamic code execution No
From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.
Verified badge
Passed review? Show it. Paste this badge into your README, it links to the public security report.
Reliability & compatibility
Declared compatibility
Compatibility is declared by the source manifest. End-to-end runtime verification is coming, see below.
We're building live execution health for every listing: tool-call success rate, median latency, uptime, and last-checked timestamps, measured, not self-reported. It isn't live yet, so we don't show numbers we can't stand behind.
How agent discovery & health will work →About
Retain
Turn completed implementation into durable project knowledge.
Retain is closeout, not a retrospective by default. Make the active spec and plan accurate, preserve useful context, update broader docs only with approval, then archive the whole change folder.
Inputs
specs/active//_spec.mdspecs/active//plan.md- Completed implementation in the repository
- Optional notes or artifacts in the same change folder
- Relevant repo documentation, such as README, setup, architecture, or product docs
If implementation appears incomplete, stop and ask whether to return to spar-act.
Retention Context
Before editing, review the spec, plan, implementation changes, validation results, and optional notes. Preserve optional artifacts unless the user asked to remove them or they are clearly obsolete.
The retained folder should explain what shipped and why it matters without becoming a noisy build log.
Reconcile the Spec
Update _spec.md so it describes final behavior and durable intent.
- Keep
Summary,Problem,Scope, andOut of Scopeaccurate. - Update
Constraintsif implementation revealed durable requirements. - Update
Success Criteriaso they reflect the outcomes that shipped and were
validated.
- Update
Decisionswith important product or technical choices discovered
during implementation.
- Resolve or remove stale
Open Questions; keep only questions that materially
affect future implementation or validation.
Do not add step-by-step implementation narrative to the spec.
Reconcile the Plan
Update plan.md so it remains a useful execution record.
- Ensure
Tasksare checked or explicitly explained. - Ensure
Validation Strategyreflects what actually ran or what could not be
validated.
- Ensure
Risks / Follow-upscaptures unresolved risks, deferred work, or
follow-up decisions.
- Ensure
ApproachandExecution Constraintsdo not contradict what shipped. - Remove only scratch notes or duplicate lines that would confuse future readers.
Documentation Updates
Identify broader documentation impact from the final spec, plan, implementation changes, and repo docs.
If broader docs should change, propose concrete edits and ask for approval before applying them. Do not silently edit repo-wide documentation.
If no broader documentation updates are warranted, say so briefly in the final summary so the user knows it was considered.
Archive the Change
Move the entire folder:
specs/active// -> specs/completed//
Create specs/completed/ and specs/completed// if needed. Do not leave a copy under specs/active/. If a destination file already exists, stop and ask how to resolve it; do not overwrite or merge file contents silently.
Stop Conditions
Stop and ask if:
- Implementation appears incomplete.
- Validation is missing and cannot be explained honestly.
- Final behavior contradicts the spec in a way the user has not approved.
- Broader documentation changes are needed but not yet approved.
- A destination file already exists in
specs/completed//.
Completion
Retention is complete when:
- The spec matches the implementation.
- The plan reflects completed or explained work.
- Approved documentation updates are applied, or none were needed.
- The change folder exists only under
specs/completed//.
Then summarize concisely with genuine enthusiasm for the completed change: final archived path, spec and plan reconciliation, documentation updates made or skipped, and any retained follow-ups. Emphasize that the completed folder is the durable source of truth for what shipped.
Artifact Recap
| Artifact | In this phase | | --- | --- | | _spec.md | Final behavior, durable intent, constraints, success criteria, decisions, and material open questions | | plan.md | Final task state, validation record, risks, and follow-ups | | specs/completed// | Archived source of truth for the shipped change |
Source & license
This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.
- Author: Jed-Tech
- Source: Jed-Tech/spar-kit
- License: Apache-2.0
- Homepage: https://jed-tech.github.io/spar-kit/
Install and usage instructions live in the source repository linked above.
Reviews
No reviews yet, be the first.
Write a review
Versions
- v0.1.0 Imported from the upstream source.