@jakkrichm/create-nexus-devflow 2.2.2 → 2.6.0

package/template/.agents/skills/20-spec/SKILL.md

@@ -1,155 +0,0 @@
----
-name: 20-spec
-description: "[devflow][D] Spec stage in DevFlow 2.0 - write the formal markdown-first specification from a stable definition."
-argument-hint: "{running-id or workspace path}"
----
-
-# Phase 20: Spec
-
-$ARGUMENTS
-
-Turn the defined work into a specification that is concrete enough for planning and explicit enough to serve as the delivery contract.
-
-## Usage
-
-```text
-20-spec {running-id or workspace path}
-```
-
-Use this when:
-
-- the goal and scope are stable
-- the team needs testable or reviewable requirements
-- planning should not start until the contract is explicit
-
-## Markdown-First Contract
-
-Write the primary stage artifact to:
-
-```text
-devflow/runs/{ID}-{slug}20-spec.md
-```
-
-using:
-
-```text
-.agent/resources/schemas/spec.template.md
-```
-
-Before writing `20-spec.md`, read `artifact_language` from `spec.template.md` and produce the artifact in that language.
-
-## Required Section Content
-
-Before completing any generated artifact:
-
-- preserve every heading required by the selected template
-- write concrete information under every heading
-- when no information exists or the section does not apply, write exactly `-`
-- never leave a heading immediately followed by another heading with no body content
-- remove template placeholders from the final artifact
-- do not invent facts merely to avoid using `-`
-- re-read the saved artifact and verify every heading satisfies this rule
-
-## Process
-
-### Loop Contract
-
-Run specification as a contract-hardening loop, not as a prose expansion of the definition.
-
-- **Intent**: produce requirements and acceptance criteria that are concrete enough for planning and review.
-- **Context**: read the run's `10-define.md`, follow its `source_discovery` link when original framing matters, and read relevant research, hard constraints, and domain or codebase decisions that shape this run's delivery contract.
-- **Action**: write requirements, acceptance criteria, constraints, and out-of-scope items, then inspect whether each requirement is testable and unambiguous.
-- **Observation**: use concrete evidence such as ambiguous wording, unchecked assumptions, edge cases, missing acceptance criteria, conflicting constraints, and implementation details that are not true constraints.
-- **Adjustment**: if facts are missing, route to `Research`; if requirements need stress-testing, use `grill-with-docs`; if module or interface boundaries affect the contract, use `codebase-design`; if scope is unstable or still contains multiple independently deliverable contracts, return to `10-define` and split the run before continuing.
-- **Stop Condition**: stop when every requirement has checkable acceptance criteria, hard constraints are explicit, out-of-scope items are visible, and `30-plan` can break the work down without inventing intent.
-- **Handoff**: `20-spec.md` must tell `30-plan` what must be delivered, how success will be checked, what constraints cannot move, and what is intentionally excluded.
-
-### 1. Read Definition Artifacts
-
-Read:
-
-- `10-define.md`
-- the shared `00-explore.md` referenced by `source_discovery` when the original framing still matters
-- research notes if they impose real constraints
-
-### 2. Write The Specification
-
-Define:
-
-- core requirements
-- acceptance criteria
-- hard constraints
-- explicit out-of-scope items
-
-The spec should be strong enough that planning can break it into executable units without guessing intent.
-
-### 3. Handle Missing Certainty
-
-If the spec cannot be written confidently:
-
-- call `Research` when facts are missing
-- use `grill-with-docs` when requirements, acceptance criteria, constraints, or out-of-scope items need to be stress-tested against scenarios and domain language
-- use `codebase-design` when requirements imply module boundaries, interface contracts, seams, or testability constraints
-- record assumptions explicitly when they are unavoidable
-
-Do not hide uncertainty inside vague requirement text.
-
-Do not combine sibling Running IDs into one spec. If this run still contains multiple independent acceptance, release, ownership, or context boundaries, stop and return to `10-define {running_id}` for an explicit split.
-
-### 4. Finalize `20-spec.md`
-
-- preserve the template headings
-- follow the `artifact_language` configured in `spec.template.md`
-- replace all placeholders
-- keep implementation details out unless they are true constraints
-- make sure the acceptance criteria can actually be checked
-
-### 5. Manual Review Soft Gate
-
-Before recommending `30-plan`, check whether the delivery contract has been human-reviewed.
-If `Approval Status` is not approved yet:
-
-- warn that planning may drift if the spec is still under review
-- recommend review of requirements, exclusions, and acceptance criteria first
-- keep `30-plan` as a soft recommendation only
-
-## Output
-
-Report:
-
-- core requirements
-- acceptance criteria
-- hard constraints
-- out-of-scope items
-- manual review warnings when the contract is still pending
-- recommended next step
-
-## Relationship To DevFlow 2.0
-
-- Classification: Mainline workflow
-- Previous state: `10-define`
-- Next state: `30-plan` when the contract is implementation-ready
-- Common companion commands: `PRD`, `Spec-Research`, `Competitor`, `Spec-Orchestrate` when product or integration context is still incomplete; support skills: `grill-with-docs`, `domain-modeling`, and `codebase-design` when the spec depends on precise domain language, durable decisions, or module/interface constraints
-
-## Sources
-
-- `AGENTS.md`
-- `docs/workspace-artifacts.md`
-- `.agent/resources/schemas/spec.template.md`
-- Related commands: `10-define`, `PRD`, `Spec-Research`, `Competitor`, `Spec-Orchestrate`, `30-plan`
-
-## Next Workflow Recommendation
-
-- **Primary**: `30-plan`
-- **Why**: The specification is now concrete enough to break into executable work.
-- **Alternatives**:
-  - `Research` - choose this when the spec still depends on missing facts.
-  - `grill-with-docs` - choose this when the spec is readable but not yet tough enough to plan from.
-  - `codebase-design` - choose this when interface shape or testability constraints must be settled before planning.
-  - `10-define` - choose this when the scope itself is still unstable.
-
-## Nexus Event
-
-- Use `Research` when a requirement, rule, or integration constraint still lacks evidence.
-- Use `Spec-Research`, `Competitor`, or `PRD` when the contract needs stronger external, product, or market framing before planning.
-- Use `grill-with-docs` when available if clarification could materially change acceptance criteria, edge cases, exclusions, or rules.

package/template/.agents/skills/30-plan/SKILL.md

@@ -1,226 +0,0 @@
----
-name: 30-plan
-description: "[devflow][D] Plan stage in DevFlow 2.0 - transform 20-spec.md into an executable task breakdown with test decisions."
----
-# Phase 30: Plan Implementation
-
-**Strict mode: planning only. Do not edit source code in this phase.**
-
-Create a codebase-informed implementation plan using `30-plan.md` as the primary artifact in DevFlow 2.0.
-
-## Usage
-
-```text
-30-plan {ID}
-```
-
-## Markdown-First Contract
-
-Use `30-plan.md` as the main planning artifact.
-
-Use controlled task-engine commands when plan status or subtask tracking must be synchronized:
-
-Record complexity, context, phases, subtasks, and validation notes directly in the stage markdown files for this running ID. Treat `30-plan.md` as the source of truth.
-
-**MANDATORY RULE:** If you create temporary script files (e.g. `.ps1`, `.sh`) to execute multiple compatibility commands in batch, save them inside the task workspace, never in the central `scripts/` directory.
-
-## Required Section Content
-
-Before completing any generated artifact:
-
-- preserve every heading required by the selected template
-- write concrete information under every heading
-- when no information exists or the section does not apply, write exactly `-`
-- never leave a heading immediately followed by another heading with no body content
-- remove template placeholders from the final artifact
-- do not invent facts merely to avoid using `-`
-- re-read the saved artifact and verify every heading satisfies this rule
-
-## Process
-
-### Loop Contract
-
-Run planning as an evidence loop, not as a one-shot outline.
-
-- **Intent**: produce a plan that lets implementation proceed without guessing scope, files, risks, or verification.
-- **Context**: read the spec, prior stage artifacts, relevant code/docs, existing commands, and any research that constrains execution.
-- **Action**: draft the smallest useful plan, then inspect whether every phase has files, dependencies, risks, verification, and a test decision.
-- **Observation**: use concrete evidence such as file paths, existing patterns, package scripts, validation commands, and unresolved assumptions.
-- **Adjustment**: if evidence is missing, search/read more, recommend `Research` or `Agent codebase-explorer`, split the work, or route back to `20-spec` when the contract is not plan-ready.
-- **Stop Condition**: stop only when phases are ordered, subtasks are scoped, verification is explicit, test decisions are recorded, and any blockers are visible.
-- **Handoff**: `30-plan.md` must give `40-execute` enough context to select one scoped unit and execute it without inventing intent.
-
-### 1. Read Task Artifacts
-
-Read:
-
-- `devflow/runs/{ID}-*20-spec.md`
-- `10-define.md` and the shared `00-explore.md` referenced by `source_discovery` when they help clarify intent
-
-### 2. Assess Complexity
-
-Use the old planning discipline:
-
-- `simple`: 1 phase, 1-3 subtasks
-- `standard`: multiple ordered phases with clear verification
-- `complex`: deeper codebase exploration, possibly specialist help
-
-If architecture or data flow is still unclear, recommend `Research` or `Agent codebase-explorer` before pretending the plan is stable.
-If domain terms, boundaries, or hard-to-reverse design choices are still questionable, use `grill-with-docs` before locking the plan.
-Use `codebase-design` when phases depend on seam placement or module interfaces. Use `tdd` when behavior-change subtasks need red-green-refactor test cases.
-
-### 3. Explore Codebase Patterns
-
-Use fast searches (`rg`, file reads) to find:
-
-- similar implementations
-- entry points
-- config and test commands
-- files likely to change
-- patterns that implementation should mirror
-
-Record important findings in `30-plan.md`. Use legacy context updates only when compatibility tooling still needs them.
-
-### 4. Build The Plan
-
-Use strict planning discipline, keeping `30-plan.md` as the main contract:
-
-- **Atomic Micro-Task Sizing (2–5 Minutes)**: Every subtask must be a small, verifiable unit that can be implemented and reviewed cleanly without context sprawl.
-- record the planning loop evidence: context read, observations, adjustments made, stop condition, and handoff notes
-- add phases in dependency order
-- include explicit files to modify or create (exact file paths)
-- include patterns to follow
-- include verification command or manual check
-- include a test decision for every subtask
-- record assumptions, scope boundaries, and risks explicitly
-
-Each subtask should answer:
-
-- what to change
-- where to change it (exact path)
-- which pattern to follow
-- how to verify it
-- whether automated tests are required, manual, or not required
-
-### 4.1 Strict TDD Task Breakdown & Test Decision Gate
-
-**STRICT MANDATE (กฎเหล็ก Unit Test & TDD)**: สำหรับทุก subtask ที่มีการเพิ่ม แก้ไข หรือเปลี่ยนแปลงการทำงานของโค้ด (Behavior Change) **ต้องระบุเป็น `Required` เสมอ** และต้องย่อยงานเป็น **TDD Triplet Sub-tasks** ดังนี้:
-
-```markdown
-- [ ] Task 1.1 [TDD-Red]: Write failing test for {feature/behavior} in {test_file} and verify failure
-- [ ] Task 1.2 [TDD-Green]: Implement minimal code in {src_file} to satisfy Task 1.1 test
-- [ ] Task 1.3 [TDD-Refactor]: Refactor logic, eliminate duplication, and verify zero regression
-```
-
-For every subtask, decide one of:
-
-- `Required`: automated tests must be created or updated (Mandatory for all behavior changes, formatted as TDD Triplet)
-- `Manual/Command Only`: verification is non-test but still explicit (Only for configuration/infrastructure tasks)
-- `Not Required`: no new automated test is needed because there is no meaningful behavior surface (Only for documentation/comments)
-
-Record:
-
-- reason
-- planned cases when tests are required (using AAA pattern: Arrange-Act-Assert)
-- verification command or manual check
-- expected result
-
-Do not use "too simple" as the only reason for skipping tests.
-
-### 5. Create Human-Readable Plan
-
-Create `30-plan.md` in the task workspace and base its structure on:
-
-```text
-.agent/resources/schemas/plan.template.md
-```
-
-Before writing `30-plan.md`, read `artifact_language` from `plan.template.md` and produce the artifact in that language.
-
-Before reporting completion:
-
-Review `{plan_md_path}` against `plan.template.md`, keep the required headings, and remove placeholder text before completion.
-
-Replace every placeholder with concrete phases, files, commands, dependencies, and verification evidence.
-Follow the `artifact_language` configured in `plan.template.md` for all plan narrative text.
-
-Create the checklist directory when detailed execution tracking is needed:
-
-```text
-devflow/runs/{ID}-*/checklists/
-```
-
-Seed at least:
-
-- `implementation-checklist.md`
-- `verification-checklist.md`
-
-Use the schema templates under `.agent/resources/schemas/` and turn approved phases/subtasks into live markdown checklist items using task markers such as `- [ ]`, `- [/]`, `- [!]`, and `- [-]` so humans can follow the run without reading the full planning narrative.
-
-### 6. Validate And Close Planning
-
-Run:
-
-Run `npm run validate` after changing the framework, templates, or shared references. For task work, manually verify that `30-plan.md` still matches the required template contract.
-
-If validation fails, repair only what is necessary and keep `30-plan.md` aligned with the corrected state.
-
-### 7. Manual Review Soft Gate
-
-Before recommending `40-execute`, check whether the plan still shows pending review.
-If `Approval Status` is still pending or major dependencies remain unresolved:
-
-- warn that implementation should wait for review
-- recommend human confirmation of sequencing, scope, and verification strategy
-- keep `40-execute` as a soft recommendation only
-
-## Output Checklist
-
-- complexity is clear
-- loop evidence is recorded: intent, context, observation, adjustment, stop condition, and handoff
-- phases are ordered by dependency
-- every subtask is scoped and verifiable
-- every subtask has a test decision
-- `30-plan.md` is written and reviewable
-- validation passes
-- manual review warning is explicit when approval is still pending
-- next command is ready
-
-## Relationship To DevFlow 2.0
-
-- Classification: Mainline workflow
-- Previous state: `20-spec`
-- Next state: `40-execute` when execution steps and verification are clear
-- Common companion commands: `Research` or `Agent` when architecture, data flow, or external constraints still need investigation; support skills: `grill-with-docs`, `domain-modeling`, `codebase-design`, `tdd`, and `to-issues` for final design stress-testing, durable terminology capture, test planning, and issue packaging
-
-## Sources
-
-- `AGENTS.md`
-- `docs/workspace-artifacts.md`
-- `.agent/resources/schemas/plan.template.md`
-- Related commands: `20-spec`, `Research`, `Agent`, `40-execute`
-
-## Next Workflow Recommendation
-
-- **Primary**: `40-execute {ID}`
-- **Why**: Approved planning is the gate before implementation in DevFlow 2.0.
-- **Alternatives**:
-  - `Research` - choose this when the plan still depends on missing evidence.
-  - `Agent codebase-explorer devflow/runs/{ID}-*/` - choose this when architecture or data flow is unclear.
-  - `grill-with-docs` - choose this when plan assumptions or design boundaries need one last adversarial pass.
-  - `codebase-design` - choose this when a plan needs clearer seams, interfaces, or test surfaces.
-  - `20-spec {ID}` - choose this when the spec itself is not strong enough for planning.
-
-## Nexus Event
-
-- Use `Research` when architecture, sequencing, or rollout decisions still depend on missing evidence.
-- Use `Agent codebase-explorer` or another specialist lane when the codebase shape or integration boundary is still unclear.
-- Use `grill-with-docs` when available if a short clarification pass could materially change sequencing, dependency order, rollout risk, or verification strategy.
-
-## Wiki Update Recommendation
-
-- **Needed**: `yes` when planning records a reusable architecture decision, project pattern, or context-loading lesson.
-- **Scope**: `project` unless the planning lesson changes DevFlow framework behavior.
-- **Reason**: Plans often discover stable patterns that future sessions should reuse.
-- **Suggested Command**: `Wiki project ingest devflow/runs/{ID}-*30-plan.md`
-

package/template/.agents/skills/40-execute/SKILL.md

@@ -1,158 +0,0 @@
----
-name: 40-execute
-description: "[devflow][D] Execute stage in DevFlow 2.0 - execute planned tasks incrementally with evidence and unit tests."
----
-# Phase 40: Execute Code
-
-Implement and execute the approved plan incrementally. Source code edits are allowed in this phase.
-
-## Usage
-
-```text
-40-execute {ID}
-```
-
-## Markdown-First Contract
-
-Use `40-execute.md` as the primary execution artifact.
-Before writing `40-execute.md`, produce the artifact in Thai (`th`).
-
-Before execution, confirm the plan is approved in the stage artifacts. Track subtask progress, execution notes, and completion evidence directly in `40-execute.md` and related stage markdown files.
-
-## Required Section Content
-
-Before completing any generated artifact:
-
-- preserve every heading required by the selected template
-- write concrete information under every heading
-- when no information exists or the section does not apply, write exactly `-`
-- never leave a heading immediately followed by another heading with no body content
-- remove template placeholders from the final artifact
-- do not invent facts merely to avoid using `-`
-- re-read the saved artifact and verify every heading satisfies this rule
-
-## Process
-
-### Loop Contract
-
-Run execution as scoped execution loops, one unit at a time.
-
-- **Intent**: complete the selected planned unit while preserving the spec, plan, and repository conventions.
-- **Context**: read `30-plan.md`, `20-spec.md`, relevant checklist items, target files, pattern files, and test decisions before editing.
-- **Action**: make the smallest useful change for the current unit, update or create tests when required, run the planned verification, and record the result.
-- **Observation**: inspect concrete evidence from diffs, command output, tests, manual checks, and checklist status before claiming progress.
-- **Adjustment**: if evidence does not match intent, fix within the current unit, capture the blocker, use `Debug`, or return to `30-plan` or `20-spec` when the work no longer matches the contract.
-- **Stop Condition**: stop the unit when the planned change is complete, verification evidence is recorded, deviations are explained, and the next unit or handoff is clear.
-- **Handoff**: `40-execute.md` must tell `50-verify` what changed, why it changed, which checks ran, what failed or was skipped, and what residual risk remains.
-
-### 1. Get Bearings
-
-Read:
-
-- `30-plan.md`
-- `20-spec.md`
-- `checklists/implementation-checklist.md` when present
-- referenced pattern files
-- `10-define.md` when the intent needs a quick reminder
-
-Confirm the current Git branch with `git branch --show-current` and use that branch as the user's chosen working branch. Do not create, switch, or checkout branches automatically.
-
-Select one scoped unit of work at a time. Do not implement the whole plan as one blob.
-
-### 2. Execute One Scoped Unit (Strict TDD Red-Green-Refactor)
-
-Use the strict coder discipline:
-
-- **STRICT MANDATE (กฎเหล็ก Unit Test & TDD)**: สำหรับทุกงานที่มีการแก้ไข logic การทำงาน ต้องสร้างหรือแก้ไข Unit Test ควบคู่กับการแก้ไขโค้ดเสมอ โดยห้ามเขียนเฉพาะ Production Code โดยไม่มีเทสต์
-- **🔴 RED (Test First)**: ออกแบบและเขียน Test Case ในไฟล์เทสต์ก่อนเสมอ แล้วรันคำสั่งเทสต์เพื่อพิสูจน์ว่า **Test ล้มเหลว (FAIL)** ตามที่คาดหวัง
-- **🟢 GREEN (Minimal Implementation)**: เขียน Production Code เท่าที่จำเป็นเพื่อให้เทสต์ผ่าน แล้วรันคำสั่งเทสต์เพื่อพิสูจน์ว่า **Test ผ่าน 100% (PASS)**
-- **🔵 REFACTOR (Clean Code)**: ปรับปรุงโครงสร้างโค้ดให้อ่านง่าย กำจัดความซ้ำซ้อน (DRY) โดยที่เทสต์ยังคงเขียว 100%
-- **Code Deletion / Reversion Rule**: หากเผลอเขียน Production Code ก่อนมีเทสต์ ให้ Revert หรือลบโค้ดส่วนนั้น แล้วเริ่มวงจร RED ก่อนเสมอ
-- start each scoped unit by naming its intent, context, expected observation, adjustment route, and stop condition
-- read referenced pattern files before editing
-- read the test decision from `30-plan.md`
-- confirm assumptions, target files, and success criteria before editing
-- preserve project style
-- run the planned verification and capture concrete terminal outputs
-- record observation, adjustment, stop condition status, and the result in `40-execute.md`
-- update checklist item status, timestamps, and evidence links as work progresses
-
-### 3. Recovery
-
-Use the old recovery discipline when blocked:
-
-- capture the blocker with evidence
-- mark failure only when the current unit truly cannot continue
-- recommend `Debug` when root cause analysis is needed
-- return to Plan when the work no longer matches the plan
-
-Use `tdd` for behavior-change implementation loops, `diagnosing-bugs` when a tight repro is needed before a fix, and `codebase-design` when implementation exposes an awkward seam or shallow module.
-
-### 4. Finalize Execution
-
-When the scoped work is complete:
-
-- summarize the completed units
-- list changed files
-- record verification performed
-- record loop evidence for each completed unit: intent, observation, adjustment, and stop condition
-- record deviations, blockers, and manual checks
-- make sure checklist statuses match the actual state of the code and tests
-- make sure `40-execute.md` is ready for Verify
-
-### 5. Manual Review Soft Gate
-
-If the plan was not clearly approved, warn that execution proceeded under review risk.
-When finishing `40-execute.md`:
-
-- record any deviation from the approved plan explicitly
-- set reviewer expectations before `50-verify`
-- keep `50-verify` as the next soft recommendation rather than an unconditional jump
-
-## Output
-
-Report:
-
-- scoped units completed
-- files changed
-- verification commands run
-- test decisions followed or changed, with reasons
-- loop evidence and handoff notes for Verify
-- blocked items or manual checks
-- next command: `50-verify {ID}`
-
-## Relationship To DevFlow 2.0
-
-- Classification: Mainline workflow
-- Previous state: `30-plan`
-- Next state: `50-verify` when scoped execution is complete
-- Common companion commands: `Debug` for blockers, `Preview` for local checks; support skills: `tdd`, `diagnosing-bugs`, and `codebase-design` for behavior changes, root-cause loops, and implementation-time design pressure
-
-## Sources
-
-- `AGENTS.md`
-- `docs/workspace-artifacts.md`
-- Related commands: `30-plan`, `Debug`, `Preview`, `50-verify`
-
-## Next Workflow Recommendation
-
-- **Primary**: `50-verify {ID}` when the planned work is complete.
-- **Why**: Implementation needs independent verification before release or human acceptance.
-- **Alternatives**:
-  - `Debug "{blocker}"` - choose this when execution is blocked by an unexplained failure.
-  - `30-plan {ID}` - choose this when the plan is incomplete or no longer matches the work.
-  - `Preview` - choose this when a local runtime or visual check is useful before formal verification.
-  - `codebase-design` - choose this when the implementation cannot be tested cleanly because the module shape is wrong.
-
-## Nexus Event
-
-- Use `Debug` when the conversation reveals an unexplained blocker, flaky behavior, or root-cause gap.
-- Use `Preview` when a runtime, UI, or local interaction check would reduce verification risk.
-- Return to `30-plan` when execution drift shows the plan no longer matches reality.
-
-## Wiki Update Recommendation
-
-- **Needed**: `yes` when coding discovers a reusable implementation pattern, gotcha, or context optimization.
-- **Scope**: `project` unless the discovery is about DevFlow itself.
-- **Reason**: Coding findings are useful only when they are stable enough to help future tasks.
-- **Suggested Command**: `Wiki project ingest devflow/runs/{ID}-*40-execute.md`

package/template/.agents/skills/50-verify/SKILL.md

@@ -1,62 +0,0 @@
----
-name: 50-verify
-description: "[devflow][D] Verify stage in DevFlow 2.0 - perform senior QA review, record evidence, and decide pass or return-to-implement."
----
-
-# Phase 50: Verify Quality
-
-Review implementation quality, run multi-lane validation, produce a verification report, and route the task forward or back to implementation.
-
-## Usage
-
-```text
-50-verify {ID}
-```
-
-## Markdown-First Contract
-
-Use `50-verify.md` as the primary verification artifact.
-Use `50-verify-impact.md` as an optional companion artifact when the run changes behavior, touches core logic, crosses integration boundaries, or needs explicit rollback and client impact analysis.
-
-## Process & Quality Gates (Two-Stage Review Pattern)
-
-### Stage 1: Spec Fidelity & Acceptance Criteria Gate
-Before evaluating technical code metrics, verify that the implementation faithfully delivers what was specified:
-1. **Acceptance Criteria Validation**: Cross-check each Acceptance Criterion (AC-1, AC-2, ...) in `20-spec.md` or `current-feature.md` and verify concrete evidence of completion.
-2. **Done-When Observable Verification**: Check that all observable conditions ("Done when...") are satisfied in the running application or test suite.
-3. **Scope Discipline**: Ensure zero scope creep (no unrequested features added) and no unfulfilled functional requirements.
-4. **Boundary & Negative Scenarios**: Verify unhappy paths, empty inputs, and error states defined in the specification.
-
-### Stage 2: Code Quality, Security & Architecture Gate
-Execute multi-lane technical verification across all essential quality dimensions:
-
-1. **Lane 1: Typecheck & Static Code Quality**:
-   - Run typecheck and static analysis (`tsc --noEmit`, `npm run lint`).
-2. **Lane 2: Automated Test Suites (Strict TDD Gate)**:
-   - Run automated unit and integration tests (`npm test`).
-   - Confirm 100% test pass rate with zero disabled or skipped tests.
-3. **Lane 3: Scrutinize QA & Edge Cases Review**:
-   - **Boundary Conditions**: Check empty inputs, 0/1 counts, off-by-one errors.
-   - **Null / Undefined Safety**: Verify nullish handling and strict type invariants.
-   - **Error Handling & Propagation**: Verify errors provide actionable diagnostics without swallowing.
-4. **Lane 4: Security & Hygiene Audit**:
-   - **Secrets Check**: Ensure no hardcoded credentials or API keys exist.
-   - **Input Sanitization**: Ensure parameterized queries and validated inputs.
-5. **Lane 5: Findings Ledger State Machine (`findings.md`)**:
-   - Inspect `devflow/context/findings.md`.
-   - **P0/P1 HARD GATE**: Any Finding of severity `P0` or `P1` in `open` or `fixed` status unconditionally blocks pass.
-6. **Lane 6: Manual Scenario Proof**:
-   - Provide clear manual verification instructions: "Where to go", "What to run/click", "What to expect".
-
-### 2. Decision & Route
-
-- **Pass**: Both Stage 1 and Stage 2 pass with 0 blockers -> Route to `60-report {ID}`.
-- **Fail**: Either Stage 1 or Stage 2 fails -> Route back to `40-execute {ID}` with exact failure evidence and remediation steps.
-
-## Output
-
-Report:
-- **Stage 1 Verdict**: Spec Fidelity & Acceptance Criteria status
-- **Stage 2 Verdict**: Technical Multi-lane quality & security matrix
-- Evidence commands and outputs
-- Next command: `60-report {ID}` (if pass) or `40-execute {ID}` (if fail)

package/template/.agents/skills/60-report/SKILL.md

@@ -1,57 +0,0 @@
----
-name: 60-report
-description: "[devflow][D] Report stage in DevFlow 2.0 - produce standardized markdown summary report with retrospective lessons learned."
-argument-hint: "{running-id or workspace path}"
----
-
-# Phase 60: Report
-
-$ARGUMENTS
-
-Produce the final human-friendly summary of the full running flow in Markdown (`60-report.md`) with retrospective lessons learned, findings summary, and release digest.
-
-## Usage
-
-```text
-60-report {running-id or workspace path}
-```
-
-## Markdown-First Contract
-
-Write the primary stage artifact to:
-
-```text
-devflow/context/current-run/60-report.md
-```
-
-> [!IMPORTANT]
-> **No Auto-Generated HTML**: ห้ามสร้างไฟล์ `60-report.html` แบบอัตโนมัติในขั้นตอนนี้! ระบบจะสร้างเฉพาะ `60-report.md` เท่านั้น หากต้องการดู HTML Report ให้เรียกคำสั่งแยก: `/report:html`
-
-## Process
-
-### 1. Gather Full Run Context & Verification Evidence
-Read all relevant stage artifacts:
-- `10-define.md`
-- `20-spec.md`
-- `30-plan.md`
-- `40-execute.md`
-- `50-verify.md`
-
-### 2. Retrospective Lessons Learned & Gotchas (Insight Extraction)
-Extract durable insights from the completed run:
-- **Reusable Patterns**: Design choices or implementations that future runs should mirror.
-- **Gotchas & Pitfalls**: Unforeseen issues or quirks encountered during execution.
-- **Unresolved Follow-ups**: Route any residual out-of-scope ideas to `devflow/ideas.md`.
-
-### 3. Produce Standardized Report (`60-report.md`)
-Structure the report in **Thai (`th`)**:
-1. **Executive Summary**: ปัญหาและแนวทางแก้ไข
-2. **Delivery Scope**: รายการฟีเจอร์และคอมโพเนนต์ที่ส่งมอบ
-3. **Verification Evidence Snapshot**: ผลการทดสอบทุก Lane
-4. **Retrospective & Lessons Learned**: บทเรียนและข้อควรระวัง
-5. **Manual Try Guide**: ขั้นตอนสำหรับมนุษย์ทดสอบระบบ
-
-## Next Workflow Recommendation
-
-- **Primary**: `70-deliver {ID}`
-- **Optional Standalone HTML**: `/report:html`