4.1 KiB
name, generated-by, description, argument-hint, user-invocable
| name | generated-by | description | argument-hint | user-invocable |
|---|---|---|---|---|
| aidlc-security-patch | aidlc-runner-gen | Run the AI-DLC workflow with the security-patch scope baked in — no scope detection. CVE response. Packaging over `/aidlc --scope security-patch`, which works without this skill. | [description | --status | --stage <slug|#> | --phase <name|#>] | true |
AI-DLC — security-patch scope
Drive the AI-DLC engine with the security-patch scope fixed. This is the same
deterministic forwarding loop the /aidlc orchestrator runs, with --scope security-patch baked into the first next so scope detection is skipped. The
engine owns all routing; the conductor persona arrives on the first directive's
conductor_persona field — adopt it for the whole run.
The loop
directive = aidlc engine orchestrate next --scope security-patch $ARGUMENTS- Before acting on each directive, read
.aidlc/aidlc-common/protocols/stage-protocol.mdonce per session, then read every.aidlc/aidlc-common/protocols/stage-protocol-<module>.mdnamed bydirective.protocol_modules. Load every listed module before acting; skip only a module already loaded earlier in this session. Then act ondirective.kindexactly as the orchestrator does (run-stage / invoke-swarm / ask / print / error / done). aidlc engine orchestrate report --stage <directive.stage> --result <outcome> [--user-input "<text>"]when the directive names a stage; omit--stageonly for non-stage report round-trips.- Repeat from step 1 until
directive.kind == done.
Pass $ARGUMENTS through verbatim after --scope security-patch; the engine parses
any flags (--status, --stage, …) and the --scope from the
state file always wins on an existing workflow, so re-running a started workflow
resumes it. To run a different scope, use /aidlc --scope <other> instead.
Starting unrelated new work?
Before you forward $ARGUMENTS on step 1, make the SAME recognise-vs-route
judgment the /aidlc orchestrator makes: does this input continue the
active intent, or does it describe a genuinely new, unrelated piece of work?
This matters most when the active intent is already complete: then next
correctly returns done (the engine is read-only and never creates alongside a
live intent), and the loop above would simply stop. New work is NOT a
continuation; the escape hatch is next --new-intent.
-
Default to CONTINUATION. Treat the input as new-work ONLY when it clearly names a distinct feature/bug/unit unrelated to the active intent's subject (
aidlc engine intent list --jsongives itsslugandstatus). When in doubt, continue: false-positive offers are the main risk. -
On genuine new-work, OFFER, never auto-create. Surface an
AskUserQuestionshowing the active intent and the proposed new one, including the scope you'd give the new intent. Default that scope to this runner's bakedsecurity-patch(the new work is likely the same flavour that made the user reach for this command), but if the new work clearly fits a DIFFERENT scope, propose that instead, and name it so the human can correct it. Lead the affirmative option with "Yes" (e.g. "Yes, start a second intent"). Starting a workflow is a mutation gated on a human yes. -
On CONFIRM, re-run
nextwith--new-intent, the confirmed scope, and the new-work text:aidlc engine orchestrate next --new-intent --scope <the confirmed scope> "<the new-work description>"The engine returns a
printdirective naming theintent-createcommand (with the--label "<2-3 word kebab essence>"placeholder). Act on it exactly as the loop'sprinthandling describes: create the intent, then, because this is a NEW, unrelated intent and this session still carries the previous intent's context, STOP and follow the directive's hand-off: tell the user to start a fresh session (exit or restart OpenCode and start a new session) and invoke/aidlcto begin the new intent with a clean slate. Nothing is lost; the intent is saved on disk. -
On DECLINE, proceed with the active intent, the normal loop above.