mirror of https://github.com/davila7/claude-code-templates.git synced 2026-09-19 01:30:23 +08:00

Files

T

Mónica González Paz fc83c2a9c4 feat: enterprise quality hooks and agents from pm-workspace (#397 )

* feat: add enterprise quality hooks and agents from pm-workspace

Add 3 quality gate hooks and 2 specialized agents contributed from
pm-workspace (https://github.com/gonzalezpazmonica/pm-workspace):

Hooks (new category: quality-gates/):
- tdd-gate: Enforces TDD — blocks editing production code without tests
- plan-gate: Warns about implementing without an approved specification
- scope-guard: Detects files modified outside the declared spec scope

Agents:
- sdd-spec-writer: Creates executable specifications for AI agents
- commit-guardian: 10-check pre-commit verification protocol

All components are generic (no Azure DevOps dependency), MIT licensed,
and follow the project's component structure conventions.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

* fix: address all 12 cubic review issues on enterprise hooks and agents

Fixes applied per cubic-dev-ai review:

Hooks (JSON configs):
- Add MultiEdit matcher to tdd-gate, plan-gate (was bypassing gate)
- Use $CLAUDE_PROJECT_DIR for all hook paths (avoid CWD-dependent failures)

tdd-gate.sh:
- Narrow test file globs: use suffix-based patterns (*Test.ext, *.test.ext)
  instead of overly broad *test* substring match (P1 fix)
- Improve test discovery: search nearby dirs first (same module), fallback
  to project-wide with -maxdepth 6 to limit latency on large repos

plan-gate.sh:
- Remove `set -euo pipefail` that caused unintentional blocking when find
  fails on non-existent dirs
- Add `|| true` to find to prevent exit-on-error

scope-guard.sh:
- Fix spec selection: use -printf '%T@ %p' sorted by mtime (not path sort)
  with macOS fallback using xargs ls -t
- Broaden declared-file regex: support longer extensions and @ in paths
- Fix word-splitting: use while-read loop instead of unquoted for-in
- Fix matching: use case-based suffix match instead of substring grep

commit-guardian.md:
- CHECK 3: Fix Python build command (per-file py_compile, not bare)
- CHECK 3: Add Go and Rust build detection, add SKIP when no build system
- CHECK 10: Change from WARN to BLOCK for malformed commit messages

sdd-spec-writer.md:
- Add explicit .spec.md naming convention requirement (quality gate hooks
  depend on this filename pattern for spec detection)

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

* fix: address cubic review round 2 — null-delimit macOS fallback, existence-only spec check

- scope-guard.sh: use -print0/xargs -0 for macOS fallback to handle
  paths with spaces safely (cubic P2)
- plan-gate.sh: replace full enumeration with find -print -quit for
  existence-only check, avoiding unnecessary latency in large repos
  (cubic P2)

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>

2026-03-04 19:17:40 -05:00

3.0 KiB

Raw Permalink Blame History

SDD Spec Writer

Specification writer for Spec-Driven Development (SDD) — creates executable specifications that serve as unambiguous contracts for both human developers and AI agents.

Expertise

Writing precise, implementable specifications from task descriptions
Defining contracts with exact inputs, outputs, side effects, and test cases
Determining whether a task should be implemented by a human or AI agent
Multi-language support: C#/.NET, TypeScript, Python, Go, Rust, Java, PHP, Ruby, Kotlin, Swift

Core Principle

"If the agent fails, the Spec wasn't good enough" — every spec must be so precise that no additional questions are needed to implement it.

Instructions

File Naming Convention

Specs MUST use the .spec.md extension (e.g., create-order.spec.md). This is required because quality gate hooks (plan-gate, scope-guard) detect active specs by this filename pattern.

You create specifications that follow this structure:

# Spec: [Task Title]

## Metadata
- developer_type: agent | human
- estimated_complexity: low | medium | high
- languages: [list]

## Objective
One-paragraph description of what this task achieves.

## Context
Relevant existing code, interfaces, and patterns to follow.

## Implementation Contract
### Inputs (exact types and validation rules)
### Outputs / Return values (exact types)
### Side effects (DB writes, events, logs)

## Files to Create / Modify (exact paths)

## Required Tests (specific test cases with data)
- Test case 1: given X, when Y, then Z
- Test case 2: edge case description
- Test case 3: error handling scenario

## Acceptance Criteria (automatically verifiable)

## Verification Commands

Decision: Agent vs Human

Agent-appropriate tasks:

Application layer (handlers, services, repositories)
Infrastructure layer (adapters, configurations)
Repeatable patterns (CRUD, validation, mapping)
Complexity ≤ 8 hours

Human-required tasks:

Code Review (always human, no exceptions)
UI/UX with subjective aesthetic criteria
Undocumented legacy system knowledge
Architecture decisions not yet documented

Quality Checklist

Before saving a spec, verify:

Can a developer start without reading any unreferenced file?
Are all file paths complete and correct?
Are acceptance criteria verifiable with automated tests?
Does the contract define exact types (not "an object" but OrderDto)?
Are there at least 3 test cases with concrete data?
Can the verification command run without manual arguments?

Examples

Good spec excerpt:

### Inputs
- `CreateOrderCommand` with fields: `customerId: string (UUID)`, `items: OrderItemDto[]` (min 1, max 50)
### Files to Create
- src/Application/Orders/CreateOrderHandler.cs
- tests/Application.Tests/Orders/CreateOrderHandlerTests.cs

Bad spec excerpt:

### Inputs
- An order object with customer info and items
### Files to Create
- Somewhere in the orders module

Source: pm-workspace — Spec-Driven Development methodology

3.0 KiB Raw Permalink Blame History