Tyler J. Peckenpaugh / Agentic development

Tooling anatomy

ArDD, Superpowers, and Spec Kit each combine durable knowledge, delivery practices, and workflow machinery. Pulling those concerns apart makes overlap visible and composition possible.

01Signal

02Problem

03Decision

04Specification

05Design

06Plan

07Work

08Evidence

09Updated truth

The structural model

Three planes

The planes separate meaning, delivery, and operational reliability. A complete methodology usually spans all three; a composable tool does not need to.

Knowledge plane

Establishes what the project and a proposed change mean.

Policy definition
System model
Intent
Specification
Design

Delivery plane

Transforms an approved commitment into integrated, evidenced code.

Decomposition
Execution
Testing
Review
Integration

Control plane

Makes the other planes observable, recoverable, and composable.

Routing
State
Isolation
Validation
Adapters

Across all three planes

Governance has to reach the work.

Project specificity and execution effectiveness are independent. A rule needs an owner, an application point, and evidence.

Knowledge1. Define

What do we require?
Behavior changes need regression coverage.

Control2. Resolve

Which rules apply?
Combine project policy, defaults, and explicit exceptions.

Delivery3. Apply

How does work change?
Carry requirements into plans and worker briefs.

Delivery4. Assure

What proves compliance?
Review evidence and run required checks.

A skill instructs. A reviewer assesses. A required check blocks. Each provides a different level of assurance.

How Superpowers accommodates project policy

Its documented precedence puts direct user instructions and project files such as AGENTS.md and CLAUDE.md above skill defaults. Plans also carry global constraints. This supports explicit project overrides without changing upstream skills; consistent propagation to every worker and reviewer still depends on the workflow. Instruction precedence · Plan constraints

How a module takes effect

Mechanism, activation, consequence.

A module names a responsibility. Its mechanism supplies the behavior; its trigger determines whether that behavior runs.

Instruction files

Project rules and decisions. AGENTS.md / CLAUDE.md are harness entry points where supported; a constitution needs an explicit reference or read step. Being on disk does not make it active.

Skill or command prose

A procedure interpreted by an agent. Activated by a user command, skill discovery, or another workflow step. Strong wording guides behavior but supplies no independent barrier.

Agent specification

A role, instructions, input context, and output contract. Dispatch activates it. Tools, model, isolation, and permissions are separate harness settings when supported; a reviewer prompt alone does not restrict access.

Templates and structured records

Shape specs, plans, task briefs, and ledgers. Loaded during generation or execution. A template suggests structure; a parser or validator can enforce it.

Scripts and tool APIs

Execute concrete operations: mutate state, inspect Git, run tests, or create an issue. Deterministic behavior begins after invocation; an agent may still omit the call or mishandle its result.

Harness hooks

The harness invokes a handler on an event such as session start or tool use. A handler may inject instructions, report findings, or block an operation where supported. Automatic activation is not automatically enforcement.

Git, CI, and access controls

Git hooks, CI events, protected branches, and tool permissions operate outside skill prose. A required check can block a merge; an optional check merely reports. Coverage and bypass rules determine the guarantee.

Human decisions

Approval, clarification, review, and exceptions. A prompt asks for a decision; enforcement depends on whether the agent or runtime actually waits before acting.

One script, four different guarantees

Manual: a person remembers to run it. Agent-directed: a skill tells the agent to run it. Event-driven: the harness, Git, or CI runs it. Required gate: a controlling system refuses the operation when it fails. These describe invocation and consequences, not the sophistication of the script.

Superpowers' Claude hook starts at SessionStart; it bootstraps skill guidance. Spec Kit's implementation template directs the agent to invoke extension hooks. Those are different activation mechanisms despite sharing the name “hook.” Superpowers hook configuration · Spec Kit implementation template

Capability comparison

Module matrix

Capability coverage and implementation mechanisms are separate assessments. Mechanism entries summarize the reviewed sources; installed versions and harness configuration can change activation and enforcement.

ArDD Superpowers Spec Kit

Module	ArDD	Superpowers	Spec Kit

First-class Partial Absent

State is not one thing

Artifact vocabulary

Calling every file an artifact hides crucial differences in authority, lifetime, mutability, and recovery.

Charter

What rules govern all work?

Project lifetimeCanonical

System model

What is the system supposed to be?

LivingCanonical

Intake record

What might need attention?

Until triageMutable

Change spec

What behavior should this change produce?

One changeHistorical

Technical plan

How will the approved behavior be built?

One changeHistorical

Work queue

What executable action happens next?

Until completeOperational

Evidence record

Why should a correctness claim be believed?

Audit historyImmutable

Progress ledger

Where did this execution run stop?

Active runRecoverable

Derived view

What does current state look like right now?

DisposableRegenerated

Orthogonal to lifecycle

Operational archetypes

A lifecycle stage says where a capability acts. An archetype says what kind of action it performs.

CaptorTurns conversation into durable input.

ElicitorQuestions assumptions until intent is explicit.

CompilerTransforms one artifact class into another.

InspectorReports findings without changing canonical state.

GatePermits or refuses a state transition.

MutatorAdvances canonical lifecycle state.

ExecutorChanges the product under declared constraints.

VerifierProduces evidence for or against a claim.

CoordinatorAssigns work and manages concurrency.

AdapterSynchronizes an external system.

A coherent hybrid

Recommended ownership

Use each tool where its model is strongest. Treat overlap as an ownership decision, not an invitation to run both.

Project truth

OwnerCharter, system model, drift

Applies project overrides through skills and task constraints

Constitution alternative

Change discovery

Intake source

OwnerDialogue and design approval

Formal specification alternative

Change packet

Durable decisions only

OwnerDesign and implementation plan

Owner when formal traceability matters

Implementation

Does not orchestrate

OwnerTDD, debugging, review, finish

Convergence alternative

Ecosystem

Focused adapters

Skill library

OwnerExtensions, presets, bundles

Safe overlap

Many inspectors may read the same state. Independent reviews, audits, and validators add evidence without competing for ownership.

Dangerous overlap

Two planners, queues, status ledgers, or branch coordinators create split authority and contradictory transitions.

The unit of composition

Module contract

A module becomes composable when its authority and failure behavior are as explicit as its happy path. Commands and prompts are delivery mechanisms; this contract is the capability boundary.

Name:
Question answered:
Inputs:
Outputs:
Canonical state owned:
Policy inputs and precedence:
Mechanism and invocation owner:
Failure consequence: report | ask | block
Authority: advisory | gating | mutating
Execution: deterministic | constrained judgment | open judgment
Trigger: explicit | automatic | event-driven
Failure and recovery contract:

RULE 01One canonical owner

A capability can have many readers and inspectors, but only one module should mutate its authoritative state.

RULE 02Approval before mutation

Drafting and deliberation should not consume intake, supersede accepted work, or advance lifecycle state.

RULE 03Derived means disposable

Status views should be regenerated from source records, never patched into becoming another source of truth.

RULE 04Policy is not mechanism

“Use TDD” is policy. Running a test command is mechanism. A module should make clear which it supplies.

RULE 05Recovery is part of behavior

Every mutating module needs an idempotency, rollback, reconciliation, or abandonment story.

RULE 06Commands may hide coupling

A command that elicits, compiles, gates, mutates, and coordinates should usually be decomposed behind its interface.