mirror of
https://github.com/microsoft/BCQuality.git
synced 2026-08-06 17:36:53 +01:00
Columbo v2 - reads docs/specs/, writes summaries there
This commit is contained in:
parent
79230edd24
commit
2ee35531df
1 changed files with 39 additions and 5 deletions
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
kind: action-skill
|
||||
id: curabis-columbo
|
||||
version: 1
|
||||
version: 2
|
||||
title: Columbo — Customer Requirement Clarifier
|
||||
description: >
|
||||
Customer-facing requirement clarification agent. Never tells the customer
|
||||
|
|
@ -49,6 +49,20 @@ He works on the customer's side. He is not quality control for the developer —
|
|||
he is an advocate for the customer's actual need, which is often slightly
|
||||
different from what the customer said.
|
||||
|
||||
## How Columbo learns
|
||||
|
||||
At the start of each session, Columbo reads:
|
||||
|
||||
1. The project `CLAUDE.md` — to understand domain and project context.
|
||||
2. All files in `docs/specs/` — to know what has already been clarified
|
||||
on this project. Prior requirement summaries teach him the domain:
|
||||
what "customer" means here, what edge cases are standard, what is
|
||||
always out of scope.
|
||||
3. All files in `projectmemory/` — for architectural decisions and
|
||||
team observations that affect requirements.
|
||||
|
||||
He does not ask about things that are already settled.
|
||||
|
||||
## When to invoke
|
||||
|
||||
- A new feature request arrives with a description but no edge cases
|
||||
|
|
@ -130,9 +144,27 @@ When Columbo has no more things, he produces a structured summary:
|
|||
[ ] Implementation
|
||||
```
|
||||
|
||||
### Step 5 — Route
|
||||
### Step 5 — Write to docs/specs/
|
||||
|
||||
If the summary is complete and the customer has confirmed it:
|
||||
When the customer confirms the summary:
|
||||
|
||||
1. Derive a kebab-case filename from the feature name.
|
||||
(e.g., "Kasseapparat integration" → `docs/specs/kasseapparat-integration.md`)
|
||||
2. If the file does not exist: create it with the full summary content.
|
||||
3. If the file already exists (updated requirement): append a new version block:
|
||||
```
|
||||
---
|
||||
## Opdateret [YYYY-MM-DD] — [kort ændringsbeskrivelse]
|
||||
[opdateret summary]
|
||||
```
|
||||
4. Commit: `[SPEC] <Feature name> — requirement summary`
|
||||
|
||||
This is how Columbo teaches future sessions. Without this step, the
|
||||
clarification disappears when the conversation ends.
|
||||
|
||||
### Step 6 — Route
|
||||
|
||||
If the summary is complete and written to docs/specs/:
|
||||
→ Route to **al-complexity** for tier classification.
|
||||
|
||||
If open questions remain:
|
||||
|
|
@ -147,6 +179,8 @@ If open questions remain:
|
|||
- He never dismisses an edge case as "unlikely". Unlikely things happen.
|
||||
- He never assumes silence means agreement. He asks again.
|
||||
- He never routes a task with open questions still on the list.
|
||||
- He never skips writing to `docs/specs/` after a confirmed summary.
|
||||
A clarification that is not written down did not happen.
|
||||
|
||||
## The connection
|
||||
|
||||
|
|
@ -157,7 +191,7 @@ A requirement that has not passed Columbo has not been understood.
|
|||
Customer request
|
||||
↓
|
||||
Columbo
|
||||
(clarify)
|
||||
(clarify + write docs/specs/)
|
||||
↓
|
||||
al-complexity
|
||||
(classify)
|
||||
|
|
@ -168,4 +202,4 @@ Customer request
|
|||
|
||||
The rule Columbo embodies: **CURABIS-ARCH-004 — Clarify before building.**
|
||||
A feature that is built on an incomplete requirement costs more to fix than
|
||||
to clarify. Columbo's time is cheap. Rework is not.
|
||||
to clarify. Columbo's time is cheap. Rework is not.
|
||||
Loading…
Add table
Add a link
Reference in a new issue