From fc-assistant
Defines the Functional Decision Record (FDR) format used by all functional consultant skills to document complex or counter-intuitive design decisions throughout the engagement.
How this skill is triggered — by the user, by Claude, or both
Slash command
/fc-assistant:fc-fdr-formatThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
A Functional Decision Record documents a design decision that is complex, counter-intuitive, or significant enough that it could surprise the client or the implementation team if not made explicit. FDRs are the audit trail of non-obvious reasoning — they exist so that every important decision is visible, traceable, and reviewable.
A Functional Decision Record documents a design decision that is complex, counter-intuitive, or significant enough that it could surprise the client or the implementation team if not made explicit. FDRs are the audit trail of non-obvious reasoning — they exist so that every important decision is visible, traceable, and reviewable.
An FDR is not a log of every decision made during the project. It captures decisions that required deliberate judgment — where a reasonable person could have chosen differently, where Salesforce standard practice was consciously set aside, or where a disagreement between stakeholders forced an explicit choice.
FDRs are not the mechanism for resolving ambiguous requirements. Ambiguous requirements are handled directly: ask the consultant for clarification or propose a concrete interpretation. Only create an FDR when the decision itself is non-trivial and worth documenting for future reference.
All FDRs must be Closed before the Functional Document can be generated or signed.
Create an FDR when:
Do not create an FDR when:
## FDR-[NNN] — [Short descriptive title]
**Status:** Open | Closed
**Date opened:** YYYY-MM-DD
**Date closed:** YYYY-MM-DD *(only if Status = Closed)*
**Source:** Workshop [N] | Commercial document | Design discussion | Requirement [REQ-NNN]
### Context
[Why this decision was needed. What tension, contradiction, or non-obvious situation triggered it. 2–4 sentences.]
### Decision
[The decision taken. Clear, specific, in business language. Only present if Status = Closed.]
### Consequences
[What this means for the solution. What alternatives are now ruled out. Only present if Status = Closed.]
### Pending *(only if Status = Open)*
[What specific answer or decision is needed. Who is responsible for providing it.]
### Revision History *(only if the FDR has been updated after initial creation)*
| Date | Change | Trigger |
|---|---|---|
| [YYYY-MM-DD] | [What changed] | [CL-ID if triggered by a scope change, or "Design review"] |
# Functional Decision Records — [Project Name]
Generated: [date] | Last updated: [date]
Sources: Requirements Register, Workshop sessions [list], Functional Document v[X]
---
## Status Summary
| FDR | Title | Status | Date Opened | Date Closed |
|---|---|---|---|---|
---
## Open FDRs *(must be resolved before Functional Document generation)*
[FDR entries with Status = Open]
---
## Closed FDRs
[FDR entries with Status = Closed]
Fetches up-to-date documentation from Context7 for libraries and frameworks like React, Next.js, Prisma. Use for setup questions, API references, and code examples.
Applies a firm's KYC/AML rules grid to parsed onboarding records: assigns risk rating, checks required documents, outputs rule outcomes with citations, and routes for escalation.
Generates daily or weekly digests of activity from connected sources (chat, email, docs, tasks, CRM), highlighting action items, decisions, mentions, and project updates.
npx claudepluginhub wam-leadclic/functional-consultant-assistant-skills --plugin fc-assistant