task-spec-authoring

Write Executor task specifications and calibrate verification depth for delegated implementation work.

Updated Jul 30, 2026
One-click install
npx skills add https://github.com/primax79/ai-architect-executor --skill task-spec-authoring-primax79
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: task-spec-authoring
Source: https://github.com/primax79/ai-architect-executor/tree/main/plugins/architect-side/skills/task-spec-authoring
Command: npx skills add https://github.com/primax79/ai-architect-executor --skill task-spec-authoring-primax79

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Delegating implementation work to a fast Executor agent fails when task specs are vague, rest on unverified assumptions, or receive uniform verification regardless of risk. This Skill provides rules for writing specs that are hard to misimplement and for matching review depth to actual defect risk. ## Core Features & Use Cases - Spec authoring rules: Enforce narrow task granularity, the negative-claim rule (mandating full regression runs when correctness depends on something being unused or unreachable), caller tracing across files, grounding in real code with re-grep instructions, and one-task-one-commit discipline. - Cross-engine spec review: Submit draft specs to independent AI engines or blind self-review instances in iterative cycles before finalizing, keeping at least one unprimed reviewer per cycle. - Parallel batch coordination: Define disjoint write scopes, constrain shared barrel files, pre-assign shared type names, and pin toolchain versions to make merges cheap. - Risk-calibrated verification: Scale review from a simple diff plus smoke test for narrow tasks up to full regression sweeps for negative-claim tasks, always against disposable data copies. - Use Case: Before handing a multi-file refactoring task to an Executor, write a spec citing exact functions with re-grep warnings, trace all callers of shared helpers, and require a full test suite run in the Verification section. ## Quick Start Use the task-spec-authoring skill to write an Executor task spec for converting the authentication module, including caller tracing and a risk-appropriate verification section.

Frequently Asked Questions about task-spec-authoring

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I write a task spec for an AI coding agent?▼

Cite real functions and line numbers with re-grep warnings, keep scope narrow to a single module, trace every caller of functions being modified, and include an explicit Verification section. Note that the task should produce exactly one commit scoped to its changes.

How to verify code produced by a delegated AI agent?▼

Match verification depth to risk: narrow single-module tasks need a diff review plus one smoke test, while any task resting on a negative claim requires a full regression suite run. Always test against disposable copies of data, never live files.

What is the negative-claim rule in task specification?▼

The negative-claim rule states that if a task's correctness depends on something not being used or reachable elsewhere, its Verification section must mandate a full regression-suite run. Negative claims cannot be validated from a code fragment alone.

How do I run parallel AI coding tasks without merge conflicts?▼

Give each task a disjoint write scope down to the directory, constrain any shared barrel file to one export line per task, pre-assign shared type names across the batch, and pin the toolchain version in both the spec and verification commands.

When should a task spec be reviewed by multiple AI engines?▼

Submit any non-trivial draft spec to independent engines or blind self-review instances before finalizing, cycling until reviewers come back clean. Keep at least one reviewer unprimed each cycle to catch issues outside the known findings list.

What are the limitations of file-count heuristics for task scoping?▼

File count only approximates defect risk; a single-file change can still rest on an unverified negative claim about the rest of the codebase. The sharper criterion is whether correctness depends on something being unused or unreachable elsewhere.