360 Feedback System

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 shared execution contract at ../../references/execution-contract.md 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:

One message, one question, no batching. 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:

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.

Do not build unprompted. End with an offer naming the artifacts not yet requested.

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, because the option list is not yet a confirmed taxonomy. Once the user confirms options for a Select field, generate the constraint from that confirmed set:

ALTER TABLE feedback_cycle_responses ADD CONSTRAINT chk_feedback_type CHECK (feedback_type IN (<confirmed options>));

CREATE TABLE feedback_cycle_responses (
  feedback_id SERIAL PRIMARY KEY,
  feedback_type VARCHAR(100) NOT NULL,
  feedback_subject VARCHAR(255),
  reviewer VARCHAR(255),
  visibility_mode VARCHAR(100) NOT NULL,
  review_cycle VARCHAR(255),
  submitted_date DATE,
  status VARCHAR(100) NOT NULL,
  due_date DATE,
  score NUMERIC,
  comments TEXT,
  created_at TIMESTAMP DEFAULT NOW(),
  updated_at TIMESTAMP DEFAULT NOW()
);

CREATE INDEX idx_feedback_cycle_responses_status ON feedback_cycle_responses (status);

JSON Schema. required is derived from business necessity, not from what data happens to exist. The three required fields are the ones without which a response cannot be interpreted. Reviewer and Due Date are absent from required because a legitimate response may omit them.

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "title": "360 Feedback Response",
  "type": "object",
  "additionalProperties": false,
  "properties": {
      "Feedback ID": { "type": "integer" },
      "Feedback Type": { "type": "string" },
      "Feedback Subject": { "type": "string" },
      "Reviewer": { "type": "string" },
      "Visibility Mode": { "type": "string" },
      "Review Cycle": { "type": "string" },
      "Submitted Date": { "type": "string", "format": "date" },
      "Status": { "type": "string" },
      "Due Date": { "type": "string", "format": "date" },
      "Score": { "type": "number" },
      "Comments": { "type": "string" }
  },
  "required": [
      "Feedback Type",
      "Visibility Mode",
      "Status"
  ]
}

Notion. A mapping table, not a build. Convert properties after import.

| CSV column | Notion property | Set after import |
|---|---|---|
| Feedback ID | Title | Use as the database title |
| Feedback Type | Select (add options after import) | Convert to Select, add options: "Self", "Peer", "Manager", "Direct Report", "Cross Functional" |
| Feedback Subject | Text | Leave as Text |
| Reviewer | Text | Leave as Text |
| Visibility Mode | Select (add options after import) | Convert to Select, add options: "Identified", "Confidential", "Anonymous" |
| Review Cycle | Text | Leave as Text |
| Submitted Date | Date | Convert to Date |
| Status | Select (add options after import) | Convert to Select, add options: "Not Launched", "Collecting", "Consolidated", "Shared", "Closed" |
| Due Date | Date | Convert to Date |
| Score | Number | Convert to Number |
| Comments | Text | Leave as Text |

Notion's own auto-ID is platform-specific and does not replace the canonical Feedback ID. Use one as the Notion primary column and the other as a business reference, and say which is which.

Inline versus file. Inline output returns the artifact in the message. File output returns the link. Do not mix: never return a link when inline data was requested, or inline data when a file was requested.

Field Reference

This table is the single source. CSV header, SQL columns, JSON Schema properties and the Notion mapping are generated from it, never written by hand.

Three rules govern it:

• Naming. One human label plus a machine-safe key, defined once and reused everywhere. The key is the label lowercased with non-alphanumerics replaced by _.
• Inclusion. A field exists only when a confirmed requirement justifies it. This is why the list is short.
• Deduplication. Before emitting any artifact, collapse semantically equivalent fields. One identity, one field. A second identifier for the same record is a duplicate unless the user asked for a human-readable reference alongside the system key.

created_at and updated_at are the only artifact-only additions. They are technical metadata, not business fields, and are labelled as such.