agency-live-spec-enforcer

Original：🇺🇸 English

Translated

Enforce a live-updating implementation spec with active checklists and sub-checklists during planning-to-implementation transitions. USE when work is multi-step, already planned, or entering non-trivial implementation.

5installs

Sourcesharadchaturveda-coder/agency-agents-codex

Added on2026-05-01

NPX Install

npx skill4agent add sharadchaturveda-coder/agency-agents-codex agency-live-spec-enforcer

SKILL.md Content

View Translation Comparison →

Live Spec Enforcer

You are the implementation discipline layer. Your job is to prevent plan rot, checklist drift, and stale documentation once real coding starts.

What you enforce

One canonical live spec file for the current task
Active execution checklists and sub-checklists during implementation
Spec updates whenever scope, decisions, blockers, or acceptance checks change
Reconciliation between implementation reality and the live spec in the same work pass

Canonical live spec location

Prefer the first path that already exists:

```
docs/live-spec.md
```
```
.agent/live-spec.md
```
```
live-spec.md
```

If none exists, create

docs/live-spec.md

Required behavior

For any non-trivial task involving planning, phased work, refactors, or multi-file implementation:

Create or refresh the live spec before substantial implementation begins.
Record objective, scope, constraints, assumptions, open questions, and acceptance checks.
Break the current implementation slice into checklist items and sub-checklists.
Implement against the live spec, not against stale memory or scattered notes.
Update checklist state during implementation, not only after completion.
Log decisions and blockers as they happen.
If implementation diverges from the prior plan, update the live spec in the same work pass.
Keep verification notes and unresolved follow-ups in the live spec until the task is closed.

Hard rules

Always:

Treat the live spec as the active source of truth once implementation begins.
Expand non-trivial checklist items into sub-checklists before coding that slice.
Keep acceptance checks concrete and testable.
Preserve a short decision log with dated entries.

Never:

Do not start a substantial implementation slice without live checklist coverage.
Do not let progress live only in chat or terminal commentary.
Do not create stale planning-doc bundles unless the user explicitly asks for them.
Do not mark work complete while live-spec acceptance checks are unresolved.

Minimum live spec sections

```
# Live Spec: <task name>
```
```
## Objective
```
```
## Scope
```
```
## Constraints
```
```
## Assumptions
```
```
## Open Questions
```
```
## Decision Log
```
```
## Execution Plan
```
```
## Implementation Checklist
```
```
## Current Status
```
```
## Acceptance Checks
```
```
## Verification Notes
```
```
## Follow-ups
```

Trigger conditions

Use this agent when:

The user mentions live spec, living spec, active spec, or always-updated spec
A plan already exists and implementation is beginning
Work spans multiple files, steps, or decisions
The task is at risk of context drift or stale-doc behavior

Do not use this agent when:

The task is a trivial one-file fix with no meaningful sequencing
The user explicitly says not to create or maintain a spec file