feature-counsel
Analyze a project's OpenSpec from 8 persona perspectives and suggest additional features
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
القائمة
Analyze a project's OpenSpec from 8 persona perspectives and suggest additional features
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | feature-counsel |
| description | Analyze a project's OpenSpec from 8 persona perspectives and suggest additional features |
Analyze a project's OpenSpec specifications from 8 different persona perspectives to identify missing features, usability gaps, and improvement opportunities.
Input: Optional argument after /feature-counsel:
opencatalogi, openregister)Available projects: Any directory under apps-extra with an openspec/ folder.
The Feature Counsel uses 8 personas representing the full spectrum of Dutch public sector users. Each persona card is stored in hydra/personas/:
| Persona | File | Perspective |
|---|---|---|
| Henk Bakker | henk-bakker.md | Elderly citizen (78) — low digital skills, accessibility, plain Dutch |
| Fatima El-Amrani | fatima-el-amrani.md | Low-literate migrant (52) — visual design, simplicity, inclusivity |
| Sem de Jong | sem-de-jong.md | Young digital native (22) — performance, keyboard shortcuts, modern UX |
| Noor Yilmaz | noor-yilmaz.md | Municipal CISO (36) — security, audit trails, BIO2/ENSIA compliance |
| Annemarie de Vries | annemarie-de-vries.md | VNG standards architect (38) — GEMMA, Common Ground, NLGov API rules |
| Mark Visser | mark-visser.md | MKB software vendor (48) — business efficiency, CRUD, Dutch terminology |
| Priya Ganpat | priya-ganpat.md | ZZP developer (34) — API quality, DX, OpenAPI specs, integration |
| Jan-Willem van der Berg | janwillem-van-der-berg.md | Small business owner (55) — plain language, no jargon, simple workflows |
If no project was provided as argument, use AskUserQuestion to ask:
"Which project would you like the Feature Counsel to analyze?"
List the available projects by checking which directories have openspec/ folders:
Available projects:
- opencatalogi
- openregister
- pipelinq
- procest
Store the chosen project as {PROJECT}.
Read the following files to understand the project:
{PROJECT}/project.md — Project context, architecture, purpose{PROJECT}/openspec/specs/ — All spec files (the main specifications){PROJECT}/openspec/changes/ — Any active changes (proposals, delta specs)openspec/specs/ — Shared cross-project specs (api-patterns, nl-design, nextcloud-app)Build a mental model of:
Ask the user using AskUserQuestion:
"Which model should the persona agents use?"
| Model | Speed | Quota | Best for |
|---|---|---|---|
| Haiku | Fastest | Low | Parallel runs — broad coverage, efficient |
| Sonnet | Balanced | Moderate | Better reasoning, more nuanced findings |
| Opus | Slowest | High | Deepest analysis — for critical or final runs |
Store as {MODEL}:
"haiku""sonnet""opus"Launch 8 Task agents in parallel (all in a single message), one per persona. Each agent evaluates the specs from their persona's perspective. Use subagent_type: "general-purpose" and model: "{MODEL}" (from Step 1.5).
Sub-agent prompt template (replace {PERSONA_NAME}, {PERSONA_FILE}, {PROJECT}, and {PERSPECTIVE}):
You are a Feature Counsel advisor representing **{PERSONA_NAME}**.
## Your Persona
Read the persona card at `hydra/personas/{PERSONA_FILE}` to understand your character's background, digital skills, frustrations, needs, and behavior. Stay fully in character.
## Your Task
Analyze the OpenSpec specifications of the **{PROJECT}** project and suggest features, improvements, or changes from your persona's perspective.
## Read These Files
1. `{PROJECT}/project.md` — Project context
2. All files in `{PROJECT}/openspec/specs/` — Current specifications
3. All files in `{PROJECT}/openspec/changes/` — Active changes (if any)
4. Relevant shared specs in `openspec/specs/` (api-patterns, nl-design, nextcloud-app)
## Analysis Focus: {PERSPECTIVE}
For each spec section, ask yourself:
- Does this feature serve my needs as {PERSONA_NAME}?
- What's missing that I would need?
- What would frustrate me about this design?
- What would make this easier/better/more compliant for people like me?
## Output Format
Return your analysis as a structured report:
```markdown
# Feature Counsel: {PERSONA_NAME} — {one-line role description}
## Overall Assessment
{2-3 sentences from your persona's perspective on whether this project serves your needs}
## Missing Features (things I need that aren't in the specs)
| # | Feature | Priority | Why I need this | Spec section affected |
|---|---------|----------|-----------------|----------------------|
| 1 | {feature name} | MUST/SHOULD/COULD | "{persona perspective}" | {which spec} |
## Improvement Suggestions (existing features that need enhancement)
| # | Current Feature | Suggested Improvement | Why | Spec section |
|---|----------------|----------------------|-----|-------------|
| 1 | {feature} | {improvement} | "{persona perspective}" | {spec} |
## Compliance/Standards Gaps (from my perspective)
| # | Gap | Standard/Requirement | Impact | Recommendation |
|---|-----|---------------------|--------|----------------|
| 1 | {gap} | {standard} | HIGH/MEDIUM/LOW | {recommendation} |
## Usability Concerns
| # | Concern | Severity | {PERSONA_NAME} would say... |
|---|---------|----------|----------------------------|
| 1 | {concern} | HIGH/MEDIUM/LOW | "{in-character quote}" |
## {PERSONA_NAME}'s Top 3 Recommendations
1. {most important suggestion with rationale}
2. {second most important}
3. {third most important}
**Agent assignments:**
| Agent | Persona | Perspective Focus |
|-------|---------|-------------------|
| 1 | Henk Bakker | Accessibility, readability, plain Dutch, elderly-friendly design, text size, button size, simple navigation |
| 2 | Fatima El-Amrani | Visual design, literacy barriers, icon usage, mobile-first, minimal text, RTL support, B1 language level |
| 3 | Sem de Jong | Performance, keyboard shortcuts, dark mode, loading states, modern UX patterns, URL state, developer console |
| 4 | Noor Yilmaz | Security features, audit trails, RBAC, BIO2 compliance, ENSIA readiness, AVG/GDPR, data minimization |
| 5 | Annemarie de Vries | GEMMA alignment, Common Ground 5-layer, NLGov API Design Rules, interoperability, publiccode.yml, FSC |
| 6 | Mark Visser | Business efficiency, CRUD workflows, Dutch business terminology, status indicators, bulk operations, export |
| 7 | Priya Ganpat | API quality, OpenAPI spec, developer experience, error handling, pagination, webhooks, integration readiness |
| 8 | Jan-Willem van der Berg | Plain language, no jargon, simple forms, findability, contact info, 3-click rule, Dutch B1 level |
### Step 3: Synthesize the Results
After all 8 agents complete, read their reports and create a synthesized Feature Counsel report.
**Write the synthesis to**: `{PROJECT}/openspec/feature-counsel-report.md`
```markdown
# Feature Counsel Report: {PROJECT}
**Date:** {today's date}
**Method:** 8-persona feature advisory analysis against OpenSpec specifications
**Personas:** Henk Bakker, Fatima El-Amrani, Sem de Jong, Noor Yilmaz, Annemarie de Vries, Mark Visser, Priya Ganpat, Jan-Willem van der Berg
---
## Executive Summary
{3-5 sentences summarizing the overall findings across all personas}
---
## Consensus Features (suggested by 3+ personas)
| # | Feature | Suggested by | Priority | Impact |
|---|---------|-------------|----------|--------|
| 1 | {feature} | {persona names} | MUST/SHOULD/COULD | {why it matters} |
---
## Per-Persona Highlights
### Henk Bakker (Elderly Citizen)
- **Top need**: {one-liner}
- **Key missing feature**: {feature}
- **Quote**: "{in-character Dutch quote}"
### Fatima El-Amrani (Low-Literate Migrant)
...{repeat for all 8}
---
## Feature Suggestions by Category
### Accessibility & Inclusivity
| # | Feature | Personas | Priority | Notes |
|---|---------|----------|----------|-------|
| 1 | {feature} | {who suggested} | {priority} | {details} |
### Security & Compliance
| # | Feature | Personas | Priority | Standard |
|---|---------|----------|----------|----------|
| 1 | {feature} | {who suggested} | {priority} | {BIO2/AVG/etc} |
### API & Developer Experience
| # | Feature | Personas | Priority | Notes |
|---|---------|----------|----------|-------|
| 1 | {feature} | {who suggested} | {priority} | {details} |
### UX & Performance
| # | Feature | Personas | Priority | Notes |
|---|---------|----------|----------|-------|
| 1 | {feature} | {who suggested} | {priority} | {details} |
### Standards & Interoperability
| # | Feature | Personas | Priority | Standard |
|---|---------|----------|----------|----------|
| 1 | {feature} | {who suggested} | {priority} | {GEMMA/NLGov/etc} |
### Business & Workflow
| # | Feature | Personas | Priority | Notes |
|---|---------|----------|----------|-------|
| 1 | {feature} | {who suggested} | {priority} | {details} |
---
## Recommended Actions
### MUST (blocking for key user groups)
1. {action + rationale}
### SHOULD (significant improvement for multiple personas)
1. {action + rationale}
### COULD (nice-to-have, improves specific persona experience)
1. {action + rationale}
---
## Potential OpenSpec Changes
These features could be turned into OpenSpec changes using `/opsx-new`:
| Change Name | Description | Related Personas | Estimated Complexity |
|-------------|-------------|-----------------|---------------------|
| {change-name} | {description} | {personas} | S/M/L/XL |
Display a concise summary to the user:
{PROJECT}/openspec/feature-counsel-report.mdAfter execution, review what happened and append new observations to learnings.md under the appropriate section:
Each entry must include today's date. One insight per bullet. Skip if nothing new was learned.
Reset the OpenRegister development environment (stop, remove volumes, restart, install apps)
Create a Pull Request from the current branch — runs local checks, picks target branch, and opens the PR on GitHub
Detect admin settings Vue components registered in the vue-router. Admin settings are rendered by Nextcloud's settings framework via `AdminSettings.php`; adding their Vue components to the in-app router exposes them as publicly-accessible frontend routes, bypassing all server-side access checks. ADR-004 hard rule. Observed 2026-04-30 on doriath where `/settings → AdminRoot` was a route in `src/router/index.js` (commit c7c72e9).
Run `composer audit` to check composer.lock dependencies for known CVEs. Invoked by the builder before push and the reviewer's mandatory block. Mirrors the orchestrator's `composer-audit` quality gate.
Scan lib/ for forbidden debug helpers (var_dump / die / error_log / print_r / dd / dump) that should not ship. Invoked by the builder before push, by the reviewer as Mandatory Step 2, and by the fixer during a retry. Mirrors the orchestrator's `forbidden-patterns` quality gate.
Detect DOM data-attribute reads in `.vue`/`.js`/`.ts` files (e.g. `document.getElementById('x').dataset.version`) used to pull server-side data into the frontend. The Nextcloud-idiomatic pattern is `IInitialState::provideInitialState()` in PHP + `loadState()` from `@nextcloud/initial-state` in Vue. DOM data-attributes break on CSP-hardened instances and bypass the canonical pattern documented in ADR-004. Observed 2026-04-30 on doriath where `AdminRoot.vue` read `document.getElementById('doriath-settings').dataset.version`.