Initial commit

This commit is contained in:
Zhongwei Li
2025-11-30 08:43:43 +08:00
commit 025c9debb4
7 changed files with 796 additions and 0 deletions

View File

@@ -0,0 +1,12 @@
{
"name": "productivity",
"description": "Productivity and reporting tools for daily summaries, work tracking, and team communication",
"version": "0.0.0-2025.11.28",
"author": {
"name": "Jeremy Miranda",
"email": "jeremy@nicewolfstudio.com"
},
"skills": [
"./skills/daily-summary"
]
}

3
README.md Normal file
View File

@@ -0,0 +1,3 @@
# productivity
Productivity and reporting tools for daily summaries, work tracking, and team communication

56
plugin.lock.json Normal file
View File

@@ -0,0 +1,56 @@
{
"$schema": "internal://schemas/plugin.lock.v1.json",
"pluginId": "gh:Nice-Wolf-Studio/wolf-skills-marketplace:productivity",
"normalized": {
"repo": null,
"ref": "refs/tags/v20251128.0",
"commit": "bc85fa78fcd3736b235376aed5ea59f0b6f6a4ab",
"treeHash": "a6d9dafaf948c31ebeaeae199805263525bab5e88f87153940dd26062d2c83ba",
"generatedAt": "2025-11-28T10:12:14.499761Z",
"toolVersion": "publish_plugins.py@0.2.0"
},
"origin": {
"remote": "git@github.com:zhongweili/42plugin-data.git",
"branch": "master",
"commit": "aa1497ed0949fd50e99e70d6324a29c5b34f9390",
"repoRoot": "/Users/zhongweili/projects/openmind/42plugin-data"
},
"manifest": {
"name": "productivity",
"description": "Productivity and reporting tools for daily summaries, work tracking, and team communication"
},
"content": {
"files": [
{
"path": "README.md",
"sha256": "b1d35ac182ec9adebff36611d6b5fbefc4f03c937828a5d2b4e5721922e79fa4"
},
{
"path": ".claude-plugin/plugin.json",
"sha256": "1a54ed6f70b29259479af07a87f376a5fd4ae51e2670a9c1e940399ea3aed7a2"
},
{
"path": "skills/daily-summary/SKILL.md",
"sha256": "49ef37b37f02bea3900053833f58ed447ae0fefd1a19e2e7b64f513ac0dea37e"
},
{
"path": "skills/daily-summary/references/agent-instructions.md",
"sha256": "7fd7401de1cb89004369aff8a1ed09ae23acfd40a364424ae600ca883bf9bfdf"
},
{
"path": "skills/daily-summary/references/agent-definitions.md",
"sha256": "e26bb232bcb6fb9c058abf9a7ecd0e0fe773fa3a5e841226b991cefd23afe5a2"
},
{
"path": "skills/daily-summary/assets/daily-pr-summary-template.md",
"sha256": "aff9a6ec5d0fbd14588c7656b9673a8afcb1e356d0d6313303ea1c42e01b99d5"
}
],
"dirSha256": "a6d9dafaf948c31ebeaeae199805263525bab5e88f87153940dd26062d2c83ba"
},
"security": {
"scannedAt": null,
"scannerVersion": null,
"flags": []
}
}

View File

@@ -0,0 +1,369 @@
---
name: daily-summary
version: 1.0.1
description: Use when preparing daily standups or status reports - automates PR summary generation with categorization, metrics, and velocity analysis; eliminates manual report compilation and ensures consistent format
triggers:
- daily standup
- PR summary
- status report
- progress tracking
- gh pr list
---
# Daily Summary Skill
This skill automates the generation of comprehensive daily Pull Request (PR) summaries for team standups, status reports, and progress tracking. It produces structured markdown reports with metrics, categorization, contributor activity analysis, and velocity tracking.
## When to Use This Skill
Use this skill when you need:
- Daily standup preparation with current PR status
- End-of-day progress reporting for stakeholders
- Project status updates with metrics
- PR activity analysis and trends
- Weekly or monthly sprint retrospectives
- Contributor focus and productivity analysis
## When NOT to Use This Skill
Skip this skill when:
- **Real-time PR monitoring** - Use GitHub notifications or `gh pr status` instead
- **Individual PR details** - Use `gh pr view <number>` for single PR inspection
- **Non-GitHub repositories** - This skill requires GitHub-hosted projects
- **Missing `gh` CLI** - Installation of GitHub CLI is mandatory (see Dependencies)
- **Ad-hoc queries** - Use direct `gh` commands for one-off questions
- **Live collaboration** - Use GitHub web interface for interactive review sessions
## What This Skill Provides
Automated generation of structured markdown reports including:
- **Key Metrics** - PRs created/merged/open, active contributors
- **Categorized PR Lists** - Performance, Bug Fixes, Features, UI/UX, Documentation
- **Contributor Activity** - Breakdown by developer with focus areas
- **Highlights and Themes** - Grouped work patterns
- **Impact Summary** - Code quality, UX improvements, developer experience
- **Velocity Metrics** - Average time to merge, review turnaround
- **Action Items** - PRs ready for review, blockers, backlog items
## Dependencies
### Required Tools
- **GitHub CLI (`gh`)** - Required for fetching PR data
```bash
# Install: https://cli.github.com/
# Verify: gh --version
```
### Optional Tools
- **jq** - JSON processing for advanced filtering (recommended but not required)
### Bundled Resources
This skill includes:
- `assets/daily-pr-summary-template.md` - Output format specification
- `references/agent-instructions.md` - Agent framework methodology context
- `references/agent-definitions.md` - Terminology and behavioral principles
## The Seven Steps (MANDATORY)
### Step 1: Data Collection (REQUIRED)
Fetch PR data using GitHub CLI:
```bash
# Basic PR list command
gh pr list \
--repo [owner]/[repo] \
--state all \
--limit 100 \
--json number,title,state,createdAt,mergedAt,closedAt,author,url,additions,deletions,labels
```
The JSON output provides all necessary data for analysis and categorization.
**GATE: Verify JSON response contains expected fields before proceeding.**
### Step 2: Date Filtering (REQUIRED)
Filter PRs for the target date or date range:
```bash
# For single-day summary
TARGET_DATE="2025-11-13"
# Filter PRs created on target date
jq --arg date "$TARGET_DATE" \
'[.[] | select(.createdAt | startswith($date))]'
# Filter PRs merged on target date
jq --arg date "$TARGET_DATE" \
'[.[] | select(.mergedAt | startswith($date))]'
# For date range (sprint retrospective)
jq '[.[] | select(
(.createdAt >= "2025-10-28") and (.createdAt <= "2025-11-13")
)]'
```
**GATE: Confirm filtered PR count > 0 and matches expected activity level. If zero PRs, verify date format and repository activity.**
### Step 3: Categorization (MANDATORY)
Apply keyword-based categorization to PR titles and labels:
**Categories:**
- **Performance & Optimization** - Keywords: `perf`, `optimize`, `memory`, `performance`, `speed`, `cache`
- **Bug Fixes** - Keywords: `fix`, `bug`, `resolve`, `issue`, `patch`
- **Features** - Keywords: `feat`, `feature`, `add`, `implement`, `new`
- **UI/UX** - Keywords: `ui`, `ux`, `design`, `animation`, `responsive`, `layout`
- **Documentation** - Keywords: `docs`, `documentation`, `readme`, `comments`, `adr`
- **Refactoring** - Keywords: `refactor`, `cleanup`, `restructure`, `simplify`
- **Testing** - Keywords: `test`, `spec`, `coverage`, `qa`
**Example Categorization Logic:**
```bash
if [[ "$title" =~ (perf|optimize|memory|performance) ]]; then
category="Performance & Optimization"
elif [[ "$title" =~ (fix|bug|resolve|issue) ]]; then
category="Bug Fixes"
elif [[ "$title" =~ (feat|feature|add|implement) ]]; then
category="Features"
# ... continue for other categories
fi
```
**GATE: Every PR must be categorized. "Uncategorized" should be < 10% of total PRs. If > 10%, review keyword rules.**
### Step 4: Priority Assignment (MANDATORY)
Assign priority based on keywords in title or labels:
- 🔴 **HIGH PRIORITY** - Keywords: `breaking`, `critical`, `blocker`, `security`, `urgent`
- 🟡 **MEDIUM PRIORITY** - Keywords: `feature`, `enhancement`, `bug` (non-critical)
- 🟢 **LOW PRIORITY** - Keywords: `docs`, `chore`, `style`, `minor`
**GATE: All PRs must have priority assigned. Default to MEDIUM if no keywords match.**
### Step 5: Contributor Analysis (REQUIRED)
Group PRs by author and track focus areas:
```bash
# Count PRs by author
jq 'group_by(.author.login) |
map({author: .[0].author.login, count: length, prs: map(.number)})'
# Identify focus areas by analyzing categories of each author's PRs
```
**Track:**
- PRs created count
- PRs merged count
- Focus areas (primary categories)
- Human vs. bot contributors
**GATE: Contributor count must match unique authors in filtered data. Verify no duplicate attribution.**
### Step 6: Velocity Calculation (REQUIRED)
Calculate time-based metrics:
```bash
# Average time to merge (in hours)
jq '[.[] | select(.mergedAt != null) |
(((.mergedAt | fromdate) - (.createdAt | fromdate)) / 3600)] |
add / length'
# Active development windows (peak activity hours)
jq '[.[] | .createdAt | fromdate | strftime("%H")] |
group_by(.) | map({hour: .[0], count: length}) | sort_by(.count) | reverse'
```
**GATE: Velocity metrics must be calculated for all merged PRs. If no merged PRs, state "N/A - no merges in period" in report.**
### Step 7: Report Generation (MANDATORY)
Fill in the template (`assets/daily-pr-summary-template.md`):
1. Load template content
2. Replace `[count]` placeholders with calculated values
3. Fill in PR lists with categorized entries
4. Add contributor breakdown
5. Insert velocity metrics
6. List action items (open PRs needing review)
**GATE: All template sections must be filled. No `[placeholder]` text should remain in final output.**
## Red Flags - STOP
Immediately halt and fix if you observe:
- 🚨 **Fetching PR data without date filtering** - You'll pull thousands of irrelevant PRs. Filter immediately after fetch.
- 🚨 **Skipping categorization** - Everything marked "Uncategorized" means keyword rules weren't applied. Go back to Step 3.
- 🚨 **Not validating contributor counts** - Duplicate authors or missing bot detection corrupts analysis. Verify unique authors.
- 🚨 **Missing velocity calculations** - Average merge time and turnaround are core metrics. Don't skip Step 6.
- 🚨 **Template sections left unfilled** - `[count]`, `[author]`, `[category]` placeholders in output = incomplete execution.
- 🚨 **Running multiple times for same date** - Cache results! Re-running wastes API quota and produces identical output.
- 🚨 **Zero PRs in filtered results** - Verify date format (YYYY-MM-DD), repository name, and that activity occurred on target date.
## Verification Checklist
Before delivering the report, confirm:
- [ ] Report generated without errors
- [ ] All PRs from target date included (verify count matches API response)
- [ ] Categorization accuracy ≥ 90% (manual spot-check recommended)
- [ ] Metrics calculations correct (sanity checks on outliers)
- [ ] Output follows template format exactly
- [ ] Executable commands included for verification
- [ ] Data collection timestamp included in report
- [ ] No `[placeholder]` text remains in final output
- [ ] Contributor count matches unique authors in data
- [ ] Velocity metrics calculated (or explicitly marked N/A)
## Usage Examples
### Example 1: Daily Standup Summary
**Context:** Monday morning standup, need summary of Friday's work
**Command:**
```bash
gh pr list --repo owner/repo \
--state all --limit 100 \
--json number,title,state,createdAt,mergedAt,author,url | \
jq '[.[] | select(
(.createdAt | startswith("2025-11-08")) or
(.mergedAt | startswith("2025-11-08"))
)]'
```
**Output:** `daily-summary-2025-11-08.md` with Friday's PRs categorized and analyzed
### Example 2: Sprint Retrospective
**Context:** End of 2-week sprint, need cumulative summary
**Command:**
```bash
gh pr list --repo owner/repo \
--state all --limit 200 \
--json number,title,state,createdAt,mergedAt,author,url | \
jq '[.[] | select(
(.createdAt >= "2025-10-28") and (.createdAt <= "2025-11-08")
)]'
```
**Output:** `sprint-46-retrospective.md` with aggregated metrics across 2 weeks
### Example 3: Contributor Focus Report
**Context:** Manager needs to understand individual contributions
**Command:**
```bash
gh pr list --repo owner/repo \
--author username \
--state all --limit 50 \
--json number,title,state,createdAt,mergedAt,url | \
jq '[.[] | select(
(.createdAt >= (now - 604800 | strftime("%Y-%m-%d")))
)]'
```
**Output:** Contributor-focused report with activity patterns and specialization
## Integration with Agent Framework
This skill was developed within the olympics-fotb agent framework, which uses:
- **Eight-Phase Methodology** - Structured approach from introspection to reality check
- **Confidence Scale (0-10)** - Quantifies certainty before and after execution
- **Role-Based Execution** - Used primarily by `reporting-agent` and `pm-agent` roles
- **Complexity Ratings** - Tracks low/medium/high complexity, not time estimates
For context on the framework, see the bundled `references/` files.
---
## After Using This Skill
**REQUIRED NEXT STEPS:**
1. **Share the report** - Distribute to stakeholders via Slack, email, or wiki
2. **Archive data** - Save PR JSON response for historical analysis
3. **Update tracking** - Mark standup/status report as complete in project tracker
**OPTIONAL NEXT STEPS:**
- **Trend Analysis** - Compare with previous reports to identify velocity changes
- **Action Items Follow-up** - Create GitHub issues for blockers identified in report
- **Team Metrics** - Track PR merge times, review latency trends over time
---
## Skill Maturity
**Current Confidence Level:** 8/10
- ✅ Template format proven
- ✅ Data collection commands tested
- ✅ Categorization rules documented and validated manually
- ⏳ Automation not yet in production (reduces confidence by 1)
- ⏳ Cross-project validation pending (prevents 10/10)
**Path to 9/10:** Successful automation in production for 2+ weeks with ≥90% accuracy
**Path to 10/10:** Canonicalized after 3+ months of reliable use across multiple projects
## Related Resources
### Templates
- `assets/daily-pr-summary-template.md` - Output format specification
### Framework Documentation
- `references/agent-instructions.md` - Eight-Phase methodology and confidence scale
- `references/agent-definitions.md` - Canonical vocabulary and behavioral principles
### External Resources
- GitHub CLI Documentation: https://cli.github.com/manual/gh_pr_list
- jq Manual: https://stedolan.github.io/jq/manual/
## Changelog
**v1.0.1** (2025-11-14)
- Added `version` and `triggers` to frontmatter for skill discovery
- Enhanced description to follow superpowers style (when/what/why format)
- Added "When NOT to Use This Skill" section with anti-patterns
- Renamed "Implementation Guide" → "The Seven Steps (MANDATORY)"
- Added REQUIRED/MANDATORY language to step headers
- Added gate functions between steps for validation checkpoints
- Added "Red Flags - STOP" section with common failure modes
- Renamed "Validation Criteria" → "Verification Checklist" with checkbox format
- Strengthened process-oriented language throughout
- Added cache warning to prevent redundant executions
**v1.0** (2025-11-13)
- Converted to standard Claude Code SKILL.md format
- Added bundled references for agent framework context
- Included template in assets/ directory
- Adapted for use outside olympics-fotb repository
- Maintained all original implementation details and examples
**v1.0 (olympics-fotb)** (2025-11-11)
- Initial skill definition in olympics-fotb repository
- Data collection commands documented
- Categorization rules established
- Examples provided for common use cases

View File

@@ -0,0 +1,244 @@
Version: 1.0
Owner: Jeremy Miranda
Last Updated: 2025-11-10
# Daily PR Summary Template
**Purpose:** Generate comprehensive daily summaries of PR activity for team standups, status reports, and progress tracking.
**Usage:** Run `gh pr list --state all --limit 100 --json number,title,state,createdAt,mergedAt,author,url` and fill in sections below.
---
## 📊 [Project Name] - Daily PR Summary ([Date])
### 🎯 Key Metrics
- **PRs Created Today:** [count]
- **PRs Merged Today:** [count]
- **Currently Open from Today:** [count]
- **Contributors Active:** [count] ([list names])
---
## ✅ PRs Merged Today ([count])
### [Category 1: e.g., Performance & Optimization]
1. **#[number]** - `[title]`
- Author: [name]
- Merged: [time]
- Description: [brief description]
2. **#[number]** - `[title]`
- Author: [name]
- Merged: [time]
- Description: [brief description]
### [Category 2: e.g., Bug Fixes]
[Repeat pattern above]
### [Category 3: e.g., Features]
[Repeat pattern above]
### [Category 4: e.g., UI/UX]
[Repeat pattern above]
### [Category 5: e.g., Documentation]
[Repeat pattern above]
---
## 🆕 PRs Created Today ([count])
### Currently Open ([count])
#### **#[number]** - `[title]` [priority emoji: 🔴/🟡/🟢]
- **Author:** [name]
- **Created:** [time]
- **Status:** OPEN
- **Description:** [brief description]
- **Changes:** +[lines] / -[lines] lines
- **URL:** [link]
#### **#[number]** - `[title]`
[Repeat pattern above]
### Merged Same Day ([count])
- **#[number]** - `[title]`
- **#[number]** - `[title]`
### Closed Without Merge ([count])
- **#[number]** - [reason for closure]
---
## 👥 Contributor Activity
### [Contributor Name 1] ([github_username])
- **Created:** [count] PRs (#[numbers])
- **Merged:** [count] PRs (#[numbers])
- **Focus Areas:** [list areas]
### [Contributor Name 2] ([github_username])
- **Created:** [count] PRs (#[numbers])
- **Merged:** [count] PRs (#[numbers])
- **Focus Areas:** [list areas]
### [Bot/Automation Name] (Automated)
- **Created:** [count] PRs (#[numbers])
- **Merged:** [count] PRs (#[numbers])
- **Focus Areas:** [list areas]
---
## 🔥 Highlights & Themes
### [Theme 1: e.g., Performance Work] ([count] PRs)
[Brief summary of related work]
- [Key achievement 1]
- [Key achievement 2]
- [Key achievement 3]
### [Theme 2: e.g., Feature Development] ([count] PRs)
[Brief summary of related work]
- [Key achievement 1]
- [Key achievement 2]
### [Theme 3: e.g., Bug Fixes] ([count] PRs)
[Brief summary of related work]
- [Key achievement 1]
- [Key achievement 2]
---
## 📈 Impact Summary
### Code Quality
- ✅ [metric 1: e.g., PRs merged after review]
- ✅ [metric 2: e.g., Test coverage improvements]
- ✅ [metric 3: e.g., Memory leak elimination]
- ✅ [metric 4: e.g., Performance optimizations]
### User Experience
- ✅ [improvement 1]
- ✅ [improvement 2]
- ✅ [improvement 3]
### Developer Experience
- ✅ [improvement 1]
- ✅ [improvement 2]
- ✅ [improvement 3]
---
## 🚀 Velocity
- **Average Time to Merge:** [time range]
- **Review Turnaround:** [description]
- **Active Development Windows:** [time range]
- **Deployment Frequency:** [metric if applicable]
---
## 📋 Action Items for Tomorrow
### Ready for Review
1. **PR #[number]** - [title] ([author]) - [status/notes]
2. **PR #[number]** - [title] ([author]) - [status/notes]
### Blockers
- [List any blockers that need resolution]
### Backlog Open PRs (Not from today)
- **PR #[number]** - [title] ([category])
- **PR #[number]** - [title] ([category])
---
## 📝 Notes
[Any additional context, risks, or observations]
---
**Generated by:** [Agent/Tool name]
**Report Date:** [YYYY-MM-DD HH:MM]
**Data Source:** `gh pr list --state all --limit 100`
---
## Instructions for Agents
### Data Collection
```bash
# Fetch PR data
gh pr list --state all --limit 100 --json number,title,state,createdAt,mergedAt,author,url
# Filter for today's date
# Compare createdAt and mergedAt timestamps against current date
```
### Categorization Rules
1. **Performance & Optimization:** PRs with keywords: perf, optimize, memory, performance, speed
2. **Bug Fixes:** PRs with keywords: fix, bug, resolve, issue
3. **Features:** PRs with keywords: feat, feature, add, implement
4. **UI/UX:** PRs with keywords: ui, ux, design, animation, responsive
5. **Documentation:** PRs with keywords: docs, documentation, readme, comments
### Priority Indicators
- 🔴 **HIGH PRIORITY:** Breaking changes, critical bugs, blockers
- 🟡 **MEDIUM PRIORITY:** Features in review, non-critical bugs
- 🟢 **LOW PRIORITY:** Documentation, minor improvements
### Contributor Attribution
- Track both human contributors and automated tools (bots, CI/CD)
- Group by focus area to show specialization
- Include both created and merged counts for full picture
### Velocity Calculations
- **Average Time to Merge:** Calculate from createdAt to mergedAt timestamps
- **Review Turnaround:** Time from creation to first review comment
- **Active Windows:** Identify peak activity hours from timestamps
---
**Related Templates:**
- `.agents/templates/pr.md` - PR structure
- `.agents/templates/journal.md` - Daily work log
- `.agents/templates/review.md` - Code review format
- `.github/PULL_REQUEST_TEMPLATE.md` - Canonical PR template
**Related Skills:**
- Consider creating `.agents/skills/daily-summary.md` for automation
- Consider creating `.agents/roles/reporting-agent/` for automated generation

View File

@@ -0,0 +1,45 @@
# Agent Framework Definitions
**Source:** olympics-fotb/.agents/DEFINITIONS.md v1.0
**Purpose:** Canonical vocabulary and terminology for the agent framework
## Core Concepts
### Agent
An autonomous, role-bound process operating within defined guardrails. Agents are bounded contributors with explicit scope and accountability.
### Role
A discrete, domain-specific operational identity (e.g., `reporting-agent`, `pm-agent`). Each role defines what can be done, what cannot be done, and when escalation is required.
### Skill
A reusable, domain-independent capability that extends roles with behavioral modules or execution patterns. Skills cannot override guardrails.
### Journal
A mandatory documentation artifact created when uncertainty exists (confidence <7), a prototype is built, or research is performed.
### Plan
A structured document defining upcoming file creations or refactors. No file may be created outside of an approved plan.
### ADR (Architecture Decision Record)
A formal document explaining an architectural decision, alternatives considered, and consequences.
## Behavioral Principles
1. **Efficiency First** - Read only what is necessary. Use pointer references and localized reasoning.
2. **Autonomy Within Boundaries** - Agents solve problems independently within role and architectural limits.
3. **No Unscoped File Creation** - Every new file must trace back to an approved plan.
4. **No Generic Roles** - Tasks must be assigned to specific defined roles.
5. **No Time Estimates** - Only track complexity (low/medium/high), not duration.
6. **Journal for Learning** - Journals preserve reasoning and insight, not activity logs.
7. **Growth Signals** - Missing roles or skills are opportunities for system evolution.
## Task Classifications
- **New Task** - Work without prior implementation. Requires full Eight-Phase process.
- **Old Task** - Maintenance or iteration on existing feature. Must reference prior work.
- **Prototype** - Experimental implementation for validation. Must be isolated and logged.
- **Production Task** - Mature, validated work aligned with established architecture.
---
*For full details, see the original DEFINITIONS.md in the olympics-fotb repository*

View File

@@ -0,0 +1,67 @@
# Agent Framework Instructions
**Source:** olympics-fotb/.agents/INSTRUCTIONS.md v1.2
**Purpose:** Context for understanding the agent framework that uses the daily-summary skill
## Eight-Phase Methodology
The daily-summary skill operates within an eight-phase agent methodology:
1. **Introspection** - Identify role and confidence
2. **Research** - Gather necessary context
3. **Strategy** - Plan the approach
4. **Prototype** - Test the solution
5. **Execute** - Implement the work
6. **Validate** - Verify correctness
7. **Journal** - Document learnings
8. **Reality Check** - Confirm evidence
## Confidence Scale (0-10)
| Level | Definition |
|-------|-----------|
| 0 | No understanding of problem or environment |
| 1 | Aware of the problem but lack any solution path |
| 2 | Can describe the problem, not the solution |
| 3 | Have potential directions, none validated |
| 4 | Have a strategy but need prototype confirmation |
| 5 | Prototype works partially; still researching |
| 6 | Prototype works; still uncertain about edge cases |
| 7 | Tested locally; moderately confident |
| 8 | Validated and tested; high confidence to execute |
| 9 | Proven pattern reused successfully before |
| 10 | Verified in production or canonicalized as a skill |
**Confidence < 7:** Journal before continuing
**Confidence ≥ 8:** Proceed with execution
## Complexity Ratings
| Level | Description | Action Expectation |
|-------|-------------|-------------------|
| **Low** | Small, reversible, local change | Complete independently with minimal validation |
| **Medium** | Multi-file change or one dependency touched | Validate with tests; peer review recommended |
| **High** | Architectural impact, multiple dependencies | Requires ADR and cross-role review before merge |
## File Architecture
The framework uses a hierarchical structure:
1. `.agents/INSTRUCTIONS.md` - Canonical law
2. `AGENTS.md` - Global operational strategy
3. `.agents/templates/` - Reusable templates
4. `.agents/roles/` - Role definitions
5. `.agents/skills/` - Reusable capabilities
6. `.agents/insights/` - Curated lessons learned
## Skill Creation Policy
Skills must:
- Have confidence ≥9
- Be proven reusable across 2+ contexts
- Include validation criteria
- Reference journals that validated the pattern
---
*For full details, see the original INSTRUCTIONS.md in the olympics-fotb repository*