sdd-steer
Skill0 starsChanged 37 days agoMITView on GitHub
Use when the human defines a focused amendment at a checkpoint during partial SDD task-list implementation, especially reducing previously implemented functionality, and requests impact assessment or amendment implementation across existing development documents, code, tests, and documentation. Stop after reporting; do not resume sdd-implement.
In this repository14 other files it gives its agents.
- sdd-conventionsSkill
- sdd-designSkill
- sdd-docsSkill
- sdd-forgeSkill
- sdd-implementSkill
- sdd-integrate-featureSkill
- sdd-manageSkill
- sdd-orientSkill
- sdd-planSkill
- sdd-reportSkill
- sdd-specifySkill
- sdd-tasksSkill
- sdd-tddSkill
- sdd-verifySkill
The file
Files
Apply a human-directed checkpoint amendment
Steering is the lightweight checkpoint variant of the revision core workflow. Use sdd-manage's Core development workflows model in its Available workflows reference for purpose and routing; this skill owns the focused amendment procedure and requires no formal campaign artifacts.
The human defines the objective at a checkpoint and decides whether to command its implementation. Distinguish an assessment request from an implementation request; discussion alone does not authorize repository changes. A command to implement the established amendment authorizes routine steps within that scope without repeated confirmation. sdd-manage coordinates scope and shared prerequisites. Use sdd-manage's Branch management reference to establish or reuse an amendment branch from the paused implementation checkpoint, with that implementation branch as its target. Use a current sdd-orient handoff for repository instructions, Git and task state, pending-change ownership, and the implementation checkpoint.
| Work | Load |
| Establish the objective, scope, and affected work | objective and impact |
| Amend existing development documents and implemented behavior | amendment execution |
| Bootstrap disclosure and usage records before the first SDD commit | sdd-manage: skills/sdd-manage/references/repository-bootstrap.md (bundled dependency) |
| Verify, commit, push, report, and stop | verification and stop |
- Establish the amendment. Allocate or recover its shared review-campaign identity and matching revision branch; retain a minimal REVISION-REPORT with objective, scope, full baseline and paused target, adding observed verification/publication at completion. Require no fabricated review or plan. Identify the human's intended end state, affected implemented features, retained behavior, relevant existing documents and task IDs, and the checkpoint baseline. Report missing decisions or conflicts that prevent the focused amendment.
- Update existing development documents. Within the commanded scope, directly amend affected SPEC, PLAN, TASKS or active FEATURE-TASKS, design, and layout so they describe the accepted end state. Preserve unaffected content and stable identities. Create no feature-document layer and invoke no feature-integration step.
- Align implementation. Use sdd-tdd for test strategy and changes, perform focused production changes, and use sdd-docs for module, API, README, and guide alignment. For a reduction, remove affected functionality consistently while protecting the retained contracts and dependencies. This skill owns the production edits and repairs within the amendment.
- Verify and finish. Use sdd-verify to assess the amendment and relevant regressions. Reassess affected completion claims, use sdd-report for the commit and result, commit and push the verified amendment, perform the default explicit merge into the paused implementation branch, verify and publish the target, and coordinate any warranted hosted reconciliation through sdd-forge when tracking is active.
- Stop. Report the resulting checkpoint, implemented amendment, verification and limitations, working/target branches, amendment and merge commits and publication state, and remaining work. Do not hand off to, invoke, or resume sdd-implement, select further tasks, or start another amendment. The human separately decides when to resume the main task list.
sdd-implement owns the main task-list workflow; this skill owns the human-commanded checkpoint amendment, including its direct development-document updates, completion reassessment, commits, pushes, and issue-state coordination. A planning-only request returns findings and proposed scope, then stops. Preserve pending work and do not reset or delete unrelated implementation. Git and the current documents retain history; no separate transaction journal or recovery workflow is required.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

