Passive vocabulary = kata yang bisa kamu pahami saat melihat/mendengar.
Active vocabulary  = kata/chunk yang bisa kamu ambil cepat saat berbicara.

Words → Chunks → Collocations → Sentence Frames → Scenario Playbooks

Saya ingin bilang bahwa deployment sebaiknya ditunda karena rollback belum dites.

I suggest we delay the deployment because the rollback path hasn't been tested yet.

Maybe deployment... not now... because rollback... not test... so better later.

rollback
latency
constraint
assumption
trade-off
investigate
intermittent
reproducible

The issue is intermittent and not reproducible locally.

The issue seems intermittent, and I haven't been able to reproduce it locally yet.

seems intermittent
reproduce it locally
not fully sure yet
the main trade-off is
my concern is
the safer option is
we need to validate this first

constraint = batasan
assumption = asumsi
mitigation = mitigasi
reproduce = mereproduksi

My concern is...
I'm concerned about...
One concern I have is...
That addresses my concern.
I don't think this is a major concern.

word → chunk

issue
risk
blocker
deploy
rollback
latency
failure
constraint
assumption
impact

the main issue is
I'm blocked by
we need to roll back
my assumption is
this could impact

raise a concern
make a decision
reduce latency
increase reliability
meet a requirement
reproduce a bug
run a test
review a pull request

The main issue is that...
My concern is that...
I suggest we...
Could you clarify...?
The trade-off is between... and...

ask
clarify
explain
agree
disagree
suggest
decide
summarize
escalate

standup
code review
debugging
architecture discussion
incident update
stakeholder meeting
interview

Could you explain...?
Could you clarify...?
What do you mean by...?
Can you walk me through...?
Do you know why...?
Do we have any data on...?
What are the constraints?
What are the next steps?

Could you clarify the expected behavior?
Can you walk me through the deployment process?
Do we have any data on the failure rate?
What are the constraints for this migration?

The main issue is...
The reason is...
This happens because...
The impact is...
The trade-off is...
The current behavior is...
The expected behavior is...

The main issue is that the service times out under load.
This happens because the connection pool is exhausted.
The impact is that checkout becomes unreliable.
The trade-off is higher latency but better consistency.

Let me clarify that.
What I mean is...
To be more specific...
Just to confirm...
So you're saying that...?
Do you mean...?

Let me clarify that. I'm not suggesting a full rollback.
What I mean is we should disable the feature flag first.
Just to confirm, this only affects staging, right?

That makes sense.
I agree with that.
I think that's reasonable.
That sounds like a good approach.
I'm aligned with the direction.

That makes sense. A gradual rollout would reduce the risk.
I agree with that. We should validate it in staging first.

I see your point, but...
I'm not fully convinced that...
My concern is...
I'm worried that...
I would be careful with...
I think there is another risk here.

I see your point, but I'm worried about the migration risk.
I'm not fully convinced that this solves the root cause.
My concern is that we don't have enough observability yet.

I suggest we...
We could...
Maybe we should...
One option is to...
It might be safer to...
What if we...?

I suggest we roll it out gradually.
We could add a feature flag first.
It might be safer to postpone the deployment.
What if we test the rollback path before merging this?

Let's go with...
I think the best option is...
Based on the risk, we should...
Let's align on the next step.
So the decision is...

Let's go with the safer option for now.
Based on the risk, we should delay the deployment.
So the decision is to roll this out to 10% of users first.

Let me summarize.
So far, we know that...
The key points are...
The decision is...
The next steps are...

Let me summarize. The issue started after the deployment, it affects checkout, and the safest next step is to roll back.
The next steps are to check the logs, validate the config, and prepare a patch.

progress
blocker
update
priority
timeline
scope
estimate
dependency
handoff
follow-up

I'm working on...
I'm currently blocked by...
The main dependency is...
The timeline is tight.
This is out of scope for now.
I'll follow up after the meeting.

I'm currently blocked by the missing API contract.
The main dependency is the authentication service.
This is out of scope for the current sprint.

bug
issue
error
failure
exception
stack trace
log
timeout
regression
root cause
reproducible
intermittent

The issue is reproducible locally.
The error happens intermittently.
The logs show a timeout.
The root cause seems to be...
This looks like a regression.

The issue is reproducible locally, but only with test data.
The logs show a timeout before the request reaches the database.
This looks like a regression from the last release.

deploy
deployment
release
rollback
rollout
feature flag
migration
staging
production
canary
blast radius

deploy to staging
release to production
roll it back
roll it out gradually
reduce the blast radius
behind a feature flag

We should deploy this to staging first.
Let's roll it out gradually behind a feature flag.
If anything goes wrong, we can roll it back quickly.

architecture
design
constraint
assumption
trade-off
scalability
reliability
availability
consistency
latency
throughput
coupling
cohesion
boundary

The main trade-off is...
This increases coupling.
This improves reliability.
The assumption is that...
The constraint is...
We need a clear boundary between...

The main trade-off is latency versus consistency.
This design improves reliability, but it increases operational complexity.
The assumption is that traffic will grow gradually.

approach
implementation
edge case
readability
maintainability
abstraction
validation
naming
side effect
behavior

This approach works, but...
Could we simplify this?
What happens if...?
This might break when...
Could we add a test for...?
The naming is a bit unclear.

This approach works, but I'm concerned about the edge case where the input is null.
Could we add a test for the failure scenario?
The naming is a bit unclear because this method does more than validation.

make a test
make a bug
open the feature
close the risk

run a test
find a bug / fix a bug
enable the feature
reduce the risk / mitigate the risk

raise a ______
run a ______
reduce ______
roll out ______
reproduce ______
meet the ______
handle edge ______
make a ______

raise a concern
run a test
reduce latency / reduce risk
roll out a feature
reproduce a bug
meet the requirement / deadline
handle edge cases
make a decision

The main issue is that [problem].

The main issue is that the service times out under load.
The main issue is that we don't have enough observability.
The main issue is that the migration path is not reversible.

This happens because [cause].

This happens because the connection pool is exhausted.
This happens because the cache is not invalidated correctly.
This happens because the config is different in production.

This affects [user/system] because [impact].

This affects checkout because payment requests time out.
This affects internal users because the dashboard shows stale data.
This affects the deployment because the migration takes too long.

I suggest we [action] so that [benefit].

I suggest we roll it out gradually so that we can reduce the blast radius.
I suggest we add more logging so that we can debug this faster.
I suggest we postpone the deployment so that we can test the rollback path.

My concern is that [risk].

My concern is that this change increases coupling between services.
My concern is that we don't have a safe rollback plan.
My concern is that this may create a regression in the checkout flow.

The trade-off is [benefit] versus [cost].

The trade-off is lower latency versus weaker consistency.
The trade-off is faster delivery versus higher operational risk.
The trade-off is simpler implementation versus lower flexibility.

Based on [reason], I think we should [decision].

Based on the production risk, I think we should delay the deployment.
Based on the logs, I think we should investigate the database connection first.
Based on the timeline, I think we should reduce the scope.

This is definitely wrong.
This will never work.
I don't know anything.

I'm not fully sure yet.
My current guess is...
It seems like...
It looks like...
This might be...
This could be related to...
I need to verify this first.

I'm not fully sure yet, but it seems related to the deployment.
My current guess is that the cache is returning stale data.
This could be related to the config change from yesterday.
I need to verify this in staging first.

I don't know yet.
I'm not sure.
It might be...
It could be...
It seems like...
It looks like...
I think...
I'm fairly sure...
I'm confident that...

Your code is wrong.
This design is bad.
You must change this.
I don't agree.

I think this might break in this edge case.
I'm concerned about this part of the design.
Could we consider another approach?
I see your point, but I have a different concern.

Chunk: My concern is that...
Function: soft disagreement / risk expression
Scenario: code review, design review
Examples:
1. My concern is that this increases coupling.
2. My concern is that the rollback path is not tested.
3. My concern is that this will be hard to debug in production.

I suggest we add more logging.
I suggest we delay the deployment.
I suggest we split this into two pull requests.

I suggest we + verb phrase

01-asking.md
02-clarifying.md
03-explaining.md
04-agreeing.md
05-disagreeing.md
06-suggesting.md
07-decision-making.md
08-standup.md
09-debugging.md
10-code-review.md
11-architecture.md
12-incident.md

Phrase:
Function:
Formality:
Scenario:
Example 1:
Example 2:
Example 3:
Common mistake:

Phrase: Could you walk me through...?
Function: ask for explanation
Formality: neutral/professional
Scenario: debugging, onboarding, design review
Example 1: Could you walk me through the deployment process?
Example 2: Could you walk me through how this service handles retries?
Example 3: Could you walk me through the failure scenario?
Common mistake: Explain me about... ❌
Better: Could you explain...? / Could you walk me through...? ✅

I wanted to ask about...
I have a quick question about...
Can we talk about...?
I need your input on...
I want to clarify one thing before we move on.
Let me give a bit of context.
For context, this started after...
The background is...

I see.
Got it.
That makes sense.
I understand the concern.
I see what you mean.
Let me make sure I understood.
So you're saying that...
Just to confirm...

Could you clarify that?
Could you say that again?
Could you rephrase that?
What do you mean by...?
Do you mean...?
Are you referring to...?
Can you give an example?
Can you be more specific?

The main issue is...
The problem is that...
This happens because...
The reason is...
The impact is...
The current behavior is...
The expected behavior is...
The difference is...

I can reproduce it locally.
I can't reproduce it yet.
The logs show...
The error happens when...
This started after...
My current guess is...
The root cause seems to be...
We need more data before deciding.

I suggest we...
We could...
Maybe we should...
One option is to...
It might be safer to...
What if we...?
Would it make sense to...?
Let's consider...

I see your point, but...
I'm not fully convinced that...
My concern is...
I'm worried that...
I would be careful with...
That might work, but...
I think there is another risk.
Can we validate that assumption first?

Let's go with...
I think the best option is...
Based on the risk, we should...
So the decision is...
The next step is...
Who will own this?
When do we need to decide?
Let's align on the timeline.

Thanks, that helps.
That answers my question.
I'll follow up after checking the logs.
I'll update the ticket.
Let's continue this in the thread.
I'll send a summary after the meeting.
Talk to you later.
Thanks for the clarification.

Let's discuss about the issue.

Let's discuss the issue.
Let's talk about the issue.

discuss + object
talk about + object

Can you explain me this code?

Can you explain this code to me?
Could you walk me through this code?

I ever worked on that service.

I've worked on that service before.
I worked on that service previously.

I'll join with the meeting.

I'll join the meeting.
I'll join the call.

I sent a request for access.

I requested access.

Until now, I don't have any blocker.

I don't have any blockers at the moment.
So far, I don't have any blockers.

Yesterday, I worked on...
Today, I'm going to...
I'm currently blocked by...
I need help with...
I don't have any blockers at the moment.
This is taking longer than expected because...
I should be able to finish it by...

Yesterday, I worked on the authentication flow. Today, I'm going to add integration tests. I'm currently blocked by the missing test credentials.

The issue started after...
The error happens when...
The logs show...
I can reproduce it by...
I haven't found the root cause yet.
My current guess is...
Let's check the logs first.
Let's isolate the failing component.

The issue started after the deployment. The logs show repeated timeout errors. My current guess is that the database connection pool is exhausted.

Could we simplify this part?
What happens if the input is null?
This might cause a regression.
Could we add a test for this scenario?
The naming is a bit unclear.
This looks good to me.
Thanks for the update.

This looks good overall. One concern I have is the edge case where the input is null. Could we add a test for that scenario?

The main trade-off is...
The constraint is...
The assumption is...
This improves reliability but increases complexity.
This creates tighter coupling between services.
We need to define the service boundary clearly.
How does this behave under load?
What is the rollback strategy?

The main trade-off is lower latency versus weaker consistency. If we choose asynchronous replication, we need to handle stale reads explicitly.

We are investigating the issue.
The impact is limited to...
The current hypothesis is...
We have mitigated the immediate impact.
The service is recovering.
We will share a follow-up after the root cause analysis.

We are investigating a timeout issue in the payment service. The impact is limited to checkout requests in one region. We have mitigated the immediate impact by rolling back the latest deployment.

Saya ingin bilang bahwa saya belum yakin root cause-nya.

I'm not sure about the root cause yet.
I haven't found the root cause yet.
My current guess is that it's related to the deployment, but I need to verify it.

Saya ingin menyampaikan concern tentang risiko rollback.

My concern is that the rollback path hasn't been tested yet.
I'm worried that we don't have a safe rollback plan.

Ask for clarification.

Could you clarify that?
Do you mean the staging environment or production?
Let me make sure I understood.

Disagree politely.

I see your point, but I'm concerned about the rollout risk.
I'm not fully convinced that this solves the root cause.

Function: expressing concern

My concern is...
I'm concerned about...
I'm worried that...
One risk is...
I would be careful with...

My concern is that the migration is not reversible.
My concern is that the service boundary is unclear.
My concern is that this increases operational complexity.

Your teammate wants to deploy today, but rollback hasn't been tested.

I see why we want to deploy today, but my concern is that the rollback path hasn't been tested yet. It might be safer to delay the deployment until we validate that.

I want to say that maybe we need to do checking about the log first before we make decision for rollback.

We should check the logs before deciding whether to roll back.

The problem that happens is maybe because the configuration in production is not same with staging.

The issue might be caused by a config difference between staging and production.

I am afraid that if we deploy this, it will make another problem in checkout.

I'm concerned this could cause a regression in checkout.

Considering the architectural implications and the operational constraints, perhaps it would be prudent to evaluate whether the deployment strategy should be modified.

Given the risk, I think we should change the deployment strategy.

Can I add something here?
Can I jump in for a second?
I have one quick point.
Just to add to that...

Let me finish this thought.
There are two parts to this.
The first point is...
The second point is...

What do you think?
Does that make sense?
How does that sound?
Any concerns with that approach?

Maybe we should park this for now.
Let's take this offline.
We can follow up on this after the meeting.
This might need a separate discussion.

So the next step is...
I'll take ownership of that.
Let's document the decision.
I'll update the ticket after this.

mitigate

mengurangi risiko

How do you say: "mengurangi risiko deployment"?

reduce the deployment risk
mitigate the deployment risk

You want to suggest feature flag because it reduces deployment risk.
Say it in English.

I suggest we put this behind a feature flag to reduce the deployment risk.

The main risk is...
This reduces the risk of...
I'm worried about the risk of...

deploy to staging
deploy to production
deploy it behind a feature flag

Could you clarify that?
Let me clarify my point.
Just to clarify, are we talking about production?

I'm blocked by...
I don't have any blockers.
This is a blocker for the release.

The impact is...
This impacts checkout.
This has no user impact.

The main issue is that...
This happens because...
The impact is...
My concern is that...
I suggest we...
The trade-off is...
Based on the risk, we should...
Let me summarize...

The main issue is that the service times out under load.
This happens because the connection pool is too small.
The impact is that some checkout requests fail.
My concern is that the rollback path hasn't been tested.
I suggest we deploy this behind a feature flag.
The trade-off is faster delivery versus higher operational risk.
Based on the risk, we should postpone the deployment.
Let me summarize the decision and next steps.

You are blocked because the API contract is unclear.

I'm currently blocked by...
I need clarification on...
The expected behavior is unclear.

I'm currently blocked by the API contract. I need clarification on the expected response when the user is inactive. Once that's clear, I can finish the implementation.

A teammate's PR works, but you see an edge case.

This looks good overall.
One concern I have is...
What happens if...?
Could we add a test for...?

This looks good overall. One concern I have is the edge case where the input is null. What happens in that case? Could we add a test for it?

Team wants to deploy, but rollback is not tested.

I see why we want to...
My concern is...
It might be safer to...

I see why we want to deploy today, but my concern is that the rollback path hasn't been tested yet. It might be safer to validate that first before releasing to production.

The issue is the timeout.
The issue is the timeout in the payment service.
The issue is the timeout in the payment service after the deployment.
The issue is that the payment service started timing out after the deployment.

My concern is the rollback.
My concern is the rollback strategy.
My concern is that the rollback strategy hasn't been tested.
My concern is that the rollback strategy hasn't been tested in staging yet.

I suggest we delay.
I suggest we delay the deployment.
I suggest we delay the deployment until the rollback path is tested.

I want to say that the problem is coming from the configuration that is different between staging and production.

The issue might be caused by a config difference between staging and production.

Maybe we need to make the deployment not for all users first.

Maybe we should roll this out gradually.

I am not really agree because this can make the service more difficult to maintain.

I'm not fully convinced because this could make the service harder to maintain.

Can you explain me about how this function works?

Could you walk me through how this function works?

Level 2 untuk semua function utama, Level 3 untuk scenario kerja paling sering.