Half the reviews arrive after the deadline and the ratings mean something different in each team. Here is the model behind a cycle app, the prompts to build it, and what it takes to run it.
Your private status link is on its way to your inbox.
A performance review cycle app is four parts: dated stages, inputs ordered so the manager writes last, a rating scale defined in behaviour rather than adjectives, and calibration before anything is shared. The ordering matters more than people expect. A manager who writes before reading the self-assessment and peer input writes their impression of the last month, and the whole exercise becomes a record of recency rather than of a year.
Review cycle
412
In the cycle
388
Self-assessments in
61
Manager reviews outstanding
4 days
To calibration
Autumn cycle, every date an offset from the close
You run people operations, or you are a manager who has been through a cycle that ran on spreadsheets and reminders. What you want is a cycle that finishes on time and ratings that mean the same thing in two different teams.
What happens across a cycle, and why the order of it is the important part.
From the employee list, with anyone who started after a cut-off excluded and anyone whose manager changed flagged for a conversation.
Self-assessment opens before anything else, so the manager later reads it rather than writing over it.
The employee nominates, the manager approves, and nobody can receive more requests than a limit you set.
Which is the structural change that stops a review being a record of the last month.
Per level, shown on the screen where the rating is chosen, with evidence required.
Distributions compared across teams, adjustments recorded with reasons, and nothing visible to the employee until it closes.
A review app is not a form with a deadline. It is four parts, and the second is the one that decides whether the reviews are any good.
Self-assessment, peer input, manager review, calibration, delivery. Each with its own dates, derived from the cycle so a slipped date moves everything.
Self first, peers second, manager last. A manager who writes before reading either produces a review of the last month rather than of the year.
Each rating point written out in behaviour, per level. Adjectives on their own are how the same performance gets rated two different ways in two teams.
Managers compare proposed ratings across teams and adjust before anything is shared. Adjusting after the person has seen it is a far worse conversation.
These prompts start from a Helix project, which is what handles sign-in, credentials and hosting. Start with Helix
Paste these into Claude Code, Codex or Cursor in order. Each one leaves you with something that runs, so you can stop after any step.
Stages anchored to the cycle, so a slip moves everything.
In this Helix project, build me a performance review cycle app.
A cycle has a name, a period it covers, and dated stages: self-assessment
opens and closes, peer input opens and closes, manager review closes,
calibration, then delivery. Derive every stage date as an offset from the
cycle close, so when the cycle slips a week the whole schedule moves
instead of somebody editing five dates.
Participants are generated from a list of employees with their manager,
team, level and start date. Exclude anyone who started after a cut-off I
set, and flag anyone whose manager changed during the period, because
those reviews need a conversation rather than a form.
Show me a live view of the cycle: how many self-assessments are in, how
many peer requests are outstanding, how many manager reviews are drafted
against submitted, and who is behind. Chase automatically rather than
through somebody's reminder list.
I sign in through Helix, so do not build a login page. Read the signed-in
user from the runtime. And do not put any key or connection string in the
code: if this needs to reach another system, tell me and I will create the
connection in my workspace.The ordering that decides whether the reviews are worth reading.
Enforce the order, and this is the part that matters most.
Self-assessment opens first. Then peer input. Only when those close does
the manager see them and start writing.
A manager who writes before reading the self-assessment and the peer input
writes their impression of the last month, and the whole cycle becomes a
record of recency rather than of a year. Making the sequence structural
rather than advisory is the fix.
For peer input: the employee nominates, the manager approves the list, and
there is a limit on how many requests one person can receive. Without a
limit, the same three generous colleagues are nominated by everybody and
spend a fortnight writing reviews.
Ask peers specific questions rather than for general comments. What did
this person do that helped you, and what one thing would make working with
them easier. General prompts produce general praise, which is pleasant and
useless.Worth knowing. Sequencing self, then peers, then manager is a scheduling decision that does more for review quality than any amount of writing guidance.
Behaviour written out, per level.
Define the rating scale properly, in a config file.
For each point on the scale, write out what it looks like behaviourally,
and do it per level. What "exceeds" means for a graduate and for a
principal are different things, and a single generic description means
each manager silently supplies their own.
Show those descriptions on the screen where the manager selects a rating,
not in a document nobody opens.
Require evidence for every rating: specific things that happened, not
adjectives. Do not accept a rating without it.
Separate the rating on what was achieved from the rating on how, if you
use both, and keep them visibly separate all the way through. Blending
them into one number is how a company loses the ability to say that
somebody delivered and was difficult to work with, which is exactly the
case the review exists for.Before anything is shared, because afterwards is worse.
Add a calibration stage between the manager review and delivery.
Managers see proposed ratings across teams, with the distribution per
team, per level and per manager. Show who rates everybody highly and who
rates nobody highly, because both are real and neither is visible from
inside one team.
Let ratings be adjusted during calibration, with a reason recorded and the
original preserved. Nothing is visible to the employee until calibration
closes. Changing a rating after somebody has seen it is a much harder
conversation than changing it before.
Then delivery: the employee sees their review, acknowledges it, and can
add their own comment, which is kept.
Finish with something to act on: agreed development goals with dates,
carried into the next cycle so it opens with what was agreed last time.
Then report completion rate by manager, rating distribution over cycles,
and time from cycle close to delivery.Worth knowing. Carrying agreed goals into the next cycle is what turns an annual ritual into something continuous, and it costs one table.
The step that turns a working prototype into something with your data in it.
Now connect it to the systems we actually run, so it works on real data
rather than the rows you seeded.
Anything in angle brackets is a placeholder. Swap it for whatever we use
instead, and have the app name the connection it wants rather than assume
a vendor, so changing my mind later is a config change and not a rewrite.
<Workday>. Read the employee list, managers, levels and start dates to
generate the cycle, and write the final rating and agreed goals back once
calibration closes.
<Okta>. Read the manager relationship, which is what the app uses to
decide who can see a draft and who can see peer feedback.
<Gmail>. Send the formal cycle notices, which people keep and refer back
to in a way they do not with a chat message.
<Lattice>. If you already run reviews somewhere, read the cycle and write
results back rather than running two.
<Slack>. Chase self-assessments and peer input against the stage dates,
which is most of running a cycle.
<Google Drive>. Hold the written review where HR retention rules already
apply.
Only write where I have said to write. Everything else is read only.
Do not write a key, a token or a connection string anywhere in the code,
and do not ask me to paste one. Tell me which connections you need and I
will create each as an authentication in my Helix workspace. Reference
them by alias.Worth knowing. Every name in angle brackets is a placeholder for whatever you run. Helix holds the credential as a workspace authentication, so the app references an alias and never the secret itself.
The last step of every build: a URL, and the right people on it.
Deploy my app.Worth knowing. Your assistant runs helix deploy underneath and the app comes back as a URL. This is among the most sensitive data a company holds, and drafts must never be visible to the subject, so set Access Control carefully before anyone uses it.
This holds the most sensitive data in the library, so it reads a lot and shares almost nothing.
Workday
Read the employee list, managers, levels and start dates to generate the cycle, and write the final rating and agreed goals back once calibration closes.
Okta
Read the manager relationship, which is what the app uses to decide who can see a draft and who can see peer feedback.
Gmail
Send the formal cycle notices, which people keep and refer back to in a way they do not with a chat message.
Lattice
If you already run reviews somewhere, read the cycle and write results back rather than running two.
Slack
Chase self-assessments and peer input against the stage dates, which is most of running a cycle.
Google Drive
Hold the written review where HR retention rules already apply.
Each line says whether the app reads, writes or both. Anything not described as writing should be read only.
Named systems are the ones most teams actually run, not a list of the only ones that work. Swap in whatever you use.
Each connection is an authentication in your Helix workspace, referenced by alias. The app names the connection it wants and never holds the credential, so nothing here ends up in your code and any of it can be rotated or revoked without a redeploy.
The build gets you a working cycle. It holds among the most sensitive data in the company, and a visibility mistake here is a serious one, so how it is run is the larger half.
AI Deployment
One command takes the app from your assistant to a live address, so the people who need it get a link rather than instructions for running it locally.
App Security
Draft reviews, peer feedback and calibration discussions must never be visible to the subject. SSO plus tightly scoped access is the whole safety property of this app, not a nicety.
App Security
Reading the employee list, managers and levels from an HR system keeps the cycle accurate. Granting that access to the app rather than pasting a key into it means it can be rotated or revoked without a redeploy.
App Registry
Every app carries a named owner and an entry IT can see, so the tool does not become nobody's problem when the person who built it changes role.
Cost Management
Per-app spend visibility, with budgets and caps, so an internal tool cannot quietly become a line item nobody can explain.
It runs a review cycle to dated stages, collects self-assessment and peer input before the manager writes, holds a rating scale defined in behaviour per level, and adds a calibration step before anything is shared with the employee.
Because a manager who writes before reading the self-assessment and peer input produces a review of the last month rather than of the year. Making the sequence structural does more for review quality than any amount of writing guidance.
In behaviour, per level, shown on the screen where the manager picks the rating. "Exceeds" means something different for a graduate and a principal, and a single generic description means each manager quietly supplies their own.
Because changing a rating after somebody has seen it is a much harder conversation than changing it before. Calibration also surfaces the managers who rate everybody highly and those who rate nobody highly, neither of which is visible from inside one team.
Cap how many requests one person can receive, and have the manager approve the nomination list. Without a limit, the same three generous colleagues get nominated by everybody and lose a fortnight to it.
Yes for the app, and the prompts here are written for Claude Code, Codex or Cursor. Be deliberate about access: draft reviews and peer feedback must never be visible to the subject, and that is a running decision rather than a coding one.
People
Score candidates against the competencies the role actually needs, collect evidence rather than impressions, and make the hiring decision from a comparable record. Prompts to build it, and what it takes to run it.
People
One record per role from request to filled, with approval, budget, and a status that finance, recruiting and the hiring manager all read the same way. Prompts to build it, and what it takes to run it.
People
Generate the right task list per role, route each task to the team that owns it, and prove that access was actually removed. Prompts to build it, and what it takes to run it.
Last reviewed September 2026.
Helix is the governed runtime for AI-built apps. Deploy what you build, put SSO in front of it, connect it to your systems with managed credentials, and give it a named owner.
Your private status link is on its way to your inbox.