ワンクリックで
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 職業分類に基づく
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`.
| 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.