Agent skill

Prd V07 Implementation Loop

by mattgierhart in mattgierhart/PRD-driven-context-engineering

Execute implementation within EPICs following test-first development, continuous SoT updates, and code traceability during PRD v0.7 Build Execution.

MITAuto-check: notesProduct & Project Management

Install Prd V07 Implementation Loop

skills CLI
$ npx skills add mattgierhart/PRD-driven-context-engineering --skill prd-v07-implementation-loop -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install mattgierhart/PRD-driven-context-engineering prd-v07-implementation-loop --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/mattgierhart/PRD-driven-context-engineering.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.claude/skills/prd-v07-implementation-loop .claude/skills/prd-v07-implementation-loop && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
prd-v07-implementation-loop
GitHub stars
180
Token cost
~5.1k tokens
SKILL.md length
1,351 words
Files
7 (incl. references, assets)
Skills in repo
45
Repo updated
First seen
Licence
MIT

At a glance

Execute implementation within EPICs following test-first development, continuous SoT updates, and code traceability during PRD v0.7 Build Execution.

  • Works in 3 steps: Red (Write Failing Test) → Green (Make Test Pass) → Refactor (Improve Code Quality)
  • Requests to start building
  • SKILL.md covers Consumes, Produces, This skill executes the build.… and The Core Loop (The Heartbeat), plus 11 more sections
  • Needs INVALID_PASSWORD

What it does

Prd V07 Implementation Loop is an agent skill from mattgierhart/PRD-driven-context-engineering. Execute implementation within EPICs following test-first development, continuous SoT updates, and code traceability during PRD v0.7 Build Execution. Triggers on requests to start building, implement an epic, begin coding, or when user asks "start building", "implement epic", "coding", "development", "build execution", "implementation", "write code". Consumes EPIC- (context), TEST- (acceptance criteria). Updates existing IDs and creates code. Outputs working code with @implements traceability tags.

Its SKILL.md is about 5.1k tokens, which your agent loads only when the skill is triggered. The skill folder holds 8 other files, including reference files and assets (for example `assets/session-state.md`, `assets/traceability-checklist.md` and `references/behavioral-examples.md`).

It sits in Product & Project Management, covering PRD writing, User stories and Test-driven development. It works with dbt. The repository describes itself as: PRD-Led Context Engineering — Memory as Infrastructure. An ontology layer for product teams building products that solve real problems — with AI agents that remember. Gated PRD… The licence is MIT.

When your agent uses it

  • Requests to start building
  • Implement an epic
  • User asks start building
  • Build execution

Example prompts

  • “start building”
  • “implement epic”
  • “coding”
  • “/prd-v07-implementation-loop”

Requirements

  • Pre-approved tools (allowed-tools): Read, Write, Edit, Glob, Grep, Bash

Workflow steps

3 steps, taken from the step headings in SKILL.md.

  1. Red (Write Failing Test)
  2. Green (Make Test Pass)
  3. Refactor (Improve Code Quality)

What it can do on your machine

Read from SKILL.md and the folder at commit 30ed1b0. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves these tools, so the agent can use them without asking each time:

    • Read
    • Write
    • Edit
    • Glob
    • Grep
    • Bash

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    No scripts in the folder and no shell commands in SKILL.md (its code samples are typescript and markdown).

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names these keys or tokens, usually read from environment variables:

    • INVALID_PASSWORD

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Prd V07 Implementation Loop loads about 5.1k tokens when it runs, and up to ~11k if it reads all its reference files. Until then it costs about 133 tokens; SKILL.md has 1,351 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~133
When it runs · the whole SKILL.md, loaded when a task matches
~5.1k
With references · SKILL.md plus every file in references/, read only if the agent opens them
~11k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check: notes

The automated check noted patterns worth knowing about, such as sudo or a known installer.

  • NotePre-approves every shell command (allowed-tools: Bash)SKILL.md
    allowed-tools: Read, Write, Edit, Glob, Grep, Bash

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from mattgierhart/PRD-driven-context-engineering at commit 30ed1b0, republished under its MIT licence (© mattgierhart). 1,351 words, ~5,105 tokens.

Download SKILL.mdSave it as .claude/skills/prd-v07-implementation-loop/SKILL.md (or your agent's skills folder). This skill also uses 6 other files; get the full folder from GitHub.
name
prd-v07-implementation-loop
description
Execute implementation within EPICs following test-first development, continuous SoT updates, and code traceability during PRD v0.7 Build Execution. Triggers on requests to start building, implement an epic, begin coding, or when user asks "start building", "implement epic", "coding", "development", "build execution", "implementation", "write code". Consumes EPIC- (context), TEST- (acceptance criteria). Updates existing IDs and creates code. Outputs working code with @implements traceability tags.
allowed-tools
Read, Write, Edit, Glob, Grep, Bash
context
fork

Implementation Loop

Position in workflow: v0.7 Test Planning → v0.7 Implementation Loop → v0.8 Release

Consumes

This skill requires prior work from v0.7 Epic Scoping and v0.7 Test Planning:

  • EPIC-* entries (from v0.7 Epic Scoping) — EPIC context, objectives, Context & IDs table, execution plan phases, Session State tracking
  • TEST-* test specifications (from v0.7 Test Planning) — Acceptance criteria in Given-When-Then format; tests define "done" for each deliverable
  • API-* endpoint contracts (referenced in EPIC Context & IDs) — Implementation targets with request/response shapes, error codes, constraints
  • DBT-* schema specifications (referenced in EPIC Context & IDs) — Data model, field types, relationships, constraints to implement
  • BR-* business rules (referenced in EPIC Context & IDs) — Product logic constraints to enforce in code
  • Existing SoT files (if brownfield) — Durable specs that guide implementation without re-research

This skill assumes EPIC- and TEST- entries are complete, with all upstream IDs fully specified.

Produces

This skill updates/creates:

  • Working code (implementation of API-, DBT-, BR-, tested against TEST-) — Runnable code with @implements tags tracing back to specifications; passes all TEST- for EPIC
  • Updated SoT entries (if implementation reveals changes) — When building reveals new constraints or edge cases, update API-/DBT-/BR- entries immediately (not deferred)
  • Session State updates (EPIC.md Section 1) — "Brain dump" tracking exact stopping point, Next Steps for resume, blockers, decisions, Context
  • Development Graph (status/devgraph.json) — the @implements/@verifies tags you write are harvested into bridge edges, producing the as-built layer that readiness scores (implementation_coverage, architecture_conformance) and the HeartBeat visualizer renders. Schema: docs/DEVELOPMENT_GRAPH.md.

All implementation outputs are code and live SoT, not confidence-based. They are:

  • Traceable (every function tagged with @implements pointing to specification ID)
  • Tested (all TEST- for EPIC pass before marking phase/EPIC complete)
  • SoT-synchronized (implementation matches specs/ or specs/ updated to match implementation reality)
  • Session-state-preserved (Session State section allows seamless resume from exact stopping point)

Example code with traceability (from EPIC-01):

typescript
// @implements API-001 (POST /users)
// @see BR-001 (email uniqueness), BR-002 (password requirements), DBT-010 (users table)
export async function createUser(req: Request, res: Response) {
  // @implements BR-002 (password validation)
  const passwordResult = validatePassword(req.body.password);
  if (!passwordResult.valid) {
    return res.status(400).json({
      error: { code: 'INVALID_PASSWORD', message: passwordResult.errors[0] }
    });
  }

  // @implements BR-001 (email uniqueness check)
  const existingUser = await db.users.findByEmail(req.body.email);
  if (existingUser) {
    return res.status(409).json({
      error: { code: 'EMAIL_EXISTS', message: 'User already exists' }
    });
  }

  // @implements DBT-010 (users table creation)
  const user = await db.users.create({
    email: req.body.email,
    passwordHash: await hashPassword(req.body.password),
    createdAt: new Date(),
  });

  return res.status(201).json({ data: { id: user.id, email: user.email } });
}

Example Session State update (EPIC-01 mid-session):

markdown
## 1. Session State (The "Brain Dump")
- **Last Action**: Completed API-001–003 implementation; all tests passing. Password reset flow complete.
- **Stopping Point**: src/api/auth/reset.ts:85 — need to add rate limiting per BR-005
- **Next Steps**:
  1. Add rate limiter middleware to password reset endpoint (BR-005)
  2. Update TEST-012 to verify rate limiting (5 attempts per hour)
  3. Run full test suite for EPIC-01
  4. Move to API-005 (verify email endpoint)
- **Blockers**: None
- **Context**: Decided to implement rate limiting in middleware rather than at function level for reuse across endpoints. Using `express-rate-limit`.
- **Decisions Made**: POST /reset-password should return 429 with retry-after header when limit exceeded (API-001 error response spec). Using Redis for distributed rate limit tracking.

### Resume Instructions
> 1. Load EPIC-01 context (done in previous session)
> 2. Create new branch session if needed
> 3. Begin with Step 3 above (add rate limiter middleware)
> 4. When complete, run: `npm run test -- tests/api/auth.test.ts`
> 5. Update this Session State with new stopping point

This skill executes the build. It's the iterative cycle of: Load Context → Test → Code → Tag → Update → Validate → Repeat.

The Core Loop (The Heartbeat)

Each pass leaves a trace: step 5 tags code with @implements, and those tags are exactly what the Development Graph harvests — so this loop literally produces the pulse the HeartBeat visualizer shows (built → 🟢, unbuilt → 🔴, drifted → 🔴). Rerun readiness.py run after a Context Window to watch implementation_coverage move.

┌─────────────────────────────────────────────────────────────┐
│  1. LOAD CONTEXT                                            │
│     Read EPIC, referenced IDs, Session State                │
│     → Can you state this session's goal in one sentence     │
│       with specific IDs? If not, clarify before proceeding. │
└──────────────────────────┬──────────────────────────────────┘
                           │
                           ▼
┌─────────────────────────────────────────────────────────────┐
│  2. SELECT FOCUS                                            │
│     Choose a Context Window from Phase C                    │
│     → Pick the smallest scope that yields a verifiable      │
│       outcome. One TEST- passing > three half-implemented.  │
└──────────────────────────┬──────────────────────────────────┘
                           │
                           ▼
┌─────────────────────────────────────────────────────────────┐
│  3. WRITE TEST (Red)                                        │
│     Implement TEST- entry, watch it fail                    │
│     → Assertions must derive from TEST-/API-/BR- specs.     │
│       Missing detail = spec gap — flag it, don't guess.     │
└──────────────────────────┬──────────────────────────────────┘
                           │
                           ▼
┌─────────────────────────────────────────────────────────────┐
│  4. WRITE CODE (Green)                                      │
│     Implement to pass test                                  │
│     → Minimum code to pass. No TEST- requires it? Don't     │
│       build it. No speculative features or error handling.   │
└──────────────────────────┬──────────────────────────────────┘
                           │
                           ▼
┌─────────────────────────────────────────────────────────────┐
│  5. TAG CODE                                                │
│     Add // @implements ID comments                          │
└──────────────────────────┬──────────────────────────────────┘
                           │
                           ▼
┌─────────────────────────────────────────────────────────────┐
│  6. UPDATE SoT                                              │
│     Update specs/ if implementation reveals changes         │
│     → Only update specs YOUR implementation changed.        │
│       Don't "improve" adjacent specs you happened to read.  │
└──────────────────────────┬──────────────────────────────────┘
                           │
                           ▼
┌─────────────────────────────────────────────────────────────┐
│  7. VALIDATE                                                │
│     Run tests, check traceability                           │
│     → Name the specific TEST- IDs that pass. "It works"     │
│       is not validation — cite IDs.                         │
└──────────────────────────┬──────────────────────────────────┘
                           │
                           ▼
┌─────────────────────────────────────────────────────────────┐
│  8. UPDATE SESSION STATE                                    │
│     Write to Session State before stopping                      │
└──────────────────────────┬──────────────────────────────────┘
                           │
                           └──────────► REPEAT until EPIC complete

Session State Protocol (MANDATORY)

Before ending ANY session, update the EPIC Session State section:

markdown
## 0. Session State (The "Brain Dump")
- **Last Action**: [What was just completed]
- **Stopping Point**: [Exact file:line or test failure]
- **Next Steps**: [Exact instructions for next session]
- **Context**: [Key decisions, blockers, open questions]

Good Example:

markdown
- **Last Action**: Completed API-002 (login endpoint), all tests passing
- **Stopping Point**: src/api/auth/login.ts:47 — need to add rate limiting
- **Next Steps**:
  1. Add rate limiter middleware per BR-005
  2. Update TEST-008 to verify rate limiting
  3. Move to API-003 (logout)
- **Context**: Decided to use Supabase's built-in rate limiting rather than custom middleware

Assumptions & Ambiguities: During implementation, log assumptions and ambiguities in the EPIC's structured table (see EPIC template). This makes "Think Before Coding" persistent across sessions.

Example row during implementation:

| 3 | API-001 | ASSUMPTION | Response includes created_at field | Spec says "user object" but doesn't enumerate fields | Implemented with created_at; needs spec update |

Bad Example:

markdown
- **Last Action**: Working on auth
- **Stopping Point**: Somewhere in the code
- **Next Steps**: Continue
- **Context**: N/A

Code Traceability Protocol

Every major code unit MUST declare which ID it implements:

typescript
// @implements API-001 (Create User endpoint)
// @see BR-001 (Email uniqueness)
// @see DBT-001 (Users table)
export async function createUser(data: CreateUserInput): Promise<User> {
  // Implementation...
}
Traceability Tag Patterns
Code ElementTag PatternExample
API handler@implements API-XXXAPI endpoint function
Business logic@implements BR-XXXValidation, rules
Database model@implements DBT-XXXSchema definition
UI component@implements SCR-XXXScreen component
Test file@tests TEST-XXXTest implementation
Cross-reference@see [ID]Related specification
Example with Full Traceability
typescript
// @implements API-001 (POST /users)
// @see BR-001 (email uniqueness)
// @see BR-002 (password requirements)
// @see DBT-001 (users table)
export async function createUser(req: Request, res: Response) {
  // @implements BR-002
  const passwordResult = validatePassword(req.body.password);
  if (!passwordResult.valid) {
    return res.status(400).json({ error: passwordResult.errors });
  }

  // @implements BR-001
  const existingUser = await db.users.findByEmail(req.body.email);
  if (existingUser) {
    return res.status(409).json({ error: { code: 'EMAIL_EXISTS' } });
  }

  // @implements DBT-001
  const user = await db.users.create({
    email: req.body.email,
    passwordHash: await hashPassword(req.body.password),
  });

  return res.status(201).json({ data: user });
}

SoT Update Rules

The Source of Truth (specs/) must stay in sync with implementation:

SituationAction
Spec matches implementationNo update needed
Implementation reveals new constraintAdd BR- entry to specs/
API shape changed during buildUpdate API- entry
New field needed in schemaUpdate DBT- entry
Spec was wrong/incompleteFix spec AND code
Discovered edge caseAdd to spec, add TEST-

Rule: Update specs during implementation, not "later."

Counter-rule: Only update specs that YOUR current work directly affects. If you notice that API-020 has a typo while working on API-001, log it in the Assumptions & Ambiguities table for a future session. Do not fix it now. Unplanned spec changes create invisible scope creep and break traceability for any parallel work.

Context Window Navigation

Work through Context Windows sequentially within an EPIC:

markdown
## 4. Context Windows

### Window 1: Database Schema ← CURRENT
- [x] Create users table migration
- [x] Add RLS policies
- [ ] Create sessions table
- [ ] Verify schema in studio

### Window 2: API Endpoints
- [ ] Implement API-001 (signup)
- [ ] Implement API-002 (login)
- [ ] Implement API-003 (logout)

### Window 3: UI Integration
- [ ] Build signup form
- [ ] Build login form
- [ ] Add auth state management

Test-First Development (Red-Green-Refactor)

Phase 1: Red (Write Failing Test)
typescript
// tests/api/users.test.ts
// @tests TEST-001

describe('POST /api/users', () => {
  it('creates user with valid data', async () => {
    const response = await request(app)
      .post('/api/users')
      .send({ email: 'test@example.com', password: 'ValidPass123!' });

    expect(response.status).toBe(201);
    expect(response.body.data.email).toBe('test@example.com');
    // Test FAILS because endpoint doesn't exist yet
  });
});

Constraint: If the test requires details not in the TEST- spec (response field names, error codes, status codes), look them up in API-/BR- specs. Do not invent them. If the spec lacks the detail, log an AMBIGUITY in the Assumptions & Ambiguities table before proceeding.

Phase 2: Green (Make Test Pass)

Write the minimum code to make the test pass:

typescript
// @implements API-001
export async function createUser(req, res) {
  const user = await db.users.create(req.body);
  return res.status(201).json({ data: user });
}

Constraint: "Minimum code" means literally what makes this one test go green. No additional validation, no extra error handling, no service layer abstractions unless a TEST- requires that behavior. This feels uncomfortable. That is correct.

Phase 3: Refactor (Improve Code Quality)

Now improve the code while tests stay green:

typescript
// @implements API-001
// @see BR-001, BR-002
export async function createUser(req, res) {
  const validated = validateUserInput(req.body); // Add validation
  if (!validated.ok) return res.status(400).json(validated.error);

  const user = await userService.create(validated.data); // Extract service
  return res.status(201).json({ data: user });
}

Constraint: Refactor only code you just wrote. Do not "improve" existing code that was already working. Do not extract abstractions unless you have 3+ concrete uses (not hypothetical future uses). Do not touch files outside the current focus area. See references/behavioral-examples.md for detailed good/bad comparisons.

EPIC Phases (Detailed)

Phase A: Plan (Load Context)
  • Read EPIC file
  • Review all referenced IDs (BR-, API-, DBT-)
  • Check Session State section
  • Review Assumptions & Ambiguities table for unresolved items
  • Verify git branch is correct
  • Confirm dependencies are complete
  • Can state session goal in one sentence with specific IDs

If you cannot articulate what this session accomplishes in terms of specific TEST- or API- IDs, you are not ready to build. Refine the goal until it names IDs.

Show full SKILL.md (504 more words)Show less
Phase B: Design (Update Specs)
  • Draft/refine any unclear specs
  • Add missing details discovered during planning
  • Create TEST- entries if not done
  • Update EPIC Context & IDs section
Phase C: Build (Context Windows)

For each Context Window:

  • Select focus area
  • Write tests for this window
  • Implement code
  • Add traceability tags
  • Run tests, verify passing
  • Update Session State
Phase D: Validate
  • All TEST- entries for this EPIC pass
  • Manual verification of UJ- journeys
  • @implements tags present in all major code units
  • No orphaned code (everything traces to an ID)
  • specs/ updated to match implementation
Phase E: Finish (Harvest)
  • Move useful temp/ notes to specs/ or archive/
  • Verify all specs/ files match final code
  • Clean Session State section
  • Update EPIC state to Complete
  • Log completion in Change Log
  • Commit with message: feat(EPIC-XX): [summary]

Red Flags (Stop and Fix)

SignalAction
Can't write testRequirement unclear → revisit spec
Test keeps failingImplementation wrong OR spec wrong → investigate
Need code outside EPIC scopeWrong EPIC boundaries → re-scope
Lost context mid-sessionLoad Session State, verify EPIC context
Spec and code divergingStop, update spec to match reality
Test is testing implementationRewrite to test behavior
Writing code not required by any TEST-Speculative — remove it, or write the TEST- first
Editing files outside current Context WindowScope creep — note in Assumptions & Ambiguities table, defer

Anti-Patterns to Avoid

Anti-PatternSignalFix
Test-afterCode written, then "add tests"Write TEST- implementation first
Spec driftCode diverges from specs/Update SoT during implementation
Missing traceabilityCode has no @implements tagsAdd tags as you write
Session amnesiaNo Session State updateALWAYS update before stopping
Context switchingJumping between EPICsFinish one EPIC before starting another
One-shot buildingNo iteration, just code dumpFollow the loop: test → code → tag
Orphaned codeCode not linked to any IDEvery function serves an ID
Speculative error handlingtry/catch for scenarios no TEST- coversRemove it. If the scenario matters, write TEST- first.
Drive-by improvements"While I was here, I also improved..."Revert non-essential changes. Note in Assumptions & Ambiguities table.
Vague completion claims"Auth is working" without naming IDsAlways cite IDs: "TEST-001 through TEST-005 pass. API-001, API-002 verified."

Quality Gates

Before marking EPIC complete:

  • All TEST- entries pass
  • All code has @implements tags
  • specs/ matches implementation
  • Session State is clean
  • Manual UJ- verification done
  • Change Log updated
  • Development Graph green — status/devgraph.json rebuilt; implementation_coverage ≥ threshold (no scoped spec unbuilt, no unbuilt_specs cap) and no architecture_conformance violations

Downstream Connections

Implementation Loop outputs feed into:

ConsumerWhat It UsesExample
v0.8 ReleaseCompleted EPICs ready for deploymentAll TEST- pass, SoT current
Code Review@implements tags for contextReviewer knows which BR- to check
Readiness (v0.7)Development Graph build-vs-blueprintimplementation_coverage + architecture_conformance from status/devgraph.json
HeartBeatThe Development Graph as a live pulseRenders built / unbuilt / drifted across the codebase
Future SessionsSession State for continuityResume exactly where left off
MaintenanceTraceability for debugging"Which BR- does this code implement?"

Detailed References

  • Implementation examples: See references/examples.md
  • Traceability patterns: See references/traceability.md
  • Session state guide: See references/session-state.md
  • Behavioral examples (good/bad): See references/behavioral-examples.md

© mattgierhart, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

SKILL.md and 6 other files (references, assets) in .claude/skills/prd-v07-implementation-loop of mattgierhart/PRD-driven-context-engineering.

  • SKILL.md
  • assets/session-state.md
  • assets/traceability-checklist.md
  • references/behavioral-examples.md
  • references/examples.md
  • references/session-state.md
  • references/traceability.md

Open the folder on GitHubat commit 30ed1b0

Compare with similar skills

Prd V07 Implementation Loop next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Prd V07 Implementation Loop compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Prd V07 Implementation Loop this skillmattgierhart/PRD-driven-context-engineering180—~5.1kAutomated safety check: NotesMIT
Speccodewithmukesh/dotnet-claude-kit751—~2kAutomated safety check: PassMIT
Ralph Tui Create Beadssubsy/ralph-tui2.5k1 repos~2.6kAutomated safety check: PassMIT
Ralph Tui Create Beads Rustsubsy/ralph-tui2.5k1 repos~2.8kAutomated safety check: PassMIT
Ralph Tui Create JSONsubsy/ralph-tui2.5k1 repos~2.6kAutomated safety check: PassMIT
To Prdywwynm/EverythingDone14411 repos~777Automated safety check: PassGPL-3.0

Similar skills

  • Spec

    codewithmukesh/dotnet-claude-kit

    Turn a vague feature or product idea into an agreed, persisted specification through relentless structured questioning.

    751 GitHub stars~2k tokensUpdated 2 mo ago
    Product & Project ManagementAuto-check passed
  • Ralph Tui Create Beads

    subsy/ralph-tui

    Convert PRDs to beads for ralph-tui execution. An agent skill from subsy/ralph-tui.

    2.5k GitHub starsUsed in 1 repo~2.6k tokens
    Product & Project ManagementAuto-check passed
  • Convert PRDs to beads for ralph-tui execution using beads-rust (br CLI).

    2.5k GitHub starsUsed in 1 repo~2.8k tokens
    Product & Project ManagementAuto-check passed
  • Ralph Tui Create JSON

    subsy/ralph-tui

    Convert PRDs to prd.json format for ralph-tui execution. An agent skill from subsy/ralph-tui.

    2.5k GitHub starsUsed in 1 repo~2.6k tokens
    Product & Project ManagementAuto-check passed
  • To Prd

    ywwynm/EverythingDone

    Turn the current conversation context into a PRD and publish it to the project issue tracker.

    144 GitHub starsUsed in 11 repos~777 tokens
    Product & Project ManagementAuto-check passed
  • Ralph

    julianromli/opencode-template

    Autonomous agent loop for completing features. An agent skill from julianromli/opencode-template.

    144 GitHub starsUsed in 1 repo~1.1k tokens
    Product & Project ManagementAuto-check passed

More from mattgierhart/PRD-driven-context-engineering

All 45 skills in this repo
  • Prd V06 Technical Specification

    mattgierhart/PRD-driven-context-engineering

    Define implementation contracts (APIs and data models) that developers will build against during PRD v0.6 Architecture.

    180 GitHub starsUsed in 1 repo~3.4k tokens
    Auto-check passed
  • Ghm Gate Check

    mattgierhart/PRD-driven-context-engineering

    Validates gate criteria before PRD lifecycle advancement by delegating to the readiness scoring pipeline (scripts/readiness.py).

    180 GitHub stars~1.3k tokensUpdated 1 mo ago
    Auto-check: notes
  • Ghm Harvest

    mattgierhart/PRD-driven-context-engineering

    Extracts durable insights from temp/ files to SoT during EPIC Phase E.

    180 GitHub stars~1.1k tokensUpdated 1 mo ago
    Auto-check passed
  • Ghm Id Register

    mattgierhart/PRD-driven-context-engineering

    Validates and registers new SoT IDs with cross-reference integrity.

    180 GitHub stars~1.5k tokensUpdated 1 mo ago
    Auto-check passed
  • Ghm Sot Builder

    mattgierhart/PRD-driven-context-engineering

    Creates new Source of Truth (SoT) files when existing templates don't fit your needs.

    180 GitHub stars~2k tokensUpdated 1 mo ago
    Auto-check passed
  • Prd V01 Problem Framing

    mattgierhart/PRD-driven-context-engineering

    Transform vague product ideas into evidence-anchored problem statements for PRD v0.1 Spark.

    180 GitHub stars~1.7k tokensUpdated 1 mo ago
    Auto-check passed

Works with

Questions about Prd V07 Implementation Loop

What does Prd V07 Implementation Loop do?

Execute implementation within EPICs following test-first development, continuous SoT updates, and code traceability during PRD v0.7 Build Execution. Prd V07 Implementation Loop is an agent skill from mattgierhart/PRD-driven-context-engineering.7 Build Execution.

When should I use Prd V07 Implementation Loop?

Prd V07 Implementation Loop fits situations like: requests to start building; implement an epic; user asks start building; build execution.

How do I install Prd V07 Implementation Loop in Claude Code?

Run `npx skills add mattgierhart/PRD-driven-context-engineering --skill prd-v07-implementation-loop -a claude-code`. Or copy the skill folder (.claude/skills/prd-v07-implementation-loop in mattgierhart/PRD-driven-context-engineering) into .claude/skills/prd-v07-implementation-loop in your project. Claude Code loads it when a task matches its description.

How do I install Prd V07 Implementation Loop in Codex?

Run `npx skills add mattgierhart/PRD-driven-context-engineering --skill prd-v07-implementation-loop -a codex`. Or copy the skill folder (.claude/skills/prd-v07-implementation-loop in mattgierhart/PRD-driven-context-engineering) into .agents/skills/prd-v07-implementation-loop in your project. Codex loads it when a task matches its description.

Can I use Prd V07 Implementation Loop in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add mattgierhart/PRD-driven-context-engineering --skill prd-v07-implementation-loop -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/prd-v07-implementation-loop, .gemini/skills/prd-v07-implementation-loop, .github/skills/prd-v07-implementation-loop and .opencode/skills/prd-v07-implementation-loop in your project.

What does Prd V07 Implementation Loop need to run?

Going by SKILL.md and its folder, Prd V07 Implementation Loop needs credentials named INVALID_PASSWORD. Its frontmatter pre-approves these tools: Read, Write, Edit, Glob, Grep, Bash.

Does Prd V07 Implementation Loop access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Prd V07 Implementation Loop safe to install?

Our automated static check of SKILL.md found notes only (pre-approves every shell command (allowed-tools: bash)), nothing it rates as a warning. It is not a guarantee. Review the folder before installing.

What licence does Prd V07 Implementation Loop use?

Prd V07 Implementation Loop is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Prd V07 Implementation Loop use?

About 5.1k tokens (SKILL.md is roughly 20k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full. Its references folder adds about 6.1k tokens, read only when the agent opens those files.

What are the alternatives to Prd V07 Implementation Loop?

Skills that share tags, products or a category with Prd V07 Implementation Loop: Spec (codewithmukesh/dotnet-claude-kit, 751 stars), Ralph Tui Create Beads (subsy/ralph-tui, 2.5k stars), Ralph Tui Create Beads Rust (subsy/ralph-tui, 2.5k stars) and Ralph Tui Create JSON (subsy/ralph-tui, 2.5k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Prd V07 Implementation Loop?

mattgierhart (a GitHub user) maintains it in mattgierhart/PRD-driven-context-engineering, which has 180 GitHub stars. The repository holds 45 skills in this directory. The repository was last updated on August 31, 2026.

Source: mattgierhart/PRD-driven-context-engineering on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.