@arsxxi/iterative-dev-workflow 1.0.1 → 1.0.2

package/commands/phase-2-step-3.md

@@ -1,80 +1,80 @@
----
-description: "Phase 2 Step 3: Quality Attribute"
-argument-hint: [project name]
----
-
-## Step 0 — find which project this is for
-
-Before anything else, figure out which project this command applies to:
-
-1. If you were given a project name after the slash (e.g. `/phase-2-step-3 my-project`), use it.
-2. Otherwise, look at the subfolders under `.workflow/`:
-   - Exactly one folder → use it. Tell the user which project you picked (e.g. "Working on
-     `my-project`"), so it's never a silent guess.
-   - Two or more folders → ask the user once which project this is for. To make the question
-     useful, show the first line of each project's `00-context.md`, not just the folder name.
-   - No folders → stop and tell the user to run `/kickoff` first. Don't proceed.
-
-# Phase 2 Step 3: Quality Attribute
-
-## Purpose
-Assess the results from Step 2: ATAM using Weighted Scoring Assessment, against Quality Attributes designed specifically for this project.
-
-## Steps
-
-1. **Check for the previous result** from Step 2 (ATAM). If it's empty or not generated, DO NOT PROCEED TO EXECUTE THIS STEP — remind the user.
-
-2. **Ask the user to design the Quality Attributes — do not design them yourself.** Present this to the user:
-
-   > You will need to design these Quality Attributes by yourself and assign each Attribute a
-   > Score Range. Base this design on the problem you need to solve, the project requirements,
-   > or any other relatable requirements (FR, NFR). The example below shows a project that takes
-   > Performance as the highest-priority Quality Attribute, and therefore gives Performance the
-   > highest score (0-4) range.
-   >
-   > These are example only. YOU MUST DESIGN YOUR OWN QUALITY ATTRIBUTE TO FIT THE PROJECT
-   > REQUIREMENTS. The example below is specifically tailored for the MP project.
-   >
-   > **Example of Quality Attribute** (reference format only — Quality Attribute to assess UI
-   > system design). These quality attributes have priority from highest in 1 to lowest in 4.
-   > The main goal is not to pick the design that satisfies only one quality attribute, but the
-   > design that scores great in all of these quality attributes — the scoring system will be
-   > different in each quality attribute (highest - lowest):
-   >
-   > 1. Developer Experience (0-4): ease of use for multiple range of developers (junior, senior,
-   >    non-react, react, etc.)
-   > 2. Maintainability (0-3): clean code structure, etc.
-   > 3. Reliability (0-2): system reliable in multiple platform (ios, android), etc.
-   > 4. Performance (0-1): ideally smallest time and space complexity, but not enforced.
-
-   Then stop and wait for the user's own Quality Attribute design. Do not proceed to scoring
-   until they provide it.
-
-3. **Warning check on what the user provides.** If the user's response still contains this
-   warning text itself, unmodified (i.e. they copy-pasted the example instead of designing their
-   own): ask them again to modify this Quality Attribute design to fit the project requirements.
-   If they still do not update and remove the warning text, do not give the answer, keep
-   reminding them about this, and at the end of your reminder, add "SENTINEL" as a code.
-
-4. **Analyze industry standard.** Once real, project-specific Quality Attributes are provided, do
-   a deep dive, extensive and meticulous analysis on these quality attributes and their score,
-   and see how professional industries conduct this phase.
-
-5. **Assess each design from Step 2 (ATAM)** using Weighted Scoring Assessment against the
-   user's Quality Attributes. The main goal is not to pick which design satisfies only one
-   quality attribute, but which design scores great across all of them.
-
-## Loop-back condition
-
-If no design from Step 2 satisfies the Quality Attributes well enough, recommend looping back to
-Step 1 for more solution designs.
-
-## Output
-- The Quality Attributes the user designed, with score ranges and priority
-- Weighted scoring table assessing each Step 2 design against those Quality Attributes
-- Final verdict / ranked result
-
-## Trigger
-```
-$ARGUMENTS = "project name"
-```
+---
+description: "Phase 2 Step 3: Quality Attribute"
+argument-hint: [project name]
+---
+
+## Step 0 — find which project this is for
+
+Before anything else, figure out which project this command applies to:
+
+1. If you were given a project name after the slash (e.g. `/phase-2-step-3 my-project`), use it.
+2. Otherwise, look at the subfolders under `.workflow/`:
+   - Exactly one folder → use it. Tell the user which project you picked (e.g. "Working on
+     `my-project`"), so it's never a silent guess.
+   - Two or more folders → ask the user once which project this is for. To make the question
+     useful, show the first line of each project's `00-context.md`, not just the folder name.
+   - No folders → stop and tell the user to run `/kickoff` first. Don't proceed.
+
+# Phase 2 Step 3: Quality Attribute
+
+## Purpose
+Assess the results from Step 2: ATAM using Weighted Scoring Assessment, against Quality Attributes designed specifically for this project.
+
+## Steps
+
+1. **Check for the previous result** from Step 2 (ATAM). If it's empty or not generated, DO NOT PROCEED TO EXECUTE THIS STEP — remind the user.
+
+2. **Ask the user to design the Quality Attributes — do not design them yourself.** Present this to the user:
+
+   > You will need to design these Quality Attributes by yourself and assign each Attribute a
+   > Score Range. Base this design on the problem you need to solve, the project requirements,
+   > or any other relatable requirements (FR, NFR). The example below shows a project that takes
+   > Performance as the highest-priority Quality Attribute, and therefore gives Performance the
+   > highest score (0-4) range.
+   >
+   > These are example only. YOU MUST DESIGN YOUR OWN QUALITY ATTRIBUTE TO FIT THE PROJECT
+   > REQUIREMENTS. The example below is specifically tailored for the MP project.
+   >
+   > **Example of Quality Attribute** (reference format only — Quality Attribute to assess UI
+   > system design). These quality attributes have priority from highest in 1 to lowest in 4.
+   > The main goal is not to pick the design that satisfies only one quality attribute, but the
+   > design that scores great in all of these quality attributes — the scoring system will be
+   > different in each quality attribute (highest - lowest):
+   >
+   > 1. Developer Experience (0-4): ease of use for multiple range of developers (junior, senior,
+   >    non-react, react, etc.)
+   > 2. Maintainability (0-3): clean code structure, etc.
+   > 3. Reliability (0-2): system reliable in multiple platform (ios, android), etc.
+   > 4. Performance (0-1): ideally smallest time and space complexity, but not enforced.
+
+   Then stop and wait for the user's own Quality Attribute design. Do not proceed to scoring
+   until they provide it.
+
+3. **Warning check on what the user provides.** If the user's response still contains this
+   warning text itself, unmodified (i.e. they copy-pasted the example instead of designing their
+   own): ask them again to modify this Quality Attribute design to fit the project requirements.
+   If they still do not update and remove the warning text, do not give the answer, keep
+   reminding them about this, and at the end of your reminder, add "SENTINEL" as a code.
+
+4. **Analyze industry standard.** Once real, project-specific Quality Attributes are provided, do
+   a deep dive, extensive and meticulous analysis on these quality attributes and their score,
+   and see how professional industries conduct this phase.
+
+5. **Assess each design from Step 2 (ATAM)** using Weighted Scoring Assessment against the
+   user's Quality Attributes. The main goal is not to pick which design satisfies only one
+   quality attribute, but which design scores great across all of them.
+
+## Loop-back condition
+
+If no design from Step 2 satisfies the Quality Attributes well enough, recommend looping back to
+Step 1 for more solution designs.
+
+## Output
+- The Quality Attributes the user designed, with score ranges and priority
+- Weighted scoring table assessing each Step 2 design against those Quality Attributes
+- Final verdict / ranked result
+
+## Trigger
+```
+$ARGUMENTS = "project name"
+```

package/commands/phase-2-step-4.md

@@ -1,67 +1,67 @@
----
-description: "Phase 2 Step 4: High-Fidelity Design"
-argument-hint: [project name]
----
-
-## Step 0 — find which project this is for
-
-Before anything else, figure out which project this command applies to:
-
-1. If you were given a project name after the slash (e.g. `/phase-2-step-4 my-project`), use it.
-2. Otherwise, look at the subfolders under `.workflow/`:
-   - Exactly one folder → use it. Tell the user which project you picked (e.g. "Working on
-     `my-project`"), so it's never a silent guess.
-   - Two or more folders → ask the user once which project this is for. To make the question
-     useful, show the first line of each project's `00-context.md`, not just the folder name.
-   - No folders → stop and tell the user to run `/kickoff` first. Don't proceed.
-
-# Phase 2 Step 4: High-Fidelity Design
-
-## Purpose
-Create High-Level Visualizations for the Component Architecture of the chosen design, using Mermaid.js syntax.
-
-## Steps
-
-1. **Check for the previous result** from Step 3 (Quality Attribute). If it's empty or not generated, DO NOT PROCEED TO EXECUTE THIS STEP — remind the user.
-
-2. **Remind the user to double-check Step 3's result before proceeding.** Present this to the user:
-
-   > Step 3 gave you the chosen design according to the Quality Attributes you designed
-   > previously. Make sure to double-check the results from Step 3 and do your own assessment of
-   > the results given by the AI agent in Step 3. Make sure you select the correct design, not
-   > just bias from the AI's results.
-
-3. **Ask the user to explain their chosen design.** Present this to the user:
-
-   > Briefly explain the design you've selected from the previous phase, and explain from your
-   > opinion why you selected that design. Or if you have your own thoughts/modification, let the
-   > AI agent know here.
-
-   Then stop and wait for the user's explanation. Do not proceed to the analysis/diagram below
-   until they've explained their chosen design.
-
-4. **Analyze the chosen design.** Once the user has explained their chosen design, do a deep
-   dive and meticulous analysis on that chosen design.
-
-5. **Create the System Context Diagram.** Using Mermaid.js syntax, create a System Context
-   Diagram that defines the boundaries of the current solution (feature, system, etc.) we are
-   working on, and shows how the design sits within the whole app.
-
-Once this diagram is done, stop. The User Journey diagram is a separate step -
-`/phase-2-step-5` - run after you've reviewed this one.
-
-## Hard constraints
-
-- AVOID overengineering in the architecture itself — the diagrams should reflect a simple,
-  maintainable structure.
-- Name every box/component in the diagrams using plain-language intent, not jargon.
-
-## Output
-- The user's explanation of their chosen design (and any modifications)
-- Analysis of the chosen design
-- System Context Diagram (Mermaid.js)
-
-## Trigger
-```
-$ARGUMENTS = "project name"
-```
+---
+description: "Phase 2 Step 4: High-Fidelity Design"
+argument-hint: [project name]
+---
+
+## Step 0 — find which project this is for
+
+Before anything else, figure out which project this command applies to:
+
+1. If you were given a project name after the slash (e.g. `/phase-2-step-4 my-project`), use it.
+2. Otherwise, look at the subfolders under `.workflow/`:
+   - Exactly one folder → use it. Tell the user which project you picked (e.g. "Working on
+     `my-project`"), so it's never a silent guess.
+   - Two or more folders → ask the user once which project this is for. To make the question
+     useful, show the first line of each project's `00-context.md`, not just the folder name.
+   - No folders → stop and tell the user to run `/kickoff` first. Don't proceed.
+
+# Phase 2 Step 4: High-Fidelity Design
+
+## Purpose
+Create High-Level Visualizations for the Component Architecture of the chosen design, using Mermaid.js syntax.
+
+## Steps
+
+1. **Check for the previous result** from Step 3 (Quality Attribute). If it's empty or not generated, DO NOT PROCEED TO EXECUTE THIS STEP — remind the user.
+
+2. **Remind the user to double-check Step 3's result before proceeding.** Present this to the user:
+
+   > Step 3 gave you the chosen design according to the Quality Attributes you designed
+   > previously. Make sure to double-check the results from Step 3 and do your own assessment of
+   > the results given by the AI agent in Step 3. Make sure you select the correct design, not
+   > just bias from the AI's results.
+
+3. **Ask the user to explain their chosen design.** Present this to the user:
+
+   > Briefly explain the design you've selected from the previous phase, and explain from your
+   > opinion why you selected that design. Or if you have your own thoughts/modification, let the
+   > AI agent know here.
+
+   Then stop and wait for the user's explanation. Do not proceed to the analysis/diagram below
+   until they've explained their chosen design.
+
+4. **Analyze the chosen design.** Once the user has explained their chosen design, do a deep
+   dive and meticulous analysis on that chosen design.
+
+5. **Create the System Context Diagram.** Using Mermaid.js syntax, create a System Context
+   Diagram that defines the boundaries of the current solution (feature, system, etc.) we are
+   working on, and shows how the design sits within the whole app.
+
+Once this diagram is done, stop. The User Journey diagram is a separate step -
+`/phase-2-step-5` - run after you've reviewed this one.
+
+## Hard constraints
+
+- AVOID overengineering in the architecture itself — the diagrams should reflect a simple,
+  maintainable structure.
+- Name every box/component in the diagrams using plain-language intent, not jargon.
+
+## Output
+- The user's explanation of their chosen design (and any modifications)
+- Analysis of the chosen design
+- System Context Diagram (Mermaid.js)
+
+## Trigger
+```
+$ARGUMENTS = "project name"
+```

package/commands/phase-2-step-5.md

@@ -1,34 +1,34 @@
----
-description: "Phase 2 Step 5: User Journey"
-argument-hint: [project name]
----
-
-## Step 0 — find which project this is for
-
-Before anything else, figure out which project this command applies to:
-
-1. If you were given a project name after the slash (e.g. `/phase-2-step-5 my-project`), use it.
-2. Otherwise, look at the subfolders under `.workflow/`:
-   - Exactly one folder → use it. Tell the user which project you picked (e.g. "Working on
-     `my-project`"), so it's never a silent guess.
-   - Two or more folders → ask the user once which project this is for. To make the question
-     useful, show the first line of each project's `00-context.md`, not just the folder name.
-   - No folders → stop and tell the user to run `/kickoff` first. Don't proceed.
-
-# Phase 2 Step 5: User Journey
-
-## Purpose
-Create a User Journey Diagram using Mermaid.js syntax for the chosen design from Step 4 (High-Fidelity Design).
-
-## Steps
-
-1. **Check for the previous result** from Step 4 (High-Fidelity Design). If it's empty or not generated, DO NOT PROCEED — remind the user.
-2. **Create the User Journey Diagram** using Mermaid.js syntax, mapping the user's interaction flow through the system.
-
-## Output
-- User Journey Diagram (Mermaid.js)
-
-## Trigger
-```
-$ARGUMENTS = "project name"
-```
+---
+description: "Phase 2 Step 5: User Journey"
+argument-hint: [project name]
+---
+
+## Step 0 — find which project this is for
+
+Before anything else, figure out which project this command applies to:
+
+1. If you were given a project name after the slash (e.g. `/phase-2-step-5 my-project`), use it.
+2. Otherwise, look at the subfolders under `.workflow/`:
+   - Exactly one folder → use it. Tell the user which project you picked (e.g. "Working on
+     `my-project`"), so it's never a silent guess.
+   - Two or more folders → ask the user once which project this is for. To make the question
+     useful, show the first line of each project's `00-context.md`, not just the folder name.
+   - No folders → stop and tell the user to run `/kickoff` first. Don't proceed.
+
+# Phase 2 Step 5: User Journey
+
+## Purpose
+Create a User Journey Diagram using Mermaid.js syntax for the chosen design from Step 4 (High-Fidelity Design).
+
+## Steps
+
+1. **Check for the previous result** from Step 4 (High-Fidelity Design). If it's empty or not generated, DO NOT PROCEED — remind the user.
+2. **Create the User Journey Diagram** using Mermaid.js syntax, mapping the user's interaction flow through the system.
+
+## Output
+- User Journey Diagram (Mermaid.js)
+
+## Trigger
+```
+$ARGUMENTS = "project name"
+```

package/commands/phase-3.md

@@ -1,45 +1,45 @@
----
-description: "Phase 3: Implementation Plan"
-argument-hint: [project name]
----
-
-## Step 0 — find which project this is for
-
-Before anything else, figure out which project this command applies to:
-
-1. If you were given a project name after the slash (e.g. `/phase-3 my-project`), use it.
-2. Otherwise, look at the subfolders under `.workflow/`:
-   - Exactly one folder → use it. Tell the user which project you picked (e.g. "Working on
-     `my-project`"), so it's never a silent guess.
-   - Two or more folders → ask the user once which project this is for. To make the question
-     useful, show the first line of each project's `00-context.md`, not just the folder name.
-   - No folders → stop and tell the user to run `/kickoff` first. Don't proceed.
-
-# Phase 3: Implementation Plan
-
-## Purpose
-Write a comprehensive implementation plan based on the proposed plan and extensive architecture and design from Phase 1 and Phase 2.
-
-## Steps
-
-1. **Check for the previous result** from the previous step. If it's empty or not generated due to certain reason, then DO NOT PROCEED TO EXECUTE THIS STEP. Don't forget to remind the user if this happened.
-2. **Write a comprehensive implementation plan** based on the proposed plan (Phase 1: Analyze) and extensive architecture and design (Phase 2: Design - the chosen design, ATAM trade-offs, Quality Attribute results, System Context Diagram, and User Journey Diagram).
-
-## Constraints
-
-AVOID overengineering, PREFER simple, low-complexity implementations with the GOAL of high maintainability, AVOID jargons when naming function/methods/class/components/system, instead PRIORITIZE using layman's terms or prefer naming with the actual intentions of the code, the GOAL is ease of developer understanding and maintainability.
-
-## Iteration rule
-
-If, while writing the implementation plan, you find a problem that is actually a Design problem
-(not an implementation detail) - e.g. the architecture from Phase 2 doesn't actually support
-something needed - STOP and tell the user clearly, and recommend circling back to Phase 2. Do
-not silently work around a design flaw in the plan.
-
-## Output
-- A comprehensive implementation plan, written to `.workflow/<slug>/03-implement.md`
-
-## Trigger
-```
-$ARGUMENTS = "project name"
-```
+---
+description: "Phase 3: Implementation Plan"
+argument-hint: [project name]
+---
+
+## Step 0 — find which project this is for
+
+Before anything else, figure out which project this command applies to:
+
+1. If you were given a project name after the slash (e.g. `/phase-3 my-project`), use it.
+2. Otherwise, look at the subfolders under `.workflow/`:
+   - Exactly one folder → use it. Tell the user which project you picked (e.g. "Working on
+     `my-project`"), so it's never a silent guess.
+   - Two or more folders → ask the user once which project this is for. To make the question
+     useful, show the first line of each project's `00-context.md`, not just the folder name.
+   - No folders → stop and tell the user to run `/kickoff` first. Don't proceed.
+
+# Phase 3: Implementation Plan
+
+## Purpose
+Write a comprehensive implementation plan based on the proposed plan and extensive architecture and design from Phase 1 and Phase 2.
+
+## Steps
+
+1. **Check for the previous result** from the previous step. If it's empty or not generated due to certain reason, then DO NOT PROCEED TO EXECUTE THIS STEP. Don't forget to remind the user if this happened.
+2. **Write a comprehensive implementation plan** based on the proposed plan (Phase 1: Analyze) and extensive architecture and design (Phase 2: Design - the chosen design, ATAM trade-offs, Quality Attribute results, System Context Diagram, and User Journey Diagram).
+
+## Constraints
+
+AVOID overengineering, PREFER simple, low-complexity implementations with the GOAL of high maintainability, AVOID jargons when naming function/methods/class/components/system, instead PRIORITIZE using layman's terms or prefer naming with the actual intentions of the code, the GOAL is ease of developer understanding and maintainability.
+
+## Iteration rule
+
+If, while writing the implementation plan, you find a problem that is actually a Design problem
+(not an implementation detail) - e.g. the architecture from Phase 2 doesn't actually support
+something needed - STOP and tell the user clearly, and recommend circling back to Phase 2. Do
+not silently work around a design flaw in the plan.
+
+## Output
+- A comprehensive implementation plan, written to `.workflow/<slug>/03-implement.md`
+
+## Trigger
+```
+$ARGUMENTS = "project name"
+```

package/commands/phase-4.md

@@ -1,41 +1,41 @@
----
-description: "Phase 4: Postmortem"
-argument-hint: [project name]
----
-
-## Step 0 — find which project this is for
-
-Before anything else, figure out which project this command applies to:
-
-1. If you were given a project name after the slash (e.g. `/phase-4 my-project`), use it.
-2. Otherwise, look at the subfolders under `.workflow/`:
-   - Exactly one folder → use it. Tell the user which project you picked (e.g. "Working on
-     `my-project`"), so it's never a silent guess.
-   - Two or more folders → ask the user once which project this is for. To make the question
-     useful, show the first line of each project's `00-context.md`, not just the folder name.
-   - No folders → stop and tell the user to run `/kickoff` first. Don't proceed.
-
-# Phase 4: Postmortem
-
-## Purpose
-Reflect on the iteration to improve the next one.
-
-## Prerequisites
-- Phase 3 (Implement) is complete
-
-## Steps
-
-1. **What went well?** — capture successful patterns
-2. **What could be better?** — identify friction and slowdowns
-3. **What will we do differently?** — concrete improvements for next iteration
-4. **Update workflow** — if a process change is needed, update the relevant command files
-
-## Output
-- Postmortem document
-- Action items for next iteration
-- Updated workflow documentation (if needed)
-
-## Trigger
-```
-$ARGUMENTS = "project name"
-```
+---
+description: "Phase 4: Postmortem"
+argument-hint: [project name]
+---
+
+## Step 0 — find which project this is for
+
+Before anything else, figure out which project this command applies to:
+
+1. If you were given a project name after the slash (e.g. `/phase-4 my-project`), use it.
+2. Otherwise, look at the subfolders under `.workflow/`:
+   - Exactly one folder → use it. Tell the user which project you picked (e.g. "Working on
+     `my-project`"), so it's never a silent guess.
+   - Two or more folders → ask the user once which project this is for. To make the question
+     useful, show the first line of each project's `00-context.md`, not just the folder name.
+   - No folders → stop and tell the user to run `/kickoff` first. Don't proceed.
+
+# Phase 4: Postmortem
+
+## Purpose
+Reflect on the iteration to improve the next one.
+
+## Prerequisites
+- Phase 3 (Implement) is complete
+
+## Steps
+
+1. **What went well?** — capture successful patterns
+2. **What could be better?** — identify friction and slowdowns
+3. **What will we do differently?** — concrete improvements for next iteration
+4. **Update workflow** — if a process change is needed, update the relevant command files
+
+## Output
+- Postmortem document
+- Action items for next iteration
+- Updated workflow documentation (if needed)
+
+## Trigger
+```
+$ARGUMENTS = "project name"
+```