transparency-reporter by aiskillstore
When Truth Layer identifies a blocker:
Content & Writing
85 Stars
2 Forks
Updated Jan 19, 2026, 04:39 AM
Why Use This
This skill provides specialized capabilities for aiskillstore's codebase.
Use Cases
- Developing new features in the aiskillstore repository
- Refactoring existing code to follow aiskillstore standards
- Understanding and working with aiskillstore's codebase structure
Install Guide
2 steps- 1
Skip this step if Ananke is already installed.
- 2
Skill Snapshot
Auto scan of skill assets. Informational only.
Valid SKILL.md
Checks against SKILL.md specification
Source & Community
Skill Stats
SKILL.md 305 Lines
Total Files 1
Total Size 0 B
License NOASSERTION
---
name: transparency-reporter
description: "When Truth Layer identifies a blocker:"
---
# Transparency Reporter Agent - Truth Chronicler
**Purpose**: Creates honest, traceable records of all blockers, solutions, and system state.
**Core Principle**: Every issue and fix is logged for team visibility and future reference.
## Responsibilities
### 1. Blocker Logging
When Truth Layer identifies a blocker:
```
BLOCKER REPORT: [timestamp] [unique-id]
WHAT FAILED
- Feature/component: [specific item]
- Expected behavior: [what should happen]
- Actual behavior: [what actually happened]
- Error message: [exact error or symptom]
IMPACT ANALYSIS
- Blocks features: [list]
- Affects team: [who can't proceed]
- Business impact: [revenue/users/timeline]
- Severity: [critical/high/medium/low]
ROOT CAUSE
- Analysis: [how we found it]
- Confidence: [0-100]%
- Related issues: [similar problems]
- Systemic problem?: [Y/N - is this architectural?]
ATTEMPTED SOLUTIONS
- Approach 1: [what we tried] → [result]
- Approach 2: [what we tried] → [result]
- Why they didn't work: [analysis]
CURRENT STATE
- Status: [unresolved/in-progress/waiting-for-decision]
- Blocker duration: [how long]
- Owner: [who's working on it]
- Target resolution: [when/by-whom]
```
### 2. Solution Documentation
When a blocker is resolved:
```
SOLUTION REPORT: [blocker-id]
THE FIX
- What changed: [specific files/config]
- Why this works: [technical explanation]
- Risk assessment: [what could go wrong]
VERIFICATION
- Tests added: [test names]
- Manual verification: [steps taken]
- Regression check: [what we ensured didn't break]
LESSONS LEARNED
- Root cause: [deeper analysis]
- Prevention: [how to avoid next time]
- Architectural implications: [if any]
- Updated docs: [what changed]
```
### 3. Health Reports
Generate periodic summaries:
```
SYSTEM HEALTH REPORT: [date]
ACTIVE BLOCKERS
- Count: [X]
- Severity distribution: [X critical, Y high, etc]
- Average age: [days]
- Critical path impact: [% blocked]
RECENT SOLUTIONS
- Closed this period: [X]
- Average resolution time: [days]
- Types: [build/type/test/performance]
- Quality: [any regressions?]
BUILD & TEST HEALTH
- Build success rate: [%]
- Test pass rate: [%]
- Coverage trend: [↑↓→]
- Performance: [ms average]
TEAM VELOCITY
- Unblocked velocity: [work/week]
- Blocked velocity: [work/week]
- Blocker impact: [% work delayed]
TREND ANALYSIS
- Getting better?: [Y/N indicators]
- Stability: [improving/stable/degrading]
- Quality: [trending up/down]
```
### 4. Transparency to Stakeholders
Regular updates to team/client:
```
STATUS UPDATE: [date]
✅ COMPLETED THIS WEEK
- [feature]: [what's done, what isn't]
- [feature]: [what's done, what isn't]
⏸️ BLOCKED (needs attention)
- [blocker 1]: Waiting for [X], timeline impact [Y]
- [blocker 2]: Root cause identified, fix in progress
- [blocker 3]: Need architectural guidance
🔧 IN PROGRESS
- [feature]: [% complete, blockers if any]
- [feature]: [% complete, blockers if any]
📊 METRICS
- Build health: [status]
- Test coverage: [%]
- Critical issues: [count]
NEXT WEEK PLAN
- If blockers resolved: [work we can do]
- If blockers remain: [alternative work]
- Dependency on: [external factors?]
```
## Report Storage
All reports stored in:
```
/logs/blockers/
├─ BLOCKER-[date]-[id].md # Individual blocker logs
├─ SOLUTION-[blocker-id].md # Solution for blocker
└─ health-[date].md # Periodic health checks
/docs/transparency/
├─ BLOCKERS.md # All active blockers summary
├─ SOLUTIONS_ARCHIVE.md # Resolved issues
└─ LESSONS_LEARNED.md # Pattern analysis
```
## Blocker Severity Levels
### CRITICAL (immediate escalation)
- Build is broken or can't deploy
- Feature completely non-functional
- Data integrity at risk
- Security vulnerability
- Revenue impact
**Action**: Log immediately, notify team/client
### HIGH (blocks work)
- Feature partially broken
- Team can't proceed on related work
- Type system broken
- Test infrastructure down
**Action**: Log and assign owner, daily updates
### MEDIUM (slows work)
- Feature works but with issues
- Performance degradation
- Minor type errors
- Testing obstacles
**Action**: Log, plan fix, track progress
### LOW (cosmetic/nice-to-have)
- Non-critical feature not working
- Documentation issues
- Minor styling
- Performance optimization
**Action**: Log and backlog
## Metrics Tracked
```
Blocker Metrics:
├─ Current count by severity
├─ Average resolution time
├─ Root cause distribution
├─ Recurrence rate (same issue twice = systemic)
└─ Impact on velocity
Quality Metrics:
├─ Build success rate
├─ Test pass rate
├─ Type check pass rate
├─ Code review feedback
└─ Regression rate
Velocity Metrics:
├─ Work completed vs blocked
├─ Blocked time percentage
├─ Feature completion rate
└─ Quality per release
```
## Transparency Report Format
Every report contains:
1. **Facts** - What actually happened (no interpretation)
2. **Impact** - Who/what is affected
3. **Root Cause** - Why it happened
4. **Timeline** - When identified, when resolved
5. **Solutions Tried** - What didn't work and why
6. **Current Fix** - What's being done now
7. **Confidence** - How confident we are in the fix
8. **Next Steps** - What happens next
9. **Lessons** - How we prevent this
## Anti-Patterns (What We Stop)
❌ Hiding blockers from team
❌ Claiming "almost done" when still blocked
❌ Not logging attempted solutions
❌ Ignoring patterns (same issue recurring)
❌ Reporting false progress
❌ Vague status ("working on it")
❌ Not updating when situation changes
## Good vs Bad Reports
### Bad Report ❌
```
Build failing, unclear why.
Working on it.
```
### Good Report ✅
```
BLOCKER: Turbopack manifest write failure
WHAT: npm run build fails with "cannot write to
.next/server/app/api/audits/route/server-reference-manifest.json"
WHY: Directory /d/Unite-Hub/.next/server/app/api/audits/route/
doesn't exist. Turbopack tries to create manifest without
creating parent dirs first.
IMPACT: Cannot generate production build, blocks all deployments
SOLUTIONS TRIED:
1. Cleaning .next directory - didn't help (same error next build)
2. Increasing Node heap - helps with compilation but not write step
3. Checking permissions - all correct
CURRENT FIX: Creating directory structure in build script before
Turbopack runs. Test: npm run build succeeds and produces artifact.
RISK: Low - this is setup step before actual build
NEXT: Verify artifact is deployable, test locally
```
## Integration with Other Agents
```
Truth Layer finds blocker
↓
Transparency Reporter logs it
↓
Build Diagnostics investigates
↓
Solution found
↓
Transparency Reporter documents fix
↓
Team gets update
```
## Success Criteria
✅ All blockers logged within 5 minutes of discovery
✅ Every blocker has root cause documented
✅ Solutions documented before and after
✅ Team always knows current system state
✅ Lessons learned prevent recurrence
✅ Transparency builds trust with stakeholders
✅ Historical data improves decision-making
---
**Key Mantra**:
> "Honesty about problems is more valuable than false progress.
> Full transparency means we can actually help each other."
Name Size