skills/speckit-task-grounding/SKILL.md
Task grounding validation framework for ensuring development tasks are properly specified in planning artifacts before implementation. Use when validating feature specifications, checking task grounding against artifacts like spec.md, plan.md, data-model.md, api-contracts.md, research.md, and quickstart.md, or when performing parallel task validation for feature readiness assessment.
npx skillsauth add arisng/github-copilot-fc speckit-task-groundingInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
A framework for validating that development tasks are properly grounded in planning artifacts before implementation, enabling parallel task validation and reducing implementation risks.
This skill integrates with the Spec-Driven Development (SDD) methodology implemented by Speckit:
specs/[branch-name]/ specification folders/speckit.tasks generates the task listParallel Task Validation: Each task grounding check is independent, allowing multiple reviewers to validate tasks simultaneously (2-3 minutes per task).
| Score | Meaning | Evidence Required | Action | | -------- | ---------- | ------------------------------------ | ---------------- | | 100% | Explicit | Direct quote with exact location | ✅ Execute | | 90% | Detailed | Code example or schema provided | ✅ Execute | | 80% | Referenced | Clear spec with implementation notes | ✅ Execute | | 70% | Pattern | Documented pattern to follow | ⚠️ Verify pattern | | 60% | Inferred | Multiple weak references | ⚠️ Clarify | | 50% | Assumed | Single weak reference | 🔴 High risk | | <50% | Missing | No evidence found | 🔴 Block |
| Status | Meaning | Description | Action | | --------------------------------------- | ------- | ---------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------ | | 🟢 Documented<br/>(Fully Grounded) | 80-100% | Clear specification with implementation details from planning phase artifacts (plan.md, research.md, data-model.md, contracts/, quickstart.md) | ✅ Ready to implement | | 🟡 Inferred<br/>(Partially Grounded) | 50-79% | Evidence exists but requires clarification | ⚠️ Verify before implementation | | 🔴 Missing<br/>(Ungrounded) | <50% | No evidence found in artifacts | 🔴 Block until specified |
| Status | Meaning | Description | | ------------------------ | --------------------------- | -------------------------------------------- | | 🟢 Fully Documented | ≥80% tasks fully grounded | All critical tasks have clear specifications | | 🟢 Mostly Documented | 70-79% tasks fully grounded | Most tasks grounded, minor gaps | | 🟡 Partially Inferred | 50-69% tasks fully grounded | Significant gaps requiring clarification | | 🟡 Mostly Inferred | 30-49% tasks fully grounded | Major gaps, high risk | | 🔴 Poorly Grounded | <30% tasks fully grounded | Critical gaps, block implementation |
| Level | Meaning | Description | | ------------ | --------------------------------- | -------------------------------------- | | 🟢 Low | ≥90% grounding, no gaps | Straightforward implementation | | 🟡 Medium | 70-89% grounding, resolvable gaps | Needs verification but implementable | | 🔴 High | <70% grounding, critical gaps | High risk, may require planning rework |
| Assessment | Meaning | Description | | ------------------------- | --------------------------------------- | ------------------------------ | | ✅ APPROVE | Meets phase thresholds | Proceed with implementation | | ⚠️ NEEDS CLARIFICATION | Resolvable gaps identified | Address gaps before proceeding | | 🔴 BLOCK | Critical gaps or insufficient grounding | Return to planning phase |
| Score | Qualitative Term | Evidence Required | | -------- | ---------------- | --------------------------------------------------------------------------------------------------------------------------- | | 100% | Explicit | Direct quote with exact location from planning phase artifacts | | 90% | Detailed | Code example or schema provided from planning phase artifacts | | 80% | Referenced | Clear implementation details from planning phase artifacts (plan.md, research.md, data-model.md, contracts/, quickstart.md) | | 70% | Pattern | Documented pattern to follow from any artifact | | 60% | Inferred | Multiple weak references from any artifacts | | 50% | Assumed | Single weak reference from any artifact | | <50% | Missing | No evidence found in any artifacts (spec.md alone does not qualify for ≥80% scores) |
Important: Tasks must be grounded in planning phase artifacts to achieve "Documented" (≥80%) status. Evidence from spec.md alone caps scoring at 70% maximum, as spec.md represents requirements specification rather than implementation planning.
For each task in tasks.md:
# Reviewer A validates their assigned tasks
.\scripts\Validate-TaskGrounding.ps1 -FeaturePath "specs/my-feature" -TaskFilter "T001,T002,T003" -JsonOutput -OutputPath "specs/my-feature/assessments/reviewerA-assessment.json"
# Reviewer B validates their assigned tasks
.\scripts\Validate-TaskGrounding.ps1 -FeaturePath "specs/my-feature" -TaskFilter "T004,T005" -JsonOutput -OutputPath "specs/my-feature/assessments/reviewerB-assessment.json"
# Combine all individual assessments into final report
.\scripts\Aggregate-TaskGrounding.ps1 -FeatureName "my-feature" -AssessmentFiles @("specs/my-feature/assessments/reviewerA-assessment.json", "specs/my-feature/assessments/reviewerB-assessment.json", "specs/my-feature/assessments/reviewerC-assessment.json") -OutputPath "specs/my-feature/tasks.grounding.md"
Post-Aggregation Cleanup:
# Optional: Remove intermediate assessment files after successful aggregation
Remove-Item "specs/my-feature/assessments/*.json"
Benefits:
After complete validation, your specification folder will contain:
specs/[branch-name]/
├── spec.md # Original artifacts
├── plan.md
├── research.md
├── data-model.md
├── contracts/
├── quickstart.md
├── tasks.md
├── assessments/ # Intermediate files (can be removed after aggregation)
│ ├── reviewerA-assessment.json
│ ├── reviewerB-assessment.json
│ └── reviewerC-assessment.json
└── tasks.grounding.md # Final validation report (VS Code nested under tasks.md)
spec.md - Feature specification with user stories and requirements (highest authority)plan.md - Implementation plan with technical decisionsresearch.md - Technical research and context gatheringdata-model.md - Data models and entity definitionscontracts/ - Directory containing API contracts and interface specificationsquickstart.md - Key validation scenarios and quickstart guidetasks.md - Executable task list derived from plan (input for validation)assessments/ - Directory for intermediate assessment files (created automatically)File Locations (relative to specification root):
assessments/reviewer*-assessment.json - Individual reviewer assessments (intermediate files)tasks.grounding.md - Final comprehensive validation reportReport Contents:
devops
Programmatically create tldraw whiteboards and visualize them with a self-hosted tldraw instance. Create boards with shapes, text, and connectors, then deploy to a self-hosted server for collaborative editing and gallery management.
tools
Execute Google Cloud Platform operations using the gcloud CLI (and gsutil/bq where applicable). Use when the user wants to: authenticate with GCP, manage GCP resources, deploy applications, configure projects or IAM, view logs, run SQL/BigQuery, or interact with any GCP service from the command line. Triggers on phrases like "gcloud", "Google Cloud CLI", "deploy to GCP", "create a VM", "Cloud Run", "GKE cluster", "Cloud Storage bucket", "set GCP project", "service account", "Cloud Functions", "App Engine deploy", or any request to manage Google Cloud resources via command line.
testing
Grilling session that challenges your plan against the existing domain model, sharpens terminology, and updates documentation (CONTEXT.md, ADRs) inline as decisions crystallise. Use when user wants to stress-test a plan against their project's language and documented decisions.
development
Session-scoped git commit orchestrator that commits only current-session changes and leaves unrelated dirty worktree edits untouched. Inherits git-atomic-commit for atomic grouping and commit message execution, and git-commit-scope-constitution for scope governance and validation. Use when asked to commit this session only or isolate commits from mixed worktree state.