Skip to content

Releases: shinpr/claude-code-workflows

Release: v0.22.8

Choose a tag to compare

@shinpr shinpr released this 28 Jul 02:45
a52bbcf

This release improves Opus 5 workflow efficiency and strengthens execution contracts across agents.

Highlights

  • Bounds exploration and implementation to approved scope, Direct MVP, and total change budgets.
  • Improves handoffs for quality, integration-test, security, and final verification flows.
  • Adds irreversible-risk coverage, shared-mutation route parity, and consumer-observable capability checks.
  • Removes model-known and duplicated guidance from shared coding, testing, and frontend skills while preserving broad discovery and repository-specific rules.
  • Preserves false-positive test guardrails and gates bundle/rendering fixes on approved scope and measurable evidence.
  • Keeps generated plugin metadata synchronized.

Release: v0.22.7

Choose a tag to compare

@shinpr shinpr released this 26 Jul 11:20
7955a46

This release refines development workflows to prioritize required value and minimize unnecessary design surface.

Highlights

  • Adds evidence-backed Design Convergence through Direct MVP, Failed Items, Adopted Additions, and Rejected Additions.
  • Keeps quality fixes within the confirmed task scope and improves review routing for missing inputs.
  • Consolidates prompt guidance and synchronizes all plugin distributions.

Release: v0.22.6

Choose a tag to compare

@shinpr shinpr released this 19 Jul 09:54
56ab6c1

What's Changed

  • Updated TypeScript and React guidance to follow each project's configured tooling, compatibility targets, and quality signals.
  • Made test guidance project-aware across runners, file conventions, network mocks, browser harnesses, and configured quality thresholds.
  • Added verification-aware execution for TDD, behavior-preserving refactors, blocked bug reproductions, and non-executable deliverables.
  • Improved integration and E2E test selection with explicit lanes, deduplication, scoring criteria, per-feature budgets, and existing-harness reuse.
  • Refined implementation guidance for fallback observability, impact analysis, cleanup scope, authentication and authorization review, and targeted test execution.
  • Reduced unnecessary external research and alternative generation while preserving meaningful implementation strategy decisions.
  • Aligned task analysis, planning, execution, and review handoffs, including Work Plan review gates, retry safeguards, and affected-verifier reruns.
  • Consolidated external-resource discovery into a single declaration after the required domain context is collected.

Release: v0.22.5

Choose a tag to compare

@shinpr shinpr released this 15 Jul 14:41
36bf637

What's Changed

  • Improved Design Doc reviews by validating adopted designs against confirmed requirements and component contracts.
  • Kept confirmed scope and analysis context consistent across design and review workflows.

Release: v0.22.4

Choose a tag to compare

@shinpr shinpr released this 12 Jul 06:12
7bedf37

Changed

  • Agent definitions now declare their skills frontmatter as a YAML list instead of a comma-separated string, matching the format documented for subagent frontmatter. Skill names are unchanged, so agent behavior is identical. The tools field remains comma-separated, per its documented form.

Release: v0.22.3

Choose a tag to compare

@shinpr shinpr released this 06 Jul 06:14
e8b4c7d

Patch release adding an evidence-backed assumption check to the design-doc workflow.

Changes

  • Behavioral assumption verification: Design docs often rely on unstated behavioral claims — a framework/library default, a capability assumed already provided, or a feature assumed already implemented — that flow into implementation unverified. The existing dependency check only confirmed that a component exists, not that it behaves as assumed. Each relied-upon behavioral claim now attaches evidence (codebase file:line, command result, or authoritative doc) at design time, or is recorded as an unverified assumption bound to a follow-up.
  • Generator (technical-designer, backend + frontend): a Behavioral Claim Verification step records each claim with Confirmed: Yes and its evidence, or Confirmed: No plus a matching Risks and Mitigation row naming how it will be verified during implementation (command, test, or code-inspection point) or guarded by a fallback.
  • Template (design-template): an Assumed Behaviors slot in the Agreement Checklist, reusing the existing Evidence/Confirmed pattern; the restated claim links the slot row to its Risks and Mitigation row.
  • Reviewer (document-reviewer): a behavioral-claim evidence check flags, as an important feasibility issue, any relied-upon claim that is absent from the slot, Confirmed: Yes without evidence, or Confirmed: No without a matching Risks and Mitigation row.

Release: v0.22.2

Choose a tag to compare

@shinpr shinpr released this 30 Jun 04:24
66e3b29

Fixed

  • Subagents orchestration guide: enforce fresh subagent invocation. The Execution Method section now states that each subagent invocation is a fresh Agent tool call that isolates each phase's context. A SendMessage resume reuses the prior agent's context and breaks that isolation, so it is no longer an implicit option. This prevents the orchestrator from continuing a completed subagent and silently disrupting the workflow.

Release: v0.22.1

Choose a tag to compare

@shinpr shinpr released this 29 Jun 04:51
11e0047

Patch release hardening the task-executor agents.

Changes

  • Unimplemented dependency handling: The executor now treats a missing or unimplemented dependency as a stop condition only when it prevents preserving the required contract and no local, reversible construct (local slice or contract-preserving stub/adapter) can satisfy it. Otherwise it proceeds with the local approach and records the integration handoff; genuinely undecidable architectural trade-offs escalate.
  • Escalation detail completeness: Design-compliance escalations now populate every field the escalation schema requires, with the Design Doc requirement mapped to design_doc_expectation and the actual situation (absent dependency / undecided decision) mapped to actual_situation.

Release: v0.22.0

Choose a tag to compare

@shinpr shinpr released this 24 Jun 13:14
6390869

Highlights

  • Added the new llm-friendly-context skill for clearer LLM-facing prompts, handoffs, generated artifacts, and instructions.
  • Wired llm-friendly-context into artifact-producing agents and recipe prompt/artifact creation points.
  • Added document-reviewer coverage for LLM-facing artifact clarity, including ambiguous downstream execution and non-executable downstream work.
  • Strengthened task-decomposer self-checks to reduce ambiguous task files and preserve consistency with the Work Plan and related design artifacts.
  • Added llm-friendly-context to the task analyzer skill index and README skill listings.
  • Bumped package and plugin versions to 0.22.0.

Release: v0.21.3

Choose a tag to compare

@shinpr shinpr released this 23 Jun 08:55
d238b9b

Strengthens failure-mode and spec-completeness coverage across the planning agents so a feature's combinatorial shape is forced into a verifiable contract instead of slipping through planning, task decomposition, and review.

Improvements

  • New failure-mode categorymissing-sort-key ordering added to the domain-independent Failure Mode Checklist (ordering when some elements lack the sort key). The work plan now enumerates nine categories, and the document reviewer flags it when applicable.
  • Mode × branch combination expansion — when a change adds a mode, flag, or variant that overlays an existing selection / ordering / filtering / display branch, acceptance-criteria drafting now requires expanding the combination of the new value with each existing branch value. Catches modes that take effect on one branch while silently no-opping on the others.
  • Reset/clear lifecycle as a contract — the Design Doc Client State Design table gains a Reset/Clear Behavior column, and the work planner records "state returns to its unused/default value on reset" as a state-lifecycle negative so it is verified rather than assumed.