360-feedback-system – Data & Science skill for AI agents

360° Feedback System

What it is: Records one feedback response per row, with the field list built only from what the user confirms.

Overview

Works out the smallest useful 360° feedback setup for the business in front of it, then builds

it only when asked. The default output is a short recommendation, not a spreadsheet. CSV, SQL

DDL, JSON Schema and the Notion mapping are derived from the one Field Reference below, so they

cannot drift apart.

Three conceptual models are kept separate, because merging them is what forces fields to be

invented:

• Response - one row per feedback response. The only model with a table in this skill.
• Scoring Configuration - scale, weights, missing and not-applicable handling, rounding.

Configuration, never a column on the response row.

• Questions - the question set and its version, held only when questions change between

cycles. A question ID is a column on Response only once that requirement is confirmed.

Artifacts are empty templates by default. The single illustrative row is a shape placeholder

carrying Example / -EXAMPLE- values, never business data.

Layer: Layer 4: Manage. Fits: Growth stage. Table code: n/a.

When to Use This Skill

• 360 feedback
• feedback system
• peer review tool
• 360 degree feedback tracker

Also use it when the user says "holistic feedback", or describes the same process happening in a

spreadsheet, a document or someone's inbox.

Not for payroll, tax, legal, or employment-decision work. This skill does not automate those.

How It Works

Follow the shared execution contract. The module-specific rules below define only domain fields, decisions, calculations, and safety constraints.

The rules below stand on their own. If the upstream shared execution contract (not bundled here) is unavailable, follow this file directly; a missing

reference never blocks basic execution.

Step 1 - Identify intent

Read the request and pick one intent before asking anything. This is the canonical set, used

here and in the context block with the same spelling:

| Intent | Trigger | Go to |

|---|---|---|

| advice | "how do I ...", "what should we" | Answer, offer the build only if it helps |

| review | "is this right", "review", "audit" | Check what they share |

| build | "set up", "build", "create" | Step 2 |

| convert | "move it from our sheet/forms" | Capture their process, then Step 2 |

| export | "give me the CSV / SQL / JSON / Notion" for confirmed rules | Step 5 |

Prefer one concise question for a material ambiguity; bundle related missing facts when the user prefers it. Never ask a question whose answer would not change the

recommendation or the requested artifact.

Scope boundary

Decline only the specific high-risk action that is out of scope, and continue with the rest of

the request. Example: for a request that mixes feedback capture with payroll, decline the payroll

calculation and proceed with the feedback setup.

Step 2 - Ask only what is missing

Skip anything already answered in any earlier message. Ask the rest one at a time, and stop as

soon as the remaining answers would not change the output.

Decide fields from the answers, not from habit. The only fields that need no confirmation are the

ones in the minimum core below. Each optional field needs a confirmed requirement behind it:

| Candidate field | Only add when the user confirms |

|---|---|

| Score | A scoring mode on a defined scale |

| Additional score fields | Named competency areas, one per confirmed area |

| Due Date | Deadlines are part of their process |

| Reviewer | Responses are identified or confidential, not anonymous |

| Review Cycle | Feedback runs in more than one cycle |

| Submitted Date | Submission is timestamped in their process |

| Question ID | The question set changes between cycles |

| Feedback Subject | A subject is recorded at all |

Feedback Subject stays a generic label. The subject may be a person, a project, a customer or

a team, so take the type from the user rather than assuming an employee.

Never invent an answer. Record it as unknown and carry on. Unknown is a real value meaning not

yet supplied. Never turn Unknown into zero, and never turn a blank into a zero. Never re-ask an

unknown already recorded.

Answers like yes, no, maybe, same, okay or fine are not an answer to a

multiple-choice question. Re-ask as an explicit choice:

> Q: Which do you mean: identified or anonymous feedback?

>

> A: maybe

Keep only the answered part of a partial answer, and leave the rest Unknown.

Step 3 - Hold the internal context

Hold the answers in this shape. It stays internal, is not shown unless asked, and never carries a

value the user did not give.

module: 360-feedback-system
intent: null            # advice | review | build | convert | export
scale: null             # only when the answer changes the recommendation
areas:
  "Subject": null
  "Relationships": null
  "Visibility": null
  "Scoring": null
  "Follow-up": null
requested_outputs: []   # csv | sql | json | notion | xlsx - only what was explicitly asked
confirmed_facts: []     # only what the user actually said
unknowns: []            # asked and not answered
open_questions: []      # the unanswered ones, in the order worth asking

Step 4 - Recommend the smallest workflow

Give the smallest recommendation: one approach sentence, one workflow line, and only the

unresolved facts that matter. Generate the approach and the workflow from confirmed context. Do

not carry a canned approach, a canned rationale, or a fixed step list across requests.

Build the workflow line from the collection, review and follow-up process the user described. If

they described none, say the workflow is Unknown and ask. Do not assume a review role, an

automated analysis step, or a specific tool.

Do not enumerate fields, statuses or schema mappings unless the user asks for a schema or

artifact. Follow-up and completion are process steps, not fields in this module.

When scoring is mentioned but its policy is incomplete, label each missing input explicitly:

Scale: Unknown, Included scores: Unknown, Weights: Unknown,

Missing-score behavior: Unknown, Not-applicable handling: Unknown, Rounding: Unknown. Do not

compute an overall figure until all six are resolved.

For advice-only requests, offer useful artifacts. A request to build already authorizes artifact generation; do not stop for a second request.

Step 5 - Build only on request

Once asked, derive the fields from the confirmed context and emit only the requested artifacts.

When more than one is requested, generate every one of them from the same Field Reference, in one

pass, so they cannot disagree.

**A selected Notion output is rendered by notion-manual-import, so route the

Notion step there.** When the user selects Notion, hand that step to

@notion-manual-import: it holds the CSV, the property

mapping, the import steps and the verification checklist, and it renders the Field

Reference below instead of defining a table of its own. Do not restate the mapping

here and do not improvise the import steps. Manual CSV and mapping outputs need no

connection. For requested workspace changes, follow the shared contract: verify actual

tool access and the target before writing. A user saying "connected" is not tool evidence.

Never ask for a Notion password or token.

Validate before replying, then check cross-format consistency: same field names, same spelling,

same order, same required set in all artifacts.

Reply with the artifact or link, plus a short note only when there is an error, a limitation, or

an unresolved unknown to surface. Do not append column counts, validation claims or closing text

to an otherwise clean artifact request.

If artifact generation or validation fails, return the error in one line naming the field or

format that failed, emit the artifacts that did succeed, and say which one is missing. Never

substitute a plausible value to make a build pass.

The examples below show a documented shape. They are not this business's schema.

CSV. UTF-8 with a byte order mark so Excel opens the text correctly. A CSV is not an

.xlsx workbook; create one only when the user asks. A CSV carries no types, so when import

guidance is requested, name the columns needing a number, date or currency format applied.

Feedback ID,Feedback Type,Feedback Subject,Reviewer,Visibility Mode,Review Cycle,Submitted Date,Status,Due Date,Score,Comments
,Peer,Example Subject 01,Example Reviewer,Identified,Example Cycle 2026-Q1,2026-01-15,Collecting,2026-01-22,4,Example comment recorded to show free text.

SQL. Portable types. The engine is not known, so SERIAL PRIMARY KEY is shown as the

PostgreSQL form; on an unconfirmed engine use a portable feedback_id <int type> PRIMARY KEY and

state the engine in one line. No CHECK is emitted against a Select column here

… (full content is in the download package)