@dezkareid/osddt 1.7.0 → 1.9.0

package/AGENTS.md

@@ -184,17 +184,19 @@ Templates are generated by `npx @dezkareid/osddt setup` and placed in each agent
 | `osddt.plan`       | Create a technical implementation plan from a specification        |
 | `osddt.tasks`      | Generate actionable tasks from an implementation plan              |
 | `osddt.implement`  | Execute tasks from the task list one by one                        |
+| `osddt.fast`       | Bootstrap all planning artifacts (spec, plan, tasks) in one shot   |
 | `osddt.done`       | Resolve project path, verify tasks, and move the feature to done   |
 
 #### Template Workflow
 
-`osddt.research` and `osddt.start` are **peer entry points** — use whichever fits your situation. Both lead to `osddt.spec`. If you close the coding session, execute `osddt.continue` to resume the workflow.
+`osddt.research`, `osddt.start`, and `osddt.fast` are **entry points**. `osddt.research` and `osddt.start` are peer entry points for the step-by-step workflow. `osddt.fast` is an accelerated entry point that skips manual steps and generates all planning artifacts in a single invocation. If you close the coding session, execute `osddt.continue` to resume the workflow.
 
 **Standard steps:**
 
 1. Pick an entry point:
    - **`osddt.research <topic>`** — explore the codebase or gather external findings first, then proceed to spec.
    - **`osddt.start <feature>`** — jump straight to creating the branch and working directory, then write the spec.
+   - **`osddt.fast <description>`** — create the branch, spec, plan, and task list in one shot without any manual steps.
 2. **`osddt.spec <feature>`** — analyse requirements and write the feature specification.
 3. *(optional)* **`osddt.clarify <feature>`** — resolve any Open Questions in the spec and record decisions.
 4. **`osddt.plan <tech decisions>`** — create a technical implementation plan from the spec.
@@ -202,6 +204,8 @@ Templates are generated by `npx @dezkareid/osddt setup` and placed in each agent
 6. **`osddt.implement`** — execute tasks one by one until all are checked off.
 7. **`osddt.done`** — verify all tasks are complete and move the feature folder to `done/`.
 
+> **Fast mode:** Steps 1–5 can be replaced by a single `osddt.fast <description>` invocation. The agent derives all decisions automatically and records them in an `## Assumptions` section of the plan for review before implementing.
+
 > **Note:** You can re-run any step to go back and revise it — except once `osddt.done` has been executed, the feature is considered finished and cannot be revisited.
 
 **If you close a session:**

package/README.md

@@ -44,6 +44,7 @@ flowchart LR
     subgraph entry[Entry points]
         research([osddt.research])
         start([osddt.start])
+        fast([osddt.fast])
     end
 
     spec([osddt.spec])
@@ -55,6 +56,7 @@ flowchart LR
 
     research --> spec
     start --> spec
+    fast --> implement
     spec --> clarify
     clarify --> plan
     spec --> plan
@@ -93,6 +95,17 @@ flowchart LR
 /osddt.done
 ```
 
+#### Fast mode (spec + plan + tasks in one shot)
+
+```
+/osddt.fast add payment gateway
+# → creates branch, writes spec, plan (with Assumptions), and task list automatically
+/osddt.implement
+/osddt.done
+```
+
+> Review the `## Assumptions` section of `osddt.plan.md` before implementing. Run `/osddt.clarify` if any Open Questions in the spec need resolving first.
+
 #### Resuming after closing a session
 
 ```
@@ -115,6 +128,7 @@ flowchart LR
 | `osddt.plan`       | Create a technical implementation plan from a specification        |
 | `osddt.tasks`      | Generate actionable tasks from an implementation plan              |
 | `osddt.implement`  | Execute tasks from the task list one by one                        |
+| `osddt.fast`       | Bootstrap all planning artifacts (spec, plan, tasks) in one shot   |
 | `osddt.done`       | Resolve project path, verify tasks, and move the feature to done   |
 
 Generated files are placed in:

package/dist/index.js

@@ -224,6 +224,9 @@ ${getNextStepToSpec(args)}
 3. Identify the core problem being solved
 4. Define the scope, user-facing constraints, and acceptance criteria
 5. Write the specification to \`osddt.spec.md\` in the working directory
+6. After writing the spec, check whether the **Open Questions** section contains any items:
+   - If it does, inform the user: "I have some open questions — can we clarify these? You can answer them now, or run \`/osddt.clarify\` to go through them one by one."
+   - If it does not (or the section is absent), proceed to the Next Step without mentioning clarification.
 
 ## Specification Format
 
@@ -394,6 +397,88 @@ Once all tasks are checked off, run the following command to mark the feature as
 \`\`\`
 /osddt.done
 \`\`\`
+`,
+    },
+    {
+        name: 'osddt.fast',
+        description: 'Bootstrap all planning artifacts (spec, plan, tasks) from a single description',
+        body: ({ args, npxCommand }) => `${getRepoPreamble(npxCommand)}## Instructions
+
+The argument provided is: ${args}
+
+This command runs the full spec-driven setup sequence in one shot — branch creation, spec, plan, and task list — without pausing for user input. Follow each step below in order without asking the user for clarification or confirmation between steps.
+
+### Step 1 — Derive branch and feature name
+
+Determine the branch name from ${args}:
+
+1. If ${args} looks like a branch name (no spaces, kebab-case or slash-separated), use it as-is.
+2. Otherwise treat ${args} as a human-readable feature description, convert it to a feature name, and use the format \`feat/<derived-name>\` as the branch name.
+
+Apply the constraints below to the feature name (the segment after the last \`/\`):
+
+${FEATURE_NAME_RULES}
+
+### Step 2 — Create branch and working directory
+
+3. Check whether the branch already exists locally or remotely:
+   - If it **does not exist**, create and switch to it:
+     \`\`\`
+     git checkout -b <branch-name>
+     \`\`\`
+   - If it **already exists**, warn the user and ask whether to:
+     - **Resume** — switch to the existing branch (\`git checkout <branch-name>\`) and continue
+     - **Abort** — stop and do nothing
+
+4. ${WORKING_DIR_STEP}
+
+Where \`<feature-name>\` is the last segment of the branch name (after the last \`/\`, or the full branch name if no \`/\` is present).
+
+### Step 3 — Generate spec
+
+Write \`osddt.spec.md\` to the working directory. Base it entirely on ${args} and any codebase context you can gather. Do **not** ask the user any questions. If there are ambiguities, record them in an **Open Questions** section and continue.
+
+The spec must include:
+- **Overview**: What the feature is and why it is needed
+- **Requirements**: Functional requirements expressed as user-observable behaviours
+- **Scope**: In scope and out of scope in product terms
+- **Acceptance Criteria**: Clear, testable criteria from a user or business perspective
+- **Open Questions** (if any): Ambiguities to resolve later — do not block on these
+
+### Step 4 — Generate plan
+
+Write \`osddt.plan.md\` to the working directory. Derive all technical decisions from the spec and codebase inspection. Do **not** ask the user for input.
+
+The plan must include:
+- **Assumptions**: Document every technical decision made automatically (e.g. library choices, architecture patterns) so the user can review them before implementing
+- **Architecture Overview**: High-level design decisions
+- **Implementation Phases**: Ordered phases with goals
+- **Technical Dependencies**: Libraries, APIs, services needed
+- **Risks & Mitigations**: Known risks and mitigations
+- **Out of Scope**: What will not be built
+
+### Step 5 — Generate task list
+
+Write \`osddt.tasks.md\` to the working directory based on \`osddt.plan.md\`.
+
+The task list must include:
+- A checklist of tasks grouped by phase: \`- [ ] [S/M/L] Description\`
+- Dependencies between tasks noted where relevant
+- A Definition of Done per phase
+
+### Step 6 — Report
+
+Display the full contents of \`osddt.tasks.md\` to the user. Then prompt them to run:
+
+\`\`\`
+/osddt.implement
+\`\`\`
+
+> You can optionally run \`/osddt.clarify\` before implementing to resolve any Open Questions recorded in the spec.
+
+## Arguments
+
+${args}
 `,
     },
     {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@dezkareid/osddt",
-  "version": "1.7.0",
+  "version": "1.9.0",
   "description": "Package for Spec-Driven Development workflow",
   "keywords": [
     "spec-driven",