@duypham93/openkit 0.2.0

package/registry.json

@@ -0,0 +1,328 @@
+{
+  "schema": "openkit/component-registry@1",
+  "registryVersion": 1,
+  "kit": {
+    "name": "OpenKit AI Software Factory",
+    "version": "0.1.0",
+    "description": "Local component metadata for the checked-in OpenKit repository and the global-kit compatibility surface.",
+    "repositoryRoot": ".",
+    "productSurface": {
+      "current": "repository-local-openkit-runtime",
+      "emerging": "global-openkit-install",
+      "installReadiness": "emerging",
+      "migrationState": "staged-not-complete",
+      "activeRuntimeManifest": ".opencode/opencode.json",
+      "targetWrapperEntrypoint": "opencode.json",
+      "installMode": "additive-non-destructive",
+      "repositoryInternal": [
+        ".opencode/opencode.json",
+        ".opencode/workflow-state.json",
+        ".opencode/work-items/",
+        ".opencode/workflow-state.js",
+        "hooks/",
+        "agents/",
+        "skills/",
+        "commands/",
+        "context/",
+        "docs/"
+      ],
+      "globalFacing": [
+        "registry.json",
+        ".opencode/install-manifest.json"
+      ],
+      "notes": "This registry describes repository-local components that exist today and also records metadata that supports the global OpenKit kit. It does not mean the checked-in repository runtime has been removed or replaced."
+    }
+  },
+  "componentCategories": [
+    "agents",
+    "skills",
+    "commands",
+    "artifacts",
+    "runtime",
+    "hooks",
+    "docs"
+  ],
+  "components": {
+    "agents": [
+      {
+        "id": "agent.master-orchestrator",
+        "name": "Master Orchestrator",
+        "role": "primary",
+        "path": "agents/master-orchestrator.md"
+      },
+      {
+        "id": "agent.pm-agent",
+        "name": "PM Agent",
+        "role": "team",
+        "path": "agents/pm-agent.md"
+      },
+      {
+        "id": "agent.ba-agent",
+        "name": "BA Agent",
+        "role": "team",
+        "path": "agents/ba-agent.md"
+      },
+      {
+        "id": "agent.architect-agent",
+        "name": "Architect Agent",
+        "role": "team",
+        "path": "agents/architect-agent.md"
+      },
+      {
+        "id": "agent.tech-lead-agent",
+        "name": "Tech Lead Agent",
+        "role": "team",
+        "path": "agents/tech-lead-agent.md"
+      },
+      {
+        "id": "agent.fullstack-agent",
+        "name": "Fullstack Agent",
+        "role": "team",
+        "path": "agents/fullstack-agent.md"
+      },
+      {
+        "id": "agent.qa-agent",
+        "name": "QA Agent",
+        "role": "team",
+        "path": "agents/qa-agent.md"
+      },
+      {
+        "id": "agent.code-reviewer",
+        "name": "Code Reviewer",
+        "role": "helper",
+        "path": "agents/code-reviewer.md"
+      }
+    ],
+    "skills": [
+      {
+        "id": "skill.brainstorming",
+        "name": "brainstorming",
+        "path": "skills/brainstorming/SKILL.md"
+      },
+      {
+        "id": "skill.code-review",
+        "name": "code-review",
+        "path": "skills/code-review/SKILL.md"
+      },
+      {
+        "id": "skill.subagent-driven-development",
+        "name": "subagent-driven-development",
+        "path": "skills/subagent-driven-development/SKILL.md"
+      },
+      {
+        "id": "skill.systematic-debugging",
+        "name": "systematic-debugging",
+        "path": "skills/systematic-debugging/SKILL.md"
+      },
+      {
+        "id": "skill.test-driven-development",
+        "name": "test-driven-development",
+        "path": "skills/test-driven-development/SKILL.md"
+      },
+      {
+        "id": "skill.verification-before-completion",
+        "name": "verification-before-completion",
+        "path": "skills/verification-before-completion/SKILL.md"
+      },
+      {
+        "id": "skill.using-skills",
+        "name": "using-skills",
+        "path": "skills/using-skills/SKILL.md"
+      },
+      {
+        "id": "skill.writing-plans",
+        "name": "writing-plans",
+        "path": "skills/writing-plans/SKILL.md"
+      },
+      {
+        "id": "skill.writing-specs",
+        "name": "writing-specs",
+        "path": "skills/writing-specs/SKILL.md"
+      }
+    ],
+    "commands": [
+      {
+        "id": "command.task",
+        "name": "/task",
+        "path": "commands/task.md"
+      },
+      {
+        "id": "command.quick-task",
+        "name": "/quick-task",
+        "path": "commands/quick-task.md"
+      },
+      {
+        "id": "command.migrate",
+        "name": "/migrate",
+        "path": "commands/migrate.md"
+      },
+      {
+        "id": "command.delivery",
+        "name": "/delivery",
+        "path": "commands/delivery.md"
+      },
+      {
+        "id": "command.brainstorm",
+        "name": "/brainstorm",
+        "path": "commands/brainstorm.md"
+      },
+      {
+        "id": "command.write-plan",
+        "name": "/write-plan",
+        "path": "commands/write-plan.md"
+      },
+      {
+        "id": "command.execute-plan",
+        "name": "/execute-plan",
+        "path": "commands/execute-plan.md"
+      }
+    ],
+    "artifacts": [
+      {
+        "id": "artifact.tasks",
+        "name": "quick-task-cards",
+        "path": "docs/tasks",
+        "kind": "directory",
+        "optional": true
+      },
+      {
+        "id": "artifact.briefs",
+        "name": "briefs",
+        "path": "docs/briefs",
+        "kind": "directory"
+      },
+      {
+        "id": "artifact.specs",
+        "name": "specs",
+        "path": "docs/specs",
+        "kind": "directory"
+      },
+      {
+        "id": "artifact.architecture",
+        "name": "architecture",
+        "path": "docs/architecture",
+        "kind": "directory"
+      },
+      {
+        "id": "artifact.plans",
+        "name": "plans",
+        "path": "docs/plans",
+        "kind": "directory"
+      },
+      {
+        "id": "artifact.qa",
+        "name": "qa",
+        "path": "docs/qa",
+        "kind": "directory"
+      },
+      {
+        "id": "artifact.adr",
+        "name": "adr",
+        "path": "docs/adr",
+        "kind": "directory"
+      },
+      {
+        "id": "artifact.templates",
+        "name": "templates",
+        "path": "docs/templates",
+        "kind": "directory"
+      }
+    ],
+    "runtime": [
+      {
+        "id": "runtime.opencode-manifest",
+        "name": "OpenCode Runtime Manifest",
+        "path": ".opencode/opencode.json",
+        "role": "active-runtime-manifest",
+        "surface": "repository-internal"
+      },
+      {
+        "id": "runtime.workflow-state",
+        "name": "Workflow State",
+        "path": ".opencode/workflow-state.json",
+        "surface": "repository-internal"
+      },
+      {
+        "id": "runtime.workflow-state-cli",
+        "name": "Workflow State CLI",
+        "path": ".opencode/workflow-state.js",
+        "surface": "repository-internal"
+      },
+      {
+        "id": "runtime.install-manifest",
+        "name": "Install Manifest",
+        "path": ".opencode/install-manifest.json",
+        "role": "additive-install-metadata",
+        "surface": "global-facing-metadata"
+      }
+    ],
+    "hooks": [
+      {
+        "id": "hook.session-start",
+        "name": "Session Start Hook",
+        "path": "hooks/session-start"
+      },
+      {
+        "id": "hook.config",
+        "name": "Hooks Config",
+        "path": "hooks/hooks.json"
+      }
+    ],
+    "docs": [
+      {
+        "id": "doc.readme",
+        "name": "README",
+        "path": "README.md",
+        "surface": "shared"
+      },
+      {
+        "id": "doc.navigation",
+        "name": "Navigation",
+        "path": "context/navigation.md",
+        "surface": "repository-internal"
+      },
+      {
+        "id": "doc.workflow-contract",
+        "name": "Workflow Contract",
+        "path": "context/core/workflow.md",
+        "surface": "repository-internal"
+      },
+      {
+        "id": "doc.governance",
+        "name": "Governance",
+        "path": "docs/governance/README.md",
+        "surface": "repository-internal"
+      }
+    ]
+  },
+  "profiles": [
+    {
+      "id": "profile.openkit-core",
+      "name": "openkit-core",
+      "description": "Core local profile for the checked-in repository runtime, with wrapper metadata present for migration visibility but not as a replacement runtime surface.",
+      "componentRefs": [
+        "agents",
+        "skills",
+        "commands",
+        "artifacts",
+        "runtime",
+        "hooks",
+        "docs"
+      ],
+      "defaultForRepository": true
+    },
+    {
+      "id": "profile.runtime-docs-surface",
+      "name": "runtime-docs-surface",
+      "description": "Non-default local profile covering repository-internal runtime and documentation surfaces for inspection, without implying a wrapper-only, plugin-only, or destructive install model.",
+      "componentRefs": [
+        "commands",
+        "artifacts",
+        "runtime",
+        "hooks",
+        "docs"
+      ],
+      "defaultForRepository": false
+    }
+  ]
+}

package/skills/brainstorming/SKILL.md

@@ -0,0 +1,51 @@
+---
+name: brainstorming
+description: "Socratic design refinement process. Used before writing any specs or code to clarify intent and explore options."
+---
+
+# Skill: Brainstorming (Socratic Refinement)
+
+## Context
+
+When the user brings a new idea or request, or when the PM Agent or Architect Agent starts designing, this skill **must** be used before locking in a solution.
+
+Do NOT jump straight into writing a spec or code. You must go through the "ask questions - explore - converge" process first.
+
+## Execution Process
+
+### Phase 1: Context Exploration
+1. Read the user's initial request.
+2. Identify any relevant existing files.
+3. Ask clarifying questions. **Golden Rule: ask only ONE question at a time.**
+   - Do not dump a list of 5 questions on the user and overwhelm them.
+   - Ask the most important question first. Wait for the answer before asking the next one.
+   - Example: "Who is the primary user of this feature: Admin or Client?"
+
+### Phase 2: Option Generation
+Once you have enough information (no major open questions remain), do NOT choose a single solution on your own. You must present 2-3 approaches:
+
+**Proposal template:**
+```markdown
+Based on what you've shared, I see X main approaches:
+
+**Option 1: [Short name]**
+*   **How it works**: [Brief description]
+*   **Pros**: [...]
+*   **Cons / Trade-offs**: [...]
+
+**Option 2: [Short name]**
+*   **How it works**: [Brief description]
+*   **Pros**: [...]
+*   **Cons / Trade-offs**: [...]
+
+Which direction do you prefer, or do you want to combine ideas from both?
+```
+
+### Phase 3: Incremental Design
+After the user chooses an option, design the solution **one part at a time**.
+- Do not drop one giant design block on the user.
+- For example, design the database first and get feedback. Then design the API and get feedback.
+- Use visual tools when helpful (Mermaid diagrams, ASCII art).
+
+### Phase 4: Handoff
+Finish brainstorming by moving into a Product Brief or Architecture Document (depending on which agent is active), then hand off to the next agent in the pipeline.

package/skills/code-review/SKILL.md

@@ -0,0 +1,48 @@
+---
+name: code-review
+description: "Pre-review checklist and quality gates. Uses a two-stage approach: spec compliance then code quality."
+---
+
+# Skill: Code Review
+
+## Context
+
+Used by the Code Reviewer subagent, the QA Agent, or the Tech Lead Agent.
+The goal is to be the final gate that keeps bad code or off-spec code from reaching the main branch.
+
+## Required Inputs
+
+- What needs review? (files / commit / PR)
+- Comparison documents: spec (requirements), architecture (design), code standards.
+
+## Two-Stage Review Process
+
+Strictly follow these two stages in order. Do not talk about formatting or clean code if the feature itself is off-spec.
+
+### Stage 1: Spec Compliance
+**Ask exactly one question: "Does this code meet the acceptance criteria in the spec exactly, and does it avoid inventing extra features?"**
+
+- Inspect each acceptance criterion (Given - When - Then).
+- Does the code handle the edge cases the BA documented?
+- **Overscope Audit (Over-engineering)**: counter the developer instinct to "helpfully" add extra behavior. Has the code built convenience features that were never requested? (YAGNI)
+
+=> **Record Pass / Fail for Stage 1. If it fails, stop the review there and send it back to the developer. Do not continue to Stage 2.**
+
+### Stage 2: Code Quality
+Only reach this step if Stage 1 has passed. Use `context/core/code-quality.md` as the review baseline.
+
+Review by severity:
+1. **Critical / Security (Must fix immediately)**: SQL injection, leaked environment variables, crash-level memory issues.
+2. **Architecture (Needs consultation)**: wrong boundary ownership (for example, a controller doing database query logic). Escalate to Tech Lead.
+3. **Important Quality (Should fix)**: meaningless variable names (`let a = 1`), functions longer than 50 lines, badly degraded test coverage.
+4. **Minor**: brace and spacing debates. Follow the existing linter or formatter.
+
+## Checklist for a Good Review Report
+- [ ] Clearly state Stage 1 (Pass/Fail) and why.
+- [ ] Cite the exact file path and failing line number.
+- [ ] State severity clearly (Critical / Important / Minor).
+- [ ] Do not just criticize - include a concrete fix suggestion or example snippet.
+
+## Anti-Patterns to Avoid
+- Superficial review: "LGTM" without actually reading the files.
+- Fixing the code for the developer: "I'll just patch it quickly and approve." The reviewer must not touch the implementation. The developer stays responsible for the fix.

package/skills/subagent-driven-development/SKILL.md

@@ -0,0 +1,79 @@
+---
+name: subagent-driven-development
+description: "Execution engine. Dispatches fresh subagents for each task to avoid context pollution and ensures 2-stage review."
+---
+
+# Skill: Subagent-Driven Development
+
+## Context
+
+Used by the Fullstack Agent to execute an implementation plan.
+
+When working through a complex sequence of tasks, the primary agent can get overwhelmed or hallucinate because the context grows too large. Subagent-Driven Development solves this by splitting the work into tasks and dispatching a fresh subagent to handle each task individually.
+
+## Execution Process
+
+### 1. Preparation (Task Queueing)
+Read `docs/plans/YYYY-MM-DD-<feature>.md`.
+Build a queue of tasks.
+
+### 2. Batch Execution (Repeat for Each Task)
+
+Take Task N from the queue:
+
+#### Step 2a: Prepare the Subagent Payload
+Create a prompt (define it first, do not run it yet) with enough context for the subagent (usually the implementation-focused Fullstack Agent):
+- target files
+- exact code requirements from the plan
+- tests that must pass
+- explicit instruction: "Follow the active mode's validation model and the coding standards"; use TDD in full-delivery implementation work and migration validation in migration work
+
+#### Step 2b: Dispatch & Execution
+Call the tool or script that runs the subagent independently. (This may be a shell command, a `run_agent.sh` script, or an equivalent delegation mechanism.)
+
+The subagent must report one of 4 standard statuses:
+
+- `DONE`: task completed, ready for review
+- `DONE_WITH_CONCERNS`: task completed, but with concerns the controller must read before review
+- `NEEDS_CONTEXT`: missing context; must not guess
+- `BLOCKED`: cannot complete with the current scope or context
+
+#### Step 2c: Stop and Call a Reviewer (Code Reviewer Subagent)
+Do NOT mark the current task complete and continue.
+You must dispatch an independent `code-reviewer` subagent with a fresh context to evaluate the implementation.
+
+Two-stage review process (see `skills/code-review/SKILL.md`):
+- **Stage 1**: spec compliance
+- **Stage 2**: code quality
+
+Do not reverse this order.
+
+*If it fails*: send the task back to Step 2a with the review feedback.
+*If it passes*: mark the task as DONE and commit.
+
+### 3. Loop and Throughput
+Return to Step 2 for Task N+1.
+
+## Anti-Patterns to Eliminate
+- "I'll just take all 5 tasks in the plan and do them in one shot." -> **Seriously wrong**. The LLM will forget instructions midway and accumulate context garbage.
+- Skipping the code-review subagent because "I trust my own work." -> The implementer subagent can still be wrong. An independent reviewer is mandatory.
+- Letting the implementer reread the whole plan and choose scope when the controller already knows the current task. -> Wrong. The controller should provide the full task text and relevant context, not dump the whole world into the subagent.
+- Moving to the next task while spec review or quality review still has open issues. -> Wrong. A task is DONE only after it passes both gates.
+
+## Handling Implementer Status
+
+### `DONE`
+- move straight into spec review
+
+### `DONE_WITH_CONCERNS`
+- read the concerns first
+- if they affect correctness or scope, resolve them before review
+- if they are only maintainability notes, continue into review but keep them in mind for later work
+
+### `NEEDS_CONTEXT`
+- provide the missing context
+- re-dispatch the same task; do not let the implementer invent assumptions
+
+### `BLOCKED`
+- assess whether the blocker comes from missing context, an oversized task, or a bad plan
+- if needed, split the task smaller or escalate to the coordinating human or agent

package/skills/systematic-debugging/SKILL.md

@@ -0,0 +1,61 @@
+---
+name: systematic-debugging
+description: "4-phase root cause process to debug scientifically instead of blindly guessing."
+---
+
+# Skill: Systematic Debugging
+
+## Context
+
+This skill is used by any developer agent (Fullstack, QA, Tech Lead) when it hits a bug, a build error, or an unexpected test failure. LLMs tend to guess and jump into random fixes. This skill forces an engineering-style debugging path.
+
+## The Golden Rule
+**Do NOT change or fix any line of code until the ROOT CAUSE is clear.**
+
+## Additional Guardrails
+
+- Test only 1 primary hypothesis at a time
+- Do not stack multiple fixes into the same experiment
+- If you have already tried 3 fixes and the original bug keeps returning, question the pattern or architecture instead of attempting a fourth fix
+
+## 4-Phase Bug-Fix Process
+
+### Phase 1: Context and Reproduction
+Do not read code first. Go collect evidence.
+1. Capture the exact error stack trace.
+2. Identify the file and line that fails.
+3. Reproduce the failure: which environment (dev/prod) and which input trigger it?
+4. If the system has multiple boundaries (CLI -> controller -> rules, hook -> state file, command -> artifact), gather evidence at each boundary instead of jumping straight to the last layer.
+
+### Phase 2: Hypothesis Generation
+Based on the evidence, propose hypotheses for why it fails. Do NOT talk about fixes yet.
+
+* Weak guess: "Variable X does not exist, so `.length` fails."
+* Better hypothesis: "Function A expects an array, but the backend API returns `{ data: [] }` (an object), so calling `.map()` crashes."
+
+List 2-3 hypotheses. Then narrow them down by grepping and reading code until you identify the most likely root cause.
+
+⚠️ Test only 1 primary hypothesis. Do not fix three hypotheses at once and expect the tests to explain which one was correct.
+
+### Phase 3: Propose Fix
+Propose the Minimal Fix (the fewest lines changed across the fewest files).
+
+⚠️ **RED ALERT: fixing many places usually means architecture surgery.** If you realize the plan requires changing 3-4 separate logic files at once (scattered changes), stop. You are probably not fixing a bug anymore - you are papering over a broken system or bad architecture. Escalate back to the Master Orchestrator and bring in the Architect to review the system.
+
+### Phase 4: Implementation
+Follow the active mode's validation model:
+- In full-delivery implementation work, follow TDD (see `skills/test-driven-development/SKILL.md`): write a test, confirm it fails, apply the minimal fix, and confirm it passes.
+- In migration work, capture the failing compatibility evidence first, apply the minimal fix, then rerun the strongest real regression or compatibility check available.
+- In every mode, keep the fix minimal and evidence-based.
+
+If the fix does not work:
+
+1. STOP
+2. go back to Phase 1 with the new evidence
+3. if you have already tried 3 fixes and the core failure still remains, report to `MasterOrchestrator` that this may be an architecture or pattern problem rather than a local bug
+
+## Rationalization Checklist
+- [ ] Am I blindly spraying `console.log` everywhere instead of concentrating on the root cause? (If yes -> STOP)
+- [ ] Am I about to wrap everything in `try...catch` and silently swallow errors? (If yes -> STOP)
+- [ ] Have I already tried a third workaround and the same failure still looks unchanged? (The real problem may be cache or environment state. Re-check the environment instead of editing more code.)
+- [ ] Am I changing many scattered files just to make the tests green again without proving the root cause? (If yes -> STOP)

package/skills/test-driven-development/SKILL.md

@@ -0,0 +1,48 @@
+---
+name: test-driven-development
+description: "RED-GREEN-REFACTOR cycle. Enforces strictly writing failing tests before production code."
+---
+
+# Skill: Test-Driven Development (TDD)
+
+## Context
+
+This is the Iron Law for the Fullstack Agent. You are NOT ALLOWED to write any production code until a failing test proves that code needs to exist.
+
+## Execution Process (RED-GREEN-REFACTOR)
+
+### Step 1: RED (Write a Failing Test)
+1. Pick one small task from the implementation plan.
+2. Write **one** test case for that behavior.
+3. Run the repository's defined test command for the language or framework in use. If the repo does not define a standard command, stop and report the missing validation path instead of guessing.
+4. **Mandatory validation**: the test MUST fail. It must fail for the right reason (for example, `ReferenceError: function is not defined`, or `Expected true but got false`).
+   - If the test passes immediately -> the test is wrong, delete it and rewrite it.
+
+### Step 2: GREEN (Write the Minimum Code)
+1. Write **only enough code to make that one test pass**.
+2. **Lazy Code Rule**: return a hardcoded value if that is enough to make the test pass. Do not think about future needs (YAGNI - You Aren't Gonna Need It).
+3. Run the tests again.
+4. **Mandatory validation**: the test must PASS. If it does not, keep fixing until it passes. Do not add extra features.
+
+### Step 3: REFACTOR
+When (and only when) all tests are green:
+1. Review the code: is there duplication (DRY)? Are names understandable? Is the design still sound?
+2. Refactor the code.
+3. Run the tests again. If any test fails -> revert the refactor immediately or repair it quickly.
+
+## Anti-Patterns to Eliminate and Required Responses
+
+| Rationalization | Required response |
+|-----------------|-------------------|
+| "This is too simple, writing a test will take longer, I'll just code it." | **STOP.** Delete the code you just wrote and write the test first, even for a simple `add(a, b)` function. |
+| "I'll write 5 tests at once and then code it all in one pass." | **Stop.** One RED, one GREEN, one REFACTOR. Do not batch them together. |
+| "UI testing is too hard, I'll skip TDD for this part." | You may skip it only if the user explicitly allows it. Prefer separating logic from UI so the logic can still be tested. |
+| "The test failed and I already know the issue, so I'll fix files A, B, and C at once." | The root cause still lives in one place. Find it and fix the right place. Read `systematic-debugging`. |
+
+## Checklist for a Complete Cycle
+- [ ] Test written and run (FAIL)
+- [ ] Error message read and understood
+- [ ] Minimal production code written
+- [ ] Test rerun (PASS)
+- [ ] Nearby code cleaned up (REFACTOR)
+- [ ] Commit made (each GREEN/REFACTOR is a chance for a small commit)

package/skills/using-skills/SKILL.md

@@ -0,0 +1,39 @@
+---
+name: using-skills
+description: "Meta-skill: Teaches agents how to discover, evaluate, and invoke skills. Loaded at session start."
+---
+
+# Skill Usage Guide - Meta-Skill
+
+## What Skills Mean
+
+In the AI Software Factory, "Skills" are standard operating procedures that define how the system should work. When a situation matches a skill, you **must** follow that skill instead of improvising from raw LLM instinct.
+
+## Instruction Priority
+
+When instructions conflict, apply this order (1 is highest):
+
+1. **Current user prompt**: direct instructions from the user in the current message
+2. **Skill instructions**: guidance inside the active `SKILL.md`
+3. **Agent role instructions**: the agent's role and constraints (for example, `QA Agent does not edit code`)
+4. **General system prompt**: the base LLM behavior
+
+## How to Use a Skill
+
+When you identify a situation (for example: need to write a plan, fix a bug, or test code), follow these steps:
+
+1. **Identify**: "I need to create an implementation plan"
+2. **Discover**: "Let me use the tool to read `skills/writing-plans/SKILL.md`"
+3. **Read**: use `view_file` (or the equivalent tool) to read the ENTIRE `SKILL.md`
+4. **Execute**: apply the steps from that file
+
+## Warning: Rationalization Prevention
+
+LLM instinct often tries to short-circuit the process. Watch for these faulty thoughts:
+
+| Bad thought (Rationalization) | Correct action |
+|--------------------------------|----------------|
+| "This file is easy, I'll just fix it without reporting to the Master Orchestrator." | Stop. Follow the role boundary. Report to the Master Orchestrator first. |
+| "I already know how to write plans, I don't need to reread `skills/writing-plans/SKILL.md`." | No. Every time you write a plan, reread the skill so you are using the latest checklist. |
+| "This bug is obvious, I can skip root-cause analysis and fix it directly." | No. Use `systematic-debugging`. Root cause analysis is mandatory first. |
+| "The user said it's urgent, so I'll skip the test-writing step (TDD)." | In full-delivery implementation, TDD remains the default unless the user **very explicitly** says "Skip TDD". In migration mode, follow the migration validation model instead of forcing fake TDD. |