personal-projects/leo-claude-mktplace
Template
0
1
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat(marketplace): hook migration, projman commands, optimizations [BREAKING]

Browse Source 
Remove all SessionStart and PostToolUse hooks across the marketplace,
retaining only PreToolUse safety hooks and UserPromptSubmit quality hooks.
Add /project and /adr command families, /hygiene check, /cv status.
Create 7 new projman skills for project lifecycle management.
Remove /pm-debug, /suggest-version, /proposal-status commands.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
Leo Miranda
2026-02-06 12:28:06 -05:00
parent 442ed63b4c
commit 9ba2e660d3
60 changed files with 1061 additions and 1828 deletions
Download Patch File Download Diff File Expand all files Collapse all files

49
plugins/projman/skills/adr-conventions.md Normal file
View File

@@ -0,0 +1,49 @@
---
description: Architecture Decision Record conventions and wiki page template
---
# ADR Conventions
## Wiki Page Naming
Page name: `ADR-NNNN: {Title}` (e.g., `ADR-0001: Use PostgreSQL with Alembic`)
Sequential numbering. Allocate next available number.
## Dependency Header
```
> **Project:** {Name}
> **Sprint:** N/A or sprint where ADR was created
> **Issues:** Related issue numbers or N/A
> **Parent:** Project: {Name}
> **Created:** YYYY-MM-DD
> **Status:** Proposed | Accepted | Superseded | Deprecated
```
## ADR Template
1. **Context** — What is the issue motivating this decision?
2. **Decision** — What is the change being proposed/made?
3. **Consequences** — Positive, Negative, Neutral outcomes
4. **Alternatives Considered** — Table of options with pros, cons, verdict
5. **References** — Related ADRs, RFCs, external links
## Lifecycle
| State | Meaning |
|-------|---------|
| Proposed | Under discussion, not yet approved |
| Accepted | Approved and in effect |
| Superseded | Replaced by a newer ADR (link to replacement) |
| Deprecated | No longer relevant |
## ADR Index Page
Maintain an `ADR-Index` wiki page listing all ADRs grouped by status.
## Integration with Sprint Workflow
- ADRs created via `/adr create` during project initiation or planning
- ADR status checked during `/project status`
- Sprint planning can reference ADRs in issue descriptions

165
plugins/projman/skills/domain-consultation.md
View File

@@ -1,165 +0,0 @@
---
name: domain-consultation
description: Cross-plugin domain consultation for specialized planning and validation
---
# Domain Consultation
## Purpose
Enables projman agents to detect domain-specific work and consult specialized plugins for expert validation during planning and execution phases. This skill is the backbone of the Domain Advisory Pattern.
---
## When to Use
| Agent | Phase | Action |
|-------|-------|--------|
| Planner | After task sizing, before issue creation | Detect domains, add acceptance criteria |
| Orchestrator | Before marking issue complete | Run domain gates, block if violations |
| Code Reviewer | During review | Include domain compliance in findings |
---
## Domain Detection Rules
| Signal Type | Detection Pattern | Domain Plugin | Action |
|-------------|-------------------|---------------|--------|
| Label-based | `Component/Frontend`, `Component/UI` | viz-platform | Add design system criteria, apply `Domain/Viz` |
| Content-based | Keywords: DMC, Dash, layout, theme, component, dashboard, chart, responsive, color, UI, frontend, Plotly | viz-platform | Same as above |
| Label-based | `Component/Database`, `Component/Data` | data-platform | Add data validation criteria, apply `Domain/Data` |
| Content-based | Keywords: schema, migration, pipeline, dbt, table, column, query, PostgreSQL, lineage, data model | data-platform | Same as above |
| Both signals | Frontend + Data signals present | Both plugins | Apply both sets of criteria |
---
## Planning Protocol
When creating issues, the planner MUST:
1. **Analyze each issue** for domain signals (check labels AND scan description for keywords)
2. **For Domain/Viz issues**, append this acceptance criteria block:
```markdown
## Design System Compliance
- [ ] All DMC components validated against registry
- [ ] Theme tokens used (no hardcoded colors/sizes)
- [ ] Accessibility check passed (WCAG contrast)
- [ ] Responsive breakpoints verified
```
3. **For Domain/Data issues**, append this acceptance criteria block:
```markdown
## Data Integrity
- [ ] Schema changes validated
- [ ] dbt tests pass
- [ ] Lineage intact (no orphaned models)
- [ ] Data types verified
```
4. **Apply the corresponding `Domain/*` label** to route the issue through gates
5. **Document in planning summary** which issues have domain gates active
---
## Execution Gate Protocol
Before marking any issue as complete, the orchestrator MUST:
1. **Check issue labels** for `Domain/*` labels
2. **If `Domain/Viz` label present:**
- Identify files changed by this issue
- Invoke `/design-gate <path-to-changed-files>`
- Gate PASS → proceed to mark issue complete
- Gate FAIL → add comment to issue with failure details, keep issue open
3. **If `Domain/Data` label present:**
- Identify files changed by this issue
- Invoke `/data-gate <path-to-changed-files>`
- Gate PASS → proceed to mark issue complete
- Gate FAIL → add comment to issue with failure details, keep issue open
4. **If gate command unavailable** (MCP server not running):
- Warn user: "Domain gate unavailable - proceeding without validation"
- Proceed with completion (non-blocking degradation)
- Do NOT silently skip - always inform user
---
## Review Protocol
During code review, the code reviewer SHOULD:
1. After completing standard code quality and security checks, check for `Domain/*` labels
2. **If Domain/Viz:** Include "Design System Compliance" section in review report
- Reference `/design-review` findings if available
- Check for hardcoded colors, invalid props, accessibility issues
3. **If Domain/Data:** Include "Data Integrity" section in review report
- Reference `/data-gate` findings if available
- Check for schema validity, lineage integrity
---
## Extensibility
To add a new domain (e.g., `Domain/Infra` for cmdb-assistant):
1. **In domain plugin:** Create advisory agent + gate command
- Agent: `agents/infra-advisor.md`
- Gate command: `commands/infra-gate.md`
- Audit skill: `skills/infra-audit.md`
2. **In this skill:** Add detection rules to the Detection Rules table above
- Define label-based signals (e.g., `Component/Infrastructure`)
- Define content-based keywords (e.g., "server", "network", "NetBox")
3. **In label taxonomy:** Add `Domain/Infra` label with appropriate color
- Update `plugins/projman/skills/label-taxonomy/labels-reference.md`
4. **No changes needed** to planner.md or orchestrator.md agent files
- They read this skill dynamically
- Detection rules table is the single source of truth
This pattern ensures domain expertise stays in domain plugins while projman orchestrates when to ask.
---
## Domain Acceptance Criteria Templates
### Design System Compliance (Domain/Viz)
```markdown
## Design System Compliance
- [ ] All DMC components validated against registry
- [ ] Theme tokens used (no hardcoded colors/sizes)
- [ ] Accessibility check passed (WCAG contrast)
- [ ] Responsive breakpoints verified
```
### Data Integrity (Domain/Data)
```markdown
## Data Integrity
- [ ] Schema changes validated
- [ ] dbt tests pass
- [ ] Lineage intact (no orphaned models)
- [ ] Data types verified
```
---
## Gate Command Reference
| Domain | Gate Command | Contract | Review Command | Advisory Agent |
|--------|--------------|----------|----------------|----------------|
| Viz | `/design-gate <path>` | v1 | `/design-review <path>` | `design-reviewer` |
| Data | `/data-gate <path>` | v1 | `/data-review <path>` | `data-advisor` |
Gate commands return binary PASS/FAIL for automation.
Review commands return detailed reports for human review.
**Contract Version:** Gate commands declare `gate_contract: vN` in their frontmatter. The version in this table is what projman expects. If a gate command bumps its contract version, this table must be updated to match. The `contract-validator` plugin checks this automatically via `validate_workflow_integration`.

49
plugins/projman/skills/epic-conventions.md Normal file
View File

@@ -0,0 +1,49 @@
---
description: Epic decomposition and management conventions using Gitea labels and projects
---
# Epic Conventions
## What Is an Epic
An epic is a large body of work that spans multiple sprints. Epics are tracked as Gitea labels (`Epic/*`) and optionally as Gitea Project boards.
## Label Convention
Labels follow the pattern `Epic/{Name}`:
- `Epic/Database` — Schema design, migrations, seed data
- `Epic/API` — Backend endpoints, middleware, auth
- `Epic/Frontend` — UI components, routing, state management
- `Epic/Auth` — Authentication and authorization
- `Epic/Infrastructure` — CI/CD, deployment, monitoring
Epics are defined during `/project initiation` as part of the charter's Epic Decomposition table.
## Epic-to-Sprint Mapping
Each sprint focuses on one or more epics. The sprint milestone description references the active epics:
```
**Epics:** Epic/Database, Epic/API
**Project:** Driving School SaaS
```
## Wiki Cross-References
- Project Charter (`Project: {Name}`) contains the Epic Decomposition table
- Sprint Roadmap (`Roadmap: {Name}`) maps epics to sprint sequence
- WBS (`WBS: {Name}`) breaks epics into work packages
- Sprint Lessons (`Sprint-Lessons: Sprint-X`) reference which epics were active
## Issue-Epic Relationship
Every issue in an epic-aligned sprint gets the `Epic/*` label. This enables:
- Filtering all issues by epic across sprints
- Tracking epic completion percentage
- Epic velocity analysis in lessons learned
## DO NOT
- Create epics for single-sprint work — use regular labels
- Mix unrelated work under one epic label
- Skip epic labels during sprint planning — they're the traceability link

25
plugins/projman/skills/label-taxonomy/labels-reference.md
View File

@@ -13,7 +13,7 @@ description: Dynamic reference for Gitea label taxonomy (organization + reposito
This skill provides the current label taxonomy used for issue classification in Gitea. Labels are **fetched dynamically** from Gitea and should never be hardcoded.
**Current Taxonomy:** 49 labels (31 organization + 18 repository)
**Current Taxonomy:** 58 labels (31 organization + 27 repository)
## Organization Labels (31)
@@ -123,6 +123,29 @@ Cross-plugin integration labels for domain-specific validation gates.
- Also applied when: `Component/Database` or `Component/Data` label is present
- Example: "Add census demographic data pipeline"
### Epic (5 labels)
Project-level epic labels for multi-sprint work tracking.
| Label | Color | Description |
|-------|-------|-------------|
| `Epic/Database` | `#0E8A16` | Database schema, migrations, seed data |
| `Epic/API` | `#1D76DB` | Backend endpoints, middleware, auth |
| `Epic/Frontend` | `#E99695` | UI components, routing, state management |
| `Epic/Auth` | `#D93F0B` | Authentication and authorization |
| `Epic/Infrastructure` | `#BFD4F2` | CI/CD, deployment, monitoring |
### R&D (4 labels)
Research and development tracking labels for lessons learned.
| Label | Color | Description |
|-------|-------|-------------|
| `RnD/Friction` | `#FBCA04` | Workflow friction points |
| `RnD/Gap` | `#B60205` | Capability gaps discovered |
| `RnD/Pattern` | `#0075CA` | Reusable patterns identified |
| `RnD/Automation` | `#5319E7` | Automation opportunities |
## Label Suggestion Logic
When suggesting labels for issues, consider the following patterns:

46
plugins/projman/skills/project-charter.md Normal file
View File

@@ -0,0 +1,46 @@
---
description: Template and conventions for project charter wiki pages
---
# Project Charter Conventions
## Wiki Page Naming
Page name: `Project: {Name}` (e.g., `Project: Driving School SaaS`)
## Dependency Header
```
> **Project:** {Name}
> **Sprint:** N/A (project-level)
> **Issues:** N/A (created during planning)
> **Parent:** N/A (top-level artifact)
> **Created:** YYYY-MM-DD
> **Status:** Initiating | Planning | Executing | Closing | Closed
```
## Charter Structure
The wiki page follows this structure:
1. **Vision** — One paragraph describing what this project achieves and why
2. **Scope** — In Scope (explicit list) and Out of Scope (prevents scope creep)
3. **Source Analysis Summary** — Key findings from `/project initiation` (if applicable)
4. **Architecture Decisions** — Links to ADR wiki pages
5. **Epic Decomposition** — Table of epics with description, priority, estimated sprints
6. **Sprint Roadmap** — Link to `Roadmap: {Name}` wiki page
7. **Risk Register** — Link to `Risk-Register: {Name}` wiki page
8. **Stakeholders** — Table of roles, persons, responsibilities
9. **Success Criteria** — Measurable outcomes that define "done"
## Lifecycle States
| State | Meaning | Transition |
|-------|---------|------------|
| Initiating | Discovery and chartering in progress | Planning (charter approved) |
| Planning | WBS, risk, roadmap being created | Executing (first sprint starts) |
| Executing | Sprints are running | Closing (all epics complete) |
| Closing | Retrospective and archival | Closed |
| Closed | Archived | Terminal |
State is tracked in the charter's `Status` field.

58
plugins/projman/skills/risk-register.md Normal file
View File

@@ -0,0 +1,58 @@
---
description: Risk register template and management conventions for project planning
---
# Risk Register
## Wiki Page
Page name: `Risk-Register: {Name}` (e.g., `Risk-Register: Driving School SaaS`)
### Dependency Header
```
> **Project:** {Name}
> **Sprint:** N/A (project-level, reviewed per sprint)
> **Issues:** N/A
> **Parent:** Project: {Name}
> **Created:** YYYY-MM-DD
> **Status:** Active | Archived
```
## Risk Register Template
| ID | Risk | Probability | Impact | Score | Mitigation | Owner | Status |
|----|------|------------|--------|-------|------------|-------|--------|
| R1 | Example risk description | Medium | High | 6 | Mitigation strategy | Dev | Open |
## Scoring
| Probability | Value |
|-------------|-------|
| Low | 1 |
| Medium | 2 |
| High | 3 |
| Impact | Value |
|--------|-------|
| Low | 1 |
| Medium | 2 |
| High | 3 |
**Score** = Probability x Impact (1-9 range)
## Risk Lifecycle
| Status | Meaning |
|--------|---------|
| Open | Active risk, mitigation planned |
| Monitoring | Risk identified but not yet actionable |
| Mitigated | Mitigation applied, risk reduced |
| Occurred | Risk materialized — track resolution |
| Closed | No longer relevant |
## Integration
- `/project plan` creates initial risk register
- `/project status` summarizes open risk count and top-3 by score
- `/sprint-close` updates risk statuses in lessons learned

51
plugins/projman/skills/source-analysis.md Normal file
View File

@@ -0,0 +1,51 @@
---
description: Framework for analyzing existing codebases and systems as input to project initiation
---
# Source Analysis
## Purpose
Structured approach to analyzing an existing codebase or system before project planning. Used by `/project initiation` to understand what exists before defining what to build.
## Analysis Framework
### 1. Codebase Discovery
- Technology stack identification (languages, frameworks, databases, ORMs)
- Architecture pattern recognition (monolith, microservices, modular monolith)
- Dependency inventory (package managers, versions, lock files)
- Environment configuration (env files, config patterns, secrets management)
### 2. Feature Inventory
- User-facing features (pages, flows, API endpoints)
- Admin/internal features (dashboards, tools, scripts)
- Integration points (third-party APIs, external services)
- Background processes (cron jobs, workers, queues)
### 3. Data Model Analysis
- Database schemas and relationships
- Data migration history
- Seed data patterns
- Data validation rules
### 4. Quality Assessment
- Test coverage (types, frameworks, CI integration)
- Documentation state (README, inline, API docs)
- Code quality indicators (linting, formatting, type safety)
- Known technical debt (TODO/FIXME/HACK comments)
### 5. Deployment Assessment
- Current hosting/infrastructure
- CI/CD pipeline state
- Environment parity (dev/staging/prod)
- Monitoring and logging
## Output Format
The analysis produces a structured report stored as a wiki page (`Project: {Name}`) that feeds into the project charter and epic decomposition.
## DO NOT
- Make assumptions about missing components — document gaps explicitly
- Evaluate "good vs bad" — document facts for decision-making
- Propose solutions during analysis — that's the planning phase

41
plugins/projman/skills/sprint-roadmap.md Normal file
View File

@@ -0,0 +1,41 @@
---
description: Sprint roadmap template for sequencing epics across multiple sprints
---
# Sprint Roadmap
## Wiki Page
Page name: `Roadmap: {Name}` (e.g., `Roadmap: Driving School SaaS`)
### Dependency Header
```
> **Project:** {Name}
> **Sprint:** N/A (project-level)
> **Issues:** N/A
> **Parent:** Project: {Name}
> **Created:** YYYY-MM-DD
> **Status:** Draft | Active | Complete
```
## Roadmap Template
| Sprint | Epics | Focus | Dependencies | Status |
|--------|-------|-------|-------------|--------|
| Sprint 1 | Epic/Database | Schema design, initial migrations | None | Planned |
| Sprint 2 | Epic/Database, Epic/API | Seed data, API scaffolding | Sprint 1 | Planned |
## Milestones
| Milestone | Target Sprint | Criteria |
|-----------|--------------|----------|
| Backend MVP | Sprint 3 | All core API endpoints passing tests |
| Integration Complete | Sprint 6 | End-to-end flows working |
## Integration
- `/project plan` creates the initial roadmap from epic decomposition + dependency analysis
- `/sprint-plan` references the roadmap to determine sprint scope
- `/sprint-close` updates sprint status in roadmap
- `/project status` shows roadmap progress

7
plugins/projman/skills/visual-output.md
View File

@@ -42,12 +42,13 @@ For commands that don't invoke a specific agent phase:
|---------|-------------|------------|
| `/sprint-status` | 📊 Chart | STATUS |
| `/pm-setup` | ⚙️ Gear | SETUP |
| `/pm-debug` | 🐛 Bug | DEBUG |
| `/labels-sync` | 🏷️ Label | LABELS |
| `/suggest-version` | 📦 Package | VERSION |
| `/proposal-status` | 📋 Clipboard | PROPOSALS |
| `/pm-test` | 🧪 Flask | TEST |
| `/rfc` | 📄 Document | RFC [Sub-Command] |
| `/project` | 📋 Clipboard | PROJECT [Sub-Command] |
| `/adr` | 📐 Ruler | ADR [Sub-Command] |
| `/hygiene check` | 🧹 Broom | HYGIENE |
| `/cv status` | ✅ Check | CV STATUS |
---

45
plugins/projman/skills/wbs.md Normal file
View File

@@ -0,0 +1,45 @@
---
description: Work Breakdown Structure skill for decomposing projects and sprints into implementable work packages
---
# Work Breakdown Structure (WBS)
## Purpose
Bridges project-level epics and sprint-level issues. Used by `/project plan` to create the initial decomposition and by `/sprint-plan` to refine sprint scope.
## Wiki Page
Page name: `WBS: {Name}` (e.g., `WBS: Driving School SaaS`)
### Dependency Header
```
> **Project:** {Name}
> **Sprint:** N/A (project-level, refined per sprint)
> **Issues:** N/A
> **Parent:** Project: {Name}
> **Created:** YYYY-MM-DD
> **Status:** Draft | Active | Complete
```
## Decomposition Rules
1. **Level 1:** Epics (from project charter)
2. **Level 2:** Work packages (groupings within an epic — typically 1 sprint each)
3. **Level 3:** Tasks (become Gitea issues — must be S or M size per task-sizing.md)
## Sprint Refinement
During `/sprint-plan`, the planner:
1. Loads the WBS
2. Identifies the next unstarted work packages
3. Creates issues from Level 3 tasks
4. Marks consumed work packages as "Sprint-X" in the WBS
## Integration
- `/project plan` creates the initial WBS from epic decomposition
- `/sprint-plan` consumes WBS work packages to create sprint issues
- `/sprint-close` updates WBS with completion status
- `/project status` aggregates WBS progress for project-level view

148
plugins/projman/skills/wiki-conventions.md
View File

@@ -1,73 +1,98 @@
---
name: wiki-conventions
description: Proposal and implementation page format and naming conventions
description: Wiki page naming conventions and dependency headers (Decision #30)
---
# Wiki Conventions
## Purpose
Defines the naming and structure for wiki proposal and implementation pages.
Defines naming conventions, dependency headers, and structure for all wiki pages in the project management workflow.
## When to Use
- **Planner agent**: When creating wiki pages during planning
- **Orchestrator agent**: When updating status at sprint close
- **Commands**: `/sprint-plan`, `/sprint-close`, `/proposal-status`
- **Commands**: `/sprint-plan`, `/sprint-close`, `/project initiation`, `/project plan`, `/project status`, `/project close`, `/adr create`
---
## Page Naming
## Page Naming Pattern
| Page Type | Naming Convention |
|-----------|-------------------|
| Proposal | `Change VXX.X.X: Proposal` |
| Implementation | `Change VXX.X.X: Proposal (Implementation N)` |
All wiki pages follow: `{Type}-{ID}: {Title}` or `{Type}: {Title}`
**Examples:**
- `Change V4.1.0: Proposal`
- `Change V4.1.0: Proposal (Implementation 1)`
- `Change V4.1.0: Proposal (Implementation 2)`
| Type | ID Format | Example |
|------|-----------|---------|
| RFC | NNNN (sequential) | `RFC-0001: OAuth2 Provider Support` |
| ADR | NNNN (sequential) | `ADR-0001: Use PostgreSQL with Alembic` |
| Project | Name | `Project: Driving School SaaS` |
| WBS | Name | `WBS: Driving School SaaS` |
| Risk-Register | Name | `Risk-Register: Driving School SaaS` |
| Roadmap | Name | `Roadmap: Driving School SaaS` |
| Sprint-Lessons | Sprint ID | `Sprint-Lessons: Sprint-3` |
| ADR-Index | — | `ADR-Index` |
| Change Proposal | Version | `Change VXX.X.X: Proposal` |
| Implementation | Version + N | `Change VXX.X.X: Proposal (Implementation N)` |
## Dependency Header
Every wiki page MUST include this header block:
```markdown
> **Project:** [project name or N/A]
> **Sprint:** [sprint milestone or N/A]
> **Issues:** #12, #15, #18 [or N/A]
> **Parent:** [parent wiki page or N/A]
> **Created:** YYYY-MM-DD
> **Status:** [lifecycle state]
```
## Hierarchy
- `Project: {Name}` is the root
- `WBS: {Name}` (parent: Project)
- `Risk-Register: {Name}` (parent: Project)
- `Roadmap: {Name}` (parent: Project)
- `ADR-NNNN: {Title}` (parent: Project)
- `Sprint-Lessons: Sprint-X` (parent: Project)
---
## Proposal Page Template
## Change Proposal Pages (Legacy Format)
### Proposal Page Template
```markdown
> **Type:** Change Proposal
> **Version:** V04.1.0
> **Version:** VXX.X.X
> **Plugin:** projman
> **Status:** In Progress
> **Date:** 2026-01-26
> **Date:** YYYY-MM-DD
# Feature Title
[Content migrated from input source or created from discussion]
## Implementations
- [Implementation 1](link) - Sprint 17 - In Progress
- [Implementation 1](link) - Sprint N - In Progress
```
---
## Implementation Page Template
### Implementation Page Template
```markdown
> **Type:** Change Proposal Implementation
> **Version:** V04.1.0
> **Version:** VXX.X.X
> **Status:** In Progress
> **Date:** 2026-01-26
> **Date:** YYYY-MM-DD
> **Origin:** [Proposal](wiki-link)
> **Sprint:** Sprint 17
> **Sprint:** Sprint N
# Implementation Details
[Technical details, scope, approach]
## Issues
- #45: JWT token generation
- #46: Login endpoint
- #47: Auth tests
- #45: Issue description
- #46: Issue description
```
---
@@ -85,71 +110,26 @@ Defines the naming and structure for wiki proposal and implementation pages.
## Completion Update (Sprint Close)
On sprint close, update implementation page:
On sprint close, update implementation page status to `Implemented` and add a `## Completion Summary` section with lessons learned link.
```markdown
> **Type:** Change Proposal Implementation
> **Version:** V04.1.0
> **Status:** Implemented ✅
> **Date:** 2026-01-26
> **Completed:** 2026-01-28
> **Origin:** [Proposal](wiki-link)
> **Sprint:** Sprint 17
# Implementation Details
[Original content...]
## Completion Summary
- All planned issues completed
- Lessons learned: [Link to lesson]
```
On proposal page, update implementation entries with completion status.
---
## Proposal Status Update
## R&D Notes Section
When all implementations complete, update proposal:
Lessons learned pages include a `## R&D Notes` section at the bottom for capturing:
```markdown
> **Type:** Change Proposal
> **Version:** V04.1.0
> **Status:** Implemented ✅
> **Date:** 2026-01-26
# Feature Title
[Original content...]
## Implementations
- [Implementation 1](link) - Sprint 17 - ✅ Completed
```
| Label | Description | Action |
|-------|-------------|--------|
| `RnD/Friction` | Workflow friction points | Consider improvements |
| `RnD/Gap` | Capability gaps discovered | Prioritize new tools |
| `RnD/Pattern` | Reusable patterns identified | Document for reuse |
| `RnD/Automation` | Automation opportunities | Add to backlog |
---
## Creating Pages
## Enforcement
**Create proposal:**
```python
create_wiki_page(
repo="org/repo",
title="Change V4.1.0: Proposal",
content="[proposal template content]"
)
```
**Create implementation:**
```python
create_wiki_page(
repo="org/repo",
title="Change V4.1.0: Proposal (Implementation 1)",
content="[implementation template content]"
)
```
**Update implementation on close:**
```python
update_wiki_page(
repo="org/repo",
page_name="Change-V4.1.0:-Proposal-(Implementation-1)",
content="[updated content with completion status]"
)
```
- Commands creating wiki pages use these templates from their respective skills
- Malformed pages are flagged, not auto-corrected