agentic-devtools 0.2.67__tar.gz → 0.2.70__tar.gz

agentic_devtools-0.2.70/.github/ISSUE_TEMPLATE/speckit-test.md

@@ -0,0 +1,62 @@
+---
+name: SpecKit Trigger Test
+about: Test issue for manually validating the SpecKit GitHub Action trigger
+title: "[SpecKit Test] "
+labels: ''
+assignees: ''
+---
+
+## Purpose
+
+This is a test issue for validating the **SpecKit Issue Trigger** GitHub Action.
+
+Add the `speckit` label to this issue to trigger automatic specification generation.
+
+## Feature Description
+
+<!--
+  Describe the feature you want SpecKit to generate a specification for.
+  Be as detailed as possible — the AI will use this to generate a complete spec.
+-->
+
+**What feature should be specified?**
+
+<!-- Replace this line with your feature description -->
+
+## Expected Behavior
+
+When the `speckit` label is applied to this issue, the GitHub Action should:
+
+1. ✅ Post a "Specification Creation Started" comment within 30 seconds
+2. ✅ Replace the `speckit` label with `speckit:processing`
+3. ✅ Generate a feature specification via the Copilot SDK
+4. ✅ Create a new branch named `NNN-feature-name`
+5. ✅ Commit the generated `spec.md` to that branch
+6. ✅ Open a Pull Request with the specification
+7. ✅ Post a "Specification Created Successfully" comment with links
+8. ✅ Replace `speckit:processing` with `speckit:completed`
+
+## Validation Checklist
+
+- [ ] "Started" comment posted within 30 seconds of label application
+- [ ] `speckit:processing` label appears on the issue
+- [ ] Workflow run is visible in the Actions tab
+- [ ] A new branch `NNN-*` is created in the repository
+- [ ] `spec.md` exists in `specs/NNN-*/` with correct content
+- [ ] Spec contains `Source Issue: #N (URL)` reference
+- [ ] Pull Request is created with `Relates to #N` in description
+- [ ] "Completed" comment includes links to spec file and PR
+- [ ] `speckit:completed` label replaces `speckit:processing`
+
+## Troubleshooting
+
+If the action fails:
+
+1. Check the [Actions tab](../../actions/workflows/speckit-issue-trigger.yml) for logs
+2. Verify the COPILOT_APP_ID and COPILOT_APP_PRIVATE_KEY secrets are configured
+3. Ensure the `SPECKIT_TRIGGER_LABEL` repository variable matches the label used
+4. Review the "Failed" comment on this issue for specific error details
+
+---
+
+> **Note**: This template is for testing only. For real features, create a regular issue and apply the `speckit` label.

agentic_devtools-0.2.70/.github/agents/speckit.analyze.agent.md

@@ -0,0 +1,274 @@
+---
+description: Perform a non-destructive cross-artifact consistency and quality analysis across spec.md, plan.md, and tasks.md after task generation.
+---
+
+## User Input
+
+```text
+$ARGUMENTS
+```
+
+You **MUST** consider the user input before proceeding (if not empty).
+
+## Goal
+
+Identify inconsistencies, duplications, ambiguities, and underspecified items across the three core artifacts (`spec.md`, `plan.md`, `tasks.md`) before implementation. This command MUST run only after `/speckit.tasks` has successfully produced a complete `tasks.md`.
+
+## Operating Constraints
+
+**STRICTLY READ-ONLY**: Do **not** modify any files. Output a structured analysis report. Offer an optional remediation plan (user must explicitly approve before any follow-up editing commands would be invoked manually).
+
+**Constitution Authority**: The project constitution (`.specify/memory/constitution.md`) is **non-negotiable** within this analysis scope. Constitution conflicts are automatically CRITICAL and require adjustment of the spec, plan, or tasks—not dilution, reinterpretation, or silent ignoring of the principle. If a principle itself needs to change, that must occur in a separate, explicit constitution update outside `/speckit.analyze`.
+
+## Execution Steps
+
+### 1. Initialize Analysis Context
+
+Run `.specify/scripts/bash/check-prerequisites.sh --json --require-tasks --include-tasks` once from repo root and parse JSON for FEATURE_DIR and AVAILABLE_DOCS. Derive absolute paths:
+
+- SPEC = FEATURE_DIR/spec.md
+- PLAN = FEATURE_DIR/plan.md
+- TASKS = FEATURE_DIR/tasks.md
+
+Abort with an error message if any required file is missing (instruct the user to run missing prerequisite command).
+For single quotes in args like "I'm Groot", use escape syntax: e.g 'I'\''m Groot' (or double-quote if possible: "I'm Groot").
+
+### 2. Load Artifacts (Progressive Disclosure)
+
+Load only the minimal necessary context from each artifact:
+
+**From spec.md:**
+
+- Overview/Context
+- Functional Requirements
+- Non-Functional Requirements
+- User Stories
+- Edge Cases (if present)
+
+**From plan.md:**
+
+- Architecture/stack choices
+- Data Model references
+- Phases
+- Technical constraints
+
+**From tasks.md:**
+
+- Task IDs
+- Descriptions
+- Phase grouping
+- Parallel markers [P]
+- Referenced file paths
+
+**From fr-coverage.json (if present in FEATURE_DIR):**
+
+- Load `FEATURE_DIR/fr-coverage.json` if it exists
+- This file contains deterministic FR coverage data produced by `agdt-speckit-validate-frs`
+- The data is pre-validated and should be reported as-is in the Coverage Summary section
+- Do **not** re-evaluate FR coverage — use these results directly
+- Include the `covered` and `uncovered` FR lists in the Coverage Gaps detection pass
+
+**From constitution:**
+
+- Load `.specify/memory/constitution.md` for principle validation
+- Load `.specify/memory/markdown-rules.md` and apply it to all fenced code blocks in generated output.
+
+### 3. Build Semantic Models
+
+Create internal representations (do not include raw artifacts in output):
+
+- **Requirements inventory**: Each functional + non-functional requirement with a stable key (derive slug based on imperative phrase; e.g., "User can upload file" → `user-can-upload-file`)
+- **User story/action inventory**: Discrete user actions with acceptance criteria
+- **Task coverage mapping**: Map each task to one or more requirements or stories (inference by keyword / explicit reference patterns like IDs or key phrases)
+- **Constitution rule set**: Extract principle names and MUST/SHOULD normative statements
+
+### 4. Detection Passes (Token-Efficient Analysis)
+
+Focus on high-signal findings. Limit to 50 findings total; aggregate remainder in overflow summary.
+
+**Scope distinction**: Category A detects duplicate *requirements* (in spec.md). Category G detects duplicate *tasks* (in tasks.md). These are complementary passes operating on different artifact types.
+
+#### A. Duplication Detection
+
+- Identify near-duplicate requirements
+- Mark lower-quality phrasing for consolidation
+
+#### B. Ambiguity Detection
+
+- Flag vague adjectives (fast, scalable, secure, intuitive, robust) lacking measurable criteria
+- Flag unresolved placeholders (TODO, TKTK, ???, `<placeholder>`, etc.)
+
+#### C. Underspecification
+
+- Requirements with verbs but missing object or measurable outcome
+- User stories missing acceptance criteria alignment
+- Tasks referencing files or components not defined in spec/plan
+
+#### D. Constitution Alignment
+
+- Any requirement or plan element conflicting with a MUST principle
+- Missing mandated sections or quality gates from constitution
+
+#### E. Coverage Gaps
+
+- Requirements with zero associated tasks
+- Tasks with no mapped requirement/story
+- Non-functional requirements not reflected in tasks (e.g., performance, security)
+- **FR coverage data**: If `fr-coverage.json` was loaded, use its deterministic
+  `covered`/`uncovered` lists as the authoritative source for FR-to-task coverage.
+  Report any `uncovered` FRs as coverage gap findings (severity depends on context).
+
+#### F. Inconsistency
+
+- Terminology drift (same concept named differently across files)
+- Data entities referenced in plan but absent in spec (or vice versa)
+- Task ordering contradictions (e.g., integration tasks before foundational setup tasks without dependency note)
+- Conflicting requirements (e.g., one requires Next.js while other specifies Vue)
+- Missing Phase Mapping table: when plan and tasks phase structures differ (in numbering, count, or organizational scheme, e.g., domain-driven vs. story-driven) but `tasks.md` lacks a "Phase Mapping: Plan → Tasks" table — severity HIGH
+- Stale Phase Mapping references: when the Phase Mapping table in `tasks.md` references plan phases not present in `plan.md` — severity MEDIUM
+
+#### G. Task Deduplication
+
+Detect duplicate, overlapping, or conflicting tasks in `tasks.md`. This pass operates on *tasks* (not requirements — that is Category A's scope).
+
+**Comparison Dimensions** — Evaluate each pair/cluster of tasks across three independent dimensions:
+
+1. **Description similarity** — Do the tasks express substantially the same intent or outcome? A strong match means the tasks would produce the same deliverable if implemented independently; mere keyword overlap is insufficient.
+2. **File path overlap** — Do the tasks target a majority (≥50%) of the same files or directories? A strong match means most of the modified files are shared.
+3. **Code section overlap** — Do the tasks name the same function, class, method, or module-level section? A strong match means both tasks explicitly reference the same code symbol or section heading.
+
+Each dimension is evaluated independently. A finding MAY be supported by one or more dimensions.
+
+**Classification Rules** — Classify each finding as one of:
+
+| Overlap Type | Definition | Severity |
+|--------------|-----------|----------|
+| `duplicate` | Tasks are materially redundant — same work, same scope | CRITICAL |
+| `conflicting` | Tasks prescribe contradictory or incompatible outcomes for the same scope | CRITICAL |
+| `overlapping` (≥2 dimensions match strongly) | Tasks share meaningful scope across multiple dimensions but are not fully redundant | CRITICAL |
+| `overlapping` (exactly 1 dimension matches strongly) | Tasks share scope in a single dimension only | HIGH |
+
+**Severity Decision Tree**:
+
+1. Is the cluster a duplicate (same work, same scope)? → CRITICAL
+2. Is the cluster conflicting (contradictory outcomes)? → CRITICAL
+3. Is the cluster overlapping with ≥2 dimensions matching strongly? → CRITICAL
+4. Is the cluster overlapping with exactly 1 dimension? → HIGH
+
+**Grouping Rules** — Use transitive closure to identify overlap clusters:
+
+- If task A overlaps task B, and task B overlaps task C, all three form one cluster
+- Emit one finding per cluster (not pairwise)
+- The grouped finding severity is the highest severity present in the cluster
+
+**Structured Output Contract** — Each Category G finding MUST include:
+
+- `overlap_type`: one of `duplicate`, `overlapping`, `conflicting`
+- `severity`: one of `CRITICAL`, `HIGH`
+- `task_ids`: array of implicated task identifiers
+- `dimensions`: array of which dimensions triggered (from: `description`, `file_path`, `code_section`)
+- `rationale`: concise explanation (max 500 characters)
+
+**Edge Case Handling**:
+
+- Similar descriptions but different file scopes → at most `overlapping` / `HIGH` (single dimension)
+- Same file but clearly different code sections → favor `overlapping` or no finding over `duplicate`
+- Mixed-relationship clusters (3+ tasks) → use highest severity present; represent the dominant issue
+- Broad-vs-narrow scope (one task nests within another) → treat as `overlapping` unless materially redundant
+- Missing dimensions (task lacks file paths or code section info) → evaluate only available dimensions; do not infer missing data
+- Contradictory verbs (one task adds, another removes same thing) → classify as `conflicting`
+- Single-dimension-only evidence → maximum severity is `HIGH`
+
+**Read-Only Constraint**: Category G MUST NOT modify, delete, merge, or rewrite tasks. It reports findings only. Any future deduplication action belongs in `speckit.tasks` (opt-in, not part of analysis).
+
+**Required Structured JSON Block**: After the findings table, emit a `### Category G Structured Findings` section containing a JSON array of finding objects. This section is **required** when Category G findings exist (ensures the Structured Output Contract fields are always machine-parseable):
+
+```json
+[
+  {
+    "id": "F-01",
+    "overlap_type": "duplicate",
+    "severity": "CRITICAL",
+    "task_ids": ["T001", "T002"],
+    "dimensions": ["description", "file_path"],
+    "rationale": "Tasks T001 and T002 both implement user authentication with identical file targets and matching descriptions."
+  }
+]
+```
+
+> **Output format**: The JSON array in the report MUST be emitted as **raw JSON without Markdown code fences**. The fenced block above is illustrative only (showing the schema). In actual output, emit the JSON directly so downstream parsers can extract it without stripping fence markers.
+
+### 5. Severity Assignment
+
+Use this heuristic to prioritize findings:
+
+- **CRITICAL**: Violates constitution MUST, missing core spec artifact, or requirement with zero coverage that blocks baseline functionality; task deduplication finding — duplicate tasks, conflicting tasks, or multi-dimension overlap (≥2 dimensions)
+- **HIGH**: Duplicate or conflicting requirement, ambiguous security/performance attribute, untestable acceptance criterion; task deduplication finding — single-dimension overlap
+- **MEDIUM**: Terminology drift, missing non-functional task coverage, underspecified edge case
+- **LOW**: Style/wording improvements, minor redundancy not affecting execution order
+
+### 6. Produce Compact Analysis Report
+
+Output a Markdown report (no file writes) with the following structure:
+
+## Specification Analysis Report
+
+| ID | Category | Severity | Location(s) | Summary | Recommendation |
+|----|----------|----------|-------------|---------|----------------|
+| F-01 | Duplication | HIGH | spec.md:L120-134 | Two similar requirements ... | Merge phrasing; keep clearer version |
+
+(Add one row per finding; generate sequential IDs in `F-NN` format — where F = Finding — shared across all categories.)
+
+**Coverage Summary Table:**
+
+| Requirement Key | Has Task? | Task IDs | Notes |
+|-----------------|-----------|----------|-------|
+
+**Constitution Alignment Issues:** (if any)
+
+**Unmapped Tasks:** (if any)
+
+**Metrics:**
+
+- Total Requirements
+- Total Tasks
+- Coverage % (requirements with >=1 task)
+- Ambiguity Count
+- Requirement Duplication Count (Category A)
+- Critical Issues Count
+- Task Deduplication Finding Count
+- Task Deduplication by Type (duplicate / overlapping / conflicting)
+- Multi-Task Group Count (findings involving >2 tasks)
+
+### 7. Provide Next Actions
+
+At end of report, output a concise Next Actions block:
+
+- If CRITICAL issues exist: Recommend resolving before `/speckit.implement`
+- If only LOW/MEDIUM: User may proceed, but provide improvement suggestions
+- Provide explicit command suggestions: e.g., "Run /speckit.specify with refinement", "Run /speckit.plan to adjust architecture", "Manually edit tasks.md to add coverage for 'performance-metrics'"
+
+### 8. Offer Remediation
+
+Ask the user: "Would you like me to suggest concrete remediation edits for the top N issues?" (Do NOT apply them automatically.)
+
+## Operating Principles
+
+### Context Efficiency
+
+- **Minimal high-signal tokens**: Focus on actionable findings, not exhaustive documentation
+- **Progressive disclosure**: Load artifacts incrementally; don't dump all content into analysis
+- **Token-efficient output**: Limit findings table to 50 rows; summarize overflow
+- **Deterministic results**: Rerunning without changes should produce consistent IDs and counts
+
+### Analysis Guidelines
+
+- **NEVER modify files** (this is read-only analysis)
+- **NEVER hallucinate missing sections** (if absent, report them accurately)
+- **Prioritize constitution violations** (these are always CRITICAL)
+- **Use examples over exhaustive rules** (cite specific instances, not generic patterns)
+- **Report zero issues gracefully** (emit success report with coverage statistics)
+
+## Context
+
+$ARGUMENTS

agentic_devtools-0.2.70/.github/agents/speckit.tasks.agent.md

@@ -0,0 +1,173 @@
+---
+description: Generate an actionable, dependency-ordered tasks.md for the feature based on available design artifacts.
+handoffs: 
+  - label: Analyze For Consistency
+    agent: speckit.analyze
+    prompt: Run a project analysis for consistency
+    send: true
+  - label: Implement Project
+    agent: speckit.implement
+    prompt: Start the implementation in phases
+    send: true
+---
+
+## User Input
+
+```text
+$ARGUMENTS
+```
+
+You **MUST** consider the user input before proceeding (if not empty).
+
+## Outline
+
+1. **Setup**: Run `.specify/scripts/bash/check-prerequisites.sh --json` from repo root and parse FEATURE_DIR and AVAILABLE_DOCS list. All paths must be absolute. For single quotes in args like "I'm Groot", use escape syntax: e.g 'I'\''m Groot' (or double-quote if possible: "I'm Groot").
+
+2. **Load design documents**: Read from FEATURE_DIR:
+   - Also load `.specify/memory/markdown-rules.md` and apply it to all fenced code blocks in generated output.
+   - **Required**: plan.md (tech stack, libraries, structure), spec.md (user stories with priorities)
+   - **Optional**: data-model.md (entities), contracts/ (API endpoints), research.md (decisions), quickstart.md (test scenarios)
+   - Note: Not all projects have all documents. Generate tasks based on what's available.
+
+3. **Execute task generation workflow**:
+   - Load plan.md and extract tech stack, libraries, project structure
+   - Load spec.md and extract user stories with their priorities (P1, P2, P3, etc.)
+   - If data-model.md exists: Extract entities and map to user stories
+   - If contracts/ exists: Map endpoints to user stories
+   - If research.md exists: Extract decisions for setup tasks
+   - Generate tasks organized by user story (see Task Generation Rules below)
+   - Generate dependency graph showing user story completion order
+   - Create parallel execution examples per user story
+   - Validate task completeness (each user story has all needed tasks, independently testable)
+
+4. **Generate tasks.md**: Use `.specify/templates/tasks-template.md` as structure, fill with:
+   - Correct feature name from plan.md
+   - Phase Mapping table (if task phases differ from plan phases in numbering, count, or organizational scheme)
+   - Phase 1: Setup tasks (project initialization)
+   - Phase 2: Foundational tasks (blocking prerequisites for all user stories)
+   - Phase 3+: One phase per user story (in priority order from spec.md)
+   - Each phase includes: story goal, independent test criteria, tests (if requested), implementation tasks
+   - Final Phase: Polish & cross-cutting concerns
+   - All tasks must follow the strict checklist format (see Task Generation Rules below)
+   - Clear file paths for each task
+   - Dependencies section showing story completion order
+   - Parallel execution examples per story
+   - Implementation strategy section (MVP first, incremental delivery)
+
+5. **Report**: Output path to generated tasks.md and summary:
+   - Total task count
+   - Task count per user story
+   - Parallel opportunities identified
+   - Independent test criteria for each story
+   - Suggested MVP scope (typically just User Story 1)
+   - Format validation: Confirm ALL tasks follow the checklist format (checkbox, ID, labels, file paths)
+
+Context for task generation: $ARGUMENTS
+
+The tasks.md should be immediately executable - each task must be specific enough that an LLM can complete it without additional context.
+
+## Task Generation Rules
+
+**CRITICAL**: Tasks MUST be organized by user story to enable independent implementation and testing.
+
+**Tests are OPTIONAL**: Only generate test tasks if explicitly requested in the feature specification or if user requests TDD approach.
+
+### Checklist Format (REQUIRED)
+
+Every task MUST strictly follow this format:
+
+```text
+- [ ] [TaskID] [P?] [Story?] Description with file path
+```
+
+**Format Components**:
+
+1. **Checkbox**: ALWAYS start with `- [ ]` (markdown checkbox)
+2. **Task ID**: Sequential number (T001, T002, T003...) in execution order
+3. **[P] marker**: Include ONLY if task is parallelizable (different files, no dependencies on incomplete tasks)
+4. **[Story] label**: REQUIRED for user story phase tasks only
+   - Format: [US1], [US2], [US3], etc. (maps to user stories from spec.md)
+   - Setup phase: NO story label
+   - Foundational phase: NO story label  
+   - User Story phases: MUST have story label
+   - Polish phase: NO story label
+5. **Description**: Clear action with exact file path
+
+**Examples**:
+
+- ✅ CORRECT: `- [ ] T001 Create project structure per implementation plan`
+- ✅ CORRECT: `- [ ] T005 [P] Implement authentication middleware in src/middleware/auth.py`
+- ✅ CORRECT: `- [ ] T012 [P] [US1] Create User model in src/models/user.py`
+- ✅ CORRECT: `- [ ] T014 [US1] Implement UserService in src/services/user_service.py`
+- ❌ WRONG: `- [ ] Create User model` (missing ID and Story label)
+- ❌ WRONG: `T001 [US1] Create model` (missing checkbox)
+- ❌ WRONG: `- [ ] [US1] Create User model` (missing Task ID)
+- ❌ WRONG: `- [ ] T001 [US1] Create model` (missing file path)
+
+### Task Organization
+
+1. **From User Stories (spec.md)** - PRIMARY ORGANIZATION:
+   - Each user story (P1, P2, P3...) gets its own phase
+   - Map all related components to their story:
+     - Models needed for that story
+     - Services needed for that story
+     - Endpoints/UI needed for that story
+     - If tests requested: Tests specific to that story
+   - Mark story dependencies (most stories should be independent)
+
+2. **From Contracts**:
+   - Map each contract/endpoint → to the user story it serves
+   - If tests requested: Each contract → contract test task [P] before implementation in that story's phase
+
+3. **From Data Model**:
+   - Map each entity to the user story(ies) that need it
+   - If entity serves multiple stories: Put in earliest story or Setup phase
+   - Relationships → service layer tasks in appropriate story phase
+
+4. **From Setup/Infrastructure**:
+   - Shared infrastructure → Setup phase (Phase 1)
+   - Foundational/blocking tasks → Foundational phase (Phase 2)
+   - Story-specific setup → within that story's phase
+
+### Location References
+
+Tasks MUST use **semantic anchors** — not hardcoded line numbers — when describing where to edit a file.
+
+**Acceptable anchors for code files**: function/method/class names, constants, decorators, import blocks, test names, comment markers.
+
+**Acceptable anchors for non-code files**: headings, YAML/JSON key paths, table sections, bullet groups, recognizable text blocks.
+
+**Insertion points**: Use "before/after/inside/under" a named landmark (e.g., "after the imports block", "inside the `MyClass` definition").
+
+**Cross-task references**: When a later task depends on something introduced earlier, reference it explicitly
+(e.g., "the helper introduced in T005", "the `build_anchor` function created in the previous step").
+
+**Disambiguation**: When an anchor is ambiguous, include surrounding context (e.g., "the `validate` method in `RequestHandler`", not just "the `validate` method").
+
+- ❌ `(line 73)`, `(~lines 42-57)` — bare line numbers are brittle and break when earlier tasks modify the file
+- ✅ `in the _execute_merge() function`, `under the ## Dependencies heading`
+
+### Phase Structure
+
+- **Phase 1**: Setup (project initialization)
+- **Phase 2**: Foundational (blocking prerequisites - MUST complete before user stories)
+- **Phase 3+**: User Stories in priority order (P1, P2, P3...)
+  - Within each story: Tests (if requested) → Models → Services → Endpoints → Integration
+  - Each phase should be a complete, independently testable increment
+- **Final Phase**: Polish & Cross-Cutting Concerns
+
+### Phase Mapping
+
+If the task list uses different phase numbering, count, or organizational scheme than the plan, include a **Phase Mapping: Plan → Tasks** table at the top of tasks.md (after any Path Conventions section, before Phase 1) that maps each task phase to its corresponding plan phase(s).
+
+The table uses three columns: `Tasks Phase`, `Plan Phase(s)`, and `Description`.
+
+**Example:**
+
+| Tasks Phase | Plan Phase(s) | Description |
+|---|---|---|
+| Phase 1: Setup | — | Project scaffolding (no direct plan equivalent) |
+| Phase 2: Foundational | Phase 1: Core Module | Core infrastructure from plan Phase 1 |
+| Phase 3: US1 | Phase 2: Integration, Phase 3: API Layer | Story draws from multiple plan phases |
+
+**Edge case — plans without numbered phases:** When `plan.md` uses section headings rather than numbered phases (e.g., "Design Overview", "Integration Layer"), reference those headings verbatim in the `Plan Phase(s)` column.

agentic_devtools-0.2.70/.github/scripts/speckit-trigger/copilot_generate.py

@@ -0,0 +1,135 @@
+#!/usr/bin/env python3
+"""Copilot SDK wrapper for SpecKit spec generation.
+
+Reads a prompt from stdin, sends it to the Copilot SDK with a configurable
+model, and prints the assistant's response to stdout.
+
+Environment Variables:
+    COPILOT_GITHUB_TOKEN  - Required. Provided by the workflow via GitHub App token.
+    COPILOT_MODEL         - Optional. Model to use (default: claude-opus-4.6).
+    COPILOT_TIMEOUT       - Optional. Seconds to wait for a response (default: 600).
+                            Heavy phases (Plan, Tasks, Analyze) may need 900s or more.
+
+Exit Codes:
+    0 - Success (spec content written to stdout)
+    1 - Failure (error message written to stderr)
+"""
+
+import asyncio
+import os
+import sys
+
+from copilot import CopilotClient, SubprocessConfig
+from copilot.session import PermissionHandler
+
+
+async def main() -> int:
+    prompt = sys.stdin.read()
+    if not prompt.strip():
+        print("Error: empty prompt on stdin", file=sys.stderr)
+        return 1
+
+    model = os.environ.get("COPILOT_MODEL", "claude-opus-4.6")
+    token = os.environ.get("COPILOT_GITHUB_TOKEN", "")
+    timeout_str = os.environ.get("COPILOT_TIMEOUT", "600")
+    try:
+        timeout = int(timeout_str)
+        if timeout <= 0:
+            raise ValueError("timeout must be positive")
+    except ValueError:
+        print(
+            f"Error: COPILOT_TIMEOUT must be a positive integer (got {timeout_str!r})",
+            file=sys.stderr,
+        )
+        return 1
+    if not token:
+        print(
+            "Error: COPILOT_GITHUB_TOKEN environment variable is required"
+            " (provided by workflow via GitHub App token)",
+            file=sys.stderr,
+        )
+        return 1
+
+    client = None
+    session = None
+    try:
+        client = CopilotClient(SubprocessConfig(github_token=token))
+        await client.start()
+
+        session = await client.create_session(
+            model=model,
+            on_permission_request=PermissionHandler.approve_all,
+            infinite_sessions={"enabled": False},
+        )
+
+        content_parts: list[str] = []
+        received_events: list[str] = []
+        error_messages: list[str] = []
+        done = asyncio.Event()
+
+        def on_event(event):
+            event_type = event.type.value
+            received_events.append(event_type)
+            if event_type == "assistant.message":
+                content_parts.append(event.data.content)
+            elif event_type == "session.idle":
+                done.set()
+            elif event_type in ("error", "session.error", "assistant.error"):
+                msg = getattr(event.data, "message", None) or str(event.data)
+                error_messages.append(f"{event_type}: {msg}")
+                done.set()
+
+        session.on(on_event)
+        await session.send(prompt)
+
+        try:
+            await asyncio.wait_for(done.wait(), timeout=timeout)
+        except asyncio.TimeoutError:
+            print(f"Error: Copilot SDK response timed out after {timeout}s", file=sys.stderr)
+            print(f"Events received before timeout: {received_events}", file=sys.stderr)
+            return 1
+
+        if error_messages:
+            print(
+                f"Error: Copilot SDK returned error(s): {'; '.join(error_messages)}",
+                file=sys.stderr,
+            )
+            return 1
+
+        content = content_parts[-1] if content_parts else ""
+        if not content.strip():
+            print("Error: empty response from Copilot SDK", file=sys.stderr)
+            print(f"Events received: {received_events}", file=sys.stderr)
+            print(
+                f"Model: {model}, Prompt length: {len(prompt)} chars",
+                file=sys.stderr,
+            )
+            return 1
+
+        sys.stdout.write(content)
+        return 0
+
+    except Exception as exc:
+        print(f"Error: Copilot SDK call failed: {exc}", file=sys.stderr)
+        return 1
+    finally:
+        if session is not None:
+            try:
+                await session.disconnect()
+            except Exception as exc:
+                print(
+                    f"Warning: failed to disconnect Copilot session: {exc}",
+                    file=sys.stderr,
+                )
+        if client is not None:
+            try:
+                await client.stop()
+            except Exception as exc:
+                print(
+                    f"Warning: failed to stop Copilot client: {exc}",
+                    file=sys.stderr,
+                )
+
+
+if __name__ == "__main__":
+    sys.exit(asyncio.run(main()))

agentic_devtools-0.2.70/.github/scripts/speckit-trigger/fixtures/content-preservation/checklists/requirements.md

@@ -0,0 +1,27 @@
+# Specification Quality Checklist: Test Feature
+
+**Purpose**: Validate specification completeness before proceeding to planning
+**Created**: 2026-01-01
+**Feature**: [spec.md](../spec.md)
+**Source Issue**: #9999
+
+## Content Quality
+
+- [ ] CHK001 The spec clearly states the problem being addressed
+- [x] CHK002 User stories follow the "As a ... I want ... so that ..." format
+- [X] CHK003 All functional requirements include priority assignments
+- [ ] CHK004 The spec avoids implementation details in requirements
+
+## Requirement Completeness
+
+- [x] CHK005 Each user story has at least one acceptance scenario
+- [ ] CHK006 Edge cases are documented for all critical paths
+- [x] CHK007 Acceptance scenarios follow Given/When/Then format
+- [ ] CHK008 Success criteria include measurable thresholds
+- [x] CHK009 Scope boundaries are explicitly stated
+- [ ] CHK010 Dependencies and assumptions are listed
+
+## Notes
+
+- This checklist was generated from the specification content for issue #9999
+- Items marked incomplete require spec updates before proceeding to planning