fp-control: Function Point Analysis as an AI Skill, Not an Application

I had a GitHub repository called fp-control that was originally a Flask API deployed on AWS Lambda. It was not doing much. I decided to repurpose it entirely and turn it into something I actually wanted to use: a vendor-agnostic AI skill for planning software systems using Function Point Analysis.

The fact that it started as a dedicated application is worth noting. A well-structured skill can replace a surprising number of lightweight tools — the trade-off is that you become dependent on an agent subscription cost, or on the heavier lift of running a local LLM with enough capacity to follow complex instructions reliably. A local model gives you more control and, arguably, more room for unconventional ideas since you are not working within a commercial service’s guardrails. But for most use cases, a hosted agent with a good skill file is the faster path.

What is a skill, exactly? #

In the context of AI coding assistants, a skill is a Markdown file that an agent reads and follows as a set of instructions. Claude Code calls them commands; Cursor calls them rules; Windsurf calls them memories. The format varies slightly, but the idea is the same — you write the instructions once and the agent knows how to behave for that task in every future session.

The challenge with skills is distribution. If I write one for Claude Code, it only works there. I wanted something that any agent could pick up and use.

The auto-install pattern #

The first design decision was to make the skill install itself. When an agent reads fp-control.md for the first time, the file’s own instructions tell it to detect which platform it is running on and copy itself to the appropriate global configuration directory. Claude Code gets ~/.claude/commands/fp-control.md. Cursor gets ~/.cursor/rules/fp-control.mdc. Windsurf gets its own path. Any other agent is instructed to use its platform’s equivalent.

The user never has to think about setup again after the first read. If they trust the agent to do it automatically, it just works. If they prefer to do it manually, the README includes a table with the exact command for each platform.

The Function Point Analysis workflow #

Once installed, invoking /fp-control starts an IFPUG Function Point Analysis session. The skill walks the user through eight steps:

1. Define the system boundary — what is inside, what is outside
2. Identify Internal Logical Files (ILF) — data the system owns and maintains
3. Identify External Interface Files (EIF) — external data the system reads but does not maintain
4. Count External Inputs (EI) — write operations that create, update, or delete internal data
5. Count External Outputs (EO) — reports and calculated results sent outside the boundary
6. Count External Inquiries (EIQ) — read-only lookups with no derived processing
7. Calculate Unadjusted Function Points and produce a planning summary
8. Optionally save the analysis as a structured Markdown file and generate an HTML report

The skill asks one topic at a time, reasons through RET, DET, and FTR counts from the user’s descriptions when they are unsure, and keeps a running tally visible throughout. It also detects the language the user writes in and conducts the entire session — including the HTML output — in that language.

Running it on a real system #

To test the skill, I ran a full FPA session for a multi-company platform with role-based access and a professional assignment model. The kind of system that, on paper, feels straightforward but quickly reveals its depth once you start counting what it actually does.

The analysis produced 329 Unadjusted Function Points across 74 items: 13 Internal Logical Files (91 FP), no External Interface Files, 33 External Inputs (111 FP), 12 External Outputs (62 FP), and 16 External Inquiries (65 FP). At typical industry benchmarks, that translates to roughly 4,600 hours of development effort — a concrete baseline before a single line of code is written.

The HTML report #

At the end of the session the skill generates a self-contained HTML file with no external dependencies. Everything — CSS, JavaScript, data — is inlined. The report is structured as a tabbed interface: an Overview tab with the system boundary, a bar chart, and the UFP summary, followed by one tab per function type (ILF, EIF, EI, EO, EIQ) and a final Effort & Risks tab.

Each function-type tab includes a complexity reference card showing the IFPUG matrix for that type, and a full item table with a “Rule applied” column that makes the reasoning transparent — for example, FTR 2, DET 5–15 → Avg. Anyone reading the report can trace exactly how each item was rated.

The report also has a dark/light mode toggle and two print buttons: one that prints the full report in light mode regardless of the current theme, and a second that prints a simplified summary showing only the Overview tab.

Session continuity with .fpa.md #

One limitation of working with AI agents is that sessions end. Compaction truncates context. A full FPA session for a moderately complex system involves dozens of items across five function types — not something you want to reconstruct from memory.

The skill addresses this by saving the analysis as a .fpa.md file. The file has two parts: a YAML frontmatter block with all structured data (every item, its counts, complexity, and FP value), and a human-readable markdown body with the full planning summary below it. When the user opens a new session and references the file, the agent reads the frontmatter and offers to resume from exactly where things were left off — presenting the summary, updating specific items, or going straight to HTML generation.

One file serves both purposes: machine-readable enough for an agent to restore state, human-readable enough to open in any editor and understand at a glance.

Why Function Points still matter #

There is a reasonable question about whether measuring functional size is still relevant when AI can generate code faster than ever. My view is that it matters more, not less. AI accelerates implementation but does not shrink requirements. A system with 300 Function Points has the same functional complexity whether it takes a team of ten three months or a solo developer with an AI assistant two weeks. The scope is the same; only the productivity changed.

Function Points give you a technology-agnostic baseline for that scope — one that is comparable across projects, defensible in contracts, and useful for recalibrating benchmarks as AI-assisted development productivity data accumulates. Knowing what you are asking the AI to build, and how much of it, is still the first step before asking it to build anything.

The repository is at github.com/adautomeira/fp-control and is released under the MIT license.