vt-c-pd-inbox-scan¶

Monitor project inbox for new items requiring design workflow attention. Detects usability test results, stakeholder feedback, and other inputs that may trigger iteration.

Plugin: core-standards
Category: Product Design Workflow
Command: /vt-c-pd-inbox-scan

Product Design: Inbox Scan¶

Scan the project inbox for new information that may require design workflow iteration.

Workflow Position¶

ITERATIVE DESIGN LOOP:

   New Input → [ /vt-c-pd-inbox-scan ] → /vt-c-pd-analyze-changes → /vt-c-pd-route-decision
                    ▲ YOU ARE HERE

Invocation¶

/vt-c-pd-inbox-scan                    # Scan current project inbox
/vt-c-pd-inbox-scan --project PATH     # Scan specific project

What This Skill Does¶

Loads current design state from .design-state.yaml
Scans the 00-Inbox/ folder for files newer than last scan
Classifies new items by type and urgency
Updates the design state file with pending items
Routes fully-processed items (analyzed: true) to destination folders
Reports findings (including routing results) and recommends next action

Execution Instructions¶

Step 0: Locate Project¶

Find the OneDrive project folder:

# Look for .design-state.yaml or OneDrive project structure
ls -la .design-state.yaml 2>/dev/null || \
ls -la */03-PRD/PRD.md 2>/dev/null

If not in a project context, ask user for project path.

Step 1: Load or Initialize Design State¶

# Check if state file exists
if [ -f ".design-state.yaml" ]; then
  Read: .design-state.yaml
else
  echo "No design state found. Initializing..."
  # Create from template (will be done in pd-0-start)
fi

Extract from state: - inbox.last_scan - timestamp of last inbox scan - current_state.phase - current workflow phase - current_state.iteration - iteration number

Step 1.5: Resolve Inbox Path¶

Detect the project inbox by checking these paths in priority order:

00-inbox/ (standard)
00-Inbox/ (legacy capitalization)
01-docs/01-inbox/ (alternative)
docs/inbox/ (alternative)
docs/00-inbox/ (C001 pattern)

Use whichever is found first. If none found, report: "No inbox folder detected. Create 00-inbox/ to use inbox scanning."

Store the resolved path as INBOX_DIR and use it in all subsequent steps instead of a hardcoded path.

Step 2: Scan Inbox for New Items¶

# Find files modified since last scan
LAST_SCAN="{from .design-state.yaml}"

# Get new files in inbox (using resolved INBOX_DIR)
find $INBOX_DIR -type f -newer .design-state.yaml 2>/dev/null

# If no state file, get all inbox files
find $INBOX_DIR -type f

Step 3: Classify New Items¶

For each new file, determine type based on filename patterns:

Pattern	Type	Urgency	Description
`usability`, `test-result`, `user-test`	usability_test	HIGH	Usability test findings
`stakeholder`, `feedback`, `review`	stakeholder_feedback	MEDIUM	Stakeholder input
`competitor`, `market`, `benchmark`	market_intel	LOW	Market/competitive data
`technical`, `feasibility`, `constraint`	tech_constraint	HIGH	Technical limitations
`interview`, `transcript`, `user-research`	user_research	MEDIUM	New user research
`requirement`, `scope`, `change-request`	scope_change	HIGH	Scope changes
`bug`, `issue`, `defect`	bug_report	MEDIUM	Bug/issue reports
`design`, `mockup`, `wireframe`	design_update	LOW	Design assets

Urgency Classification: - HIGH: May block current phase or require immediate return - MEDIUM: Should be processed before phase transition - LOW: Can be batched with next iteration

Step 4: Compute Artifact Hashes (Optional)¶

Check if core artifacts have changed:

# PRD hash
md5 03-PRD/PRD.md 2>/dev/null

# Prototype hash (directory checksum)
find 04-prototyp/ -type f -exec md5 {} \; 2>/dev/null | sort | md5

# specs hash
find "05-specs/" -name "*.md" -exec md5 {} \; 2>/dev/null | sort | md5

Compare to stored hashes in .design-state.yaml

Step 5: Update Design State File¶

Update .design-state.yaml:

inbox:
  last_scan: "{current timestamp}"
  pending_items:
    - file: "00-Inbox/{filename}"
      detected_at: "{timestamp}"
      type: "{classified type}"
      urgency: "{HIGH|MEDIUM|LOW}"
      analyzed: false

Step 6: Route Processed Items¶

After updating the state with new items, route any previously-processed items out of the inbox. This keeps 00-Inbox/ clean so you can see at a glance whether pending work exists.

Only route items that meet ALL of these conditions: - Marked analyzed: true in .design-state.yaml inbox.pending_items - NOT already marked processed: true - File still exists at the recorded path

6a. Detect git context (run once):

git rev-parse --is-inside-work-tree 2>/dev/null

Exit code 0 → git project → use git mv
Non-zero → non-git project (OneDrive) → use mv

6b. For each eligible item, determine destination:

File Type	Destination	Rationale
Meeting transcripts	`02-Knowledge/04-Dokumente/`	Reference material
Input documents (requirements, specs)	`02-Knowledge/04-Dokumente/`	Incorporated into PRD
Database schemas, technical docs	`02-Knowledge/04-Dokumente/`	Technical reference
External reports (xlsx, pdf)	`02-Knowledge/04-Dokumente/`	Business reference
Items with no actionable content	`00-Inbox/99-alt/`	Archive
All other analyzed items	`02-Knowledge/04-Dokumente/`	Default destination

6c. Move each file:

Create destination directory if it does not exist: mkdir -p "{destination}"
Check for name collision at destination — if a file with the same name exists, append a timestamp suffix (e.g., document_2026-02-28T1200.md) to avoid overwriting
Move the file:
Git project: git mv "{source}" "{destination}/{filename}"
Non-git project: mv "{source}" "{destination}/{filename}"
For directory-type items (e.g., database schema folders): move the entire directory, not individual files

6d. Update state after each successful move:

Add processed, routed_to, and routed_at to the item's entry in .design-state.yaml:

inbox:
  pending_items:
    - file: "00-Inbox/2026-02-20 summary of novalnet info.md"
      analyzed: true
      processed: true
      routed_to: "02-Knowledge/04-Dokumente/"
      routed_at: "2026-02-28T12:00:00"

Update state after each individual move (not as a batch) for crash safety.

6e. Handle edge cases:

File missing from disk (already moved manually): Log a warning, mark as processed: true in state with routed_to: "unknown (manual)", skip
Mixed inbox (analyzed + un-analyzed items): Only route analyzed items; un-analyzed items remain in 00-Inbox/

Step 7: Generate Scan Report¶

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Product Design: Inbox Scan Results
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Project: {project_name}
Current Phase: {phase} (Iteration {iteration})
Last Scan: {last_scan_timestamp}

New Items Detected: {count}
─────────────────────────────────────────────────────────────────
{For each item:}
{number}. [{urgency}] {type}: {filename}
   Detected: {timestamp}

Artifact Changes: {count}
─────────────────────────────────────────────────────────────────
PRD: {No change | CHANGED (v{old} → v{new})}
Prototype: {No change | CHANGED}
specs: {No change | CHANGED}

Inbox Routing: {routed_count} routed, {skipped_count} skipped
─────────────────────────────────────────────────────────────────
{If any files were routed:}
  -> 02-Knowledge/04-Dokumente/: {count} files
  -> 00-Inbox/99-alt/: {count} files
{If any files were skipped:}
  Warnings: {count} (file missing or already processed)
{If no routing occurred:}
  No analyzed items to route.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

If HIGH urgency items found:

⚠️  HIGH URGENCY items detected

ACTION REQUIRED: Run /vt-c-pd-analyze-changes to assess impact
                 before continuing current phase.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
NEXT STEP: /vt-c-pd-analyze-changes
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

If MEDIUM urgency items found:

ℹ️  MEDIUM urgency items detected

RECOMMENDATION: Process before transitioning to next phase.
                Run /vt-c-pd-analyze-changes when ready.

Current phase work can continue.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
OPTIONAL: /vt-c-pd-analyze-changes
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

If LOW urgency items only:

✓ LOW urgency items only

Items will be processed in next iteration batch.
Continue with current phase work.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
CONTINUE: Current phase ({phase})
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

If no new items:

✓ Inbox clear

No new items detected since last scan.
Continue with current phase work.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
CONTINUE: Current phase ({phase})
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Integration with Orchestrator¶

The product-design-orchestrator should call /vt-c-pd-inbox-scan automatically: - Before every phase transition - At the start of each session - When user explicitly requests

State File Location¶

The .design-state.yaml file is stored in the project root:

OneDrive/[Project]/
├── .design-state.yaml    ← Design workflow state
├── 00-Inbox/             ← Monitored folder
├── 03-PRD/
├── 04-prototyp/
└── 05-specs/

/vt-c-pd-analyze-changes - Analyze impact of detected items
/vt-c-pd-route-decision - Decide which phase to return to
/vt-c-pd-0-start - Initialize design state file